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
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)
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.
Is anyone looking at this bug at all? I get several disconnections every day - really annoying.
(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.
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.
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
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.