Bug 115814

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