Bug 65834

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.

any news?

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/