Bug 151777 - cable link state ignored on ethernet card (b44).
cable link state ignored on ethernet card (b44).
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: John W. Linville
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-22 04:59 EST by Rodd Clarkson
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-06-16 08:22:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output of dmesg (16.62 KB, text/plain)
2005-03-22 17:40 EST, Rodd Clarkson
no flags Details
jwltest-b44-link-check.patch (334 bytes, patch)
2005-06-08 13:08 EDT, John W. Linville
no flags Details | Diff

  None (edit)
Description Rodd Clarkson 2005-03-22 04:59:43 EST
Description of problem:

I've just moved from a Compaq Armada to a Dell Latitude and one of the
first things I noticed was that during boot-up the network card in the
Dell seems to think it's 'plugged-in' even when there is no cable there.

For example, when the compaq booted, it would note that there was no
cable connected and just move on (instead of stalling while trying to
start a netword card that wasn't connected).  The Dell, however, stalls
for a while, trying to establish the impossible (a wired connection
without a cable).

Is this a bug, and if so, should it be reported?  The wired connection
(when I've used it) seems to work well, although I haven't given it
anything stressful to really test it.


Version-Release number of selected component (if applicable):

kernel-2.6.11-1.1191_FC4


Additional info:

This is the output from mii-tool and ethtool:

[root@localhost ~]# mii-tool eth0
  No MII transceiver present!.
[root@localhost ~]# ethtool eth0
Settings for eth0:
Cannot get device settings: Resource temporarily unavailable
        Current message level: 0x000000ff (255)
        Link detected: yes
[root@localhost ~]#



Dan Williams asked for the output from lspci and lsmod:

[root@goose ~]# lspci
00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller (rev 03)
00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #3 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI
Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81)
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge
(rev 01)
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97
Modem Controller (rev 01)
01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon
9600 M10]
02:00.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01)
02:01.0 CardBus bridge: Texas Instruments PCI4510 PC card Cardbus Controller
(rev 02)
02:01.1 FireWire (IEEE 1394): Texas Instruments PCI4510 IEEE-1394 Controller
02:03.0 Network controller: Intel Corporation PRO/Wireless 2915ABG MiniPCI
Adapter (rev 05)

[root@goose ~]# lsmod
Module                  Size  Used by
loop                   16969  0
parport_pc             28933  0
lp                     12617  0
parport                40713  2 parport_pc,lp
autofs4                26949  0
sunrpc                167813  1
pcmcia                 26465  2
ipt_REJECT              6849  1
ipt_state               1857  3
ip_conntrack           40729  1 ipt_state
iptable_filter          2881  1
ip_tables              19521  3 ipt_REJECT,ipt_state,iptable_filter
dm_mod                 59989  0
video                  16069  0
button                  6609  0
battery                 9413  0
ac                      4805  0
md5                     4161  1
ipv6                  265089  18
ohci1394               40409  0
ieee1394              310041  1 ohci1394
yenta_socket           21065  1
rsrc_nonstatic         10433  1 yenta_socket
pcmcia_core            48761  3 pcmcia,yenta_socket,rsrc_nonstatic
uhci_hcd               33497  0
ehci_hcd               40397  0
snd_intel8x0m          18949  0
snd_intel8x0           34561  2
snd_ac97_codec         71609  2 snd_intel8x0m,snd_intel8x0
snd_pcm_oss            52081  0
snd_mixer_oss          18497  1 snd_pcm_oss
snd_pcm               100937  4
snd_intel8x0m,snd_intel8x0,snd_ac97_codec,snd_pcm_oss
snd_timer              33605  1 snd_pcm
snd                    56613  11
snd_intel8x0m,snd_intel8x0,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
soundcore              10913  1 snd
snd_page_alloc          9669  3 snd_intel8x0m,snd_intel8x0,snd_pcm
ipw2200                75085  0
ieee80211              23365  1 ipw2200
ieee80211_crypt         7493  1 ieee80211
b44                    26565  0
mii                     4929  1 b44
ext3                  133449  3
jbd                    85849  1 ext3
Comment 1 Dan Williams 2005-03-22 09:27:10 EST
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
Comment 2 Rodd Clarkson 2005-03-22 17:39:28 EST
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'
Comment 3 Rodd Clarkson 2005-03-22 17:40:49 EST
Created attachment 112233 [details]
output of dmesg
Comment 4 Rodd Clarkson 2005-03-22 17:44:23 EST
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.
Comment 5 Rodd Clarkson 2005-03-22 17:47:02 EST
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.
Comment 6 Jeremy Katz 2005-04-27 19:28:59 EDT
Does this still happen with the newest kernel?
Comment 7 Rodd Clarkson 2005-04-27 20:58:50 EDT
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.
Comment 8 Dave Jones 2005-04-28 20:37:58 EDT
1177 is ancient now. Todays is 1275, and theres a lot of changes between the
two. Please give that a try.
Comment 9 Rodd Clarkson 2005-04-28 21:06:39 EDT
Ah, bugger.  Bit of a cut and paste faux paux that.

That should have been:

kernel-2.6.11-1.1268_FC4
Comment 10 Rodd Clarkson 2005-04-28 21:19:04 EDT
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)
Comment 11 John W. Linville 2005-06-06 15:35:20 EDT
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... :-) 
Comment 12 Rodd Clarkson 2005-06-06 19:47:33 EDT
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)
Comment 13 John W. Linville 2005-06-07 12:55:07 EDT
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! 
 
 
Comment 14 Dan Williams 2005-06-07 13:03:30 EDT
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.
Comment 15 Rodd Clarkson 2005-06-07 17:20:29 EDT
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.
Comment 16 Rodd Clarkson 2005-06-07 17:32:16 EDT
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
Comment 17 Dan Williams 2005-06-07 19:26:35 EDT
Rodd: it was more a question for John Linville since he seems to be somewhat
familiar with the b44 driver code...
Comment 18 John W. Linville 2005-06-08 12:28:16 EDT
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... 
Comment 19 John W. Linville 2005-06-08 13:00:19 EDT
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. 
Comment 20 John W. Linville 2005-06-08 13:05:43 EDT
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! 
Comment 21 John W. Linville 2005-06-08 13:08:15 EDT
Created attachment 115227 [details]
jwltest-b44-link-check.patch

Patch to check link state during open...
Comment 22 Rodd Clarkson 2005-06-08 19:09:37 EDT
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 ~]#
Comment 23 Rodd Clarkson 2005-06-08 20:09:57 EDT
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.
Comment 24 John W. Linville 2005-06-09 09:48:10 EDT
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... 
Comment 25 Rodd Clarkson 2005-06-13 07:56:37 EDT
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 ~]#
Comment 26 Dan Williams 2005-06-13 09:31:59 EDT
Rodd: is the output from line 25 with the cable plugged _in_, or is the cable
detached?
Comment 27 John W. Linville 2005-06-13 10:22:10 EDT
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! 
Comment 28 Rodd Clarkson 2005-06-13 20:24:38 EDT
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???
Comment 29 Rodd Clarkson 2005-06-13 20:41:33 EDT
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.
Comment 30 John W. Linville 2005-06-14 09:08:04 EDT
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? 
Comment 31 Rodd Clarkson 2005-06-15 20:39:47 EDT
John, in a word - "YES"!

This works in the way I would expect it too.
Comment 32 John W. Linville 2005-06-16 08:22:32 EDT
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! 

Note You need to log in before you can comment on or make changes to this bug.