Ahoj,
pouzivame v nasi siti WRR (weight round robin) jako perfektni a vyvazeny shaper.Bohuzel snim budeme muset skoncit.Prisli jsme na chybu,ktera neprimo diky WRR vyhodi kernel panic.
Od autora programu mame toto vyjadreni:
Nope, I have no idea about where the problem is. Some months ago I spend a few hours looking at the source code but did not find any problems. I have never experienced the problem myself but I havn't used the program for at least a year now.
A nas admin mi sdelil:
S kolegou jsme se dostali tak daleko, ze jsem porovnavali Cckovy zdrojaky kernelu s prelozenym asembelerem a dohledali misto, kde ta chyba vznika. Misto jsme nasli, vime cim to je, ale nevime proc k tomu dochazi.Kernel pada na hubu v uplne jinem miste, ktere "na prvni pohled" s wrr nijak nesouvisi.
Bohuzel vic siti reportovalo tento problem s padanim...pokud by se vtom nekdo chtel vrtat byl bych mu vdecen.WRR je opravdu za tech par mesicu velmi dobry shaper...bohuzel ma tuto neprijemnou chybu.
Kernel 2.4.25, patche - IMQ, IMQ NAT Support, ESFQ, IPP2P, CONNMARK a WRR. Konfigurace v priloze (teda pokud se podari pred odeslanim prispevku prilozit).
Problem dle vseho souvisi s pouzitim IMQ a WRR soucasne. Vstupni shapping resime standardne, tj. pomoci IMQ "interfejsu", krome root jsou jeste vytvoreny dve tridy (dva typy uzivatelu), kazda trida ma jistou garantovanou rychlost a sve maximum (shapping resen pomoci HTB) a prave scheduler pro tyto tridy je WRR.
Co jsem pochytil v ruznych konferencich, tak problem vznika ve chvili "utoku", resp. ve chvili kdy ma WRR zarazovat pakety do jednotlivych front.
<moje domenka>
mnozstvi techto front je pevne dano pri konfiguraci coz mozna zpusobi nejakou chybu ve chvili, kdy prichazi vice paketu (vice ruznych IP), WRR pro ne nema volne fronty, dojde k vyjimce ktera mozna zpusobi nekorektni ukonceni modulu, nekoretkni uvolneni pameti, nekorektni odregistrovani tasku ze seznamu a nasledny 'kernel panic' (KP)
</moje domenka>
Na privatni email ti muzu poslat ksymoops toho tracebacku. Uz jsme porovnavali zdrojak kernelu (timer.c) s disasemblovanym kodem (timer.o) a zjistili jsme ze v procedure count_active_tasks dojde k nalezeni odkazu na neexistujici "task" a nasledne "sahnuti" do daneho mista pameti zkusobi onen KP :-( Tezko takto z toho usuzovat proc je v seznamu tasku najednou nekonzistence v odkazech mezi nimi samymi, ale takto toprimo na chybu WRR nevypada.
Zkusili jste 2.6.X? Ja mam na routeru novej kernel od myslim 2.6.2 a jeste ani jednou mi reouter nespadnul, sice na tom nic moc nebezi (oFTPd, jednoduchy WWW, bandwidthd, HostAP), ale stabilni mi to pripada dost, rozhodne to zkuste, nutnost je pouziti GCC verze 3.x, nejlepe 3.3, pro ktere je novy kernel optimalizovany i obracene. A mam P100@83 s 32MB RAM a routuju 2x wifi + 2Mb internet :-))
btw, existuje patch "kmsgdump" ktery napriklad umi dump ulozit na disketu (ze ktere to jde po rebootu precist), takze by slo nechat floppy v mechanice, pri problemu to zaloguje a vydumpuje, rebootne, skript to precte z fdd, tu vymaze a muze to spadnout znova :-)
20.10.2004 v 13:47
