Re: Kernel oops with eepro100? Can this be confirmed?

Thank you for the pointers, and thank you for all the hard work on the
drivers.  I'll try your official driver and see if it makes a difference.  I
apologize for contacting you about a driver that has since deviated from
your code.

I realize that the evidence is circumstancial at best, but it's all I have
to go on.

It seems to me that if it were a user space process dereferencing a NULL
pointer, I'd get a segfault, not a kernel oops.  But I know nothing of these
things.

Thanks again,

Matt


----- Original Message -----
From: "Donald Becker" <[email protected]>
To: "Matthew Callaway" <[email protected]>
Cc: <[email protected]>
Sent: Wednesday, July 10, 2002 6:51 PM
Subject: Re: [eepro100] Kernel oops with eepro100? Can this be confirmed?


> On Wed, 10 Jul 2002, Matthew Callaway wrote:
>
> > I have a GNU/Linux distribution that runs on two different hardware
> > platforms.  One of them has a motherboard with two built in Intel
> > network interfaces that use the eepro100 driver, the other does not.
> > The platform using the eepro100 driver oopses about once a week under
> > little to no load.
>
> Try the driver at
>   http://www.scyld.com/network/eepro100.html
>      ftp://www.scyld.com/pub/network/eepro100.c
>
> > The boxes pass memtest86-3.0, which leads me to
> > believe that the culprit is the eepro100 driver.
>
> ... however there is little reason to believe that this problem is
> caused by the driver.
>
> > Can anyone confirm that this is possible based on the following output?
> >
> > This is a stock 2.2.20 kernel with the included eepro100 driver:
> >
> > static const char *version = "eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html\n"
>
> Grrrrr, that's not a real release number, and CESDIS was shut down years
> ago.
>
> > "eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V.
Savochkin <[email protected]> and others\n"
> > "eepro100.c: VA Linux custom, Dragan Stancevic <[email protected]>
2000/11/15\n";
>
> ...with many unsupported modifications.
>
> > Jul 10 12:41:49 hostname kernel: Unable to handle kernel NULL pointer
> > Jul 10 12:41:49 hostname kernel: current->tss.cr3 = 05688000, %cr3 =
05688000
> > Jul 10 12:41:49 hostname kernel: *pde = 00000000
> > Jul 10 12:41:49 hostname kernel: Oops: 0002
> > Jul 10 12:41:49 hostname kernel: CPU:    0
> > Jul 10 12:41:49 hostname kernel: EIP:    0010:[sys_open+100/148]
>
> That's not a valid instruction pointer.  This looks more like a process
> is trying to exect a NULL function deference, which isn't likely caused
> by the driver.
>
> --
> Donald Becker [email protected]
> Scyld Computing Corporation http://www.scyld.com
> 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters
> Annapolis MD 21403 410-990-9993
>
>