Bug 489448 - Continuously occurring "b44: eth0: powering down PHY" during heavy traffic
Continuously occurring "b44: eth0: powering down PHY" during heavy traffic
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
11
i686 Linux
high Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-10 02:50 EDT by Chad Sawatzky
Modified: 2010-06-28 07:26 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-28 07:26:06 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)


External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 11056 None None None Never
Linux Kernel 14451 None None None Never
Linux Kernel 7696 None None None Never
Launchpad 279102 None None None Never

  None (edit)
Description Chad Sawatzky 2009-03-10 02:50:37 EDT
Description of problem:
When transferring larger files via http on my local network the network interface will drop link.  I installed F10 recently.  I don't think it occurred with F9, but Network Manager made it obvious in F10.  When it was first happening Network Manager would cause additional issues, dropping the interface when the link went down.  When I changed settings so NM would not manage the interface the transfers would continue, but slowly.  /var/log/messages is displays the following:

Mar  9 23:08:30 localhost kernel: b44: eth0: powering down PHY
Mar  9 23:08:31 localhost kernel: b44: eth0: Link is down.
Mar  9 23:08:31 localhost NetworkManager: <info>  (eth0): carrier now OFF (device state 8)
Mar  9 23:08:31 localhost NetworkManager: <info>  (eth0): device state change: 8 -> 2
Mar  9 23:08:31 localhost NetworkManager: <info>  (eth0): deactivating device (reason: 40).
Mar  9 23:08:31 localhost NetworkManager: <info>  eth0: canceled DHCP transaction, dhcp client pid 3982
Mar  9 23:08:31 localhost NetworkManager: <WARN>  check_one_route(): (eth0) error -34 returned from rtnl_route_del(): Sucess#012
Mar  9 23:08:33 localhost kernel: b44: eth0: Link is up at 100 Mbps, full duplex.
Mar  9 23:08:33 localhost kernel: b44: eth0: Flow control is off for TX and off for RX.
Mar  9 23:08:33 localhost NetworkManager: <info>  (eth0): carrier now ON (device state 2)
Mar  9 23:08:33 localhost NetworkManager: <info>  (eth0): device state change: 2 -> 3
Mar  9 23:08:33 localhost NetworkManager: <info>  Activation (eth0) starting connection 'System eth0'


Version-Release number of selected component (if applicable):
2.6.27.15-170.2.24.fc10.i686
2.6.27.19-170.2.35.fc10.i686

How reproducible:
Every time I try to download a large file from the HTPC on my local network.  I have no problems when doing many other things like transferring files via ssh.  I may have had a problem when streaming music using avahi and rhythmbox, but that may have just been an anomaly.

I have tried connecting different cables to my gateway/switch and rebooting the switch and computer.

Steps to Reproduce:
1. Load Firefox with webpage on local network
2. Select larger file to download
3. Network Manger displays disconnected followed quickly by connection established.  /var/log/messages displays errors above. 
  
Actual results:
Network Manger displays disconnected followed quickly by connection established.  /var/log/messages displays errors.  Specifically:

Mar  9 23:08:30 localhost kernel: b44: eth0: powering down PHY
Mar  9 23:08:31 localhost kernel: b44: eth0: Link is down.

Expected results:
No link down.  File transfer to complete with no errors.

Additional info:
This would appear to be an upstream bug.  I found the following bug reports that describe this problem.  It seems the likely culprits are the b44 and ssb drivers.  There had been some modification of the interaction of these two drivers during the time reports of the issue appeared.

http://bugzilla.kernel.org/show_bug.cgi?id=11056 
http://bugzilla.kernel.org/show_bug.cgi?id=10819 (related ?) 
http://lists.opensuse.org/opensuse-bugs/2008-10/msg10307.html 
https://bugzilla.novell.com/show_bug.cgi?id=438263 
https://bugs.launchpad.net/linux/+bug/279102 

http://www.smolts.org/client/show/pub_427622f3-210f-47be-9d97-882043158814
Comment 1 Chad Sawatzky 2009-07-31 04:49:43 EDT
Just providing an update.  I recently installed F11 and the problem continues to exist.

Linux localhost 2.6.29.6-213.fc11.i686.PAE #1 SMP Tue Jul 7 20:59:29 EDT 2009 i686 i686 i386 GNU/Linux


Jul 28 14:06:16 localhost kernel: b44: eth0: powering down PHY
Jul 28 14:06:16 localhost NetworkManager: <info>  (eth0): carrier now OFF (device state 8)
Jul 28 14:06:16 localhost NetworkManager: <info>  (eth0): device state change: 8 -> 2 (reason 40)
Jul 28 14:06:16 localhost NetworkManager: <info>  (eth0): deactivating device (reason: 40).
Jul 28 14:06:16 localhost kernel: b44: eth0: Link is down.
Jul 28 14:06:17 localhost NetworkManager: <info>  eth0: canceled DHCP transaction, dhcp client pid 10714
Jul 28 14:06:17 localhost NetworkManager: <WARN>  check_one_route(): (eth0) error -34 returned from rtnl_route_del(): Sucess#012
Jul 28 14:06:18 localhost ntpd[1701]: Deleting interface #10 eth0, 192.168.1.100#123, interface stats: received=0, sent=0, dropped=0, active_time=51 secs
Jul 28 14:06:19 localhost kernel: b44: eth0: Link is up at 100 Mbps, full duplex.
Jul 28 14:06:19 localhost kernel: b44: eth0: Flow control is off for TX and off for RX.
Jul 28 14:06:19 localhost NetworkManager: <info>  (eth0): carrier now ON (device state 2)
Comment 2 Bojan Smojver 2009-11-16 19:38:45 EST
I've seen this on two different machines with b44 in F-12. Disconnect happen even if load is not high. The interface stays down, so if you're using network authentication (e.g. Kerberos) and screen saver locks the screen, it's game over.
Comment 3 Bojan Smojver 2009-12-15 18:51:22 EST
Is anyone looking at this bug at all? I get several disconnections every day - really annoying.
Comment 4 Bojan Smojver 2009-12-15 18:52:02 EST
(In reply to comment #3)
> Is anyone looking at this bug at all? I get several disconnections every day -
> really annoying.

F-12, in my case.
Comment 5 Bojan Smojver 2009-12-29 22:46:09 EST
It seems that configuring the interface with a static IP address (for people that can do that) avoids the disconnection issues. I had it configured like that for a day now and no disconnection as yet.
Comment 6 Bug Zapper 2010-04-27 09:08:58 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Bug Zapper 2010-06-28 07:26:06 EDT
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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