Re: forcedeth fails on second port with error -12
Greetings Sebastian:
As promised, here are the relevant settings from my BIOS. Please note that I have a 3Ware 9500 RAID card handling all of the drives which is why all of the SATA controllers are all shut down. I also have two PCIe video boards, which is why some of the video settings are the way they are. The machine has 4GB of RAM (8x512MB) which effects the memory settings.
I can't vouch that any of these settings are right - or even sane. I am getting "Machine Check Exception" errors in my system logs. They don't seem to be adversely effecting the machine in any way. Tyan has not been helpful in diagnosing them or even in detailing what some of these settings mean. That having been said, here you go:
BIOS Version: 1.02.2895
Installed OS: WinXP64
Hammer Config
ECC Features
ECC: Enabled
ECC Scrub Redirection: Enabled
DRAM ECC Scrub Ctl: 1.31ms
Chip Kill: Disabled
Dcache ECC Scrub Ctl: Disabled
L2 ECC Scrub Ctl: Disabled
Memory Hole
4GB memory Hole Adjust: Auto
4GB memory hole size: 1792 MB (not adjustable)
IOMMU: Enabled
IOMMU: 128MB
Memhole mapping: auto
Memory Config:
Swizzle Memory Banks: Enabled
DDR Clock Jitter: Disabled
Memory Clock: DDR400
Enable All Memory Clocks: Populated
Controller Config Mode: Auto
Timing Config Mode: Auto
Integrated Devices:
USB Control: USB1.1+USB2
USB Legacy Support: Enabled
Self-Healing: Enabled
MAC LAN: Enabled
MAC LAN Bridge: Enabled
MAC Address: 00E08154CCF2 (not adjustable)
MAC OPROM Scan: Enabled
Audio Codec: Enabled
SATA0 Controller: Disabled
SATA1 Controller: Disabled
Interrupt Mode: APIC
SLI Broadcast Aperature: SLI on Master
PCI Express MSI: Enabled
PCIe Error Handling: Enabled
Slave Devices:
MAC LAN: Enabled
MAC LAN Bridge: Enabled
MAC Address: 00E08154CCF3 (not adjustable)
The only piece of advice that I can give about the BIOS is that my NICs stopped working when I disabled the MAC LAN Bridge settings.
Good Luck.
-Scott
-------------- Original message ----------------------
From: reeses1@comcast.net
> Greetings Sebastian:
>
> Does the ethernet adapter look like this if you use ifconfig -a?
>
> eth2 Link encap:UNSPEC HWaddr
> 00-E0-81-00-00-23-91-8A-00-00-00-00-00-00-00-00
> 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)
>
> Note the Link encap of UNSPEC and the odd HWaddr. That is not the forcedeth
> driver, that the firewire network driver (eth1394) that you could theoretically
> use to link computers together via firewire. Both of your ethernet adapters
> should look alike, with a link encap of Ethernet and hw addresses of 6 hex
> groups separated by colons.
>
> As far as the BIOS goes, I don't think that I did anything odd. I also noted
> that changing the "Installed OS" setting from Windows to Linux did not make any
> noticable difference. Let me reboot and look into it and I'll post again.
>
> -Scott
>
> -------------- Original message ----------------------
> From: Sebastian Haase <haase@msg.ucsf.edu>
> > Greetings Scott!
> > I did talk to the tech support where I bought the machine from.
> > He confirmed what you said about sequential MAC addresses (I don't know
> > what that Wikipedia page for PHYceiver is about ...)
> >
> > I finally did the BIOS upgrade to 1.03 (March'06) - did not help
> > anything for me though :-(
> > Luckily I took photos of each BIOS page before !
> > Some semi-important settings where different after the flashing. (e.g.
> > ECC ram)
> >
> > I realized that forcedeth got even loaded when I removed it from
> > /lib/modules/ ! Now I think it's in the initrd (ram disk) that I build
> > with the kernel - It came up even when I had udev deinstalled...
> > So I build a new kernel package without forcedeth - and nvnet instead.
> > This way ifconfig shows both eth0 and eth1. but eth0 has this random MAC
> > with many 00-00... appended. It does not see any other computer on its
> > network. NFS on eth1 seems somehow unstable (logging into an X-session
> > (AFTER gdm) hangs ...
> >
> > Now I'm back to forcedeth (no nvnet) (udev installed) - ifconfig shows
> > only one adapter.
> > Changing MAC addresses (ifconfig hw ether 12:23:34:45:56:67) generates
> > an error message...
> >
> >
> > Yes, I'm using 2.6.16 linux-source to build my kernel image.
> >
> > Scott, do you remember setting anything special in your BIOS ?
> > I did change "installed OS" to "Linux" - but I did not notice any benefit.
> >
> > Thanks,
> > Sebastian Haase
> >
> >
> >
> >
> > reeses1@comcast.net wrote:
> > > 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
> >
>
>
>
> --
> To UNSUBSCRIBE, email to debian-amd64-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: