> > While doing:
> >
> > rsh klimt cat /dev/kmem >/dev/null
> >
> > from another linux machine the following appeared in the syslog of klimt:
> >
> > Unable to handle kernel paging request at virtual address c4805000
> > current->tss.cr3 = 03c0c000, `r3 = 03c0c000
> I can confirm this. The oops can be reproduced deterministically with
> 2.0.32. And it seems not to be dependent on the network card/driver,
> besides EtherExpress Pro 10/100 also machines with 3c509 or 3c905
> seem to fail similarly.
Ah, this has of course nothing to do with the network or with the fact
that you do it from another Linux machine. Reading /dev/kmem is nowadays
a bad thing because of the f00f bug fix: accessing the lower page of the
moved idt causes a page fault which the kernel is unable to handle ...
Maybe the lower idt page should be treated in this context somewhat
similarly as page zero on Intel and SPARC.
However, there is certainly something in 2.0.32 which causes first
"Unable to handle kernel paging request" and to total lockup later.
This seems to happen under heavy network load and only with machines
with more than one network interface. Maybe this is related to what
Doug Paul (dbp@dragonsys.com) reported a few days ago about ipfw.
Petri Kutvonen University of Helsinki kutvonen@cs.Helsinki.FI
Department of Computer Science +358 9 708 44216