Bug 84101 – 8139too driver not working in kernels 2.6.9 and above

• Status: RESOLVED UPSTREAM
• Product: Gentoo Linux

[Description basic 2005-03-04 08:28:37 UTC]

I've a "RTL8139D" (that's what it says on the chip on the card) PCI ethernet card that I find the 8139too driver not working with in kernels 2.6.9 and above. I've had it working with 2.6.8 and below (sending this with 2.6.8 right now).

Reproducible: Always
Steps to Reproduce:
1. boot into a 2.6.9/10/11 kernel with the driver loaded
2. try to ping something on the network

Actual Results:  
This is the output of syslog after ping failed:

NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timeout, status 0c 0005 c07f media 10.
eth0: Tx queue start entry 4  dirty entry 0.
eth0:  Tx descriptor 0 is 0008a03c. (queue head)
eth0:  Tx descriptor 1 is 0008a03c.
eth0:  Tx descriptor 2 is 0008a03c.
eth0:  Tx descriptor 3 is 0008a03c.
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1


Expected Results:  
transmit the ping

[Comment 1 Stefan Schweizer (RETIRED) 2005-03-04 08:51:33 UTC]

Can you please post emerge info and the lspci -v -v entry for your network controller?

[Comment 2 Daniel Drake (RETIRED) 2005-03-04 09:06:42 UTC]

And please *attach* the full dmesg output from 2.6.11

[Comment 3 basic 2005-03-04 10:27:00 UTC]

Created attachment 52666 [details]
emerge info

here's my emerge info. forgot to mention that I only tested using
gentoo-dev-sources

[Comment 4 basic 2005-03-04 10:33:04 UTC]

Created attachment 52667 [details]
lspci -v -v net card info

this is under 2.6.8, I've done the same under 2.6.11 and found that it uses a
different irq (5 rather than 11), and that irq is also used by the onboard
C-Media CM8338A, could that be causing the problem?

[Comment 5 basic 2005-03-04 11:02:16 UTC]

Created attachment 52673 [details]
part dmesg

from when module was loaded to failed pings under 2.6.11

[Comment 6 basic 2005-03-04 11:20:47 UTC]

ok after reslotting the card on to a different pci slot, it works as expected. The only noticable diff between the different slots is the irqs assigned (5 or 11).

So it would seem that the onboard sound chip (using irq 5) conflicted with the card. I'm not sure if this is a hardware issue or just the kernel's way of handing out irqs... 

This issue is solved for me, though I could slot the card into the original slot again to test if needed.

[Comment 7 Daniel Drake (RETIRED) 2005-03-12 14:07:06 UTC]

If you are willing to help debug this and you still have the problem with the latest release then I suggest you file a bug at http://bugzilla.kernel.org