Re: forcedeth fails on second port with error -12
Greetings Sebastian:
Here is the ifconfig output from my system:
eth0 Link encap:Ethernet HWaddr 00:E0:81:54:CC:F2
inet addr:172.26.72.199 Bcast:172.26.72.255 Mask:255.255.255.0
inet6 addr: fe80::2e0:81ff:fe54:ccf2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:72422 errors:0 dropped:0 overruns:0 frame:0
TX packets:38848 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:66830782 (63.7 MiB) TX bytes:2910095 (2.7 MiB)
Interrupt:209 Base address:0x6000
eth1 Link encap:Ethernet HWaddr 00:E0:81:54:CC:F3
inet addr:67.232.43.2 Bcast:67.232.43.127 Mask:255.255.255.128
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:217 Base address:0x8000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:228 errors:0 dropped:0 overruns:0 frame:0
TX packets:228 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:17646 (17.2 KiB) TX bytes:17646 (17.2 KiB)
The MAC addresses are sequential - they are assigned by the manufacturer and tend to be assigned sequentially. Every multi-port card that I've seen has sequential MAC addresses. In the good old days, the MAC addresses were hard coded into the card and couldn't be changed. Nowadays, they are loaded into registers on the card by the firmware, so the MAC addresses natively on the card are more of a suggestion than a rule. Many card drivers can be passed a MAC address and they will use that one instead of native one on the card. Without digging into the kernel source coded, I could not say if the forcedeth driver is capable of this trick or not. Supplying a MAC address as part of the /etc/network/interface config will not work unless the forcedeth driver is capable of supporting it.
Perhaps using the debian /etc/network/interface config to assign the next sequential MAC address to the card would be in order.
I assume that you're using the debian packages of 2.6.16?
-Scott
-------------- Original message ----------------------
From: Sebastian Haase <haase@msg.ucsf.edu>
> Greetings,
> I was just ready to call the people I bought the PC from, but then:
> 1) I read here: http://www.ussg.iu.edu/hypermail/linux/kernel/0401.3/0119.html
> about the forcedeth (googling for "Switching to a random MAC")
> It says:
> #> I don't like this random MAC address stuff. Regardless of hardware
> #> behavior, this breaks MAC address uniqueness.
> #
> #> I would much rather that ->open() failed, if a valid MAC address were
> #> not present. Then a simple userspace program can be run by the admin
> #> (policy!) that sets the MAC address, before bringing up the interface.
> #
> # This was a feature many users asked for. It seems broken hardware is very
> # common for this chipset.
>
> (could this really be -- read on ...)
>
> 2) But then I looked up PHY on *wikipedia*, and it says:
> An Ethernet PHYceiver is a chip which can send and receive Ethernet frames; it
> typically lacks such advanced features of network interface card (NIC) chips
> as Wake-on-LAN or Boot ROM support. Also, unlike NIC, a *PHYceiver doesn't
> have its own MAC address*.
>
> !!!
>
> So it's "common" to NOT have a MAC address !!!
> What's that ??
>
> It goes on at http://en.wikipedia.org/wiki/MAC_address:
> In Debian just put
> hwaddress ether 02:01:02:03:04:08
> in the appropriate section of /etc/network/interfaces so that the MAC address
> is set when the network device is started.
>
>
> That sound OK now - ONLY:
> I thought I could use
> http://groups.google.com/group/linux.debian.user/msg/0bf920a45ce7a14f
> and put
> mapping eth0 eth1
> script /etc/network/get-mac-address.sh
> map 00:00:00:00:00:00 wireless
> map 11:11:11:11:11:11 ethernet
> into /etc/network/interfaces
> to fix the *udev* problem assigning problem.
>
> That of course conflicts when I first assign my own MAC number and then try to
> use that to identify the physical port ;-)
>
> Further help would be great !
>
> FYI: Windows assigns (?) just the hex number (MAC addr of the first port) +1
> to second port ... that sound reasonable to me...
>
> Thanks,
> Sebastian Haase
>
> On Tuesday 18 April 2006 20:33, reeses1@comcast.net wrote:
> > Greetings Sebastian:
> >
> > udev is pretty good about finding devices and loading whatever driver it
> > thinks is appropriate. I don't know the exact mechanisms that it employs
> > to perform these feats, but I do know that the days of having to put a
> > bunch of stuff into /etc/modules are essentially over. It always pulls the
> > drivers out of the current kernel's directory in /lib/modules, so it
> > doesn't shock me that you had to manually pull the driver files out of that
> > directory to control which module loaded for the network. I know that
> > there are a bunch of rules in /etc/udev where you can control what gets
> > loaded and what doesn't. That would be the place to look if you were
> > trying to control which driver gets loaded for your video card.
> >
> > I'm not running the 3/2006 BIOS yet, I'm still running the previous one.
> > It resolved the problems that I was having with the second NICs MAC address
> > being all zeros. It sounds like your board is newer than mine and came
> > with that BIOS on it, so maybe that isn't the problem.
> >
> > There are a number of BIOS options that, frankly, I don't have the first
> > idea what they do/mean. If you think it would be helpful, I can go through
> > the setup screens and tell you what everything is set to. I've had my fair
> > share of problems with the box, but I can honestly say that networking
> > hasn't been one of them.
> >
> > -Scott
> >
> > -------------- Original message ----------------------
> > From: Sebastian Haase <haase@msg.ucsf.edu>
> >
> > > Greetings Scott,
> > > Still having problems: after playing with nvnet.ko eth1 now shows up -
> > > but doesn't see any other PC on the local network.
> > > Also I found that the only way of preventing forcedeth from loading was
> > > to mv it out of the way -- it was not mentioned anywhere in the /etc tree
> > > -- how does the system now about it ???
> > > The same happend again when I wanted to go back - nvnet was always loaded
> > > until I mv'ed it away from the /lib/modules-`uname -r` tree...
> > >
> > > Just be sure I understand right: Are we talking about *THE* BIOS of the
> > > Tyan Thunder K8WE board ?
> > > It says it's version 1.2.2895 from Oct.2005 or so - that seems quite
> > > recent ! I tried in the BIOS setting to change "installed OS" from
> > > 'WinXP64' to 'Linux' - didn't help.
> > > Also I noticed that in the BIOS the MAC address of "eth0" is
> > > *unchangeably" displayed - there are some other options regards MAC, but
> > > I didn't look up what they are for (yet).
> > >
> > > Thanks,
> > > Sebastian Haase
> > >
> > > On Tuesday 18 April 2006 09:50, reeses1@comcast.net wrote:
> > > > Greetings Sebastian:
> > > >
> > > > I seem to recall that everything worked properly under windows. I
> > > > think that the windows driver just quietly assigned a MAC to the
> > > > interface and went on. It's been most of a year, so my recollection
> > > > might be a little hazy.
> > > >
> > > > Both interfaces are using forcedeth. I did not have to do anything
> > > > special in /etc/modules beyond adding forcedeth. If I don't add it
> > > > there, then it doesn't come up until after udev runs, which is a little
> > > > late in the boot process for me.
> > > >
> > > > Flashing the BIOS does have the potential for disaster. That said,
> > > > over the course of 15 years I have probably flashed more than 100
> > > > without a single issue. The only likely issue would be if the power
> > > > went off while the system was writing the image to the flash. What's
> > > > the likelyhood of that? Don't try it during an electrical storm, and
> > > > don't let the kids play with the cords while you're updating. If you
> > > > have a battery backup for the computer, I don't see how you could have
> > > > a problem. Read and follow the directions carefully.
> > > >
> > > > Good Luck.
> > > >
> > > > -Scott
> > > >
> > > >
> > > > -------------- Original message ----------------------
> > > > From: Sebastian Haase <haase@msg.ucsf.edu>
> > > >
> > > > > Thanks for (both) reply(s).
> > > > > BIOS update ? Does this still apply when both NICs show up fine under
> > > > > WindowsXP(x64) ?
> > > > > I have never flashed the BIOS and heard bad stories about it's
> > > > > possibly disastrous consequences ...
> > > > >
> > > > > Are you using forcedeth ? Did you need to edit any files (like
> > > > > /etc/modules) ?
> > > > >
> > > > > Thanks,
> > > > > Sebastian Haase
> > > > >
> > > > > On Monday 17 April 2006 20:11, reeses1@comcast.net wrote:
> > > > > > Greetings:
> > > > > >
> > > > > > This board had a bad habit of leaving the second NICs MAC address
> > > > > > all zeros. I don't know if this is the root cause of your problem
> > > > > > or not, but since it mentions it in your dmesg it might be worth a
> > > > > > look. There was a BIOS upgrade that fixed it. Both NICs are
> > > > > > working properly on my machine.
> > > > > >
> > > > > > -Scott
> > > > > > -------------- Original message ----------------------
> > > > > > From: Sebastian Haase <haase@msg.ucsf.edu>
> > > > > >
> > > > > > > Hi,
> > > > > > > I have two on board ethernet on Tyan Thunder K8WE (s2895).
> > > > > > > It seems the forcedeth driver works fine.
> > > > > > > But only for eth0. Eth1 doesn't show up...
> > > > > > > I thought I might need to specifically reload the module a second
> > > > > > > time with different options for the second port (like in
> > > > > > > /etc/modutils or so) !?!?!????
> > > > > > >
> > > > > > > then I discovered an error message in dmesg:
> > > > > > > <cut and paste from dmesg>
> > > > > > > forcedeth.c: Reverse Engineered nForce ethernet driver. Version
> > > > > > > 0.48. ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LMAC] -> GSI
> > > > > > > 21 (level, high) -> IRQ 18
> > > > > > > PCI: Setting latency timer of device 0000:00:0a.0 to 64
> > > > > > > eth0: forcedeth.c: subsystem: 010f1:2895 bound to 0000:00:0a.0
> > > > > > > ACPI: PCI Interrupt Link [LNK3] enabled at IRQ 19
> > > > > > > GSI 19 sharing vector 0xC9 and IRQ 19
> > > > > > > ACPI: PCI Interrupt 0000:80:0a.0[A] -> Link [LNK3] -> GSI 19
> > > > > > > (level, high) -> IRQ 19
> > > > > > > PCI: Setting latency timer of device 0000:80:0a.0 to 64
> > > > > > > 0000:80:0a.0: Invalid Mac address detected: 00:00:00:00:00:00
> > > > > > > Please complain to your hardware vendor. Switching to a random
> > > > > > > MAC. 0000:80:0a.0: open: Could not find a valid PHY.
> > > > > > > ACPI: PCI interrupt for device 0000:80:0a.0 disabled
> > > > > > > forcedeth: probe of 0000:80:0a.0 failed with error -12
> > > > > > > Probing IDE interface ide0...
> > > > > > > </cut and paste from dmesg>
> > > > > > >
> > > > > > > lspci shows that 0000:80:0a.0 should be my second NIC.
> > > > > > >
> > > > > > > Any idea what error -12 could mean ?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Sebastian Haase
>
>
> --
> To UNSUBSCRIBE, email to debian-amd64-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: