[OSy] Prepisovani navratove hodnoty TLBhandleru

[Jiri Tousek]

Ja assembler taky neovladal, ale byl jsem nucen se ho aspon trochu
naucit (pomohla referencni prirucka k MSIMu ze stranek predmetu).

Ovsem pokud se stroj zacykli a neskonci, tak se v tom bude cokoliv
hledat tezko...

Nejsem si uplne jisty, ale mozna jsme meli podobny problem - pokud si
to pamatuji dobre, taky se nam to kousalo za tlbrefill, ale kdyz jsme
na konec dali ladici tisk, proslo to. Nakonec jsme zkusili na konec
dat jednu instrukci (nop, ale poslouzi treba preddefinovana
___trace_off() ) a od te doby nam to chodi bez problemu porad.
Planujeme ji zkusit zase vyhodit, jestli to bude porad zpusobovat
chybu, je tam uz dlouho. Ale mame za to, ze by tam mozna mohl byt
problem s branch delay slotem (tohle je ale jedna z veci, ktere jsme
zatim nemeli cas dukladne prozkoumat, tak se spokojime s tim, ze nam
to zatim ve 100% pripadu funguje).

Jiri Tousek

On 12/4/06, Katerina Dufkova <dkatka at seznam.cz> wrote:
> Dobry den,
> uz dva dny resime pomerne zavazny problem, a uz si opravdu nevime rady, proto se opet obracime na konferenci.. Zda se ze v kernelu mame nejakou funkci, ktera prepisuje pamet, kterou prepisovat nema. Vec se projevuje takto: test bezi v pohode a pak dojde k vyvolani TLBREFILL, ta je korektne obslouzena. Vypisujeme do logu hodnoty ktere se nasly ve strankovacich tabulkach a ty jsou spravne, navic se vykona i posledni prikaz obsluhy, kterym je take ladici vypis. Pak vypocet skonci a zadny prikaz za prikazem, ktery vyjimku vyvolal, uz se nikdy neprovede. Zda se jako bychom si prepsali navratovou hodnotu z TLBREFILL nebo tak neco. Nenapada me nic na co by se tam jinak melo cekat. Zadna chybova hlaska z msimu se neobjevuje. V TLBREFILL jsme (az po objeveni problemu, kvuli jeho snazsi lokalizaci) pridali zakaz preruseni na zacatek handleru a preruseni povolime az na konci handleru, takze jsme si mysleli, ze pokud v okamziku kdy se do handleru dostaneme je vse ok, tak zkazit to mohla
>  jen funkce volana v handleru. Ty jsme kontrolovali, ale pricinu jsme nenasli. Jeste je divne, ze nekdy se kousne hned prvni TLBREFILL, nekdy druhy, nekdy jiny, nekdy zadny...
>
> Problem je asi predevsim v tom, ze chyba je dosti nahodna v tom smyslu, ze pridanim ladicich vypisu se nekdy zase ztrati, test projde a tedy je pro nas opravdu vellky problem zjistit, kdy jsme chybu odstranili a kdy jsme to spravili jen "na oko" tim, ze se kod prodlouzil nebo zkratil, a za chvili se chyba objevi zase.
>
> Nevim jestli to s tim souvisi, ale meli jsme jeste druhou chybu souvisejici s TLBREFILL, totiz ze behem hledani ve strankovacich tabulkach doslo k dalsi TLBREFILL a tim k zacykleni. Tuhle chybu jsme sice zda se nejak odstranili, ale je mozne ze jde o totez, totiz ze nam nekdo nekde prepisuje pamet, a jen se ted netrefuje do pointru na second-level strankovaci tabulky ale nekam jinam.
>
> Je mi jasne, ze konkretni odpoved kde je problem asi nedostaneme, ale presto budeme vdecni za kazdy postreh. Mozna mame stejny problem (a timto se omlouvam, ze se mozna ptam na totez) jako kolegove ze skupiny Jirky Touska. Ovsem vzhledem k tomu, ze v nasi skupine neni nikdo kdo by ovladal assembler, je pro nas cesta hledani chyby v tom logu a cteni onoho assemblerovskeho kodu, o kterem se zminoval, opravdu neschudna.
>
> Jeste poznamka na konec - projdeme testem malloc1, testem area1 pouze nekdy (pokud mame zrovna "spravnou delku kodu"). Ostatni testy nejsou u nas uspesne vubec nikdy. Pridani "polstare" za kernel_end nepomohlo, nebo "polstar" nemel spravnou velikost.
>
> S pozdravem
>                                Katka Dufkova
> _______________________________________________
> OSy mailing list
> OSy at nenya.ms.mff.cuni.cz
> http://nenya.ms.mff.cuni.cz/mailman/listinfo/osy
>