Created attachment 46452 [details] Dmesg info using pm_trace As per summary, there are issue resuming this laptop after a suspend action. It requires 5 minutes to resume. This issue was originally reported against Ubuntu 10.10 - see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/658307 for more info and details - but it also occurs in previous 10.04, Fedora 14 and latest development Ubuntu Natty alpha2 I'm attaching the dmesg info from latest, dumped after running sudo sh -c "sync; echo 1 > /sys/power/pm_trace; pm-suspend"
What's the latest kernel tested? Any chance to test the current Linus' tree?
(In reply to comment #1) > What's the latest kernel tested? Latest was 2.6.38-rc2 available on ubuntu natty alpha 2 > Any chance to test the current Linus' tree? I can grab if from mainline kernels archive (here[1] is today's build). There are some changes to default configuration (see patch files in [1]); is it OK as test base? Which kind of info/log/dump do you need from it? [1] http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2011-02-05-natty/
I need to know if the commits that went in after -rc2 (most importantly, the DRI fixes), didn't help. :-)
I tested with latest available mainline kernel build for ubuntu natty[1] No changes, the resume behavior is still the same: resume process starts, then "freezes" for about 4 or 5 minutes. http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.38-rc4-natty/
Would you be able to identify the exact place in the boot process that's freezing (e.g. by using dmesg timestamping)? Also, is the problem reproducible if you do "echo 0 > /sys/power/pm_async" after booting the system?
Created attachment 47592 [details] dmesg during suspend when /sys/power/pm_async = 1
Created attachment 47602 [details] dmesg during suspend when /sys/power/pm_async = 0
I too have a M301Z that is slow to wake from suspend. 2.6.38-3-generic #30-Ubuntu SMP Thu Feb 10 00:33:26 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux after echo 0 > /sys/power/pm_async the system took approximately 5 minutes 18 seconds to resume. I've attached the contents of dmesg during suspend with both values of /sys/power/pm_async
Same problem with a totally different laptop (ASRock MultiBook M15). Resume takes about 1 minute (was about 2 seconds with 2.6.38). Ask anything if I can help.
[...] was 2 seconds with *2.6.37* [...] I'm testing various kernel versions to find when the bug appeared and if latest commits help.
The problem comes from the r8169 driver. Both the Dell and ASRock laptops include this ethernet device. Disabling the module with the 2.6.38 kernels fixes the bug for me. Commit f1e02ed somehow explains the bug (explicit reference to a 60 seconds delay). I don't know why the delay is about 5 minutes with the Dell laptop.
I forgot to say that the bug appears between the 2.6.37 and 2.6.38-rc1 versions. - 2.6.37 with or without r8169: 2 seconds - 2.6.38-rc1 to latest git with r8169: 60 seconds - 2.6.38-rc1 to latest git without r8169: 2 seconds
Linux chris-M301Z 2.6.38-5-generic #32-Ubuntu SMP Tue Feb 22 16:10:15 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux I presume "$ sudo modprobe -r r8169" is enough to test whether the module is responsible? Resuming without r8169 loaded just took me 5 minutes 14 seconds.
Guillaume, I fear the r8169 issue is only related to your laptop, not M301z. The Dell laptop suffers this resume timeout even using 2.6.35 or 2.6.32, so it's not a recent regression. I've tried to use rmmod[1] as Chris did, and I've the 5 minutes delay too. Rafael, do you need another dmesg? The ones provided by Chris show a time gap after "ACPI: Waking up from system sleep state S3", and mine has the same. [1] goddamit, why ubuntu loads blacklisted modules?!?!?!?! maybe udev?
You're right, "modprobe -r" is enough for me. Installing the realtek firmware fixes my bug too. I'll open another bug, sorry for the noise.
Created attachment 49602 [details] dmesg during hibernate The laptop took about 5 minutes 8 seconds to hibernate. From about 1:00 to 1:20 the screen lit up and the Hard Disk made noises (I'd guess that's when it actually saved the RAM contents). Resuming took 5 minutes 29 seconds (my timer started after GRUB). Plenty of things took about 5 minutes according to dmesg (egrep "[0-9]{6}\.[0-9]* msecs" dmesg_hibernate.txt) The first thing to do so: [ 1268.070230] PM: restore of drv:usb dev:usb3 complete after 299823.782 msecs The last thing to do so [ 1269.550142] PM: restore of drv:radeon dev:0000:01:05.0 complete after 301371.406 msecs [ 1269.550332] PM: restore of devices complete after 301371.930 msecs
Forgot to mention: this issue was fixed on latest kernel update in ubuntu natty (development version). More info about this change are here http://marc.info/?l=linux-kernel&m=129623757413868 (while it seems more adjustments could be needed). That change should be yet committed on kernel mainline, see this comment from Andy Whitcroft: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/658307/comments/21
Patch : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/658307/comments/21 Handled-By : Andreas Herrmann <andreas.herrmann3@amd.com>
Fixed by commit 7f74f8f28a2bd9db9404f7d364e2097a0c42cc12 .