Bug 151777
Summary: | cable link state ignored on ethernet card (b44). | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Rodd Clarkson <rodd> | ||||||
Component: | kernel | Assignee: | John W. Linville <linville> | ||||||
Status: | CLOSED UPSTREAM | QA Contact: | Brian Brock <bbrock> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 4 | CC: | davej, dcbw, wtogami | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2005-06-16 12:22:32 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Rodd Clarkson
2005-03-22 09:59:43 UTC
If I am correct, the "Cannot get device settings: Resource temporarily unavailable" message comes from: static int b44_get_settings(struct net_device *dev, struct ethtool_cmd *cmd) { struct b44 *bp = netdev_priv(dev); if (!(bp->flags & B44_FLAG_INIT_COMPLETE)) return -EAGAIN; ... } So, it would seem that when you're running this ethtool, that flag isn't set... It gets set in b44_open(), which is called quite early for the card. Rodd: can you scan the output of 'dmesg' and 'cat /var/log/messages' and post here what output (if any) may contain information about the card? It would most likely include the text "b44" in the line, if its relevant. That might give us a clue whether or not the init process is working for the card. Also, when the machine is running, can you do the following? /sbin/ip link set dev eth0 up /sbin/ifconfig and post the output of the 'ifconfig'. Thanks! Dan Output of dmesg. I'll attach the file in it's entirety, but this is the only lines I can see that may have something to do with eth0 (warning: untrained eye included in my head): b44.c:v0.95 (Aug 3, 2004)b44.c:v0.95 (Aug 3, 2004) ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 ACPI: PCI interrupt 0000:02:00.0[A] -> GSI 11 (level, low) -> IRQ 11 eth0: Broadcom 4400 10/100BaseT Ethernet 00:11:43:64:74:dc ieee80211_crypt: registered algorithm 'NULL' Created attachment 112233 [details]
output of dmesg
various output from /var/log/messages: Mar 21 09:34:20 jellyfish kernel: b44.c:v0.95 (Aug 3, 2004) Mar 21 09:34:20 jellyfish kernel: ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 Mar 21 09:34:20 jellyfish kernel: ACPI: PCI interrupt 0000:02:00.0[A] -> GSI 11 (level, low) -> IRQ 11 Mar 21 09:34:21 jellyfish kernel: eth0: Broadcom 4400 10/100BaseT Ethernet 00:11:43:64:74:dc Actually, that's pretty much the gist of it. There's a couple of these (most likely from each time I've started FC4-t1 and the are all roughly equivalent (I couldn't see any differences) with the exception of the hostname which vaires depending on where I am. Output from doing the following: /sbin/ip link set dev eth0 up /sbin/ifconfig [rodd@jellyfish ~]$ /sbin/ip link set dev eth0 up SIOCSIFFLAGS: Permission denied [rodd@jellyfish ~]$ sudo /sbin/ip link set dev eth0 up [rodd@jellyfish ~]$ /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 00:11:43:64:74:DC inet6 addr: fe80::211:43ff:fe64:74dc/64 Scope:Link UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:5 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:398 (398.0 b) Interrupt:11 eth1 Link encap:Ethernet HWaddr 00:0E:35:CD:79:90 inet addr:192.168.0.111 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::20e:35ff:fecd:7990/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:28587 errors:0 dropped:2 overruns:0 frame:0 TX packets:22386 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:39616155 (37.7 MiB) TX bytes:1410962 (1.3 MiB) Interrupt:7 Base address:0xe000 Memory:faffc000-faffcfff lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:1884 errors:0 dropped:0 overruns:0 frame:0 TX packets:1884 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2366264 (2.2 MiB) TX bytes:2366264 (2.2 MiB) [rodd@jellyfish ~]$ This is with the cable out (since this is what the bug is about). If you want the cable in, the tell me. Also, I had the run the first command as sudo to get it to work. Does this still happen with the newest kernel? yes this is still happening. kernel-2.6.11-1.1177_FC4 Boot stalls for about 30 seconds (a guess) while eth0 tries to get an IP address. I'm unable to change the status back to NEW (nothing in the change status to select box in bugzilla) so someone will need to do this for me. 1177 is ancient now. Todays is 1275, and theres a lot of changes between the two. Please give that a try. Ah, bugger. Bit of a cut and paste faux paux that. That should have been: kernel-2.6.11-1.1268_FC4 I've just tested kernel-2.6.11-1.1275_FC4 and I'm getting the same thing. Here's some output from the boot if that might help: Bringing up loopback interface: [ OK ] Bringing up interface eth0: Determining IP information for eth0...audit(1114737070.474:0): avc: denied { ioctl } for path=/proc/2384/mounts dev=proc ino=156237841 scontext=system_u:system_r:hotplug_t tcontext=system_u:system_r:hotplug_t tclass=file failed. [FAILED] Bringing up interface eth1: Determining IP information for eth1...audit(1114737140.039:0): avc: denied { read } for name=config dev=hda9 ino=911654 scontext=system_u:system_r:dhcpc_t tcontext=user_u:object_r:selinux_config_t tclass=file audit(1114737140.040:0): avc: denied { getattr } for path=/etc/selinux/config dev=hda9 ino=911654 scontext=system_u:system_r:dhcpc_t tcontext=user_u:object_r:selinux_config_t tclass=file done. [ OK ] eth0 still 'pauses' for about 30-40 seconds (a "one-thousand-and-one, two-thousand-and-two" guestimate.) and then fails (which is should because no cable is present) To be clear, when eth0 is plugged-in to a properly functioning network (w/ a DHCP server), does the device work? I'm presuming so, but it is better to ask, just in case... :-) yeah, fair question. eth0 works fine in every other way. If connected to a functioning network the connection goes up fast and AFAIK remains very solid. The only thing it doesn't do is notice when a cable isn't connected (or when the cable is connected but isn't plugged into anything) and it then takes for ever to give up (really slowing down boot times) I have included a patch to check the link state early for b44 in the kernels here: http://people.redhat.com/linville/kernels/fc4/ Please give them a try and post the results here. Thanks! is b44 correctly hooked up to ((ethtool OR mii) AND netlink)? Those at least are prereqs of having the card function correctly with NetworkManager and hal. Dan, how would I tell these things? What commands do I need to run, or what config files do I need to look at. I haven't fiddled with any of the settings that FC4t3 created for this network card. John, installed the kernel you provided, but there wasn't any noticable improvement to the situation. Is this the right one: kernel-2.6.11-1.1363.2.1_FC4.jwltest.5 Rodd: it was more a question for John Linville since he seems to be somewhat familiar with the b44 driver code... Dan, both ethtool and mii-tool are supported...not sure what you mean exactly by netlink, as there isn't much a driver does to support that. What netlink messages are involved? Certainly the netif_carrier_* macros and other standard APIs are used... On my box, the patch from comment 15 actually changed the delay when attempting to bring-up the b44 card w/o a link from ~1 minute to just 4 seconds (which is a standard timeout while waiting for link-up). Without that patch, using ethtool to check the link state too soon after doing the loading the module (which ifup does in quick succession) would show the link as up even w/ no wire attached. After about 1 second, then it would show the correct link status. After the patch, link status is correctly reflected from the beginning. Interesting, mii-tool always showed the correct link status (but ifup still checks ethtool even if mii-tool says the link is down). Considering that mii-tool gave you "No MII transceiver present!" and that ethtool seems to always return link-up for you, I'm guessing that your b44 card has different PHY hardware than what I have (and likely than what the b44 driver knows about). I'll have to dig around to see if I can find an answer here... Regarding the B44_FLAG_INIT_COMPLETE flag (see comment 1), that flag gets set as soon as "ip link set dev eth0 up" completes. I would like to see the results of doing that command before executing "mii-tool" and "ethtool", just in case that effects the results. Also, if you are using NetworkManager then you probably should just edit /etc/sysconfig/network-scripts/ifcfg-eth0 and change the ONBOOT line to "ONBOOT=no". That should eliminate your boot-up delay. Of course, NM may get confused if mii-tool doesn't work and ethtool always says the link is up, so YMMV... :-) Anyway, please let me know if this suggestion is helpful, and don't forget to post the output of "mii-tool" and "ethtool" after executing "ip link set dev eth0 up"...thanks! Created attachment 115227 [details]
jwltest-b44-link-check.patch
Patch to check link state during open...
John, I'm a little bit of a semi-newbie when it comes to this sort of thing. As such I might need a little hand holding, but I'm more than happy to try and help you with anything you might wish to know. Please try to give me instructions on what to do so that I'm not stabbing in the dark. That said, here's a stab in the dark that might yield some information. [rodd@jellyfish ~]$ su - Password: [root@jellyfish ~]# echo $B44_FLAG_INIT_COMPLETE [root@jellyfish ~]# ip link set dev eth0 up [root@jellyfish ~]# echo $B44_FLAG_INIT_COMPLETE [root@jellyfish ~]# ifconfig eth0 Link encap:Ethernet HWaddr 00:11:43:64:74:DC inet6 addr: fe80::211:43ff:fe64:74dc/64 Scope:Link UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:176 (176.0 b) Interrupt:11 eth1 Link encap:Ethernet HWaddr 00:0E:35:CD:79:90 inet addr:192.168.0.111 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::20e:35ff:fecd:7990/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1458 errors:0 dropped:0 overruns:0 frame:0 TX packets:1160 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1062193 (1.0 MiB) TX bytes:98116 (95.8 KiB) Interrupt:7 Base address:0xe000 Memory:faffc000-faffcfff lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2645 errors:0 dropped:0 overruns:0 frame:0 TX packets:2645 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1926836 (1.8 MiB) TX bytes:1926836 (1.8 MiB) [root@jellyfish ~]# echo $B44_FLAG_INIT_COMPLETE [root@jellyfish ~]# Oh, and I'm not using NetworkManager yet as it doesn't really help me any (in my particular case) and I've got hardware/software issues with related stuff, so it's hard to tell if problems I've got are to do with NM or elsewhere. Mostly I just don't move my latop enough to need NM. OK, so disregard comment 20 if you are not using NM... :-) B44_FLAG_INIT_COMPLETE is something that exists in the source code for the b44 driver, not something that you would see at the shell prompt. I only mentioned it with regard to comment 1, mostly for the sake of Dan's interest. So presuming that eth0 is your b44 interface, I'd like to see the output from this command sequence: # ip link set dev eth0 up # mii-tool eth0 # ethtool eth0 Please either use my kernel or wait at least 1 second between the "ip" command and the "mii-tool" command, just to be sure... Here's the output. I hope this adds something to the discussion. [root@goose ~]# ip link set dev eth0 up [root@goose ~]# mii-tool eth0 eth0: no link [root@goose ~]# ethtool eth0 Settings for eth0: Supported ports: [ MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 1000baseT/Full Advertised auto-negotiation: Yes Speed: 10Mb/s Duplex: Half Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on Current message level: 0x000000ff (255) Link detected: no [root@goose ~]# Rodd: is the output from line 25 with the cable plugged _in_, or is the cable detached? RE: comment 16...I had neglected to copy the right kernels out there... :-( Please try again w/ the kernels at the location from comment 13...I think these will work better! :-) Please post the results here...thanks! The cable was NOT plugged in (too lazy to get up of the couch and find a plug). Did it need to be plugged in??? All of the stuff below is without a cable connected. Okay, using the 'right' ;-] kernel I get: [rodd@jellyfish ~]$ sudo su - Password: [root@jellyfish ~]# ip link set dev eth0 up [root@jellyfish ~]# mii-tool eth0 eth0: no link [root@jellyfish ~]# ethtool eth0 Settings for eth0: Supported ports: [ MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 1000baseT/Full Advertised auto-negotiation: Yes Speed: 10Mb/s Duplex: Half Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on Current message level: 0x000000ff (255) Link detected: no [root@jellyfish ~]# More importantly, look at this output: [root@jellyfish ~]# ifup eth0 Determining IP information for eth0... failed; no link present. Check cable? [root@jellyfish ~]# I think we might be on to something. So, of course, the question is: using the 'right' kernel, with the eth0 cable _un_plugged, does the boot process proceed past the attempt to bring-up eth0 w/ minimal (i.e. a few seconds) delay? John, in a word - "YES"! This works in the way I would expect it too. Excellent! That is good news...especially since I already sent that patch upstream... :-) This should filter into the FC4 kernel in a future update, hopefully not too long from now...thanks! |