Andrey Savochkin wrote:
> On Sat, Jun 03, 2000 at 04:27:30PM +0200, Anders K. Pedersen wrote:
> > 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?
>
> First of all, you should consider your system configuration (namely,
> freepages settings) to not to put the system into such out-of-memory
> situations.
We'll try this.
> When it comes to your lock up, both of your cards (epic100 and eepro100) are
> suffering from OOM. I would bet that it's epic100 that hangs in such a
> situation, because I debugged eepro100 for such cases very carefully, but
> haven't heard about somebody doing it for epic100. If your configuration
> allows you to test the system with only eepro100 cards (one or two), or with
> only epic100, the results would be interesting.
I have been running for a couple of days now, with the Intel driver
e100.c for the Intel EtherExpress Pro 100+ card instead of the
eepro100.c driver, without any lockups. Nothing else has changed - the
load is the same, and the system still runs short on memory, which now
causes the socks5 server processes to die or stop accepting more
connections. With the eepro100.c driver 3-4 hours of high load was
enough to make the machine lock up as described above.
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:23 EST