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. http://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))
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...).
>
...
Steffen Klassert <[email protected]> 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.
On Thu, Jan 19, 2006 at 03:27:57PM -0800, Andrew Morton wrote:
> Steffen Klassert <[email protected]> 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
On Thu, Jan 19, 2006 at 03:27:57PM -0800, Andrew Morton wrote:
> Steffen Klassert <[email protected]> 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 & http://www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com