Slow resume from suspend on Dell Inspiron M301Z

Bug #658307 reported by Luca Ferretti on 2010-10-11
This bug affects 13 people
Affects Status Importance Assigned to Milestone
Fix Released
linux (Ubuntu)
Andy Whitcroft
Tim Gardner
Andy Whitcroft

Bug Description

Testing Ubuntu 10.10 final release on Dell Inspiron M301Z

Suspending with several programs running (eg totem with ogg file playing), the laptop suspends fine (power button and LED goes in sleep modus), but it's slow to perform a resume when requested.

In fact, after pressing the power button to wake up, the screen remains blank and no audio is played; Ctrl+Alt+Fx seems unresponsive too. But waiting 4 or 5 minuter, the system wake up properly (lock screen, audio played, network reconnected).

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: linux-image-2.6.35-22-generic 2.6.35-22.33
Regression: No
Reproducible: Yes
ProcVersionSignature: Ubuntu 2.6.35-22.33-generic
Uname: Linux 2.6.35-22-generic x86_64
NonfreeKernelModules: wl
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.23.
Architecture: amd64
 **** List of CAPTURE Hardware Devices ****
 card 0: SB [HDA ATI SB], device 0: STAC92xx Analog [STAC92xx Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
 /dev/snd/controlC0: luca 1669 F.... pulseaudio
CRDA: Error: [Errno 2] Nessun file o directory
 Card hw:0 'SB'/'HDA ATI SB at 0xd0500000 irq 16'
   Mixer name : 'IDT 92HD81B1X5'
   Components : 'HDA:111d7605,1028044b,00100105'
   Controls : 14
   Simple ctrls : 9
 Card hw:1 'HDMI'/'HDA ATI HDMI at 0xd0210000 irq 19'
   Mixer name : 'ATI RS690/780 HDMI'
   Components : 'HDA:1002791a,00791a00,00100000'
   Controls : 4
   Simple ctrls : 1
 Simple mixer control 'IEC958',0
   Capabilities: pswitch pswitch-joined penum
   Playback channels: Mono
   Mono: Playback [on]
Date: Mon Oct 11 14:19:54 2010
HibernationDevice: RESUME=UUID=b1843e3b-a9b2-4b57-843b-8a51ec7e3022
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release Candidate amd64 (20100928)
MachineType: Dell Inc. Inspiron M301Z
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.35-22-generic root=UUID=aea8df88-f12e-42e5-8be1-74e5170cdaca ro quiet splash
RelatedPackageVersions: linux-firmware 1.38
SourcePackage: linux 07/16/2010
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A03
dmi.board.vendor: Dell Inc.
dmi.board.version: A03
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: A03
dmi.modalias: dmi:bvnDellInc.:bvrA03:bd07/16/2010:svnDellInc.:pnInspironM301Z:pvrA03:rvnDellInc.:rn:rvrA03:cvnDellInc.:ct8:cvrA03: Inspiron M301Z
dmi.product.version: A03
dmi.sys.vendor: Dell Inc.

Luca Ferretti (elle.uca) wrote :
Christof Buchbender (ascurion) wrote :

I have exactly the same behaviour on my M301z with Ubuntu 10.10. After waking up from suspension the system is unresponsive and showing a black screen, until after some minutes it wakes up properly.

tags: added: kernel-suspend
tags: added: kj-triage
tomko222 (tomko222) wrote :

The same problem in Toshiba Satellite L610-11F in Kubuntu 10.10 (x86-64). The most often it wake up normaly but sometimes the screen remains blank (even without backlight) and after a few minutes it wakes up.

Changed in linux (Ubuntu):
status: New → Confirmed
tomko222 (tomko222) wrote :

I haven't got this problem for quite long time so maybe it is already fixed? Can you confirm if it still happens?

Luca Ferretti (elle.uca) wrote :

Unfortunately it still happens on my laptop.

Ruben Verhack (ruben-verhack) wrote :

I've got exact the same problem on my Dell Studio 15(58), first I thought resuming failed, but it seems that I just was impatient. Very annoying and always happens on the worst moments. It does not happen always though. one out of five times or so.

I had the same in Lucid, but then due some problems with fglrx I had some colored blocks on my screen to say that it was indeed resuming.

Brad Figg (brad-figg) on 2010-12-04
tags: added: acpi
tags: added: acpi-brightness
tags: added: acpi-parse-exec-fail
tags: added: acpi-pci-express
tomko222 (tomko222) wrote :

I forgot about this bug report. I was wrong - it is still happening in my laptop... I noticed that if it wakes up after few minutes the system is running wery slow to the moment the wifi card (pci id 14e4:4727, bcm4313) turns on. Then it works normaly.

Ruben Verhack (ruben-verhack) wrote :

Also a broadcom driver here:

04:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g LP-PHY (rev 01)

(Now testing with another driver, I could select two in jockey, I'll let you know if it turns out for the better)

Joep Jansen (joep-jansen) wrote :
Download full text (4.2 KiB)

I have the same problem with a Dell Inspiron 2200, with a Proxim Gold Orinoco 11b/g wireless card and ath5k driver.
Normally it resumes in 2..3 seconds, but sometimes (~1 in 10) it takes up to 4 minutes.

During this time the screen is black (except for a text cursor in the upper left corner), the hard drive light is off and it does not respond to the keyboard.

I find the following backtrace in the kernel messages:

Dec 27 09:59:42 juliette-laptop kernel: [20407.148315] ath5k 0000:03:00.0: PCI INT A disabled
Dec 27 09:59:42 juliette-laptop kernel: [20407.148515] pci 0000:03:00.0: BAR 0: assigned [mem 0x24000000-0x2400ffff]
Dec 27 09:59:42 juliette-laptop kernel: [20407.148525] pci 0000:03:00.0: BAR 0: set to [mem 0x24000000-0x2400ffff] (PCI address [0x24000000-0x2400ffff]
Dec 27 09:59:42 juliette-laptop kernel: [20407.148647] ath5k 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Dec 27 09:59:42 juliette-laptop kernel: [20407.148721] ath5k 0000:03:00.0: registered as 'phy27'
Dec 27 09:59:42 juliette-laptop kernel: [20407.596308] ath5k phy27: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43)
Dec 27 09:59:42 juliette-laptop kernel: [20407.596312] ath5k phy27: RF2112B 2GHz radio found (0x46)
Dec 27 09:59:42 juliette-laptop kernel: [20407.596347] PM: resume of drv:pcmcia_socket dev:pcmcia_socket0 complete after 211646.250 msecs
Dec 27 09:59:42 juliette-laptop kernel: [20407.596444] PM: resume of devices complete after 212904.500 msecs
Dec 27 09:59:42 juliette-laptop kernel: [20407.596637] PM: resume devices took 212.912 seconds
Dec 27 09:59:42 juliette-laptop kernel: [20407.596640] ------------[ cut here ]------------
Dec 27 09:59:42 juliette-laptop kernel: [20407.596650] WARNING: at /build/buildd/linux-2.6.35/kernel/power/suspend_test.c:53 suspend_test_finish+0x89/0x90()
Dec 27 09:59:42 juliette-laptop kernel: [20407.596654] Hardware name: Inspiron 2200
Dec 27 09:59:42 juliette-laptop kernel: [20407.596657] Component: resume devices, time: 212912
Dec 27 09:59:42 juliette-laptop kernel: [20407.596659] Modules linked in: snd_seq_dummy nls_iso8859_1 nls_cp437 vfat fat usb_storage usbhid hid parport_pc ppdev arc4 binfmt_misc ath5k mac80211 ath cfg80211 led_class snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event pcmcia snd_seq i915 drm_kms_helper drm joydev snd_timer snd_seq_device yenta_socket pcmcia_rsrc intel_agp i2c_algo_bit snd dell_laptop pcmcia_core video dcdbas soundcore output snd_page_alloc agpgart lp psmouse serio_raw parport e100 mii
Dec 27 09:59:42 juliette-laptop kernel: [20407.596708] Pid: 22966, comm: pm-suspend Tainted: G W 2.6.35-23-generic #41-Ubuntu
Dec 27 09:59:42 juliette-laptop kernel: [20407.596711] Call Trace:
Dec 27 09:59:42 juliette-laptop kernel: [20407.596722] [<c014acf2>] warn_slowpath_common+0x72/0xa0
Dec 27 09:59:42 juliette-laptop kernel: [20407.596727] [<c01825c9>] ? suspend_test_finish+0x89/0x90
Dec 27 09:59:42 juliette-laptop kernel: [20407.596731] [<c01825c9>] ? suspend_test_finish+0x89/0x90
Dec 27 09:59:42 juliette-laptop kernel: [20407.596736] [<c014adc3>] warn_slowpath_fmt+0x33/0x40
Dec 27 09:59:42 juliette-laptop kernel: [20407.596741] [<c01825c9>]...


tomko222 (tomko222) wrote :

I have installed kernel 2.6.36 from and it is a partial solution of this problem for me. The system wakes up normaly every time and waking up with this kernel lasts about 2 seconds. But it is also a problem with this kernel - suspending lasts about 30 seconds (with 2.6.35 only about 5 seconds)...

tomko222 (tomko222) wrote :

Another solution of this problem working for me in normal maverick 2.6.35 kernel is using s2ram to suspend. Both suspend and waking up lasts about 2-3 seconds in my computer and works without any problems.

Ruben Verhack (ruben-verhack) wrote :

So what you are saying that kernel 2.6.36 fixes the issue? (If so, I will give up and wait for Natty, hopefully no regressions by then)

I did a fresh install, to be sure I wasn't causing my own troubles, but still no go.

Did anyone got closer to pinpointing the problem? (I didn't had this problem before I installed the STA driver for my broadcom wireless, but I only used it in that condition for about a day, so it's not conclusive)

Ruben Verhack (ruben-verhack) wrote :

Ok, so I took some time debugging the issue, I followed the guidelines on the wiki (

As I'm on a fresh install, the issue only triggered once or twice in a series of 5-6 suspends. I suspended with "sudo sh -c "sync; echo 1 > /sys/power/pm_trace; pm-suspend" creating a trace in dmesg.

I added the dmesg output as an attachment, and you can see two call stacks from fglrx. The last suspend in the trace took about 2 minutes to resume, that would be the most interesting one. Though, it could be that this is a different issue than Joep Jansen (comment #9).


Luca Ferretti (elle.uca) wrote :

Rackstar, the slow resume also occurs without fglrx.

Luca Ferretti (elle.uca) wrote :

And here is there dmesg output running pm_trace as on the wiki (

It was perfomed on Natty alpha 2 live

Changed in linux (Ubuntu Natty):
milestone: none → ubuntu-11.04-beta
Changed in linux:
importance: Unknown → Medium
status: Unknown → Incomplete
Andy Whitcroft (apw) wrote :

5 minutes seem to be a common issue when timers have to wrap during boot. We have had two specific fixes for this kind of error recently, so it is worth re-testing with the latest kernels. Could you test the latest natty kernel and report back here. Thanks!

Changed in linux (Ubuntu Natty):
status: Confirmed → Incomplete
Chris (ccouzens) wrote :

Hi Andy,

I just timed resume as 5:17 minutes on an upto date natty install.

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 also timed the system hibernating:

The laptop took about 5 minutes 8 seconds to hibernate. Resuming took 5 minutes 29 seconds (my timer started after GRUB).

Hibernating was this morning, I don't think there were any kernel updates since then.

Andy Whitcroft (apw) wrote :

That dmesg shows an almsot exactly 300s delay in the middle, and then complains about the TSC. Classic symptoms for a lost interrupt. There is a fix coming for AMD based systems which may well be your issue here. I will get some test kernels out shortly.

Changed in linux (Ubuntu Natty):
status: Incomplete → In Progress
assignee: nobody → Andy Whitcroft (apw)
Andy Whitcroft (apw) wrote :

Ok I've built a new kernel which has this patch applied. Could those of you with affected hardware please test these kernels and report back here. Thanks. Kernels are at the URL below:

Changed in linux (Ubuntu Natty):
status: In Progress → Incomplete
Chris (ccouzens) wrote :

I installed the new kernel.
Resuming from suspend now takes about 14 seconds. Hibernating now takes about 28 seconds. Resuming from hibernate now takes about 40 seconds.

This new kernel has fixed the bug! :)

Andy Whitcroft (apw) wrote :

Excellent news. This is fixed by the commit below, which is already in Natty:

  commit 7f74f8f28a2bd9db9404f7d364e2097a0c42cc12
  Author: Andreas Herrmann <email address hidden>
  Date: Thu Feb 24 15:53:46 2011 +0100

    x86 quirk: Fix polarity for IRQ0 pin2 override on SB800 systems

    On some SB800 systems polarity for IOAPIC pin2 is wrongly
    specified as low active by BIOS. This caused system hangs after
    resume from S3 when HPET was used in one-shot mode on such
    systems because a timer interrupt was missed (HPET signal is
    high active).

    For more details see:

    Tested-by: Manoj Iyer <email address hidden>
    Tested-by: Andre Przywara <email address hidden>
    Signed-off-by: Andreas Herrmann <email address hidden>
    Cc: Borislav Petkov <email address hidden>
    Cc: <email address hidden> # 37.x, 32.x
    LKML-Reference: <email address hidden>
    Signed-off-by: Ingo Molnar <email address hidden>

Changed in linux (Ubuntu Maverick):
status: New → Triaged
Changed in linux (Ubuntu Natty):
status: Incomplete → Fix Committed
importance: Undecided → Medium
Changed in linux (Ubuntu Maverick):
importance: Undecided → Medium
tags: added: kernel-key
Luca Ferretti (elle.uca) wrote :

Confirming here too. But my resuming from susped takes only 8 secs :P

PS should we update the upstream bug, adding this info?

Andy Whitcroft (apw) wrote :

@Luca -- do feel free to copy the fix information up to the upstream bug yes.

Changed in linux:
status: Incomplete → Fix Released
Tim Gardner (timg-tpi) wrote :

git describe --contains 7f74f8f28a2bd9db9404f7d364e2097a0c42cc12

Changed in linux (Ubuntu Natty):
status: Fix Committed → Fix Released
Changed in pm-utils:
status: New → Invalid
Tim Gardner (timg-tpi) wrote :

git describe --contains c28e17717762c921c22b3be05590b0746ebfa298

Since this is currently in -proposed I'm marking 'Fix Released' since there is no BugLink in the commit message.

Changed in linux (Ubuntu Lucid):
status: New → Fix Released
Tim Gardner (timg-tpi) wrote :

Coming in v2.6.35.12

Changed in linux (Ubuntu Maverick):
assignee: nobody → Tim Gardner (timg-tpi)
status: Triaged → In Progress
Tim Gardner (timg-tpi) on 2011-04-01
Changed in linux (Ubuntu Maverick):
status: In Progress → Fix Committed
Julian Wiedmann (jwiedmann) wrote :

For Maverick, this should be fixed now with 2.6.35-30.54.
Please reopen the Maverick task if you still experience this issue.

Changed in linux (Ubuntu Maverick):
status: Fix Committed → Fix Released
Julien Olivier (julo) wrote :

I seem to be still experiencing this bug on Oneiric, but only about once every 10 resumes. I'm not 100% sur it's the same bug as I don't have the patience to wait 10 minutes to see if the resume is just very slow or will simply never happen.

Should I re-open this bug?

Julien Olivier (julo) wrote :

This seems totally fixed now in Precise. Thanks!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.