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!