Bug 4818

Summary: 3c590 does not work with new kernel, no errormessages
Product: Drivers Reporter: Matthias Noe (a9931078)
Component: NetworkAssignee: Jeff Garzik (jgarzik)
Severity: blocking CC: kernel, tg42
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.12 Tree: Mainline
Regression: ---
Attachments: Debug output of the driver with 2.6.11 kernel
Debug output of the driver with 2.6.12 kernel
ifconfig output with 2.6.11 kernel
ifconfig output with 2.6.13 kernel
/proc/interrupts from 2.6.11
/proc/interrupts from 2.6.13
lspci output with 2.6.11 kernel
lspci output with 2.6.13 kernel
/proc/stat from 2.6.11
/proc/stat from 2.6.13

Description Matthias Noe 2005-06-29 15:03:50 UTC
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
Comment 1 Matthias Noe 2005-06-29 15:05:34 UTC
Sorry, forgot to add that I also tried the latest 2.6.13-rc1 kernel, which 
produces the same problem.
Comment 2 Thomas 2005-09-22 04:19:41 UTC
This problem still persists on kernels up to, 2.6.11.x is the last
working kernel.

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.
Comment 3 Thomas 2005-09-22 16:08:12 UTC
Created attachment 6095 [details]
Debug output of the driver with 2.6.11 kernel
Comment 4 Thomas 2005-09-22 16:08:58 UTC
Created attachment 6096 [details]
Debug output of the driver with 2.6.12 kernel
Comment 5 Thomas 2005-09-22 16:10:00 UTC
Created attachment 6097 [details]
ifconfig output with 2.6.11 kernel
Comment 6 Thomas 2005-09-22 16:10:31 UTC
Created attachment 6098 [details]
ifconfig output with 2.6.13 kernel
Comment 7 Thomas 2005-09-22 16:11:14 UTC
Created attachment 6099 [details]
/proc/interrupts from 2.6.11
Comment 8 Thomas 2005-09-22 16:12:01 UTC
Created attachment 6100 [details]
/proc/interrupts from 2.6.13
Comment 9 Thomas 2005-09-22 16:12:58 UTC
Created attachment 6101 [details]
lspci output with 2.6.11 kernel
Comment 10 Thomas 2005-09-22 16:13:41 UTC
Created attachment 6102 [details]
lspci output with 2.6.13 kernel
Comment 11 Thomas 2005-09-22 16:14:15 UTC
Created attachment 6103 [details]
/proc/stat from 2.6.11
Comment 12 Thomas 2005-09-22 16:14:45 UTC
Created attachment 6104 [details]
/proc/stat from 2.6.13
Comment 13 Daniel Drake 2005-10-03 06:11:38 UTC
Downstream bug report: http://bugs.gentoo.org/107861
Comment 14 Thomas 2006-03-21 01:18:26 UTC
The bug still persists in 2.6.16-rc6 as well as in  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.
Comment 15 Thomas 2007-04-26 13:19:19 UTC
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.
Comment 16 Thomas 2007-04-26 13:40:09 UTC
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

vortex_error(), status=0x6005
Transmit error, Tx status register 90.

repeating 3 times, the NIC is shut down with

vortex_close() status 6000, Tx status 00.
Comment 17 Daniel Drake 2007-04-29 07:11:34 UTC
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.

Comment 18 Matthias Noe 2007-04-30 00:33:50 UTC
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!
Cheers, Matthias
Comment 19 Daniel Drake 2007-04-30 05:16:25 UTC
OK. If you are able to reproduce this in future, please reopen this bug.