Bug 28262 - Slow resume from suspend/hibernate on Dell Inspiron M301Z
Summary: Slow resume from suspend/hibernate on Dell Inspiron M301Z
Status: CLOSED CODE_FIX
Alias: None
Product: Power Management
Classification: Unclassified
Component: Hibernation/Suspend (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: power-management_other
URL:
Keywords:
Depends on:
Blocks: 7216 27352
  Show dependency tree
 
Reported: 2011-02-05 12:37 UTC by Luca Ferretti
Modified: 2011-03-27 19:45 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.38-rc2
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Dmesg info using pm_trace (76.56 KB, text/plain)
2011-02-05 12:37 UTC, Luca Ferretti
Details
dmesg during suspend when /sys/power/pm_async = 1 (15.55 KB, application/octet-stream)
2011-02-13 12:55 UTC, ccouzens
Details
dmesg during suspend when /sys/power/pm_async = 0 (12.54 KB, application/octet-stream)
2011-02-13 12:56 UTC, ccouzens
Details
dmesg during hibernate (9.84 KB, text/plain)
2011-02-28 12:32 UTC, ccouzens
Details

Description Luca Ferretti 2011-02-05 12:37:48 UTC
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"
Comment 1 Rafael J. Wysocki 2011-02-05 18:03:33 UTC
What's the latest kernel tested?

Any chance to test the current Linus' tree?
Comment 2 Luca Ferretti 2011-02-05 18:40:47 UTC
(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/
Comment 3 Rafael J. Wysocki 2011-02-05 22:58:40 UTC
I need to know if the commits that went in after -rc2 (most importantly,
the DRI fixes), didn't help. :-)
Comment 4 Luca Ferretti 2011-02-13 01:34:32 UTC
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/
Comment 5 Rafael J. Wysocki 2011-02-13 10:51:36 UTC
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?
Comment 6 ccouzens 2011-02-13 12:55:07 UTC
Created attachment 47592 [details]
dmesg during suspend when /sys/power/pm_async = 1
Comment 7 ccouzens 2011-02-13 12:56:00 UTC
Created attachment 47602 [details]
dmesg during suspend when /sys/power/pm_async = 0
Comment 8 ccouzens 2011-02-13 12:58:30 UTC
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
Comment 9 Guillaume Ayoub 2011-02-26 19:07:01 UTC
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.
Comment 10 Guillaume Ayoub 2011-02-27 11:11:06 UTC
[...] was 2 seconds with *2.6.37* [...]

I'm testing various kernel versions to find when the bug appeared and if latest commits help.
Comment 11 Guillaume Ayoub 2011-02-27 13:48:14 UTC
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.
Comment 12 Guillaume Ayoub 2011-02-27 13:59:18 UTC
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
Comment 13 ccouzens 2011-02-27 14:06:18 UTC
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.
Comment 14 Luca Ferretti 2011-02-27 15:51:00 UTC
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?
Comment 15 Guillaume Ayoub 2011-02-27 16:02:41 UTC
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.
Comment 16 ccouzens 2011-02-28 12:32:58 UTC
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
Comment 17 Luca Ferretti 2011-03-10 21:46:07 UTC
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
Comment 18 Rafael J. Wysocki 2011-03-10 23:29:42 UTC
Patch : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/658307/comments/21
Handled-By : Andreas Herrmann <andreas.herrmann3@amd.com>
Comment 19 Rafael J. Wysocki 2011-03-27 19:45:04 UTC
Fixed by commit 7f74f8f28a2bd9db9404f7d364e2097a0c42cc12 .

Note You need to log in before you can comment on or make changes to this bug.