Bug 486601 - Broadcom BCM5787 reports "no link present" when trying to get an IP address via DHCP
Broadcom BCM5787 reports "no link present" when trying to get an IP address v...
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.3
All Linux
low Severity high
: rc
: 5.5
Assigned To: Andy Gospodarek
Red Hat Kernel QE team
:
Depends On:
Blocks: 533192
  Show dependency treegraph
 
Reported: 2009-02-20 10:20 EST by Avinash Meetoo
Modified: 2014-06-29 19:01 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-18 22:02: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)
Increase the default delay from 5s to 20s and sanitize variable names (825 bytes, patch)
2009-02-21 04:01 EST, Avinash Meetoo
no flags Details | Diff
Patch to sanitize variable names and simplify logic (762 bytes, patch)
2009-02-27 04:02 EST, Avinash Meetoo
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
CentOS 3348 None None None Never

  None (edit)
Description Avinash Meetoo 2009-02-20 10:20:24 EST
Description of problem:

I have a number of brand new PCs (Dell Optiplex 330 running Centos 5.2 x86_64) with a Broadcom Corporation NetLink BCM5787 Gigabit Ethernet NIC and they all fail to get their IP address from a DHCP server (also running Centos 5.2 x86_64) with the following error message:

    "eth0 failed; no link present. Check cable?"

After googling, I have found that adding this:

    check_link_down () {
       return 1;
    }

to /etc/sysconfig/network-scripts/ifcfg-eth0 cures the problem. My interpretation is that the predefined check_link_down() function (in initscripts) does not properly work with the BCM5787 NIC which is very common now. Of course, check_link_down() (which is found in /etc/sysconfig/network-scripts/network-functions) relies on mii-tool and/or ethtool which may be the culprits.

Another possibility is to add LINKDELAY=20 to ifcfg-eth0 (at least) and removing the check_link_down() function and this also works.

So, in a certain way, this is not really a bug but a "feature"... But, on the other hand, as the BCM5787 is a relatively common Ethernet device (being used in a lot of Dell computers for instance), it is important, IMHO, that it works with DHCP without having to edit ifcfg-eth0 manually.

[Incidentally, I've tried something else. I've booted the PC with the Centos installation disk and chosen askmethod to do an HTTP network installation. The DHCP client works correctly as, as far as I can see, the DHCP request has default timeout of 45s (this is what is written on the console) which is sufficient for the link to become up and for the DHCP server to offer an IP. I wonder why the same timeout (i.e. 45s) is not used when Linux is installed and boots. Seems like an incoherency to me. Or am I missing something?]

Steps to Reproduce:
1. Use a NIC with the Broadcom BCM5787 chipset
2. Configure it to obtain its IP address through DHCP
3. Reboot (or service network restart)
  
Actual results:

"No link present" error message.

Expected results:

An IP address should have been leased to the NIC.

Additional info:

I am a Centos 5.2 user actually and I've reported the bug there and I was advised to report the issue upstream. Incidentally, there is no Centos 5.3 yet and therefore I do not know if RHEL 5.3 solves this issue or not.
Comment 1 Bill Nottingham 2009-02-20 10:28:10 EST
This would be a driver bug, if it's lying about the link state. If it's just taking longer, setting LINKDELAY to something else (or checking the configuration of your switch w.r.t. portfast) would also work.
Comment 2 R Duffy 2009-02-20 15:53:50 EST
I am having this issue with 64-bit Centos 5.2 on an Asus P5Q-EM motherboard(Realtek® 8111C lan controller).

I dont believe it is a driver problem, because I have had no problems with the NIC in Ubuntu or Slackware.  Only CentOS.
Comment 3 Avinash Meetoo 2009-02-21 00:43:19 EST
My opinion is that the driver is fine (it works with LINKDELAY=20 for instance.)

I've checked the /etc/init.d/network, /etc/sysconfig/network-scripts/ifup, /etc/sysconfig/network-scripts/ifup-eth0 and /etc/sysconfig/network-scripts/network-functions and the problematic lines seem to be in the check_link_down function in network-functions:

check_link_down ()
{
    if [ -x /sbin/mii-tool -o -x /sbin/ethtool ]; then
        if ! LC_ALL=C ip link show dev $1 2>/dev/null| grep -q UP ; then
           ip link set dev $1 up >/dev/null 2>&1
        fi
        timeout=0
        delay=10
        [ -n "$LINKDELAY" ] && delay=$(($LINKDELAY * 2))
        while [ $timeout -le $delay ]; do
            check_mii_tool $1
            m=$?
            check_ethtool $1
            e=$?

etc. etc.

check_link_down verifies if there is currently a LINKDELAY variable set and if this is the case uses it as the delay (maximum time to wait for the link to become up.) But, if that variable is not set, then a default of 10(s?) is used.

Why 10? Why not more? An obvious solution would be to increase this delay to, say, 30. Any compelling reason not to do that?
Comment 4 Avinash Meetoo 2009-02-21 00:47:34 EST
rpm -qf /etc/sysconfig/network-scripts/network-functions

returns

initscripts-8.45.19.1.EL-1.el5.centos

so I am (re)assigning this bug to the initscripts component (as it is not a kernel bug.) Note that I am using the word bug "loosely" :-)
Comment 5 Avinash Meetoo 2009-02-21 04:01:17 EST
Created attachment 332794 [details]
Increase the default delay from 5s to 20s and sanitize variable names
Comment 6 Avinash Meetoo 2009-02-21 04:04:53 EST
The above patch does the following:

(1) The timeout before a link is reported as being absent is increased from 5s to 20s (the Broadcom BCM5787, for instance, requires about 17s)

(2) Variable names are sanitized (timeout becomes attempts and delay becomes timeout for example)

