Re: forcedeth generates Invalid MAC address message
On Sunday 11 November 2007, Douglas A. Tutty wrote: 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? Either the forcedeth module is built into the kernel or is being loaded by udev. If its loaded by udev, if you turn off networking, you should be able to rmmod the forcedeth module, then insmod the r8169 and see if it works. That would be the first step. Then, I guess you'd need to reconfigure the initrd to load the r8169 module instead of the forcedeth (i.e. remove the forcedeth module from the initrd altogether). Doug. Thanks for the information. I finally got forcedeth to quit coming up by removing it from initrd. Unfortunately, the r8169 module will not communicate with the nic. I'm going to need to keep working at that one. The good news is that the wireless card now works so I can at least configure the system to run using a consistent IP. I'm going to have to keep hacking at the NIC to see if there is a driver out there that fixes the problem as time permits. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: forcedeth generates Invalid MAC address message
On 11/12/07, Keith Schweikhard [EMAIL PROTECTED] wrote: On Sunday 11 November 2007, Douglas A. Tutty wrote: 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? Either the forcedeth module is built into the kernel or is being loaded by udev. If its loaded by udev, if you turn off networking, you should be able to rmmod the forcedeth module, then insmod the r8169 and see if it works. yeap I couln't answer before because I don't remember udev... to fix the random choice of ethX there is a file in /etc/udev*/*net* in that file the MAC is stored and could make some noise, try to erase the lines to test... That would be the first step. Then, I guess you'd need to reconfigure the initrd to load the r8169 module instead of the forcedeth (i.e. remove the forcedeth module from the initrd altogether). Doug. Thanks for the information. I finally got forcedeth to quit coming up by removing it from initrd. Unfortunately, the r8169 module will not communicate with the nic. I'm going to need to keep working at that one. The good news is that the wireless card now works so I can at least configure the system to run using a consistent IP. I'm going to have to keep hacking at the NIC to see if there is a driver out there that fixes the problem as time permits. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Perhaps the depth of love can be calibrated by the number of different selves that are actively involved in a given relationship. Carl Sagan (Contact) Jaime Ochoa Malagón Integrated Technology Tel: (55) 52 54 26 10
Re: forcedeth generates Invalid MAC address message
FYI On 11/12/07, Mike Cruz [EMAIL PROTECTED] wrote: I found a fix on the Debian forums. http://forums.debian.net/viewtopic.php?t=14331highlight=forcedeth You edit your /etc/udev/rules.d/z25_persistent-net.rules file. remove all old entries your not using then add this one ( SUBSYSTEM==net, DRIVERS==forcedeth, NAME=eth0 ). this worked like a charm on my server AMD64 kernel 2.6.18* Mike -- Perhaps the depth of love can be calibrated by the number of different selves that are actively involved in a given relationship. Carl Sagan (Contact) Jaime Ochoa Malagón Integrated Technology Tel: (55) 52 54 26 10
Re: forcedeth generates Invalid MAC address message
On Saturday 10 November 2007, William Cooper wrote: On 11/11/2007, Keith Schweikhard [EMAIL PROTECTED] wrote: Hello, I am currently configuring two identical ACER Aspire 5520 laptops. The processors are AMD Turion 64 X2 dual core, Nvidia nforce 610M providing the ethernet connection. Atheros AR5007EG for the wireless connection. I am doing a netinstall using Debian Testing (Lenny). The kernel configuration is: 2.6.22-2-amd64. The version of forcedeth is 0.60. The first machine configured without problems. The second machine generates the following error during boot: ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 23 ACPI: PCI Interrupt :00:0a.0[A] - Link [LMAC] - GSI 23 (level, low) - IRQ 23 PCI: Setting latency timer of device :00:0a.0 to 64 forcedeth: using HIGHDMA :00:0a.0: Invalid Mac address detected: 1d:9b:2a:38:1b:00 Please complain to your hardware vendor. Switching to a random MAC. eth0: forcedeth.c: subsystem: 01025:0126 bound to :00:0a.0 . . . udev: renamed network interface eth0 to eth39 This results in udev assigning a different ethernet interface each time it boots. (ie. eth1, eth2, .. eth39). This seemingly has two effects. 1. It is impossible to bring the network connection down and back up again. 2. It is impossible to tailor the network connection (dhcp or nothing) 3. The IP address of the machine changes every time it reboots. (Result of a random MAC address assignment.) 4. It seems to cause the ethernet configuration process to stop. As a result, the WAN card never initializes. I have compared the boot messages generated by both machines and the only differences are the invalid MAC address message, udev renaming the ethernet interface, and the machine failing to attempt to initialize the wlan interface. I am guessing that the invalid MAC address and the failure to initialize the wireless are somehow related. Because this is currently a dual boot machine I checked the MAC address on the windows side and it reports back the same MAC address that forcedeth is reporting as being invalid. The wireless interface also works properly in windows. I have done some searching and have found that the forcedeth module may be incorrectly identifying/ translating the MAC address. (Why it works on one machine and not on the other still confuses me.) Given the fact that a problem has been identified in forcedeth, is there a workaround that will prevent the kernel from giving up on the ethernet initialization so I can at least initialize the wireless card and obtain a consistent network connection? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Hello, I had a similar problem with the forcedeth device but with a desktop motherboard without wireless. The error was the same forcedeth device has bad MAC address, random MAC being assigned and the card not being configured when the MAC changed between boots. My problem started when I upgraded the BIOS from one version to another and went away again when I downgraded back to the original BIOS. Check for mail in the debian-user archive subject Asrock K8NF6G-VSTA BIOS upgrade warning - forcedeth fails on the 25th of July 2007. You could check if both laptops have the same BIOS versions as a start. HTH Bill Thanks for giving me something else to check. Unfortunately, both boards show the same version of the BIOS V1.07. I am firing off an email to the manufacturer to see if there is something I am missing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: forcedeth generates Invalid MAC address message
Hi, The first byte of your MAC address is 1d, i.e. 00011101. On http://en.wikipedia.org/wiki/Mac_address (the figure): if the last bit of the 1st byte is 1, then it is a multicast address, NOT a unicast one. As such, it cannot be the main address of a NIC. Maybe the address reading has a problem? On some laptops, the MAC address is printed on the back side of the laptop. Can you look at it? You can also use http://standards.ieee.org/regauth/oui/index.shtml to find out the enterprise which has built a NIC. Cheers, -- Eugen Dedu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: forcedeth generates Invalid MAC address message
On Sunday 11 November 2007, Eugen Dedu wrote: Hi, The first byte of your MAC address is 1d, i.e. 00011101. On http://en.wikipedia.org/wiki/Mac_address (the figure): if the last bit of the 1st byte is 1, then it is a multicast address, NOT a unicast one. As such, it cannot be the main address of a NIC. Maybe the address reading has a problem? On some laptops, the MAC address is printed on the back side of the laptop. Can you look at it? You can also use http://standards.ieee.org/regauth/oui/index.shtml to find out the enterprise which has built a NIC. Cheers, -- Eugen Dedu Hi, 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? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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? Either the forcedeth module is built into the kernel or is being loaded by udev. If its loaded by udev, if you turn off networking, you should be able to rmmod the forcedeth module, then insmod the r8169 and see if it works. That would be the first step. Then, I guess you'd need to reconfigure the initrd to load the r8169 module instead of the forcedeth (i.e. remove the forcedeth module from the initrd altogether). Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: forcedeth generates Invalid MAC address message
On 11/11/2007, Keith Schweikhard [EMAIL PROTECTED] wrote: Hello, I am currently configuring two identical ACER Aspire 5520 laptops. The processors are AMD Turion 64 X2 dual core, Nvidia nforce 610M providing the ethernet connection. Atheros AR5007EG for the wireless connection. I am doing a netinstall using Debian Testing (Lenny). The kernel configuration is: 2.6.22-2-amd64. The version of forcedeth is 0.60. The first machine configured without problems. The second machine generates the following error during boot: ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 23 ACPI: PCI Interrupt :00:0a.0[A] - Link [LMAC] - GSI 23 (level, low) - IRQ 23 PCI: Setting latency timer of device :00:0a.0 to 64 forcedeth: using HIGHDMA :00:0a.0: Invalid Mac address detected: 1d:9b:2a:38:1b:00 Please complain to your hardware vendor. Switching to a random MAC. eth0: forcedeth.c: subsystem: 01025:0126 bound to :00:0a.0 . . . udev: renamed network interface eth0 to eth39 This results in udev assigning a different ethernet interface each time it boots. (ie. eth1, eth2, .. eth39). This seemingly has two effects. 1. It is impossible to bring the network connection down and back up again. 2. It is impossible to tailor the network connection (dhcp or nothing) 3. The IP address of the machine changes every time it reboots. (Result of a random MAC address assignment.) 4. It seems to cause the ethernet configuration process to stop. As a result, the WAN card never initializes. I have compared the boot messages generated by both machines and the only differences are the invalid MAC address message, udev renaming the ethernet interface, and the machine failing to attempt to initialize the wlan interface. I am guessing that the invalid MAC address and the failure to initialize the wireless are somehow related. Because this is currently a dual boot machine I checked the MAC address on the windows side and it reports back the same MAC address that forcedeth is reporting as being invalid. The wireless interface also works properly in windows. I have done some searching and have found that the forcedeth module may be incorrectly identifying/ translating the MAC address. (Why it works on one machine and not on the other still confuses me.) Given the fact that a problem has been identified in forcedeth, is there a workaround that will prevent the kernel from giving up on the ethernet initialization so I can at least initialize the wireless card and obtain a consistent network connection? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Hello, I had a similar problem with the forcedeth device but with a desktop motherboard without wireless. The error was the same forcedeth device has bad MAC address, random MAC being assigned and the card not being configured when the MAC changed between boots. My problem started when I upgraded the BIOS from one version to another and went away again when I downgraded back to the original BIOS. Check for mail in the debian-user archive subject Asrock K8NF6G-VSTA BIOS upgrade warning - forcedeth fails on the 25th of July 2007. You could check if both laptops have the same BIOS versions as a start. HTH Bill
