From: becker@super.org (Donald J. Becker) Subject: Re: TCPIP occasionally causes sy.. Date: 29 Mar 1993 04:01:42 GMT
In article <7ebc0154%fido.de@p100.f2003.n241.z2.fidonet.org> Damien_Neil@p100.f2003.n241.z2.fidonet.org (Damien Neil) writes:
>I am running linux kernel version 0.99p7 with v0.69 8390 drivers and v0.50
>ne drivers. (Those should be the latest versions of the network software.)
>Occasionally, during periods of high net activity, my entire system will
>freeze. The cursor continues to blink, but I cannot type or switch VTs, and
>all programs appear to seize up.
Those aren't the latest versions. (BTW, until yesterday the version
number was the day of the year.) The most recent versions are at
usra.edu:/pub/linux/newether/*
or on ftp.super.org. Please try that version and see if the probem
persists.
>I am using a 486SX/25 with 4MB memory, a 125MB IDE hard drive, and a
>Cabletron E1000 ethernet card. I have a Soundblaster Pro; but I tried
>removing it and the problem persisted.
The Cabletron E10*0 series ethercards have proven particularly
troublesome, and Cabletron hasn't provided programming information.
(It's not that they've refused, but rather that they have repeated
said "we'll get back to you" since Dec. 12! Funny, organizations like
that usually have "Open" in their names.)
>I tried compiling the kernel with EI_DEBUG set to 5. This results in a
>huge number of status reports flooding my screen. While running the debug
>kernel, I was able to reproduce the system hang. The final set of reports
>follow the formatx:
> eth0: interrupt(isr=0xXX).
>where XX is a number. From two seperate trials, the final ten numbers
>reported were:
>
>Trial 1: 42 42 01 01 01 01 42 01 41 41
>Trial 2: 42 01 01 42 01 01 42 01 42 01
These are normal values for the 8390's Interrupt Status Register (isr).
#define ENISR_RX 0x01 /* Receiver, no error */
#define ENISR_TX 0x02 /* Transmitter, no error */
#define ENISR_RDC 0x40 /* remote dma complete */
The "remote DMA complete" status doesn't mean a lot in this case.
>Does anyone have any idea as to what the problem is? I have tried everthing
>I could think of, and am at a loss. I know that there are people using the
>same type of card on the same network as myself who have no problems.
This is what's so frustrating about debugging some problems remotely
-- it's not obvious that it is the device driver rather than some
unusual interaction between your hardware. If your ethercard has some
jumper for alternate bus timing, you should try that. What chipset is
on your motherboard? I think some C&T chipset and Compaq boards are
known to be nonstandard.
-- Donald Becker becker@super.org Supercomputing Research Center 17100 Science Drive, Bowie MD 20715 301-805-7482