I've tested it and it works. If LINKDELAY is not set, then the (new) default of 20s is used. If LINKDELAY exists in ifcfg-eth?, then, of course, that definition overrides the default.
Comment 7 Bill Nottingham 2009-02-25 18:01:12 EST
The reason not to do that is that 99.9% of cards work with the current default, and increasing it to really long delays like 10, 20, 30 seconds annoys all the owners of such cards when there isn't a link.
Comment 8 Avinash Meetoo 2009-02-26 00:05:45 EST
I understand that waiting 5s is more tolerable than waiting 20s but the Broadcom BCM5787 is very common now especially in the corporate environment (it's found on all new Dell Optiplex PC for instance) and it should really work "out of the box" with DHCP both with RHEL or CentOS.

As far as I can see, check_link_down() does not have any chipset-specific code (and this is a good thing) and both mii-tool and ethtool return immediately (they don't wait for the link to become up.)

Any possibility of making the timeout chipset dependent (apart from manually updating ifcfg-eth0 of course?)  Something like a file containing "problematic" chipsets with their specific timeouts and which check_link_down() takes into account?
Comment 9 Bill Nottingham 2009-02-26 09:48:44 EST
By 'return immediately', you mean they claim the link is up when it isn't?
Comment 10 Andy Gospodarek 2009-02-26 13:48:21 EST
So the complaint is that it takes too more time than it should for the link to be reported as up after issuing a command like 'ifconfig eth0 up' on the system?

I don't think there are any fixes yet, but have you tried this with the latest (5.3) driver?  I don't want to chase something that's already been fixed.  Thanks!
Comment 11 Avinash Meetoo 2009-02-27 02:26:45 EST
(In reply to comment #9)
> By 'return immediately', you mean they claim the link is up when it isn't?

No. They correctly report that the link is down immediately. check_link_down() does this check at most 10 times currently (this takes at most 5s because checks are done every half a second) and this is not sufficient for the Broadcom BCM5787 which requires about 17s to detect the link.
Comment 12 Avinash Meetoo 2009-02-27 02:44:11 EST
(In reply to comment #10)
> So the complaint is that it takes too more time than it should for the link to
> be reported as up after issuing a command like 'ifconfig eth0 up' on the
> system?

Yes. The Broadcom BCM5787 takes 17s.

> I don't think there are any fixes yet, but have you tried this with the latest
> (5.3) driver?  I don't want to chase something that's already been fixed. 
> Thanks!

Not yet because Centos 5.3 has not been released yet. The Broadcom BCM5787 uses the tg3 driver by the way.

I'll wait for Centos 5.3 and then report if anything changes...
Comment 13 Avinash Meetoo 2009-02-27 04:02:54 EST
Created attachment 333447 [details]
Patch to sanitize variable names and simplify logic

This patch is the same as the previous patch except that the timeout is kept as 5s. In essence, I have renamed some variables so that they make more sense and streamlined the logic. I believe the patch increased the readability of check_link_down() function found in network-functions.

I've tested the patch and it works.
Comment 14 Bill Nottingham 2009-02-27 16:04:13 EST
Given that the patch doesn't actually change the behavior... not sure it's worth it.
Comment 15 Andy Gospodarek 2009-02-27 16:21:45 EST
(In reply to comment #12)
> (In reply to comment #10)
> > So the complaint is that it takes too more time than it should for the link to
> > be reported as up after issuing a command like 'ifconfig eth0 up' on the
> > system?
> 
> Yes. The Broadcom BCM5787 takes 17s.
> 

17s to link up?  That is waaaay too long.

> > I don't think there are any fixes yet, but have you tried this with the latest
> > (5.3) driver?  I don't want to chase something that's already been fixed. 
> > Thanks!
> 
> Not yet because Centos 5.3 has not been released yet. The Broadcom BCM5787 uses
> the tg3 driver by the way.
> 
> I'll wait for Centos 5.3 and then report if anything changes...

Feel free to try kernels here if you like:

http://people.redhat.com/agospoda/#rhel5

They are based on 5.3 with some extra patches.
Comment 16 Matt Carlson 2009-02-27 16:43:46 EST
You know, I started seeing this behavior on one of my boxes too.  I haven't gotten to the bottom of it yet, but it looks like a kernel problem.

Here is what I'm seeing :

1) In another terminal, I run 'tail -f /var/log/messages'.
2) In the main terminal, I run 'ifconfig eth0 192.168.0.2 && ping 192.168.0.1'.

I can see that the driver reports link up within an acceptable amount of time (~3 seconds), but the pings will fail for about another 30 seconds.

Avinash,
Is this what you are seeing?  Is there a way for you to confirm this behavior?
Comment 17 Matt Carlson 2009-02-27 16:46:18 EST
Oh.  And I should probably add one more thing.  On the box where this problem exists, the bnx2 driver against the 5708 also has the same problem.  This is why I suspect a kernel problem rather than a driver problem.
Comment 18 Bill Nottingham 2009-02-27 16:50:26 EST
Outside of any kernel problems, the other issue could be switch settings...
Comment 19 Andy Gospodarek 2009-02-27 17:25:11 EST
This is starting to sound like a spanning-tree issue rather than a driver one.
Comment 20 Andy Gospodarek 2009-02-27 17:27:36 EST
Avinash, I am also curious what 'ethtool eth0' reports during the time while you are waiting for 'ifup eth0' to fail.
Comment 21 Avinash Meetoo 2009-04-07 07:16:36 EDT
(In reply to comment #10)
> I don't think there are any fixes yet, but have you tried this with the latest
> (5.3) driver?  I don't want to chase something that's already been fixed. 

I've finally managed to do the same test with the recently released Centos 5.3 and I have the same issue!

If I don't add LINKDELAY=X (where X >= 17) to ifcfg-eth0, I get the "no link present error".

(In reply to comment #20)
> Avinash, I am also curious what 'ethtool eth0' reports during the time while
> you are waiting for 'ifup eth0' to fail.  

While doing an ifup eth0, ethtool eth0 reports:

        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: g
        Current message level: 0x000000ff (255)
        Link detected: no

So the problem is still not resolved even with the new driver in RHEL / Centos 5.3 and I still think this is a major problem as the Broadcom BCM5787 is so common now.
Comment 22 Andy Gospodarek 2009-04-08 12:06:25 EDT
If you boot the box without any of the delays (so the stock setup that fails), and type:

# ethtool eth0
# ifconfig eth0 up
# ethtool eth0

What does the output look like?

If your system is set to to dhcp and spanning-tree is enabled on the switches, the first ifup will fail since the system won't be able to get an address (due to spanning tree not allowing any traffic out for 30s after the port first goes 'link-up'), so the output in comment #21 is not surprising.
Comment 23 Avinash Meetoo 2009-04-10 01:55:21 EDT
(In reply to comment #22)
> If you boot the box without any of the delays (so the stock setup that fails),
> and type:
> 
> # ethtool eth0
> What does the output look like?

[root@localhost ~]# ethtool eth0
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Advertised auto-negotiation: Yes
        Speed: Unknown! (0)
        Duplex: Half
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: g
        Current message level: 0x000000ff (255)
        Link detected: no

> # ifconfig eth0 up

No output

> # ethtool eth0

[root@localhost ~]# ethtool eth0
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Advertised auto-negotiation: Yes
        Speed: Unknown! (65535)
        Duplex: Unknown! (255)
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: g
        Current message level: 0x000000ff (255)
        Link detected: no

I also did:

[root@localhost ~]# ifup eth0

Determining IP information for eth0... failed; no link present.  Check cable?

and

[root@localhost ~]# ethtool eth0
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Advertised auto-negotiation: Yes
        Speed: Unknown! (0)
        Duplex: Half
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: g
        Current message level: 0x000000ff (255)
        Link detected: no

The only way for me to get an IP address is to add LINKDELAY=60 to ifcfg-eth0

> If your system is set to to dhcp and spanning-tree is enabled on the switches,
> the first ifup will fail since the system won't be able to get an address (due
> to spanning tree not allowing any traffic out for 30s after the port first goes
> 'link-up'), so the output in comment #21 is not surprising.  

I am not sure I understand. By the way, the computer and DHCP server I'm using are directly connected to a Linksys SR2024 switch.
Comment 24 Andy Gospodarek 2009-04-14 09:23:32 EDT
Just so everyone is aware, there are some issues with x86-64 kernels running on at least the following HP systems:

    * HP ProLiant DL165 G5 Server
    * HP ProLiant DL185 G5 Server
    * HP ProLiant DL365 G5 Server
    * HP ProLiant BL685c G5 Server
    * HP ProLiant DL385 G5 Server
    * HP ProLiant DL585 G5 Server
    * HP ProLiant DL165 G5p Server
    * HP ProLiant DL385 G5p Server
    * HP ProLiant DL785 G5 Server

The recommendation is to make sure that the BIOS is set so that Power regulator is set to "OS Control" rather than any sort of "Low Power Mode."  I was able to reproduce this problem on a DL585 and after switching the RBSU setting I no longer saw the problem as the delay was now appropriate.  See the link below for more info:

http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&taskId=110&prodSeriesId=3646113&prodTypeId=15351&prodSeriesId=3646113&objectID=c01676204

I realize not everyone making complaints is using an HP system, but I wanted to make sure this was brought to everyone's attention.
Comment 25 David Brodbeck 2009-07-06 20:13:54 EDT
For what it's worth, I'm seeing the same problem with RedHat Enterprise Linux 5.3 on five Dell Optiplex 360 systems, which use the same Broadcom chipset.  It was very difficult to troubleshoot because it's not consistent; the systems will occasionally link up quickly enough to successfully get an IP, but more often time out.  I spent quite a while fruitlessly checking cables before I found this bug report.

I have a suspicion that the long delay may be auto-negotiation related as a system on a different hub came up more reliably (though still not 100%).

Increasing LINKDELAY successfully worked around the problem for me; perhaps this should be in the release notes?
Comment 26 Avinash Meetoo 2009-07-07 05:51:54 EDT
I still have the same problem with the latest CentOS 5.3 (based on RHEL 5.3) I still need to add an appropriate LINKDELAY to ifcfg-eth0 for the NIC to get an IP address from a DHCP server.

Interestingly, I also booted the PC with a Linux Mint 7 live disk (which is based on Ubuntu which is itself based on Debian) and it works flawlessly (i.e. the NIC is given an IP address) so it seems that there is a bug in RHEL (and CentOS) somewhere...
Comment 27 Andy Gospodarek 2009-07-07 08:47:37 EDT
(In reply to comment #25)
> For what it's worth, I'm seeing the same problem with RedHat Enterprise Linux
> 5.3 on five Dell Optiplex 360 systems, which use the same Broadcom chipset.  It
> was very difficult to troubleshoot because it's not consistent; the systems
> will occasionally link up quickly enough to successfully get an IP, but more
> often time out.  I spent quite a while fruitlessly checking cables before I
> found this bug report.
> 
> I have a suspicion that the long delay may be auto-negotiation related as a
> system on a different hub came up more reliably (though still not 100%).
> 
> Increasing LINKDELAY successfully worked around the problem for me; perhaps
> this should be in the release notes?  

When you are booting the system and it fails, does the time-out of the tg3-based device waiting for link-up seem to time-out quickly?

When I was able to reproduce this, the timeout was much shorter than the 5 seconds (usually 2-3 seconds, but at times almost instant).
Comment 28 Andy Gospodarek 2009-07-07 08:48:15 EDT
(In reply to comment #26)
> I still have the same problem with the latest CentOS 5.3 (based on RHEL 5.3) I
> still need to add an appropriate LINKDELAY to ifcfg-eth0 for the NIC to get an
> IP address from a DHCP server.
> 
> Interestingly, I also booted the PC with a Linux Mint 7 live disk (which is
> based on Ubuntu which is itself based on Debian) and it works flawlessly (i.e.
> the NIC is given an IP address) so it seems that there is a bug in RHEL (and
> CentOS) somewhere...  

(Same question to you.)

When you are booting the system and it fails, does the time-out of the
tg3-based device waiting for link-up seem to time-out quickly?

When I was able to reproduce this, the timeout was much shorter than the 5
seconds (usually 2-3 seconds, but at times almost instant).
Comment 29 David Brodbeck 2009-07-07 12:44:33 EDT
I think it was consistently waiting 5 seconds for me.  I admit I didn't time it, but there was always a pause before it failed.
Comment 30 Dave Jones 2009-07-31 19:17:44 EDT
May I ask how you add

"
    check_link_down () {
       return 1;
    }
"

or

"LINKDELAY=20 to ifcfg-eth0" & "check_link_down()"

to the iso that "cobbler buildiso" creates?

On HP DL385 G5p boxes I'm seeing issues with the bnx2 driver, I believe, so I cannot get an IP address and finish the install.
If I could install a new kernel module into the kickstart.iso or implement the previous suggestions, I suspect my issue may be solved.
I have the 4 "NetXstream II" nics, the BCM570x series.

Thanks,
Dave
Comment 31 Andy Gospodarek 2009-10-28 17:20:22 EDT
(In reply to comment #30)
> May I ask how you add
> 
> "
>     check_link_down () {
>        return 1;
>     }
> "
> 
> or
> 
> "LINKDELAY=20 to ifcfg-eth0" & "check_link_down()"
> 
> to the iso that "cobbler buildiso" creates?
> 
> On HP DL385 G5p boxes I'm seeing issues with the bnx2 driver, I believe, so I
> cannot get an IP address and finish the install.
> If I could install a new kernel module into the kickstart.iso or implement the
> previous suggestions, I suspect my issue may be solved.
> I have the 4 "NetXstream II" nics, the BCM570x series.
> 
> Thanks,
> Dave  

Dave, comment #24 should help you resolve your problem.  Please check your BIOS settings as it is likely that system has the problems described in the link there.
Comment 32 Andy Gospodarek 2009-10-28 17:32:05 EDT
I'm not really sure what should be done about this bug.

There are a class of users who are using HP systems listed in comment #24 whose problems will likely be resolved by the suggestion from HP.

There are some users on Dell systems that are seeing similar problems.  Could the chipset be similar to what is being used on the HP boxes?

Matt at Broadcom is seeing some problems on a box with a tg3-based and bnx2-based interfaces.

I also don't think I've heard any feedback as to whether:

- RHEL5.4 makes a difference

or

- IPMI or another management module might be contending with the MAC/PHY of these chips and preventing quick initialization.

Any feedback on either of these two queries would be greatly appreciated.
Comment 33 David Brodbeck 2009-10-28 17:37:42 EDT
The Dell workstations I'm seeing it on are not IPMI equipped.
Comment 34 Matt Carlson 2009-10-28 17:54:28 EDT
In my experience, I've never seen IPMI to introduce these types of problems.  The interrupt and link event report seem to arrive in a timely manner.  It looks as though the problem is at a higher layer.

I haven't seen this problem in a while though.
Comment 35 Andy Gospodarek 2009-10-29 11:35:35 EDT
(In reply to comment #33)
> The Dell workstations I'm seeing it on are not IPMI equipped.  

Thanks.  I did not expect that they were, but wanted to rule it out.  Did you happen to test with the latest RHEL5 kernel -- 2.6.18-164 or newer?
Comment 36 David Brodbeck 2009-10-29 14:29:12 EDT
I haven't yet.  I'll try taking out the LINKDELAY workaround on one of our machines and see what happens.  Probably won't get a chance until early next week.
Comment 37 Andy Gospodarek 2009-10-29 14:33:55 EDT
(In reply to comment #36)
> I haven't yet.  I'll try taking out the LINKDELAY workaround on one of our
> machines and see what happens.  Probably won't get a chance until early next
> week.  

Sounds great.

It can be extremely hard for us to fix these problems (or even check to see that they are fixed) when I don't have access to the hardware, so I appreciate any testing that can be done by reporters et al.
Comment 38 Avinash Meetoo 2009-10-30 01:59:49 EDT
I have tried omitting LINKDELAY with the latest kernel (2.6.18-164.el5 SMP) and this still does not work...
Comment 39 David Brodbeck 2009-11-05 15:14:01 EST
OK, I'm still seeing it on my Dell Optiplex 360 workstations with kernel 2.6.18-164.6.1.el5.  It's very intermittent on my systems, though; it seems to take them pretty close to 10 seconds to link up, so with the default LINKDELAY it winds up being a race condition.

Hardware details from lspci and ethtool:

02:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5784M Gigabit Ethernet PCIe (rev 10)

driver: tg3
version: 3.96-1
firmware-version: sb v2.19
bus-info: 0000:02:00.0
Comment 43 Andy Gospodarek 2011-08-18 22:02:32 EDT
This bug is almost two years old and the last reports seem to be on RHEL5.4 while we are shipping RHEL5.7 at this point.  Please reopen if you are still having problems with RHEL5.7.
Comment 44 David Brodbeck 2011-08-23 12:34:24 EDT
I haven't been able to test yet because the current RHEL5.7 kernel hard-locks the systems that I was experiencing this bug on.
Comment 45 Andy Gospodarek 2011-08-23 13:51:51 EDT
(In reply to comment #44)
> I haven't been able to test yet because the current RHEL5.7 kernel hard-locks
> the systems that I was experiencing this bug on.

That certainly isn't good.  Feel free to open a bug for this if you are able to collect information (backtraces, configuration, etc) that might help us resolve it.
Comment 46 David Brodbeck 2011-11-15 18:34:39 EST
I solved the lockup problem -- it was caused by our antivirus software.

However, i'm still seeing the original problem with kernel 2.6.18-274.7.1.el5.  The system does not reliably acquire link unless I add "LINKDELAY=60" to the network configuration script.

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