Re: forcedeth fails on second port with error -12
As final note on this:
A "reset BIOS to defaults" did the trick - God knows why...
Only some crucial settings like "hardware memory hole" needed to be adjusted,
but the bottom line: for whatever reason Linux suddenly started seeing the
second MAC address...
qed.
Thanks to every one
- Sebastian Haase
On Friday 21 April 2006 15:05, Sebastian Haase wrote:
> Greetings Scott!
> Thanks for all that info ! I'll check those setting as soon as I get back
> to that computer (Tuesday).
> Just as a side note: Did you elaboratedly type all those lines in manually
> - Or is there a tool that can actually generate something like this ... I
> was looking for one but didn't find anything..
>
> Thanks again,
> Sebastina Haase
>
> On Thu, 20 Apr 2006 23:25:19 +0000
>
> reeses1@comcast.net wrote:
> > 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/0bf920a45ce7a1
> >> > >>4f 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
> >
> > --
> > To UNSUBSCRIBE, email to debian-amd64-REQUEST@lists.debian.org
> > with a subject of "unsubscribe". Trouble? Contact
> >listmaster@lists.debian.org
Reply to: