Description of Problem: RTL-8139 (rev 10) card properly detected but speed is about 10kb/sec on 100BT switched network. Tested using wget from http server on a local network. Console full of following messages: eth0: Too much work at interrupt, IntrStatus=0x0040 Version-Release number of selected component (if applicable): This is a fresh install of RH 7.3, no updates. Additional Information: lspci -vn 00:13.0 Class 0200: 10ec:8139 (rev 10) Subsystem: 1186:1301 Flags: bus master, medium devsel, latency 64, IRQ 12 I/O ports at ec00 [size=256] Memory at e8000000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 Swapped the card with another (tulip driver) from AMD k6-3 400 based box - both systems work fine. Seems like the RTL card is fine but driver has problems on 486 hardware.
Could you try using the module parameter "max_interrupt_work" and set it higher than the default of 20? Eg modprobe 8139too max_interrupt_work=200 or so ?
Also, does this box have a PS/2 interface ?
This box might have PS/2 interface but it is not used. No PS/2 devices connected. I'll have to swap network cards again, it might take a while....
any news?
It is somewhat complicated to bring that 486 back to test condition right now. I'll try to do my best during next couple of days.
if it works right now I wouldn't bother (and if the hw is retired, same thing); 80486's are not the most common pieces of hw nowadays ;)
I have the same message "Too much work at interrupt, IntrStatus=0x0040" appearing in /var/log/messages. The machine is a i586, the Red Hat version is 8.0, and the package containing the 8139too.o file is kernel-2.4.18-14. I can easily reproduce this problem at any time by using scp. Copying small files with scp is no problem. As soon as the transferred data is bigger, let's say, 60 kilobytes, then the transfer slows down and the error message appears in /var/log/messages. Oct 13 17:38:20 cable-195-162-214-146 kernel: eth1: Too much work at interrupt, IntrStatus=0x0040. Oct 13 17:39:35 cable-195-162-214-146 last message repeated 16 times Oct 13 17:41:56 cable-195-162-214-146 last message repeated 16 times You suggested to try "modprobe 8139too max_interrupt_work=200". Unfortunately, this did not help. On another machine, a i686, also having a Realtek 8139, all seems to be working fine. In /proc/pci : "Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C (rev 16).". On the i586, having the problem, /proc/pci says "Class ffff: Realtek Semiconductor Co., Ltd. RTL-8139/8139C (rev 255).". I'm talking about 2 nic's here, I have not moved the nic between the machines. Feel free to ask me more information, or to test various things you want to see tested. I can keep this test setup available for a while.
I'm running Redhat 9, with the 2.4.20-13.9smp kernel (dual Pentium Pro 200Mhz). I have a card using the 8139too driver: # lspci -vvv 01:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: AFAVLAB Technology Inc: Unknown device 8139 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR+ Latency: 64 (8000ns min, 16000ns max) Interrupt: pin A routed to IRQ 18 Region 0: I/O ports at e800 [size=256] Region 1: Memory at f0cff800 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- I have increased the max_interrupt_work; tried: 256, 512, 1024, 4096, 32767 (I like round numbers :-). All have the same result, though progressively improved and longer transfer before reporting "eth0: Too much work at interrupt, IntrStatus=0x0040". The problem only occurs when transferring large files (50MB+, for example). Any other suggestions besides increasing the max_interrupt_work? /etc/modules.conf: alias eth0 8139too options 8139too irq=18 max_interrupt_work=32767 ifconfig eth0, showing no errors with small transfers: eth0 Link encap:Ethernet HWaddr 00:01:08:00:0B:99 inet addr:135.82.8.136 Bcast:135.82.8.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3195 errors:0 dropped:0 overruns:0 frame:0 TX packets:3043 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 RX bytes:296838 (289.8 Kb) TX bytes:398164 (388.8 Kb) ifconfig eth0, showing errors on a single large transfer: eth0 Link encap:Ethernet HWaddr 00:01:08:00:0B:99 inet addr:135.82.8.136 Bcast:135.82.8.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:12639 errors:1288 dropped:9 overruns:1288 frame:0 TX packets:6933 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 RX bytes:13446920 (12.8 Mb) TX bytes:707103 (690.5 Kb) Eventually, the "eth0: Too much work at interrupt, IntrStatus=0x0040" errors will start showing up in the syslog. Perhaps the problem is in the error handling???
I was able to reduce the occurrence of this error further, by increasing the latency timer for the device: setpci -s 01:08.0 latency_timer=ff lspci -vvv -s 01:08.0 01:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: AFAVLAB Technology Inc: Unknown device 8139 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR+ Latency: 255 (8000ns min, 16000ns max) Interrupt: pin A routed to IRQ 18 Region 0: I/O ports at e800 [size=256] Region 1: Memory at f0cff800 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- With this setting (in addition to max_interrupt_work=32767), I see less than one occurrence of the message per gigabyte of data transfer. Note that the error rate (overruns) remains in the 24-25% range with large transfers (rsync iso images, in my testing). The CPU resources required are likely exceeding the capacity of the processors used (200MHz in my case). I think this is about as tuned as it is going to get. :-)
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/