Distribution: Gentoo (Base System 1.6.12)
Hardware Environment: Intel Celeron 2,6 Ghz, SiS 651 Chipset, 3com 3c590
(Vortex), nothing special
Software Environment: 3c59x kernel module
Problem Description: After booting the 2.6.12 kernel, my 3com 3c590 gets loaded
and initialised correctly, but I get no connection to nowhere. Dmesg suggests
booting with pci=routeirq which makes no difference. Also, there are no
errormessages during boot or in dmesg.
This problem is not related to ACPI, because the same happens when I boot with
The problem first appeared with the 2.6.12 kernel, 2.6.11 works like a charm
(apart from a usb issue, which is fixed in 2.6.12. Therefore I would really love
to use the 2.6.12 kernel). I did not try any of the 2.6.12-rcs, so I cannot tell
when the problem got introduced.
Steps to reproduce: boot 2.6.12 kernel, try to access LAN.
If you need any other information, i will gladly provide it.
Thanks in advance,
regards Matthias Noe
Sorry, forgot to add that I also tried the latest 2.6.13-rc1 kernel, which
produces the same problem.
This problem still persists on kernels up to 188.8.131.52, 2.6.11.x is the last
Starting the driver in debug mode doesn't show anything but the correct
identification of the network link.
Neither inbound nor outbound packets get anywhere, ifconfig always shows packet
counters being 0.
Created attachment 6095 [details]
Debug output of the driver with 2.6.11 kernel
Created attachment 6096 [details]
Debug output of the driver with 2.6.12 kernel
Created attachment 6097 [details]
ifconfig output with 2.6.11 kernel
Created attachment 6098 [details]
ifconfig output with 2.6.13 kernel
Created attachment 6099 [details]
/proc/interrupts from 2.6.11
Created attachment 6100 [details]
/proc/interrupts from 2.6.13
Created attachment 6101 [details]
lspci output with 2.6.11 kernel
Created attachment 6102 [details]
lspci output with 2.6.13 kernel
Created attachment 6103 [details]
/proc/stat from 2.6.11
Created attachment 6104 [details]
/proc/stat from 2.6.13
Downstream bug report: http://bugs.gentoo.org/107861
The bug still persists in 2.6.16-rc6 as well as in 184.108.40.206. I compiled both
of these kernel on Sunday and the results didn't change since 2.6.12.
I furthermore noticed, that the problem only seems to occur when the NIC is
connected to a cheapernet cable (which seems to be less common nowadays ;-).
As soon as i connect the NIC to an (otherwise unconnected) 10baseT switch and
ping something, the counters shown by ifconfig increase.
The bug is still present in 2.6.17 (gentoo distro).
Meanwhile i have hooked up the NIC to a 10baseT hub and things have changed
- There are outgoing packets, the counter is incremented on every ping and the
LED on the hub blinks.
- These packets seem to be malformed, somehow. The destination machine does not
know the MAC address of the 3c590 NIC.
- There are no incoming packets.
dmesg show some debug messages:
Media 10baseT has link beat. (both LEDs are on, anyway)
Media selection timer finished, 10baseT.
Media selection timer tick happened, 10baseT.
After a while, the NIC seems to lose its IP address.
Maybe i should mention:
the module was loaded with
modprobe 3c59x debug=3 options=0x200 (or options=0 or none at all, same result)
The driver (this time from a 2.6.12 kernel) initializes with
0000:00:10.0: 3Com PCI 3c590 Vortex 10Mbps at 0xe800. Vers LK1.1.19
<MAC address>, IRQ 12
product code 4345 rev 00.0 date 02-18-96
Internal config register is 102001b, transceivers 0xe138.
64K word-wide RAM 1:1 RxTx split, autoselect/10baseT interface
0000:00:10.0: Media override to transceiver type 0 (10baseT)
0000:00:10.0: scatter/gather disabled, h/w checksums disabled
After the lines
Transmit error, Tx status register 90.
repeating 3 times, the NIC is shut down with
vortex_close() status 6000, Tx status 00.
Matthias, the kernel source code management tool (git) has a nice process for
tracking down the cause of regression bugs such as this one.
Unfortunately things are complicated slightly by the fact that the repository
was switched midway between 2.6.11 and 2.6.12, so we first need to figure out
which half of that period this bug was introduced in.
First could you test the latest kernel (2.6.21 or newer) and confirm that the
bug still exists there? If it's fixed, everything else would be a waste of time :)
Next, test version 2.6.12-rc2. The results from this test will tell us which
half of the history the bug was introduced in, then I can explain how to do the
git bisection to find the cause.
I am sorry, but I am not able to test this issue anymore because I changed the
system I am working on and I don't use this ethernet card anymore.
Anyways, keep up the good work!
OK. If you are able to reproduce this in future, please reopen this bug.