Bug 65834 - RTL-8139 (rev 10) does not work on i486
RTL-8139 (rev 10) does not work on i486
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Garzik
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-06-01 22:58 EDT by Eugene Kanter
Modified: 2013-07-02 22:06 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:39:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eugene Kanter 2002-06-01 22:58:06 EDT
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.
Comment 1 Arjan van de Ven 2002-06-02 03:37:44 EDT
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 ?
Comment 2 Arjan van de Ven 2002-06-02 03:39:33 EDT
Also, does this box have a PS/2 interface ?
Comment 3 Eugene Kanter 2002-06-04 18:03:02 EDT
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....
Comment 4 Arjan van de Ven 2002-09-05 06:53:41 EDT
any news?
Comment 5 Eugene Kanter 2002-09-05 09:36:52 EDT
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.
Comment 6 Arjan van de Ven 2002-09-05 09:39:22 EDT
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 ;)
Comment 7 Bart Martens 2002-10-13 12:11:39 EDT
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.
Comment 8 Bart Martens 2002-10-31 11:13:51 EST
any news?
Comment 9 Mace Moneta 2003-05-26 23:28:53 EDT
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???

Comment 10 Mace Moneta 2003-05-27 08:27:41 EDT
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.  :-)
Comment 11 Bugzilla owner 2004-09-30 11:39:39 EDT
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/

Note You need to log in before you can comment on or make changes to this bug.