Bugzilla – Bug 115814
r8169 suspend/resume does not work (and r8169 spams /var/log/messages)
Last modified: 2007-02-22 18:11:07 UTC
When RTL-8169 Gigabit Ethernet card configured to activate on cable connection. Module print message "kernel: eth0: PHY reset until link up" every 10 secs, until cable disconection. Sep 8 13:54:59 suse10-lpt kernel: r8169 Gigabit Ethernet driver 2.2LK loaded Sep 8 13:54:59 suse10-lpt kernel: ACPI: PCI Interrupt 0000:00:08.0[A] -> GSI 19 (level, low) -> IRQ 185 Sep 8 13:54:59 suse10-lpt kernel: eth0: Identified chip type is 'RTL8169s/8110s'. Sep 8 13:54:59 suse10-lpt kernel: eth0: RTL8169 at 0xffffc20000050800, 00:90:f5:32:c3:05, IRQ 185 ... Sep 8 14:14:21 suse10-lpt kernel: eth0: PHY reset until link up Sep 8 14:14:31 suse10-lpt kernel: eth0: PHY reset until link up Sep 8 14:14:41 suse10-lpt kernel: eth0: PHY reset until link up
Additional. NIC driver hang by ACPI S3 suspend to RAM. Probably need expand variable /etc/sysconfig/powersave/sleep:UNLOAD_MODULES_BEFORE_SUSPEND2RAM & UNLOAD_MODULES_BEFORE_SUSPEND2DISK to module r8169
Karsten, can you look into this please?
Hmm, I see this message only if the cable is disconnected, if I plugin the cable it goes away.
... spam messages ... Sep 13 13:06:35 suse10-lpt kernel: eth0: PHY reset until link up Sep 13 13:06:45 suse10-lpt kernel: eth0: PHY reset until link up Sep 13 13:06:55 suse10-lpt kernel: eth0: PHY reset until link up Sep 13 13:07:02 suse10-lpt kernel: r8169: eth0: link up Sep 13 13:07:03 suse10-lpt ifplugd(eth0)[4921]: Link beat detected. Sep 13 13:07:04 suse10-lpt ifplugd(eth0)[4921]: Executing '/etc/sysconfig/network/scripts/ifplugd-selectif eth0 up'. ... Sep 13 13:07:09 suse10-lpt ifplugd(eth0)[4921]: Program executed successfully. ... No messages, we happy ... Sep 13 13:11:29 suse10-lpt kernel: r8169: eth0: link down Sep 13 13:11:29 suse10-lpt ifplugd(eth0)[4921]: Link beat lost. ... Sep 13 13:11:37 suse10-lpt ifplugd(eth0)[4921]: Program executed successfully. Sep 13 13:11:37 suse10-lpt kernel: r8169: eth0: link down Sep 13 13:11:47 suse10-lpt kernel: eth1: no IPv6 routers present Sep 13 13:11:47 suse10-lpt kernel: eth0: PHY reset until link up Sep 13 13:11:48 suse10-lpt kernel: eth0: no IPv6 routers present Sep 13 13:11:57 suse10-lpt kernel: eth0: PHY reset until link up Sep 13 13:12:07 suse10-lpt kernel: eth0: PHY reset until link up Sep 13 13:12:17 suse10-lpt kernel: eth0: PHY reset until link up ... spam messages ...
I (IMHO any user) don't needed spam messages every 10 sec, when notebook don't connect to LAN.
This is not what you describe in your first comment ( ... until cable disconection). I agree that this printing is anoying, but it's the decision of the author to set the default debuglevel to this value, I do not thing we should change this in our driver before the mainline driver is changed. You can change it with ethtool -s eth0 msglvl 0x33 For the second part, suspend to RAM, I think I will have a patch later.
Created attachment 49763 [details] patch to improve suspend/resume completly untested, since my test machine do not work with suspend at all.
Pavel, this should be correct, shouldn't it ?
(In reply to comment #7) > Created an attachment (id=49763) [edit] > patch to improve suspend/resume > completly untested, since my test machine do not work with suspend at all. This patch (when applied to 2.6.13-9-default) incomplete work. Driver not hang complete, but I need disconnetct/connect cable (ifup/ifdown in my case). For example ping log, when I acivate suspend2ram: 64 bytes from 192.168.123.93: icmp_seq=16 ttl=255 time=0.810 ms 64 bytes from 192.168.123.93: icmp_seq=17 ttl=255 time=0.731 ms susped2ram - activated ping: sendmsg: No buffer space available ping: sendmsg: No buffer space available cable disconected -> "ifplugd(eth0)[4838]: client: ifdown eth0" ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable cable connected -> "ifplugd(eth0)[4838]: client: ifup eth0" 64 bytes from 192.168.123.93: icmp_seq=57 ttl=255 time=5.63 ms 64 bytes from 192.168.123.93: icmp_seq=58 ttl=255 time=0.858 ms Sorry for my best English P.S. Thank You for workaround about spam messages.
Karsten, patch looks okay to me. Try pushing it to mainline... For suse10.0, probably the best solution is to just unload the module.
As stated in the powersave documentation, it is easy to add modules to the "unload list". It is too late to change the default list for 10.0 now, but it is easy to do on the affected machines.
Created attachment 49898 [details] patch to try out Please test this patch on top of the first. I found, that some other cards used this sequence.
Created attachment 49978 [details] delta patch to r8169_suspend2.diff (id=49898) Second patch don't work. It symptoms equivalent to first patch. IMHO rtl8169_hw_start(dev) don't initalize on board ring buffer, don't map it to kernel adress space and don't restart chain timer rtl8169_request_timer(). IMHO it complety destroyed by suspend/resume. rtl8169_open() seems like to resume. I try draft delta patch on top to the second. With this patch TCP (FTP) connection ang ping(s) restored after suspend/resume. May be use rtl8169_down()? Sorry for my bests English
i have a machine with r8169 now, and suspend / resume is totally broken, even if i unload the module before suspend. I have to investigate what exactly breaks, but at least suspend to RAM is broken. I am using RC4 with kernel 2.6.13-15 on i386
ok. My error, i actually did _not_ unload the modules (syntax error in the config file :-). With unloading, suspend to RAM works. I'll test the patches anyway.
Created attachment 50783 [details] roll up all patches into one All patches together work fine for me on a Panasonic CF-51, i have rolled them up, ready to send upstream (hint, hint ;-). Since this apparently could not work before, it should also be safe to add it to the SUSE kernel, shouldn't it?
aj, some of your x86-64 notebooks have r8169 IIRC. Consider it worth fixing suspend on them? It can break badly.
it is not fully perfect yet. After suspend to RAM and suspend to disk, removing the module caused a panic (blinking leds). I have no serial console setup here at home but will try to reproduce on monday in the office.
Created attachment 50789 [details] x86_64 stack trace for rmmod/modprobe
For x86_64 suspend2ram/resume probably work (don't crash or hang). But I see two throuble: 1. Crash after: suspend2ram, resume, rmmod, modprobe (id=50789) ; 2. System can't suspend2disk, when network activity (ping, for example); Stopping tasks: ================================== stopping tasks failed (1 tasks remaining) Restarting tasks...<6> Strange, ip not stopped P.S. Stefan, I am Serguei Leontiev [lse CryptoPro.ru] (not sai.msu.ru)
Check if you have "ip" program in D state for long periods before you attempt to supsend.... But this is different problem, so please new report. Stefan, can you push that r8169 patch to mainline? It seems way better than nothing.
Randomly messages "Restarting tasks...<6> Strange, ip not stopped" caused by ping to router. This ping not in D state, it working before suspend2disk. May be suspend module cause D state of ping? This problem randomly.
maybe suspending the driver triggers an "remove interface" event and in consequence an "ifdown eth0". But userspace should be stopped at this point... Is maybe the "ip" process already in state D before you try to suspend?
No activity for more as one year