Re: forcedeth generates Invalid MAC address message
On Sun, Nov 11, 2007 at 04:29:54PM -0800, Keith Schweikhard wrote:
> No luck on the MAC addresses being printed on the bottom. I've tried to
> locate the chip on the IEEE website without luck. It looks like the MAC
> address that is getting posted on both machines is in a reverse byte order.
> When I call up the MAC address on the Windows side of the computer the byte
> order is reversed. As a result, the first three bytes of my MAC address are
> 00-1B-38. According to IEEE these MAC addresses are assigned to COMPAL
> ELECTRONICS TECHNOLOGIC CO., LTD.
> Judging from what I am reading, Nvidia chips had issues with reporting their
> MAC addresses. As a result, forcedeth swaps the bytes. The board in the
> computer claims to be Nvidia, but the chip is registered to Compal. In
> looking up the chipset in hardware for linux
> http://hardware4linux.info/component/15830/
> I get pointed to a different driver for the NIC. (r8169) But the kernel does
> not seem realize this during the boot process. As a result, it calls
> forcedeth and forcedeth swaps the byte order. I am baffled on how to
> override this selection. I've already tried blacklisting forcedeth
> in /etc/modprobe.d/blacklist and adding r8169 into /etc/modules but it seems
> to load the forcedeth module regardless of the fact that it is blacklisted.
> I have also tried moving forcedeth.ko from the kernel/drivers/net/ directory
> but without luck. forcedeth gets loaded as a module anyway. This problem
> happens as soon as forcedeth tries to initialize the NIC. I'm not certain
> what to try next. Any suggestions?
The nvidia MAC has for many years now for some stupid reason had it's
MAC address stored in reverse order on almost all boards that use it
(not sure if the documentation was confusing or what). As a result the
driver has had to reverse it before using it. A few months ago some
board makers decided to "fix" the problem and start storing the MAC in
the correct order which of course now breaks all existing drivers that
"know" the MAC address is in reverse order.
The kernel developers are aware of this and are trying to come up with a
way for the driver to detect which way the address is stored and do the
right thing based on it. Any solution is going to appear at earliest in
2.6.24 as far as I can tell. You can do a search of lkml (linux kernel
mailing list) to get more details on it.
--
Len Sorensen
Reply to: