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