Hi all...
I have just switched the network card for my internal network from a 8139
to a 3c905C-TX/TX-M. The 3c59x driver gives the buggy FF:FF:FF:FF:FF:FF
hardware address for the adapter. I had heard about the problem and looked
throug LKML archives, but they just point to a non existen web page.
I use 2.4.21-pre6+aa.
What happens ? Any solution available ?
Info:
werewolf:~# lspci -vx -s 00:12.0
00:12.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 74)
Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC Management NIC
Flags: bus master, medium devsel, latency 64, IRQ 5
I/O ports at ec00 [size=128]
Memory at febfef80 (32-bit, non-prefetchable) [size=128]
Expansion ROM at feba0000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
00: b7 10 00 92 17 01 10 a2 74 00 00 02 08 40 00 00
10: 01 ec 00 00 80 ef bf fe 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 b7 10 00 10
30: 00 00 ba fe dc 00 00 00 00 00 00 00 05 01 0a 0a
werewolf:~# modprobe 3c59x debug=4
/var/log/syslog:
Mar 28 15:45:05 werewolf kernel: 3c59x: Donald Becker and others. http://www.scyld.com/network/vortex.html
Mar 28 15:45:05 werewolf kernel: See Documentation/networking/vortex.txt
Mar 28 15:45:05 werewolf kernel: 00:12.0: 3Com PCI 3c905C Tornado at 0xec00. Vers LK1.1.16
Mar 28 15:45:05 werewolf kernel: ff:ff:ff:ff:ff:ff, IRQ 5
Mar 28 15:45:05 werewolf kernel: product code ffff rev ffff.15 date 15-31-127
Mar 28 15:45:05 werewolf kernel: Full duplex capable
Mar 28 15:45:05 werewolf kernel: Internal config register is ffffffff, transceivers 0xffff.
Mar 28 15:45:05 werewolf kernel: 1024K word-wide RAM 3:5 Rx:Tx split, autoselect/<invalid transceiver> interface.
Mar 28 15:45:05 werewolf kernel: Enabling bus-master transmits and early receives.
Mar 28 15:45:05 werewolf kernel: 00:12.0: scatter/gather enabled. h/w checksums enabled
Relevant dmesg:
3c59x: Donald Becker and others. http://www.scyld.com/network/vortex.html
See Documentation/networking/vortex.txt
00:12.0: 3Com PCI 3c905C Tornado at 0xec00. Vers LK1.1.16
ff:ff:ff:ff:ff:ff, IRQ 5
product code ffff rev ffff.15 date 15-31-127
Full duplex capable
Internal config register is ffffffff, transceivers 0xffff.
1024K word-wide RAM 3:5 Rx:Tx split, autoselect/<invalid transceiver> interfac
e.
Enabling bus-master transmits and early receives.
00:12.0: scatter/gather enabled. h/w checksums enabled
eth1: command 0x5800 did not complete! Status=0xffff
eth1: command 0x2804 did not complete! Status=0xffff
eth1: command 0x5800 did not complete! Status=0xffff
eth1: command 0x2804 did not complete! Status=0xffff
eth1: command 0x3002 did not complete! Status=0xffff
eth1: command 0x3002 did not complete! Status=0xffff
eth1: command 0x3002 did not complete! Status=0xffff
eth1: command 0x3002 did not complete! Status=0xffff
eth1: command 0x5800 did not complete! Status=0xffff
eth1: command 0x2804 did not complete! Status=0xffff
Any suggestion ?
--
J.A. Magallon <[email protected]> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.1 (Bamboo) for i586
Linux 2.4.21-pre6-jam1 (gcc 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk))
> I have just switched the network card for my internal network from a 8139
> to a 3c905C-TX/TX-M. The 3c59x driver gives the buggy FF:FF:FF:FF:FF:FF
> hardware address for the adapter. [...]
I've seen this on laptops (but never on desktops) when the PCMCIA card wasn't
seated properly-- the connectors wore out after too many plug/unplug cycles.
Something didn't work and it failed over to broadcast.
> Any suggestion ?
If all else fails, yank the card and reseat it.
-Eric
--
------------------------------------------------------------
Eric H. Weigle -- http://public.lanl.gov/ehw/
"They that can give up essential liberty to obtain a little
temporary safety deserve neither" -- Benjamin Franklin
------------------------------------------------------------
I'm running a later revision of that same NIC with no problems:
lspci:
00:09.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78)
Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC Management NIC
Flags: bus master, medium devsel, latency 32, IRQ 10
I/O ports at e000 [size=128]
Memory at e9000000 (32-bit, non-prefetchable) [size=128]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
dmesg:
3c59x: Donald Becker and others. http://www.scyld.com/network/vortex.html
See Documentation/networking/vortex.txt
00:09.0: 3Com PCI 3c905C Tornado at 0xe000. Vers LK1.1.18-ac
<HW address>, IRQ 10
product code 4b53 rev 00.3 date 01-13-97
Internal config register is 1800000, transceivers 0xa.
8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
MII transceiver found at address 24, status 782d.
Enabling bus-master transmits and whole-frame receives.
00:09.0: scatter/gather enabled. h/w checksums enabled
I'm runnning 2.4.21pre4-ac4. Looking at your dmesg output, it appears that your card
isn't being initialized correctly (e.g: the date field is bugus). I also noticed that my
NIC driver is a later revision than yours ( LK1.1.18-ac vs. LK1.1.16 )
Could you try booting 2.4.21pre4-ac4 and see if you have the same problem.
I'm assuming that you don't have any interrupt conflicts.
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
"J.A. Magallon" <[email protected]> wrote:
>
> Hi all...
>
> I have just switched the network card for my internal network from a 8139
> to a 3c905C-TX/TX-M. The 3c59x driver gives the buggy FF:FF:FF:FF:FF:FF
> hardware address for the adapter. I had heard about the problem and looked
> throug LKML archives, but they just point to a non existen web page.
> I use 2.4.21-pre6+aa.
>
> What happens ? Any solution available ?
>
The eeprom wasn't powered up.
Please take the 2.4.20 3c59x.c and place that into the 2.5 tree and confirm
that it does the same thing (it will).
Then try disabling APCI and/or otherwise fiddling with your power management
options (maybe in BIOS too).
One person has reported that turning off ACPI fixed this.
Thanks.
On 03.28, Andrew Morton wrote:
> "J.A. Magallon" <[email protected]> wrote:
> >
> > Hi all...
> >
> > I have just switched the network card for my internal network from a 8139
> > to a 3c905C-TX/TX-M. The 3c59x driver gives the buggy FF:FF:FF:FF:FF:FF
> > hardware address for the adapter. I had heard about the problem and looked
> > throug LKML archives, but they just point to a non existen web page.
> > I use 2.4.21-pre6+aa.
> >
> > What happens ? Any solution available ?
> >
>
> The eeprom wasn't powered up.
>
> Please take the 2.4.20 3c59x.c and place that into the 2.5 tree and confirm
> that it does the same thing (it will).
>
Hum, I suppose you want to say take the _2.5_ one and put into my _2.4_ tree ?
Some previous answer also talked about a more recent version in -ac.
(btw, can 2.5 be useful for something ? does not the driver depend on a new
arch of, for example, the PCI layer ? )
> Then try disabling APCI and/or otherwise fiddling with your power management
> options (maybe in BIOS too).
>
I don't build ACPI, just APM power-off (SMP box).
Will take a look at 2.4-ac (it looks like the most similar thing to what I have)
and to 2.5.
Thanks for your info.
--
J.A. Magallon <[email protected]> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.1 (Bamboo) for i586
Linux 2.4.21-pre6-jam1 (gcc 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk))
"J.A. Magallon" <[email protected]> wrote:
>
> > Please take the 2.4.20 3c59x.c and place that into the 2.5 tree and confirm
> > that it does the same thing (it will).
> >
>
> Hum, I suppose you want to say take the _2.5_ one and put into my _2.4_ tree ?
No, I didn't mean that. But you can do that too.
> Some previous answer also talked about a more recent version in -ac.
> (btw, can 2.5 be useful for something ? does not the driver depend on a new
> arch of, for example, the PCI layer ? )
The netdevice interface hasn't been broken yet ;) 2.4 drivers (or at least
3c59x.c) still work OK in the 2.5 tree.
> > Then try disabling APCI and/or otherwise fiddling with your power management
> > options (maybe in BIOS too).
> >
>
> I don't build ACPI, just APM power-off (SMP box).
Oh, OK.
As I say, it it probably power-management related. Try enabling ACPI. Try
disabling APM. Try altering the BIOS settings.
On Sat, 2003-03-29 at 00:05, J.A. Magallon wrote:
> > > What happens ? Any solution available ?
> >
> > The eeprom wasn't powered up.
> >
> > Please take the 2.4.20 3c59x.c and place that into the 2.5 tree and confirm
> > that it does the same thing (it will).>
>
> Hum, I suppose you want to say take the _2.5_ one and put into my _2.4_ tree ?
> Some previous answer also talked about a more recent version in -ac.
> (btw, can 2.5 be useful for something ? does not the driver depend on a new
> arch of, for example, the PCI layer ? )
>
> > Then try disabling APCI and/or otherwise fiddling with your power management
> > options (maybe in BIOS too).>
>
> I don't build ACPI, just APM power-off (SMP box).
> Will take a look at 2.4-ac (it looks like the most similar thing to what I have)
> and to 2.5.
I had exactly the same issue as you, but this time it was on my laptop
when using a 3CCFE575CT CardBus 10/100 NIC. The only solution I found
was to use SourceForge's PCMCIA-CS instead of the built-in PCMCIA
support.
I tracked down the problem to PCI resource allocation, although never
knew what was causing it: the CardBus bridge was using the PCI subsystem
to allocate resources for my CardBus NIC, but it failed and tried to
assign an invalid I/O range (the starting I/O address was higher than
the ending I/O address). I wasn't able to fix it, but in newer kernel
releases, the problem was fixed.
Now, I've got other problems: the card works correctly and I get full
throughput when sending data using FTP/NFS/SCP (~12MBps) but no more
than 4MBps when receiving files.
________________________________________________________________________
Felipe Alfaro Solana
Linux Registered User #287198
http://counter.li.org
Felipe Alfaro Solana <[email protected]> wrote:
>
> I had exactly the same issue as you, but this time it was on my laptop
> when using a 3CCFE575CT CardBus 10/100 NIC.
Don't think so. You were getting 0xff when reading all PCI registers. In
this case it is only the MAC address (which comes from an external eeprom)
which is coming up as 0xff.
0xff in the PCI regisers is a PCI setup problem, 0xff in the eeprom is a
power management problem.
(But the PCI IDs are read out of the eeprom into the PCI interface hardware
by the hardware. So the EEPROM must have been powered up and down again at
some point.)
On 03.29, Andrew Morton wrote:
> "J.A. Magallon" <[email protected]> wrote:
> >
> > > Please take the 2.4.20 3c59x.c and place that into the 2.5 tree and confirm
> > > that it does the same thing (it will).
> > >
> >
> > Hum, I suppose you want to say take the _2.5_ one and put into my _2.4_ tree ?
>
> No, I didn't mean that. But you can do that too.
>
> > Some previous answer also talked about a more recent version in -ac.
> > (btw, can 2.5 be useful for something ? does not the driver depend on a new
> > arch of, for example, the PCI layer ? )
>
> The netdevice interface hasn't been broken yet ;) 2.4 drivers (or at least
> 3c59x.c) still work OK in the 2.5 tree.
>
>
> > > Then try disabling APCI and/or otherwise fiddling with your power management
> > > options (maybe in BIOS too).
> > >
> >
> > I don't build ACPI, just APM power-off (SMP box).
>
> Oh, OK.
>
> As I say, it it probably power-management related. Try enabling ACPI. Try
> disabling APM. Try altering the BIOS settings.
>
I have an oldie 400GX. Just 'Enabled ACPI register' in the BIOS. But I did not
rebuilt the kernel to use ACPI. Anyways, I just got the patch for 3c59x from
-ac, and applied on mine, to upgrade to 1.1.18. Tests follow....
The 905C-TX does not work. I have tried with a couple more cards, a 905B and
a 980-TX. Both work (one older and one newer):
00:12.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 24)
Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100
Flags: bus master, medium devsel, latency 64, IRQ 5
I/O ports at ec00 [size=128]
Memory at febfef80 (32-bit, non-prefetchable) [size=128]
Expansion ROM at feba0000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 1
3c59x: Donald Becker and others. http://www.scyld.com/network/vortex.html
See Documentation/networking/vortex.txt
00:12.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xec00. Vers LK1.1.18-ac
<correct hw addr>, IRQ 5
product code 4e47 rev 00.9 date 03-15-98
Internal config register is 1800000, transceivers 0xa.
8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
MII transceiver found at address 24, status 7849.
Enabling bus-master transmits and whole-frame receives.
00:12.0: scatter/gather enabled. h/w checksums enabled
00:12.0 Ethernet controller: 3Com Corporation 3c980-TX 10/100baseTX NIC [Python-T] (rev 78)
Subsystem: 3Com Corporation: Unknown device 1000
Flags: bus master, medium devsel, latency 64, IRQ 5
I/O ports at ec00 [size=128]
Memory at febfef80 (32-bit, non-prefetchable) [size=128]
Expansion ROM at feba0000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
3c59x: Donald Becker and others. http://www.scyld.com/network/vortex.html
See Documentation/networking/vortex.txt
00:12.0: 3Com PCI 3c982 Dual Port Server Cyclone at 0xec00. Vers LK1.1.18-ac
<correct hw addr>, IRQ 5
product code 4b50 rev 00.14 date 08-01-01
Internal config register is 3800000, transceivers 0xa.
8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
MII transceiver found at address 24, status 7809.
Enabling bus-master transmits and whole-frame receives.
00:12.0: scatter/gather enabled. h/w checksums enabled
What is wrong now is the description given by the 1.1.18 version (I can swear
I only have one hole to plug the cable ;)). I will lookup the IDs in the
driver and lspci lists and compare....
So, 3 options:
- the 905C goes to trashcan
- the driver fails to initialize something (I dont trust this...)
- winblows messed the card eeprom...any way to tidy it up again ?
Thanks everybody...
--
J.A. Magallon <[email protected]> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.1 (Bamboo) for i586
Linux 2.4.21-pre6-jam1 (gcc 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk))
On Sat, 2003-03-29 at 01:44, Andrew Morton wrote:
> > I had exactly the same issue as you, but this time it was on my laptop
> > when using a 3CCFE575CT CardBus 10/100 NIC.
>
> Don't think so. You were getting 0xff when reading all PCI registers. In
> this case it is only the MAC address (which comes from an external eeprom)
> which is coming up as 0xff.
Nah! The problem I described in this mail happened a long, long time ago
(in a galaxy far, far away) and was exactly a "no command response"
(IIRC) error logged continuously to the console. Now, the problem I'm
experiencing is the slowdown-when-sending you may have read about which,
unfortunately, doesn't throw any kind of errors to the console ;-)
Thanks for your support, Andrew.
________________________________________________________________________
Felipe Alfaro Solana
Linux Registered User #287198
http://counter.li.org
----- Original Message -----
From: "J.A. Magallon" <[email protected]>
|
| So, 3 options:
| - the 905C goes to trashcan
| - the driver fails to initialize something (I dont trust this...)
| - winblows messed the card eeprom...any way to tidy it up again ?
|
| Thanks everybody...
|
| --
| J.A. Magallon <[email protected]> \ Software is
like sex:
| werewolf.able.es \ It's better when
it's free
| Mandrake Linux release 9.1 (Bamboo) for i586
| Linux 2.4.21-pre6-jam1 (gcc 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk))
Since you have MDK 9.1, could you try the 3rdparty/3c90x module from
mdk kernel-source and see if it works...
It is 3Com's own driver... that is supposed to work with that card...
If it won't work, maybe it's the card that is broken... messed up...
If it works, the bug is in the 3c59x module...
Thomas
On Sat, 2003-03-29 at 18:12, Thomas Backlund wrote:
> Since you have MDK 9.1, could you try the 3rdparty/3c90x module from
> mdk kernel-source and see if it works...
> It is 3Com's own driver... that is supposed to work with that card...
>
> If it won't work, maybe it's the card that is broken... messed up...
> If it works, the bug is in the 3c59x module...
I think it's a bug with 3c59x.c or the PCI resource allocation code in
2.4 kernels, since my 3CCFE575CT 10/100 CardBus adapter works fine with
2.5 kernels, but when running on vanilla 2.4.20, I get a
FF:FF:FF:FF:FF:FF MAC address.
Curiously, instead of using 2.4.20 built-in yenta socket, cs and 3c59x.c
driver, if I revert to running SourceForge's pcmcia-cs, the card works
flawlessly. Also, it seems that Alan Cox patches for 2.4 (part of which
are included in Red Hat's kernels) solve the problem with my card.
________________________________________________________________________
Felipe Alfaro Solana
Linux Registered User #287198
http://counter.li.org
>>>>> "thomas" == Thomas Backlund <[email protected]> writes:
thomas> ----- Original Message -----
thomas> From: "J.A. Magallon" <[email protected]>
thomas> |
thomas> | So, 3 options:
thomas> | - the 905C goes to trashcan
thomas> | - the driver fails to initialize something (I dont trust this...)
thomas> | - winblows messed the card eeprom...any way to tidy it up again ?
thomas> |
thomas> | Thanks everybody...
thomas> |
thomas> | --
thomas> | J.A. Magallon <[email protected]> \ Software is
thomas> like sex:
thomas> | werewolf.able.es \ It's better when
thomas> it's free
thomas> | Mandrake Linux release 9.1 (Bamboo) for i586
thomas> | Linux 2.4.21-pre6-jam1 (gcc 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk))
thomas> Since you have MDK 9.1, could you try the 3rdparty/3c90x module from
thomas> mdk kernel-source and see if it works...
thomas> It is 3Com's own driver... that is supposed to work with that card...
thomas> If it won't work, maybe it's the card that is broken... messed up...
thomas> If it works, the bug is in the 3c59x module...
In my experience, that bug is related with acpi. In a kernel compiled
without acpi, the card works perfectly, in a kernel compiled with acpi
it depend on the phase of the moon and similar things :(
The driver for some reason sets too much 1. I have one of my machines
conected using dhcp, and it almost never got the right address the
first boot (a reset _usually_ fix the problem, not always). Some
times, only some bits are set in the mac address, I think that a
couple of times, I have got a MAC with all FF in the address.
Worse still is the fact, that sometimes it is not the MAC address what
is afected, it is also the vendor ip/product id, that makes that the
driver is not recognized by the driver module.
I have tried both, the standard driver and the 3com "official" driver,
both have that problem. I already informend Andrew Grover about the
problem, but he is not sure what is happening.
Later, Juan "wondering what sane network card's are still on the market".
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
On Sun, 2003-03-30 at 04:21, Juan Quintela wrote:
> In my experience, that bug is related with acpi. In a kernel compiled
> without acpi, the card works perfectly, in a kernel compiled with acpi
> it depend on the phase of the moon and similar things :(
I'm not using ACPI but APM and, on a vanilla 2.4.20 kernel, that's what
I'm seeing with my 3CCFE575CT on my kernel dmesg ring:
<snip>
Yenta IRQ list 08d8, PCI irq5
Socket status: 30000020
Yenta IRQ list 08d8, PCI irq10
Socket status: 30000006
cs: cb_alloc(bus 6): vendor 0x10b7, device 0x5257
PCI: Failed to allocate resource 0(1000-2c3) for 06:00.0
PCI: Enabling device 06:00.0 (0000 -> 0003)
<snip>
eth0: command 0x5800 did not complete! Status=0xffff
eth0: command 0x2804 did not complete! Status=0xffff
<snip>
However, Alan Cox patches for 2.4.20 and Red Hat's linux kernel both
seem to work OK... I think it's related to PCI resource assignment.
________________________________________________________________________
Felipe Alfaro Solana
Linux Registered User #287198
http://counter.li.org
----- Original Message -----
From: "Felipe Alfaro Solana" <[email protected]>
To: "Juan Quintela" <[email protected]>
Cc: "Thomas Backlund" <[email protected]>; "J.A. Magallon" <[email protected]>;
"LKML" <[email protected]>
Sent: Sunday, March 30, 2003 1:19 PM
Subject: Re: 3c59x gives HWaddr FF:FF:...
| On Sun, 2003-03-30 at 04:21, Juan Quintela wrote:
| > In my experience, that bug is related with acpi. In a kernel compiled
| > without acpi, the card works perfectly, in a kernel compiled with acpi
| > it depend on the phase of the moon and similar things :(
|
| I'm not using ACPI but APM and, on a vanilla 2.4.20 kernel, that's what
| I'm seeing with my 3CCFE575CT on my kernel dmesg ring:
|
| <snip>
| Yenta IRQ list 08d8, PCI irq5
| Socket status: 30000020
| Yenta IRQ list 08d8, PCI irq10
| Socket status: 30000006
| cs: cb_alloc(bus 6): vendor 0x10b7, device 0x5257
| PCI: Failed to allocate resource 0(1000-2c3) for 06:00.0
| PCI: Enabling device 06:00.0 (0000 -> 0003)
| <snip>
| eth0: command 0x5800 did not complete! Status=0xffff
| eth0: command 0x2804 did not complete! Status=0xffff
| <snip>
|
| However, Alan Cox patches for 2.4.20 and Red Hat's linux kernel both
| seem to work OK... I think it's related to PCI resource assignment.
|
Have you tried with pci=noapic?
When I used the 3c59x on my integrated 3Com (on Asus nForce2 board), it
always got to the point that it got the IP, but no traffic was going
through...
(same thing happends with the 3Com 3c90x driver...)
This was solved by either booting with acpi=off or pci=noapic...
Thomas
On Sun, 2003-03-30 at 12:53, Thomas Backlund wrote:
> | <snip>
> | Yenta IRQ list 08d8, PCI irq5
> | Socket status: 30000020
> | Yenta IRQ list 08d8, PCI irq10
> | Socket status: 30000006
> | cs: cb_alloc(bus 6): vendor 0x10b7, device 0x5257
> | PCI: Failed to allocate resource 0(1000-2c3) for 06:00.0
> | PCI: Enabling device 06:00.0 (0000 -> 0003)
> | <snip>
> | eth0: command 0x5800 did not complete! Status=0xffff
> | eth0: command 0x2804 did not complete! Status=0xffff
> | <snip>
> |
> | However, Alan Cox patches for 2.4.20 and Red Hat's linux kernel both
> | seem to work OK... I think it's related to PCI resource assignment.
> |
>
> Have you tried with pci=noapic?
It yields the same results as above: "failed to allocate resource
0(1000-2c3)"... I'm not using neither ACPI nor APIC.
Thanks!
________________________________________________________________________
Felipe Alfaro Solana
Linux Registered User #287198
http://counter.li.org
On Sun, 30 Mar 2003, Juan Quintela wrote:
> In my experience, that bug is related with acpi. In a kernel compiled
> without acpi, the card works perfectly, in a kernel compiled with acpi
> it depend on the phase of the moon and similar things :(
>
> The driver for some reason sets too much 1. I have one of my machines
> conected using dhcp, and it almost never got the right address the
> first boot (a reset _usually_ fix the problem, not always). Some
> times, only some bits are set in the mac address, I think that a
> couple of times, I have got a MAC with all FF in the address.
>
> Worse still is the fact, that sometimes it is not the MAC address what
> is afected, it is also the vendor ip/product id, that makes that the
> driver is not recognized by the driver module.
>
> I have tried both, the standard driver and the 3com "official" driver,
> both have that problem. I already informend Andrew Grover about the
> problem, but he is not sure what is happening.
>
> Later, Juan "wondering what sane network card's are still on the market".
I've never had too many problems with one of the cheapest around,
a realtek 8139. Not sure if you want to use them in a server, but
in most of my desktops they work great.
Bas Vermeulen
--
"God, root, what is difference?"
-- Pitr, User Friendly
"God is more forgiving."
-- Dave Aronson