3c59x went nuts between .15-mm3 and .15-mm4

3c59x went nuts between .15-mm3 and .15-mm4

[J.A. Magallon]

[-- Attachment #1: Type: text/plain, Size: 3143 bytes --]

Hi all...

I can't use 2.6.15-mm4 on one of my boxes because it renders the 3Com NIC
broken. No network connection. This is a 3c905C-TX/TX-M [Tornado] (rev 74).
On one other box, I have a 3c980-C 10/100baseTX NIC [Python-T] (rev 78),
driven also with 3c59x, that goes also deafmute.
I have seen the changes between -mm3 and -mm4, and looks like a rewrite
to use mii instead of homebrew code (btw, should not this increase the
driver version number ?). But something there broke (or, as usual, some
change in ACPI...).

This is relevant dmesg diff between both kernels:

 process `syslogd' is using obsolete setsockopt SO_BSDCOMPAT
 ACPI: PCI Interrupt 0000:04:02.0[A] -> GSI 18 (level, low) -> IRQ 169
 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
-0000:04:02.0: 3Com PCI 3c905C Tornado at f0946000. Vers LK1.1.19
+0000:04:02.0: 3Com PCI 3c905C Tornado at f099c000. Vers LK1.1.19
                                          ^^^^^^^^ Uh ?
 PCI: Setting latency timer of device 0000:04:02.0 to 64
 ACPI: PCI Interrupt 0000:04:02.0[A] -> GSI 18 (level, low) -> IRQ 169
 e100: Intel(R) PRO/100 Network Driver, 3.4.14-k4-NAPI
 e100: Copyright(c) 1999-2005 Intel Corporation
-ACPI: PCI Interrupt 0000:04:04.0[A] -> GSI 16 (level, low) -> IRQ 209
+ACPI: PCI Interrupt 0000:04:04.0[A] -> GSI 16 (level, low) -> IRQ 201
 PCI: Setting latency timer of device 0000:04:04.0 to 64
-e100: eth1: e100_probe: addr 0xe1100000, irq 209, MAC addr 00:30:48:22:B6:57
+e100: eth1: e100_probe: addr 0xe1100000, irq 201, MAC addr 00:30:48:22:B6:57
 e100: eth1: e100_watchdog: link up, 100Mbps, full-duplex
 Intel(R) PRO/1000 Network Driver - version 6.1.16-k2
 Copyright (c) 1999-2005 Intel Corporation.
...
+NETDEV WATCHDOG: eth0: transmit timed out
+eth0: transmit timed out, tx_status 00 status 8000.
+  diagnostics: net 0cfa media 8880 dma 000000a0 fifo 8800
+  Flags; bus-master 1, dirty 83(3) current 99(3)
+  Transmit list 3eb1f3e0 vs. eeb1f3e0.
+  0: @eeb1f200  length 8000002a status 0000002a
+  1: @eeb1f2a0  length 8000002a status 8000002a
+  2: @eeb1f340  length 8000002a status 8000002a
+  3: @eeb1f3e0  length 8000002a status 0000002a
+  4: @eeb1f480  length 8000002a status 0000002a
+  5: @eeb1f520  length 8000002a status 0000002a
+  6: @eeb1f5c0  length 8000002a status 0000002a
+  7: @eeb1f660  length 8000002a status 0000002a
+  8: @eeb1f700  length 8000002a status 0000002a
+  9: @eeb1f7a0  length 8000002a status 0000002a
+  10: @eeb1f840  length 8000002a status 0000002a
+  11: @eeb1f8e0  length 8000002a status 0000002a
+  12: @eeb1f980  length 8000002a status 0000002a
+  13: @eeb1fa20  length 8000002a status 0000002a
+  14: @eeb1fac0  length 8000002a status 0000002a
+  15: @eeb1fb60  length 8000002a status 0000002a
+eth0: Resetting the Tx ring pointer.

Any idea ?

TIA

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.15-jam4 (gcc 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1))

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 3c59x went nuts between .15-mm3 and .15-mm4

[Steffen Klassert]

The related patch had some (I think duplex related) 
issues with setting up certain NICs. It's reverted in 2.6.16-rc1-mm1.
I'm about to work out the problems of this patch.

The driver version did not increase since more than three years.
But perhaps it is a good idea to maintain the driver version. 

Steffen

On Thu, Jan 19, 2006 at 10:53:45PM +0100, J.A. Magallon wrote:
> Hi all...
> 
> I can't use 2.6.15-mm4 on one of my boxes because it renders the 3Com NIC
> broken. No network connection. This is a 3c905C-TX/TX-M [Tornado] (rev 74).
> On one other box, I have a 3c980-C 10/100baseTX NIC [Python-T] (rev 78),
> driven also with 3c59x, that goes also deafmute.
> I have seen the changes between -mm3 and -mm4, and looks like a rewrite
> to use mii instead of homebrew code (btw, should not this increase the
> driver version number ?). But something there broke (or, as usual, some
> change in ACPI...).
> 
...

Re: 3c59x went nuts between .15-mm3 and .15-mm4

[Andrew Morton]

Steffen Klassert <klassert@mathematik.tu-chemnitz.de> wrote:
>
> The driver version did not increase since more than three years.
> But perhaps it is a good idea to maintain the driver version. 

Just nuke it.  Per-driver versioning is pretty meaningless and we should
and do identify driver versions by the version of the top-level kernel
which contains them.

Re: 3c59x went nuts between .15-mm3 and .15-mm4

[Steffen Klassert]

On Thu, Jan 19, 2006 at 03:27:57PM -0800, Andrew Morton wrote:
> Steffen Klassert <klassert@mathematik.tu-chemnitz.de> wrote:
> >
> > The driver version did not increase since more than three years.
> > But perhaps it is a good idea to maintain the driver version. 
> 
> Just nuke it.  Per-driver versioning is pretty meaningless and we should
> and do identify driver versions by the version of the top-level kernel
> which contains them.

Well, I will remove it with the next patch series.

Steffen

Re: 3c59x went nuts between .15-mm3 and .15-mm4

[Matt Domsch]

On Thu, Jan 19, 2006 at 03:27:57PM -0800, Andrew Morton wrote:
> Steffen Klassert <klassert@mathematik.tu-chemnitz.de> wrote:
> >
> > The driver version did not increase since more than three years.
> > But perhaps it is a good idea to maintain the driver version. 
> 
> Just nuke it.  Per-driver versioning is pretty meaningless and we should
> and do identify driver versions by the version of the top-level kernel
> which contains them.

With all due respect, per-driver versioning in mainline may be
meaningless (and as you note, modinfo already carries the kernel
version in it), but as soon as it hits a vendor kernel, it means very
much, and is the primary method of denoting to a larger (and mostly
non-driver-developer) audience what hardware is supported, and what
critical (to the vendor) bugs have been addressed.

And some tools, such as DKMS, make explicit use of the MODULE_VERSION
tag to automate updating individual drivers without necessarily changing out the
whole vendor kernel.  Once the vendor kernel "catches up" with the
equivalent driver, DKMS won't replace it any more.  All of the drivers
critical to Dell are separately versioned exactly for this reason, and
those tags are in the code submitted to mainline.  (3c59x isn't in
that category I admit).

Thanks,
Matt

-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com