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 acpi=off. 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 2.6.13.2, 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.
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 2.6.15.6. 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 slightly: - 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. dev->watchdog_timeo=500 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 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.
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. http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.12-rc2.tar.bz2
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
OK. If you are able to reproduce this in future, please reopen this bug.