Padani stroje

[Dan Lukes]

On 01/14/13 16:09, Radek Krejča:
>> A nezapominej, ze to co jsem nabidnul je jen hypoteza. Muze to bejt
>> uplne vedle ...
>
> No, pali to me, ale jsou veci, ktere moc neovlivnim.

Tak to musi resit nekdo, kdo ma dostatecnou pravomoc na to, aby je 
ovlivnit mohl ;-)

> Spis mi rekni, protoze tady tyhle debug informace jsou pro me dost magie, na zaklade ceho jsi vybral tady zrovna ten zaznam? To jsi vzal proto, ze tusis, ze tam byl problem?

Pokusim se ti to popsat, ale otazka je, jestli to to pomuze. Cast z toho 
totiz spada do subjektivni kategorie "odhad".

Ten trace, kterej se pri panicu zobrazuje, je retezec procedur/funkci 
jak do nich byl program v dobe sveho padu zanoreny. Je "vzhuru nohama". 
Nekolik radku nahore uz ale nepatri do puvodniho programu - to uz kernel 
vedel, ze je prusvih a vidis tam funkce, ktere se podilely na vypisovani 
panicovych hlasek.

Najit tedy radek, ktery jeste byl soucasti puvodniho retezce je prvni 
odhad. Ten nebyva tak slozity, i kdyz asi to chce trochu vedet jak 
funguje procesor. Na obrazku, ktery jsi poslal je posledni "puvodni" 
funkce ta oznacena #5 - hloubeji (nizsi cisla) uz jsou "obsluha abendu".

Radek
#5 0xffffffff8060c05a turnstile_wait+01aa
[pak rika, ze problematicka instrukce byla na ofsetu 0x1aa pocitano od 
pocatku symbolu turnstile_wait. Symbolem je obvykle nazev funkce. Neni 
tak slozite grepem najit, ze funkce s timto nazvem existuje 
(sys/kern/subr_turnstile.c)

Bohuzel, znalost binarniho offsetu nevede jednoduse na schopnost 
rozpoznat konkretni radek zdrojoveho kodu te funkce.

Proto potrebujes pad "zazit" na kernelu ktery obsahuje debugovaci 
informace. Ten a coredump, ktery se pri padu vytvori (on se vytvori ve 
swapu a pri pristim restartu se z nej extrahuje a ulozi v podobe souboru 
na disk, coz mi pripomina, ze potrebujes nejen masinu s dieksm, ale taky 
swapem, jehoz velikost musi byt vetsi nez je velist pameti, kterou stroj 
ma). Takze zpet - ten coredump a kernel.debug umozni gdb, (ktere spustis 
uz po restartu) zobrazit informace ktere uz znas z vypisu pri panicu, 
jenze diky ulozenym debugovacim informacim tentokrat uz vcetne odkazu na 
jmena souboru a cisla radku. Dozvis se tak tedy primo odkaz na konkretni 
radek zdrojaku, kde doslo k chybe.

To ti znacne usnadni hledani v cem je problem. Obzvlast, kdyz ti do gdb 
umozni i to abyses podival na hodnoty konkretnich promennych.

No, a ted k hadani, kdyz nic takovyho nemas. Zacal jsem tim, ze jsme se 
docela obycejne Googlu zeptal na

"turnstile_wait em0 panic"

Tu 'em0' jsem vzal taky z tveho backtrace - frame #14 a #15 ukazuji, ze 
cely retezec je soucasti threadu, ktery zpracovava hardwarem prijate 
sitove pakety na em sitovce.

Hned prvni odkaz vede na popis podobneho panicu - sice nenastal v 
kontextu zpracovani paketu z nejake sitovky, ale, turnstile_wait() tam 
byl volan z funkce, ktera se zabyva zamkovanim. To u tebe taky (#6) byt' 
typ zamku zamku je jiny.

Samozrejme, ze to muze byt nahodna koincidence - obzvlast, kdyz 
predchozi popsany pripad je osm let stary. Ale je to to nejlepsi co v 
teto chvili mame.

I dal pokracujeme v loterii. Mluvis o 9.0-R coz je dost stara release. 
Vyslovme hypotezu, ze nejsi jediny kdo se s tim potkal, nekdo jiny byl 
ale uspesny pri hledani priciny a treba uz to je od te doby opraveno. 
Takze jsem se podival do zdrojakoveho stromu na zmeny, ktere v tomto 
kodu provedl nekdo po 9.0-R. A hle, dve nadejne zmeny tam provedeny jsou 
- a obe se tykaji problemu se zamkovanim.

I to nepochybne muze byt nahoda a mozna resi nejaky uplne jiny problem.

Ja bych vsadil. Stejne v tyhle chvili nemam lepsi alternativu.


Ale nevim, jestli ti tahle detailni popis "toku uvah" pomuze 
(mimochodem, popsat to trva o dost dele nez to puvodne udelat). Nektera 
rozhodnuti kudy se vydat pri reseni dal jsou opravdu otazkou "dojmu" a 
to je vec tezko neprenosna.

A navic, ta sazka nemusi vyjit. Duvod proc bych ji ja vyzkousel je ten, 
ze zkusit to je dost "lacine", pravdepodobnost, ze to neco zhorsi spise 
mala (navic, pokud mi to zacne po uprave padat v situacich, kdy to driv 
nepadalo, tak to vratim zpatky) - a jiny napad momentalne nemam. A 
zatimco budu hledat nejake jine/dalsi reseni, tohle uz se muze zkouset. 
A beztak to potrebuju restartovat na debugovaci kernel, no tak to uz to 
muze restartovat na kernel s upravou ...

Toz asi tak myslenky tekly.

Dan