I guess I'll keep an eye out on lkml for any activity around forcedeth or any bugs that get posted.
]]>I think ive posted this same problem on another forum with no real answers.
]]>MOD_BLACKLIST=(forcedeth)
in rc.conf and
alias eth0 nvnet
in modprobe.conf. Seems like this forcedeth module doesn't work correctly...
]]>Just put a file called something like 01-network.rules in /etc/udev/rules.d, containing a line like SUBSYSTEM=="net", SYSFS{address}=="00:a0:d1:27:d3:2f", NAME="yukon". SYSFS{address} should be your device's MAC address, and name should be the name you want it to have. The exact name of the file isn't important, but number at the beginning determines when it's evaluated.
EDIT: Beat me to it.
]]>From /etc/udev/readme-udev-arch.txt:
- The "proper" way to configure net interfaces to hold static names within udev rules. Add lines like these to a custom rules file such as
/etc/udev/rules.d/01-network.rules:
SUBSYSTEM=="net", SYSFS{address}=="aa:bb:cc:dd:ee:ff", NAME="lan0"
SUBSYSTEM=="net", SYSFS{address}=="ff:ee:dd:cc:bb:aa", NAME="wlan0"
- To get the right mac address use this command:
udevinfo -a -p /sys/class/net/<yourdevice>
- Make sure you use lower-case hex values in your udev rules.
- NAME= determines the name of your network card. Use these names in your
network configuration in rc.conf as well.
I'm running on one of the new shiny ASUS M2N32-SLI Deluxe motherboards with an AM2 X2 3800+ dual core processor. This is a motherboard which uses the new nForce 590 SLI chipset. Everything has been going swimming fine so far with sata_nv, forcedeth and friends letting me avoid tainting my kernel with the nForce drivers. That was, until last night.
I was hopping off playing some TES IV: Oblivion on my Wintendo install, and was coming back in to Arch. During boot, it seemed like the "Network" phase was taking longer than normal. When I log in, sure enough I don't have an interface up. This wasn't too big a shock - my motherboard has two LAN ports and sometimes they swap around who is eth0 and who is eth1 (if somebody could show me how to write a udev rule to force one NIC to be eth0 and one to be eth1 I'd love you forever). However, this time the appropriate NIC was eth0. I tried "dhcpcd eth0" .... timeout. Then "dhcpcd -dBS eth0" - it reported my MAC, then timed out. After this, I tried the brute-forcing option - "ifconfig eth0 up 192.168.1.100 netmask 255.255.255.0 && route add default gw 192.168.1.1". This seemed to bring the interface up, but ping, arping and friends couldn't get any response from my router (at the other end of my LAN cable). Router's lights showed there was a valid connection though. Puzzled, I booted back into Wintendo, and networking was just fine. Booted back into Arch64, same behaviour. I grabbed the new kernel26 package from archlinux.org, booted back into arch64, installed it, same behaviour. It was late at night at this point, so I powered off my machine for the night, also toggling off the PSU. This morning, everything is rolling fine again.
So based on my observations, it looks like the chipset for this motherboard can have its NICs in what forcedeth thinks is an invalid state, but which is actually a valid, working state. Dmesg didn't report anything unusual to me while I was in this "invalid" state. So I'm wondering about next steps. Should I, and how should I escalate this to lkml? What debugging steps should I take next time I enter this state (to capture useful output for debuggers)?
Oh, also I tried manually installing the nForce drivers, and those didn't even register the interfaces when I modprobed nforce. So it's forcedeth or bust for me right now
]]>