(obs:long mail) problems with Rlt8139.o - interrupt line blocked, transmit timeout...

[Ricardo Dotta]

Greetings,


I work for a brazilian software house. We are expanding our network to a new
floor, using a Linux machine as a gateway for TCP/IP, IPX (in order to our
new subnet to see our Novell server) and a WINS server, via a new ethernet
card we installed, model Encore ENL832-TX. I am using a Linux driver of
yours (version 1.08a) for the chipset Realtek 8139. The subnet has 9
machines connected, running win95/98 with various ethernet cards. All worked
fine in the old nets. All cards are 10BaseT, except one newly installed
because the old card had no RJ-45 connector ( this card is the same encore
card - not properly tested in the win95 machine). The hub is a 10/100 16
ports Surecom. My kernel version is 2.0.36, RedHat distribution. The Linux
computer (a Pentium 133 with 64MB) is a e-mail, html, SMB server, and we
experienced no troubles till we plugged this new PCI card to connect the new
subnet with our existing ones. The card worked perfectly with your driver
1.07 in our tests for our TCP/IP, IPX and Windows networks, till real work
was done in the new subnet. Then Linux crashed. We got your new version
1.08a, and submitted the card to what we think was a real test (8 machines
trying to get 400MB at the same time from our Novell server in another
subnet), and again everything seemed ok. But when real work was done Linux
crashed again in a very similar way. The messages it displayed were more or
less like this (the order of the messages isn't exactly right):

ide 0: reset: sucess
eth2: RTL8139 interrupt line blocked, status 5
hda: irq timeout: status 0x50 {Drive ready Seek complete}
hda: irq timeout: status 0x50 {Drive ready Seek complete}
hda: irq timeout: status 0x50 {Drive ready Seek complete}
hda: irq timeout: status 0x58 {Drive ready Seek complete Data request}
eth2: Tx queue start entry 8 dirty entry 4, full
hda: irq timeout: status 0x50 {Drive ready Seek complete}
eth2: transmit timeout, status 0d 0004 media 00
eth2: transmit timeout, status 0c 0005 media 00
eth2: RTL8139 interrupt line blocked, status 4
end request: i/o error, dev 03:02, sector 213004
ext2fs error (device 03:02): ext2_write_inode: unable to read inode block -
inode 26225, block 106504
eth2: transmit timeout, status 0c 0005 media 00
eth2: Tx queue start entry 8 dirty entry 4, full


The computer could only be brought to life via a cold restart. Then
ext2.fsck only complained about /dev/hda3, mounted as /var. We used
"badblocks" in our partitions, but all were clear. Besides, we never got a
problem with the HDD (despite its huge load) until the new subnet was made
active.

We thought the problem could be our IPX router daemon (IPXRIPD), but Linux
crahed again when copying large amounts of data via NetBios over IP, even
with IPX down. The only similarity between the situations was that we were
copying FROM our new subnet TO our old ones. In our succesful test we were
copying large amounts of data TO our new subnet FROM our old ones. The
problem could also be the time involved in this large loads. Our test lasted
about half an hour (we do not waited for all the files to be copied);
in real situations the load lasts longer.

I am really thankful you read all this. If the problem is really easy to
solve and I shoud not be bothering you, I am sorry for any incovenience and
lack of technical understanding.


Thanks for your attention,

   Ricardo Dotta

 | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the
 |  body of the mail, include only the text:
 |   unsubscribe this-list-name youraddress@wherever.org
 | You will be unsubscribed as speedily as possible.