Launchpad has imported 25 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=502974.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2009-05-28T02:32:33+00:00 Laurentiu wrote: Description of problem: Gigabit ethernet card resumes from Sleep state in 100Mbs mode. Version-Release number of selected component (if applicable): eth0: PCI RTL8169sb Gigabit ethernet card (connected, 1000Mbps mode) eth1: Onboard Intel 10/100 ethernet (unconnected) (dmesg indicated it had renamed eth0 as eth1) Netgear DS608 8-port Gigabit switch. How reproducible: Every time Steps to Reproduce: 1. eth0 is in 1000Mbps mode 2. put system in Sleep mode (eth0 switches to 100Mbps mode according to switch) 3. wake up Actual results: eth0 remained in 100Mbps mode after wake up Expected results: eth0 should have renegotiated to 1000Mbps Additional info: "ethtool -s eth0 autoneg on" after sleep causes the port to go in 1000Mbps again. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/0 ------------------------------------------------------------------------ On 2009-05-28T18:32:11+00:00 Dan wrote: Do you have an /etc/sysconfig/network-scripts/ifcfg-eth0 file? If so, what's in it? This is probably a kernel driver issue though, since NM doesn't actually touch any of these layer 1/layer 2 details at this time. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/1 ------------------------------------------------------------------------ On 2009-05-29T02:28:08+00:00 Laurentiu wrote: This is a fresh Fedora 11 Preview install. ifcfg-eth0 contains the basic stuff # Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet DEVICE=eth0 BOOTPROTO=dhcp HWADDR=00:14:d1:12:34:56 ONBOOT=yes The card is a TRENDnet PCITXR. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/2 ------------------------------------------------------------------------ On 2009-06-09T16:42:25+00:00 Bug wrote: This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/3 ------------------------------------------------------------------------ On 2009-09-12T17:12:23+00:00 Per wrote: I have the same problem, Fedora 11, latest updates as of today. # lspci | grep -i eth 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01) Also, the adapter does not wake on lan using magic packets, though it will respond to broadcast or physical activity. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/4 ------------------------------------------------------------------------ On 2010-04-27T14:33:22+00:00 Bug wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/5 ------------------------------------------------------------------------ On 2010-09-24T22:39:00+00:00 Stanislaw wrote: Please attach dmesg when problem happens. Does problem still occurs on up-to-date kernels (F-13, F-14 or upstream)? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/6 ------------------------------------------------------------------------ On 2010-10-03T23:49:37+00:00 Laurentiu wrote: Problem still happens with 2.6.34.7-56.fc13.i686.PAE. Probably related: when the system goes on standby, the ethernet port turns off briefly then turns back on in low-speed mode, probably for WOL purposes. The kernel messages on resume associated with the network driver are as follows: r8169 0000:03:03.0: PME# enabled r8169 0000:03:03.0: restoring config space at offset 0x5 (was 0x0, writing 0xdf9fff00) r8169 0000:03:03.0: restoring config space at offset 0x4 (was 0x1, writing 0xdc01) r8169 0000:03:03.0: restoring config space at offset 0x3 (was 0x0, writing 0x4008) r8169 0000:03:03.0: restoring config space at offset 0x1 (was 0x2b80000, writing 0x2b00117) r8169 0000:03:03.0: PME# disabled r8169 0000:03:03.0: eth0: link up NetworkManager verbiage: wake requested (sleeping: yes enabled: yes) <info> waking up and re-enabling... <info> (eth0): now managed <info> (eth0): device state change: 1 -> 2 (reason 2) <info> (eth0): bringing up device. <info> (eth0): preparing device. <info> (eth0): deactivating device (reason: 2). <info> (eth0): carrier now ON (device state 2) <info> (eth0): device state change: 2 -> 3 (reason 40) <info> Activation (eth0) starting connection 'System eth0' <info> (eth0): device state change: 3 -> 4 (reason 0) [...] Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/7 ------------------------------------------------------------------------ On 2010-10-04T15:45:55+00:00 Stanislaw wrote: I would tell we need to put rtl8169_set_speed(dev, AUTONEG_ENABLE, SPEED_1000, DUPLEX_FULL) somewhere in resume procedure. Francois, what you think ? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/8 ------------------------------------------------------------------------ On 2010-10-04T21:23:25+00:00 Francois wrote: It is sensible. I will consider ourselves lucky if an extra rtl8169_init_phy() is not needed before long either. -- Ueimor Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/9 ------------------------------------------------------------------------ On 2010-10-18T08:05:52+00:00 Stanislaw wrote: Created attachment 454034 f13-r8169-init-phy-when-resume.patch Proposed fix. I tested similar patch on upstream kernel. I'm not able to reproduce the bug, but putting device in 10 Mb/s before suspend give me 100 Mb/s after resume - correct value for that connection. I'm not sure if we should not reset save the speed at suspend, and restore that value at resume instead of max speed. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/10 ------------------------------------------------------------------------ On 2010-10-18T08:35:11+00:00 Stanislaw wrote: Here is kernel build with above patch: http://koji.fedoraproject.org/koji/taskinfo?taskID=2540097 Laurentiu, please test. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/11 ------------------------------------------------------------------------ On 2010-10-18T21:05:48+00:00 Francois wrote: Stanislaw Gruszka : [...] > I'm not sure if we should not reset save the speed at suspend, and restore > that > value at resume instead of max speed. It would amount to supposing that the switch stays the same, imho defeating the whole purpose of auto-negotiation. I would rather see the do-not-autoneg- because-my-swithc-is-broken-or-my-setup-does-not-change an option rather than the default behavior. -- Ueimor Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/12 ------------------------------------------------------------------------ On 2010-10-19T04:28:45+00:00 Laurentiu wrote: I can confirm that with 2.6.34.7-59.bz502974.fc13.i686.PAE linked above the system resumes from sleep at 1000Mbps. As for whether autoneg should be enabled rather than saved/restored, my 2c: given that it's not something you set accidentally, we have to assume someone knows what they are doing, so it may be bad form to second-guess the user and force it back on. But hey, I'm good either way, my problem is solved. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/13 ------------------------------------------------------------------------ On 2010-11-24T21:32:09+00:00 Pierre wrote: What's the status of this bug? The patch doesn't seem to be in the normal kernels yet. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/14 ------------------------------------------------------------------------ On 2010-11-24T22:11:06+00:00 Francois wrote: It's in Linus's tree as fccec10b33503a2b1197c8e7a3abd30443bedb08 I'll push it to stable today. -- Ueimor Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/15 ------------------------------------------------------------------------ On 2010-11-25T00:01:03+00:00 Francois wrote: I have submitted it for 2.6.36.1+. Four patches are available for (now closed) 2.6.34.7 at : http://userweb.kernel.org/~romieu/r8169/2.6.34.7/ -- Ueimor Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/16 ------------------------------------------------------------------------ On 2010-11-25T20:56:54+00:00 Pierre wrote: Fantastic! Stanislaw, can we get this into the stable F13 and F14 kernel? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/17 ------------------------------------------------------------------------ On 2010-11-26T13:11:21+00:00 Stanislaw wrote: *** Bug 505561 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/18 ------------------------------------------------------------------------ On 2010-12-03T15:34:15+00:00 Fedora wrote: kernel-2.6.34.7-63.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/kernel-2.6.34.7-63.fc13 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/19 ------------------------------------------------------------------------ On 2010-12-03T15:38:12+00:00 Fedora wrote: kernel-2.6.35.9-64.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/kernel-2.6.35.9-64.fc14 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/20 ------------------------------------------------------------------------ On 2010-12-04T13:48:23+00:00 Pierre wrote: Confirmed working with 2.6.34.7-63.fc13.x86_64. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/21 ------------------------------------------------------------------------ On 2010-12-05T00:42:16+00:00 Fedora wrote: kernel-2.6.35.9-64.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/22 ------------------------------------------------------------------------ On 2010-12-07T20:07:11+00:00 Fedora wrote: kernel-2.6.34.7-63.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/23 ------------------------------------------------------------------------ On 2011-01-02T12:49:13+00:00 Jeff wrote: Also confirmed, working with 2.6.37-0.rc7.git0.2.fc15.x86_64 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732539/comments/24 ** Changed in: linux Status: Unknown => Fix Released ** Changed in: linux Importance: Unknown => Medium -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/732539 Title: r8169 is set to 100Mb/s after suspending at 1000Mb/s Status in Linux: Fix Released Status in linux package in Ubuntu: Incomplete Bug description: I have an r8169 gige card in this machine which links at 1000Mb/s just fine when powered on, however after a suspend/resume cycle, it will be linked at 100Mb/s. This is obviously a problem with the driver but a handy workaround is to just create a file in /etc/pm/config.d/r8169 with: # r8169 driver resumes at 100Mb/s. reloading it brings it back to 1000Mb/s SUSPEND_MODULES="r8169" in it. I consider this a bug in both the driver itself and PM for lack of a functioning workaround while the driver is fixed. ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: linux-image-2.6.32-28-generic 2.6.32-28.55 Regression: No Reproducible: Yes ProcVersionSignature: Ubuntu 2.6.32-28.55-generic 2.6.32.27+drm33.12 Uname: Linux 2.6.32-28-generic i686 AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.21. Architecture: i386 AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/dsp1', '/dev/dsp', '/dev/snd/by-id', '/dev/snd/controlC1', '/dev/snd/pcmC1D0c', '/dev/snd/controlC0', '/dev/snd/pcmC0D0c', '/dev/snd/pcmC0D0p', '/dev/snd/pcmC0D1c', '/dev/snd/pcmC0D2p', '/dev/snd/by-path', '/dev/snd/seq', '/dev/snd/timer', '/dev/sequencer2', '/dev/sequencer'] failed with exit code 1: CRDA: Error: [Errno 2] No such file or directory Card0.Amixer.info: Card hw:0 'nForce2'/'NVidia nForce2 with ALC650E at irq 20' Mixer name : 'Realtek ALC650E' Components : 'AC97a:414c4722' Controls : 50 Simple ctrls : 33 Card1.Amixer.info: Card hw:1 'U0x20400x7200'/'USB Device 0x2040:0x7200 at usb-0000:00:02.2-1, high speed' Mixer name : 'USB Mixer' Components : 'USB2040:7200' Controls : 1 Simple ctrls : 1 Card1.Amixer.values: Simple mixer control 'Digital In',0 Capabilities: cswitch cswitch-joined penum Capture channels: Mono Mono: Capture [on] Date: Thu Mar 10 06:43:36 2011 IwConfig: lo no wireless extensions. eth1 no wireless extensions. eth0 no wireless extensions. Lsusb: Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 002: ID 2040:7200 Hauppauge Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub ProcCmdLine: BOOT_IMAGE=/vmlinuz-2.6.32-28-generic root=/dev/mapper/rootvol_tmp-ubuntu_root ro console=ttyS0,115200 console=tty0 resume=/dev/mapper/rootvol-swap quiet splash ProcEnviron: PATH=(custom, no user) LANG=en_CA.UTF-8 SHELL=/bin/bash RelatedPackageVersions: linux-firmware 1.34.3 RfKill: SourcePackage: linux dmi.bios.date: 11/22/2004 dmi.bios.vendor: Phoenix Technologies, LTD dmi.bios.version: 6.00 PG dmi.board.name: NF7-S/NF7,NF7-V (nVidia-nForce2) dmi.board.vendor: http://www.abit.com.tw/ dmi.board.version: 2.X,1.0 dmi.chassis.type: 3 dmi.modalias: dmi:bvnPhoenixTechnologies,LTD:bvr6.00PG:bd11/22/2004:svn:pn:pvr:rvnhttp//www.abit.com.tw/:rnNF7-S/NF7,NF7-V(nVidia-nForce2):rvr2.X,1.0:cvn:ct3:cvr: To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/732539/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
