Really, really, I mean really weird hardware issue with A64

woogie · 2006-07-02 14:52:40

Alright, I'm using Arch64 (from the Arch64 repos, after my ill-fated adventure pointing pacman to archlinux.org and saying pacman -Syu) and I'm having a really odd problem with my hardware.

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

fedaykin · 2006-07-02 17:23:02

I have the same problem (I have an nforce3 board) where sometimes both eth0 and eth1 won't work, and the only way to fix it is to shutdown and start over (oh, and I don't think it's an Arch64 problem, since it happened to me in Arch32 as well). It doesn't happen often enough to bother me though, so I haven't really looked into it. As for problem where eth0 and eth1 switch, maybe this will help (so far it is working for me).

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.

pauldonnelly · 2006-07-02 17:25:02

I can't shed any light on your problem, but I can tell you how to make your interfaces consistent.

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.

blum · 2006-07-04 06:55:34

I had this kind of problem too, but I manage to fix it with disabling forcedeth module and loading the nvnet module instead. It;s done with

MOD_BLACKLIST=(forcedeth)

in rc.conf and

alias eth0 nvnet

in modprobe.conf. Seems like this forcedeth module doesn't work correctly...

syd · 2006-07-04 09:21:50

Yer I think it a problem with the forcedeth nic.
Ive had this problem with gentoo, arch32 and 64.
It seemed to happen to me when the computer was not shutdown properly.

I think ive posted this same problem on another forum with no real answers.

woogie · 2006-07-05 02:14:24

Thanks to all who helped me get clarification on my hardware issue, and get my udev rules in shape so my devices are named correctly!

I guess I'll keep an eye out on lkml for any activity around forcedeth or any bugs that get posted.

Arch Linux

#1 2006-07-02 14:52:40

Really, really, I mean really weird hardware issue with A64

#2 2006-07-02 17:23:02

Re: Really, really, I mean really weird hardware issue with A64

#3 2006-07-02 17:25:02

Re: Really, really, I mean really weird hardware issue with A64

#4 2006-07-04 06:55:34

Re: Really, really, I mean really weird hardware issue with A64

#5 2006-07-04 09:21:50

Re: Really, really, I mean really weird hardware issue with A64

#6 2006-07-05 02:14:24

Re: Really, really, I mean really weird hardware issue with A64

Board footer