Sundance ethernet card doesn't update carrier properties
dbn.lists at gmail.com
Sat Oct 14 14:32:16 PDT 2006
I was working on adding a fix to the BLFS network setup scripts so
that they will be skipped if the network card isn't connected. The
original sender suggested using `/sbin/ip link show <interface> | grep
NO-CARRIER'. Later I found that this info is exported through sysfs
since ~2.6.10 in /sys/class/net/<interface>/carrier. See the details
The problem is, I can't in good faith add the fix because one of my
ethernet cards doesn't do what I say it's going to do. The first
problem is that under normal circumstances, unplugging the cable
neither makes /sys/.../carrier switch to 0 nor does NO-CARRIER show up
in the output from /sbin/ip. It always shows an active carrier.
If I boot with the cable unplugged, /sbin/ip still always shows an
active carrier. /sys/.../carrier does something stranger where if I
cat the value early, I think it's just a null character because the
cat comes back with an "Invalid argument" error. However, it briefly
changes to 1 (I check the value again during the network init script),
then changes back to the null character later.
This leads me to believe that it's an issue with the kernel driver for
my device. Here's what lspci has to say about my device:
00:0f.0 Ethernet controller: D-Link System Inc DL10050 Sundance
Ethernet (rev 12)
Subsystem: D-Link System Inc DFE-550TX
Flags: bus master, medium devsel, latency 80, IRQ 10
I/O ports at 1000 [size=128]
Memory at e000a400 (32-bit, non-prefetchable) [size=512]
[virtual] Expansion ROM at 30000000 [disabled] [size=64K]
Capabilities:  Power Management version 2
dmesg says nothing unusual:
sundance.c:v1.2 11-Sep-2006 Written by Donald Becker
eth0: D-Link DFE-550TX FAST Ethernet Adapter at 00011000,
00:05:5d:e5:ae:08, IRQ 10.
eth0: MII PHY found at address 1, status 0x782d advertising 01e1.
eth0: MII PHY found at address 0, status 0x782d advertising 01e1.
I'm running linux-2.6.19-rc2 to test right now, and I have the
sundance driver loaded as a module. I also tested on 2.6.18 and
18.104.22.168, and the behavior was the same.
My question is, are there any kernel heroes here who'd like to help me
debug this? I can't point around in the kernel source how I think
things chain up, but I'm just kind of guessing. Otherwise, I guess
I'll take this over to LKML.
More information about the lfs-support