Administrace komentářů

Bezva. Tak jsem to prozkoumal. Bylo to trošku komplikovanější, protože při přepisování Oopsu jste se buď musel několikrát splést a nebo byl systém v daleko horším stavu, než to na první pohled vypadalo, takže nebyl schopen Oops korektně vypsat. Očividné chyby jsou např.:

EIP is at rhine_interrupt+0270/0x605 [via-rhine]
...
EIP: [<de873a8a>] rhine_interrupt+0x270/0x608 SS:ESP 0068:c044ff3c

Jednou má funkce délku 0x605, podruhé 0x608. Správná hodnota je 0x605.

Code: ... r1 ...

Velmi zvláštní hexadecimální číslo.

Ten kód jsem podrobil detailnějšímu zkoumání. Napřed jsem v objektu via-rhine.o vůbec nemohl najít kus, který by tomu odpovídal, ale pak se přece jen něco objevilo. Ten kód je zhruba toto:

83 3d 80 70 87 de 06	cmpl   $0x6, 0xde877080
7e 1f			jle    +0x1f
89 f8			movl   %edi,%eax
# správně tady mělo být asi s/f8/d8/ a tudíž s/edi/ebx/
c1 fb 03		sarl   $0x3,%ebx
83 e0 0f		andl   $0xf,%eax
# myslím, že zde vypadla celá jedna instrukce:
# 83 e3 0f		andl   $0xf,%ebx
89 44 24 08		movl   %eax,0x8(%esp)
# a tahle je tu naopak navíc:
89 5c 24 08		movl   %ebx,0x8(%esp)
89 5c 24 04		movl   %ebx,0x4(%esp)
c7 04 24 c0 r1(!) 18 61	movl   $0x6118r1c0(!),(%esp)
# teď měl následovat call na printk a další instrukce,
# ale následující byty jsou naprosto mimo:
db 9c 82 a3 9b b0 90 <26> a1 df bd 6e ec
d6 ed ef 8a b4 d2 e7 e1 73 b5 2a 64 cc 5d b6

Prostě ten kód odpovídá programu v via-rhine.s od labelu ".L461:" dále. Jenže od toho volání printk dále už to vůbec jako ten správný kód nevypadá ani omylem. Ve zdrojáku je to tahle část funkce rhine_tx():

if (rp->quirks & rqRhineI)
	rp->stats.collisions += (txstatus >> 3) & 0x0F;
else
	rp->stats.collisions += txstatus & 0x0F;
if (debug > 6)
	printk(KERN_DEBUG "collisions: %1.1x:%1.1x\n",
	       (txstatus >> 3) & 0xF,
	       txstatus & 0xF);
rp->stats.tx_bytes += rp->tx_skbuff[entry]->len;
rp->stats.tx_packets++;

Takže jaké jsou možnosti:

• Byl jste velmi unaven a opsal něco úplně jiného.
• Poškození kódu má tentokrát opravdu na svědomí ten VMware.
• Pamět programu přepsalo něco úplně jiného. Zběsilý DMA přenos? Ale ten by se asi netrefil pokaždé do toho interrupt handleru, dokonce v různých verzích Linuxu.
• Vadná paměť. Taky nepravděpodobné, že by postihla vždycky stejnou funkci.
• Opravdu je nějaká chyba v tom přičítání statistik a to, že kód v Oopsu neodpovídá, není důležitá indicie. Zkuste tu část programu prostě zakomentovat. Nebudete dostávat statistiky o kolizích, ale koho by to trápilo.