eepro100 problems - was: Re: linux-2.4.0test1 through linux-2.4.0test1-ac2

From: Anders K. Pedersen (akp@akp.dk)
Date: Sat Jun 03 2000 - 09:27:30 EST


Christopher Zimmerman wrote:
> Andrey Savochkin wrote:
> > On Tue, May 30, 2000 at 06:29:56PM +0000, Christopher Zimmerman wrote:
> > > The system locks up after several of these messages. My test system has 2GB
> > > of sdram. I've tried alan's latest patches but the problem is still there.
> > > Due to AIC7XXX scsi issues I can't get ac5 up, though.
> >
> > Is it the whole system that locks up, or just the network?
> >
> > It may be a result of a missing timer_exit(), so, please, try the driver
> > from ftp://ftp.sw.com.sg/pub/Linux/people/saw/kernel/v2.3/

> Yes, the hole system locks up. I've tested ac6 on a box which doesn't have an
> aic7xxx controller and the problem is no longer present. However, the kernel is not
> re-allocating cached pages properly. The system will literally run out of memory
> and freeze. I can see it just by watching top. Anyone should be able to recreate
> these crashes. All one has to do is really push the system hard with a memory
> intensive application.

We have a similar problem with the eepro100.c driver on kernel 2.2.15.
When the systems gets loaded and runs short on memory, the system locks
up - the only thing that still works is Emergency Sync and Reboot
through SysRq. The system has an epic100 as eth0, and an eepro100 as
eth1, and both of these run at 100 Mbit/s full duplex. I have tried
several different versions of the eepro100.c driver - including
1.20.2.3, 1.20.2.4, and we are currently running 1.20.2.10. Before we
got the eepro100 card, we used a 3c590 card at 10 Mbit/s half duplex,
but we had to upgrade because the 3c590 wasn't fast enough to send
outgoing packets, and eventually the system would run out of memory -
this however did not cause the system to lock up - the socks5 server
processes just got killed.

When the system locks up, a lot of messages are printed on the console,
but nothing gets written to the kernel log files, except for once, where
the messages in the attached kernel.log.1.gz were written. We redirected
the console output to a serial port, and captured it on another system -
this is attached as kernel.log.gz.

Is this a problem with the eepro100.c driver, or should I look
elsewhere?

Regards,
Anders K. Pedersen




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:17 EST