Natty Narwhal/Sandy Bridge Suspend Fails

Bug #760842 reported by tdeering on 2011-04-14
This bug affects 21 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)

Bug Description

On my CybperpowerPC Gamer Xplorer N57001 (Sandy Bridge) laptop running the latest Natty Narwhal daily build, suspend fails. The screen goes blank and the cpu fan goes crazy as if the processor is in an infinite loop. Only a hard reset of the computer can get it out of that state.

Please let me know any additional details I can provide- this is an important problem I think... Sandy Bridge and Natty Narwhal will be meeting each other often in the coming years.

Phillip Susi (psusi) wrote :

Does this also happen under Maverick?

Changed in pm-utils (Ubuntu):
status: New → Incomplete
tdeering (tomdeering7) wrote :

Yes, I also observe this under Maverick.

Phillip Susi (psusi) on 2011-04-14
affects: pm-utils (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
status: Incomplete → New
Phillip Susi (psusi) on 2011-04-14
tags: added: suspend
tdeering (tomdeering7) wrote :

Can anyone else confirm? This is a deal-breaker for me running Ubuntu on my laptop.

tdeering (tomdeering7) wrote :

Issue is still unresolved, although I have been searching.

HwRhymes (hanswurst) wrote :

I'm also affected by this, although on a desktop machine: i5 2500K, Asus P8P67-M Pro, Nvidia GT210.
Suspend fails on Ubuntu 10.04, 10.10 and 11.04.

As described, only a hard reset helps to restart the computer, the reset button does nothing.
There is no video signal, but the harddisk seems to spin up 2-3 times after abruptly stopping.

HwRhymes (hanswurst) wrote :

To add: Latest Bios revision (708) and working suspend/resume in Windows 7.

tdeering (tomdeering7) wrote :

Likewise, suspend/resume works fine for me in Windows 7 as well.

On 4/26/2011 1:40 PM, HwRhymes wrote:
> I'm also affected by this, although on a desktop machine: i5 2500K, Asus P8P67-M Pro, Nvidia GT210.
> Suspend fails on Ubuntu 10.04, 10.10 and 11.04.

I have the same CPU and the P8P67-Pro. Works fine in 11.04, but in
10.10, I have to sudo modprobe -r xhci_hcd first.

HwRhymes (hanswurst) wrote :

Just tried
sudo modprobe -r xhci_hcd
on a fresh and updated Ubuntu 10.10 install, but suspend/resume still fails. There must be a fundamental difference between your P8P67 Pro and my P8P67-M Pro, probably also firmware-wise. Mine only has 2 USB3 ports and no bluetooth, but I already disabled all the critical functions in BIOS.

Frankly, my machine is simply stuck on wakeup. No kernel-log, no ping, no response, no video signal. 3 times self-rebooting on wakeup tells me, that something goes awfully wrong...

tdeering (tomdeering7) wrote :

Tried: sudo modprobe -r xhci_hcd

No effect for me- Same blank screen, cpu/fan spinup, and hard reset needed.

Phillip Susi (psusi) wrote :

Can you hold down Alt and SysRQ and press S and then B when it is stuck?
 Does that immediately reboot the machine?

Also try suspending from the console instead of X:

1) Press CTRL-ALT-F1 to switch to the console
2) Run sudo -s
3) Run echo mem > /sys/power/state

Does this resume? Press CTRL-ALT-F7 to switch back to X.

HwRhymes (hanswurst) wrote :

First, thank you, Phillip. Your help is much appreciated!

Back on latest Ubuntu 11.04 I switched to tty1, ran "echo mem > /sys/power/state" as root. The machine looked like it properly suspended, fans stopping, hdd spinning down.
Waking up by pressing the power button caused the fans to run, hdd spin up, video signal stays off = stuck.

Pressing Alt + SysRQ + S then B didn't have any visible/audible effect - machine kept running in that state.

I pressed the softreset button and the fans stopped for a moment, but I couldn't get it back to the BIOS logo (or any video signal for that matter). Only a hard reset by long power button press actually resets. Weird, isn't it?

I just checked kern.log and syslog, but they don't state anything at all. It's a complete gap until the machine reboots after a hard reset.

HwRhymes (hanswurst) wrote :

Any update for you, tdeering?

tdeering (tomdeering7) wrote :

Sorry for the delay in response. 2 updates from me:

1) I freshly reinstalled Natty after the final version came out. As you would expect, the problem still persisted.

2) I did as you suggested and suspended from the console. This time, the cpu/fan did not spin up and go crazy as they do when I graphically try to suspend. The computer got to a state where the hard drive spun down and the screen went blank, but the backlight was still on. However, I could not wake it up from this state without a hard reset. In other words, suspend from the console produced different results than from within Unity or Gnome, but still failed to properly suspend my laptop.

tdeering (tomdeering7) wrote :

So HwRhymes, it seems that I had a similar result to yours. However, I believe that the suspend isn't properly completing, which would explain why resume isn't working right.

HwRhymes (hanswurst) wrote :

In the meantime, I did further testing on what is causing this. I came across 2 different hints:

1. When suspending/resuming, the motherboard may leave certain parts of "lowmem" in a corrupt state. The default parameter for the kernel is 64K, which it constantly monitors every 60 seconds as well as after resuming. Some people report fixing their suspend/resume by increasing this number. It can be done by adding

... memory_corruption_check_size=128K ...

to the kernel line in /boot/grub/menu.lst. I tried several different values but was never able to properly resume. In total, I tested kernel 2.6.32 (lts), 2.6.38-8 and 2.6.39-rc5 with this method, but it made no difference.

2. There is a wiki on debugging kernel suspend ( by letting the kernel trace its actions. The commands used are

sudo sh -c "sync; echo 1 > /sys/power/pm_trace; pm-suspend"

As I wrote before, my machine seems to automatically reset itself very early during a resume (which is probably done, because it can be potentially overclocked and wrong settings may otherwise render it broken). So, in this state after it restarts itself, I cannot do much but hard reset it, reboot and then check the dmesg output.
In contrast to the wiki article, I could not find any line in dmesg that said

hash matches drivers/base/power/resume.c:46

however I found the (probably meaningless) "Magic number" line.

Does that mean that the kernel never gets to the resume step at all?

HwRhymes (hanswurst) wrote :

By the way, here is the ACPI part of my dmesg output:

[ 0.769740] ACPI: bus type pci registered
[ 0.769745] Trying to unpack rootfs image as initramfs...
[ 0.769787] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xe0000000-0xe3ffffff] (base 0xe0000000)
[ 0.769788] PCI: not using MMCONFIG
[ 0.769789] PCI: Using configuration type 1 for base access
[ 0.770201] bio: create slab <bio-0> at 0
[ 0.770978] ACPI: EC: Look up EC in DSDT
[ 0.771651] ACPI: Executed 1 blocks of module-level executable AML code
[ 0.773175] ACPI Error: [RAMB] Namespace lookup failure, AE_NOT_FOUND (20110112/psargs-359)
[ 0.773178] ACPI Exception: AE_NOT_FOUND, Could not execute arguments for [RAMW] (Region) (20110112/nsinit-349)
[ 0.773368] ACPI: SSDT 00000000bf5d9c18 0038C (v01 AMI IST 00000001 MSFT 03000001)
[ 0.773580] ACPI: Dynamic OEM Table Load:
[ 0.773582] ACPI: SSDT (null) 0038C (v01 AMI IST 00000001 MSFT 03000001)
[ 0.773604] ACPI: SSDT 00000000bf5dae18 00084 (v01 AMI CST 00000001 MSFT 03000001)
[ 0.773778] ACPI: Dynamic OEM Table Load:
[ 0.773779] ACPI: SSDT (null) 00084 (v01 AMI CST 00000001 MSFT 03000001)
[ 0.774138] ACPI: Interpreter enabled
[ 0.774139] ACPI: (supports S0 S1 S3 S4 S5)
[ 0.774152] ACPI: Using IOAPIC for interrupt routing
[ 0.774165] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xe0000000-0xe3ffffff] (base 0xe0000000)
[ 0.774213] PCI: MMCONFIG at [mem 0xe0000000-0xe3ffffff] reserved in ACPI motherboard resources
[ 0.784041] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
[ 0.786875] ACPI: EC: GPE = 0x18, I/O: command/status = 0x66, data = 0x62
[ 0.786961] ACPI: No dock devices found.
[ 0.786962] HEST: Table not found.
[ 0.786964] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 0.787088] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])

Those 2 lines might be most important, but I didn't find out much about them:
[ 0.773175] ACPI Error: [RAMB] Namespace lookup failure, AE_NOT_FOUND (20110112/psargs-359)
[ 0.773178] ACPI Exception: AE_NOT_FOUND, Could not execute arguments for [RAMW] (Region) (20110112/nsinit-349)

Phillip Susi (psusi) wrote :

The drivers/base/power/resume.c:46 part is just an example; in your case the hash will likely match something else, so look for a slightly different message.

This is also starting to look like a case of buggy ACPI BIOS. You might check if there is a bios upgrade for your motherboard.

I have the same issue. It affects Toshiba Portege R830 model.

After many tries with s2ram and memory_corruption_check_size options
(all of them resulted the same: blank screen, noisy fans and lack of any response).
To highlight the situation I tried to suspend only from console with init=/bin/bash

Try of tracking down failing device gave the following result:

(sorry... pressed TAB too early :) )

Magic number: 11:785:170
acpi device:33: hash matches

So this gave nothing so far and is different from HwRhymes results.

HwRhymes (hanswurst) wrote :

@Phillip Susi: Unfortunately, I already have the latest BIOS version. I re-updated and also did a CMOS reset. Still, Windows 7's suspend works reliably. : (

I did 10+ runs of kernel suspend debugging with dmesg. Here are lines that contained "hash match":

run 3:
[ 1.384280] tty ttyS25: hash matches
[ 1.384296] pci_link PNP0C0F:00: hash matches

run 5:
[ 1.356874] bdi 1:1: hash matches

run 8:
[ 1.337032] tty ttyS27: hash matches
[ 1.337047] pci_link PNP0C0F:02: hash matches

run 12:
[ 1.356872] tty tty30: hash matches

Keep in mind, that those didn't show up reliably. Most of the time there was no line "hash match" at all.

On my mainboard, there are 3 pci express slots, but only 1 is used by an Nvidia graphics card. I also tried using another slot and removing the gpu altogether to suspend via ssh. It didn't make a difference.

Phillip Susi (psusi) wrote :

Can you try writing "core" to /sys/power/pm_test before suspending?
That should test everything except actually calling the firmware to turn
off the power, wait 5 seconds, then come back up.

Download full text (13.3 KiB)

Results for Toshiba R830...

[ 440.166860] PM: Syncing filesystems ... done.
[ 440.494663] PM: Preparing system for mem sleep
[ 440.499181] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 440.518495] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[ 440.538501] PM: Entering mem sleep
[ 440.538973] Suspending console(s) (use no_console_suspend to debug)
[ 440.619140] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 440.619434] sd 0:0:0:0: [sda] Stopping disk
[ 440.787961] PM: suspend of drv:tpm_tis dev:00:03 complete after 134.572 msecs
[ 440.788884] ehci_hcd 0000:00:1d.0: PCI INT A disabled
[ 440.789344] ehci_hcd 0000:00:1a.0: PCI INT A disabled
[ 440.789379] HDA Intel 0000:00:1b.0: PCI INT A disabled
[ 440.789675] sdhci-pci 0000:01:00.0: PCI INT A disabled
[ 440.790384] ACPI handle has no context!
[ 440.808520] i915 0000:00:02.0: power state changed by ACPI to D3
[ 441.048039] PM: suspend of drv:sd dev:0:0:0:0 complete after 429.685 msecs
[ 441.048193] PM: suspend of drv:scsi dev:target0:0:0 complete after 429.726 msecs
[ 441.048237] PM: suspend of drv:scsi dev:host0 complete after 429.042 msecs
[ 441.067314] PM: suspend of drv:ahci dev:0000:00:1f.2 complete after 279.209 msecs
[ 441.174135] e1000e 0000:00:19.0: PCI INT A disabled
[ 441.174171] e1000e 0000:00:19.0: PME# enabled
[ 441.174372] e1000e 0000:00:19.0: wake-up capability enabled by ACPI
[ 441.187177] PM: suspend of drv:e1000e dev:0000:00:19.0 complete after 398.469 msecs
[ 441.187319] PM: suspend of drv: dev:pci0000:00 complete after 397.644 msecs
[ 441.187377] PM: suspend of devices complete after 648.613 msecs
[ 441.187415] PM: suspend devices took 0.650 seconds
[ 441.267357] PM: late suspend of devices complete after 80.048 msecs
[ 441.268026] ACPI: Preparing to enter system sleep state S3
[ 441.270009] PM: Saving platform NVS memory
[ 441.288409] Disabling non-boot CPUs ...
[ 441.292333] CPU 1 is now offline
[ 441.556481] CPU 2 is now offline
[ 441.576769] Broke affinity for irq 9
[ 441.576803] Broke affinity for irq 23
[ 441.577974] CPU 3 is now offline
[ 441.579549] suspend debug: Waiting for 5 seconds.
[ 446.588091] Enabling non-boot CPUs ...
[ 446.588389] Booting Node 0 Processor 1 APIC 0x1
[ 446.767530] CPU1 is up
[ 446.767969] Booting Node 0 Processor 2 APIC 0x2
[ 446.774670] Switched to NOHz mode on CPU #1
[ 446.954414] Switched to NOHz mode on CPU #2
[ 446.997450] CPU2 is up
[ 446.997898] Booting Node 0 Processor 3 APIC 0x3
[ 447.184009] Switched to NOHz mode on CPU #3
[ 447.217473] CPU3 is up
[ 447.227049] ACPI: Waking up from system sleep state S3
[ 447.229629] i915 0000:00:02.0: power state changed by ACPI to D0
[ 447.244051] i915 0000:00:02.0: BAR 0: set to [mem 0xc0000000-0xc03fffff 64bit] (PCI address [0xc0000000-0xc03fffff])
[ 447.244089] i915 0000:00:02.0: BAR 2: set to [mem 0xb0000000-0xbfffffff 64bit pref] (PCI address [0xb0000000-0xbfffffff])
[ 447.244099] i915 0000:00:02.0: BAR 4: set to [io 0x3000-0x303f] (PCI address [0x3000-0x303f])
[ 447.244141] i915 0000:00:02.0: power state changed by ACPI to D0
[ 447.244215] i915 0000:00:02.0: restoring config space at offset 0x1 (w...

Phillip Susi (psusi) wrote :

This is looking more and more like broken ACPI BIOS. Instead of looking
for the hash match in dmesg, you should also check:

cat /sys/power/pm_trace_dev_match

This will find matches for drivers loaded as dynamic modules.

HwRhymes (hanswurst) wrote :

@Phillip Susi: That was a really interesting hint! Here are my results using
sudo sh -c "echo 'core' > /sys/power/pm_test"

1. GPU present (with Nvidia driver), fans kept running and machine was stuck (no ping, no keyboard, no video signal). dmesg after reboot:

2. No GPU present (but Nvidia driver still installed), it correctly suspended and resumed after a few seconds.

3. GPU present (Nvidia driver removed, nouveau driver installed), it correctly suspended and resumed after a few seconds.

4. no echo "core"
GPU present, Nvidia driver removed, nouveau driver installed, regular pm-suspend ---> machine stuck and multiple reboots

HwRhymes (hanswurst) wrote :

Thinking about it, I realise 2 things:
1. Current Nvdidia driver breaks suspend.
2. ACPI part of BIOS contains something weird (that Windows 7 ignores or correctly understands)

Still can't find any matches from /sys/power/pm_trace_dev_match

This seems in fact to be a problem for a broken BIOS. Unfortunately I tried so many things - trying to fix the BIOS ACPI tables (customized kernel loading modified DSDT's), trying to set different ODID's which ACPI would recognize (Windows 2001 SP1, SP2, SP3, Windows 2006). None of these helped in any way... So I am not convinced yet in this.

Any ideas where too look at?

HwRhymes (hanswurst) wrote :

Is there another way of disecting the ACPI parts contained in the BIOS?
Maybe even from inside Windows and comparing them to what can be found in Ubuntu...

Unfortunately, DSDTs and ODIDs exceed my knowledge by far.
Still, I'm always willing to test and try suggestions!

After many hours, runned tests and crawling in ASL code - I still could not find anything
particular... But finally got it working. I have found some notifications about disabling
USB 3.0 in some cases in previous kernels helped to solve some case. I had thought - why
not to disable all devices.. And then step by step - I tried all possible settings in BIOS...

It probably wasn't BIOS implementation. Disabling support for VT-D in BIOS - solved
the case. @HwRhymes - can you confirm this?

But it still sounds like possible bug in the kernel.

Phillip Susi (psusi) wrote :

Hash: SHA1

> It probably wasn't BIOS implementation. Disabling support for VT-D in BIOS - solved
> the case. @HwRhymes - can you confirm this?
> But it still sounds like possible bug in the kernel.

That is the hardware virtualization thing right? If so, I have VT-D
enabled on my Asus P8P67 Pro and don't have a problem.
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla -



Yes, you are right - this hw virtualization... There are two options: VT-X and VT-D. Having enabled VT-D causes problems while VT-X works fine... My laptop allows (AFAIR) 4 options:
* VT-X,
* VT-X + VT-D,
* VT-D (not sure about this one)

Can you Philip confirm that you have VT-D (IO virtualization) option enabled?

HwRhymes (hanswurst) wrote :

@Adam: As far as I remember, my BIOS allows VT-D enabled or disabled. There is just this single option for virtualisation (if I'm correct). I will check this evening and report back.

HwRhymes (hanswurst) wrote :

The option is simply called "Intel Virtualization Technology" and can be either "enabled" or "disabled".
Unfortunately, setting it to disabled also results in a broken suspend/resume.

So maybe try to follow my solution path... Disable everything what's possible to disable from BIOS level.. Then try to start in Emergency Mode (you can edit grub kernel line by including init=/bin/bash and pass it to the kernel) - and then play with s2ram (different options) -f, -s, -m, -p.

When you'll find something different than failing resume - try to boot in full mode.

Hope this will help you to find possible source of the failure.

Liam Kurmos (quantum-leaf) wrote :

i also experience this on my ASUS P8H67-M Pro under natty. Virtualization was disabled by default and i have never enabled it.
Using nvidia 173 on my geforce 8800gtx the system appeared not to suspend. With this removed it i appeared to suspend ok but not able to resume.

marc (marc-harper+launchpad) wrote :

I'm running a i7 2600k on an Asus P8P67 (standard), running kubuntu with the latest stock kernel on Natty.

When overclocked, my system fails to resume on suspend, though suspend seems to succeed. I can stably overclock to 4.8 Ghz and everything but suspend/resume works without issue.

When not overclocked, my system is able to resume successfully. This is regardless of the state of the virtualization option in the bios. (FYI Virtualbox works fine on my system.)

Loading the kernel module xhci_hcd does not fix the resume issue when overclocked. I have also compiled several custom kernels with various options, and while they dramatically improve performance, they have not resolved the suspend issue.

HwRhymes (hanswurst) wrote :

The report on archlinux forums is also by me. Sorry for not mentioning that here. At first I thought it was related to a specific linux distro, but obviously it isn't. I didn't get any proper response there, but then I found this bug report for ubuntu and joined.

Thanks for the advise! I just tried switching off or disabling every single BIOS option (only use 1 core, no turbo, etc). But again, it failed to resume with any combination of s2ram options there is...

Do you have the latest BIOS version 0708? Do you also experience multiple reboots when resuming (harddrive spins up in short intervals, red memory led flashes shortly like on a regular boot)?

Liam Kurmos (quantum-leaf) wrote :


i havent updated the bios, im pretty sure it said 0902 in cmos but that isnt listed on the asus site so ill have to check it.
im on the p8h67-m pro i think other posters were p67. i cant say i noticed multiple reboots either, ill check later.

i noticed there is a new bios on asus site 1002, only a few days old. I could try it.
Is it still the case that you need to have windows to load bios' ? it been a while since ive done it.

will post reports once done

Phillip Susi (psusi) wrote :

Hash: SHA1

For what it's worth, I am running bios rev 1502 now on my P8P67-Pro. I
upgraded to that when it came out a few days ago to address an incorrect
frequency table when overclocking. Suspending has not been a problem
under any of the 3 bios revs I have gone through since getting the board
at the end of January.

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


marc (marc-harper+launchpad) wrote :

Here's a duplicate of the bug:

This is a kernel issue. (I'm not the same Marc as in that thread.)

HwRhymes (hanswurst) wrote :

Today, I updated the BIOS to 709, which unfortunately did not make any difference.
Note says only, "1. Fixed system hang if the HDD is NTFS format and the allocation unit size is not 4096 bytes".

Sorry, I misread your post first. You have the H67 chipset with graphics ports. Still, it may be very similar to mine (P67), at least in terms of connectors and micro ATX form factor.

Updating the BIOS is done by putting the *.ROM file on a usb drive and then choosing "update" (last tab) from within the BIOS menu. No need for Windows : )

Liam Kurmos (quantum-leaf) wrote :

confirming that (with nvidia driver disabled) my asus p8h67m-pro enters suspend and on resume appear so restart multiple times before ending with an unresponsive black screen.


Stefan (stefan-tobe) wrote :

Hi ,
I have recently installed new motherboard p8p67-m with kernel 2.6.32-32
 on ubuntu 10.04. Initially system would not suspend nor hibernate
After both turning off legacy USB3 support and USB3 controller in BIOS GUI I tried again and at least hibernate works now. Suspend works fine but resume result in black screen. At least some steps ahead.

HwRhymes (hanswurst) wrote :

Hi Stefan,

This is because kernel 2.6.32 does not work well with USB3, kernel 2.6.37+ includes those modules ("xhci" if I remember correctly). So, with a new kernel no manual unloading or blacklisting of those modules is necessary.

Most people in this thread struggle with incompatibilities related to a mix of acpi/bios/kernel bugs. Unfortunately, no fix is in sight...


HwRhymes (hanswurst) wrote :

Hey everyone, I got news:

In the archlinux forums, somebody hinted at the exact same issue affecting an Intel H67 mainboard (Liam confirmed it on an ASUS P8H67-m PRO board).

The bug was found to be in the BIOS, which Intel supposedly fixed in their latest version. Also, some kernel patches were introduced, which I did not try (never attempted to build a kernel myself so far).

ASUS might fix the issue in a future BIOS release, but obviously for them, there is no issue (it works in Windows!).

HwRhymes (hanswurst) wrote :

I manually compiled a kernel from source and after applying the mentioned patches (
It did not work in my case (P67, external GPU), probably because the patches are related to an Intel video driver (i915).

Maybe this is helpful for someone with H67 board (uses Intel video driver).

Liam Kurmos (quantum-leaf) wrote :

I use H67 but not the on board. I can't look at rebuilding my kernal at the moment.

Liam Kurmos (quantum-leaf) wrote :

Is this bug still active? If all asus sandy bridge mobos have this problem it seems like it should be quite serious... does anyone know whether there are kernals/distros on which pm-suspend will work on an asus sandy-bridge mobo?

HwRhymes (hanswurst) wrote :

There is no solution yet. Frankly, it does not affect all ASUS motherboards, only P8[P/H]67-M Pro, as far as I've read.
Besides ubuntu, I tested the Archlinux kernels as well as stock (mainland) kernels. None makes a difference.

tdeering (tomdeering7) wrote :

My laptop has a Pegatron A15 motherboard (a subsidiary of Asus), and I still experience the problem.

Dave (david-collett) wrote :

I have the same problem (suspend ok, resume fails) with a new ASRock Z68 Pro3-M board.
Processor is i5 2500K, not overclocked, using onboard graphics.
FYI, Z68 is in the same family as P67/H67. ASRock is also a subsidiary of ASUS.

sea man (mar1o-bross-d) wrote :

Same problem here whit fresh install ubuntu studio 11.04 x64 and Sabertooth p67 Lasted bios 1801 , 2600k @ stock setting and a radeon 6870.

sea man (mar1o-bross-d) wrote :

Also i find this.. if a suspend the machine for short time (ie 5 min) .. awake fine.. but if i wait for long time ( ie 1 hour) never wakeup.

I have this problem too, and a separate problem with my graphics under Sandybridge:

There is a kernel available that fixes my graphics problem at comment #38 in the above bug:

It also seems to have fixed my suspend problem, so might be worth a try.

This bug is missing log files that will aid in dianosing the problem. From a terminal window please run:

apport-collect 760842

and then change the status of the bug back to 'New'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete

Architecture: amd64
DistroRelease: Ubuntu 11.04
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110426)
Package: linux (not installed)
ProcVersionSignature: Ubuntu 2.6.39-0.5~20110427-generic 2.6.39-rc5
Tags: natty running-unity
Uname: Linux 2.6.39-0-generic x86_64
UnreportableReason: The running kernel is not an Ubuntu kernel
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm admin cdrom dialout libvirtd lpadmin plugdev sambashare

tags: added: apport-collected natty running-unity
mejo (jonas-freesources) wrote :

AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.23.
 **** List of PLAYBACK Hardware Devices ****
 card 0: PCH [HDA Intel PCH], device 0: CONEXANT Analog [CONEXANT Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
Architecture: amd64
 **** List of CAPTURE Hardware Devices ****
 card 0: PCH [HDA Intel PCH], device 0: CONEXANT Analog [CONEXANT Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
 /dev/snd/controlC0: resivo 1919 F.... pulseaudio
CRDA: Error: [Errno 2] Datei oder Verzeichnis nicht gefunden
 Card hw:0 'PCH'/'HDA Intel PCH at 0xf2620000 irq 47'
   Mixer name : 'Conexant CX20590'
   Components : 'HDA:14f1506e,17aa21ce,00100000'
   Controls : 8
   Simple ctrls : 5
 Card hw:29 'ThinkPadEC'/'ThinkPad Console Audio Control at EC reg 0x30, fw unknown'
   Mixer name : 'ThinkPad EC (unknown)'
   Components : ''
   Controls : 1
   Simple ctrls : 1
 Simple mixer control 'Console',0
   Capabilities: pswitch pswitch-joined penum
   Playback channels: Mono
   Mono: Playback [on]
DistroRelease: Ubuntu 11.04
HibernationDevice: RESUME=UUID=d5516d20-8861-49b9-ba38-fa0835b73533
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110426)
MachineType: LENOVO 4180W1H
Package: linux (not installed)
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-2.6.38-10-generic root=/dev/mapper/vgsys-root ro quiet splash pcie_aspm=force vt.handoff=7
ProcVersionSignature: Ubuntu 2.6.38-10.46-generic
 linux-restricted-modules-2.6.38-10-generic N/A
 linux-backports-modules-2.6.38-10-generic N/A
 linux-firmware 1.52
Tags: natty running-unity
Uname: Linux 2.6.38-10-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm admin cdrom dialout libvirtd lpadmin plugdev sambashare 05/13/2011
dmi.bios.vendor: LENOVO
dmi.bios.version: 83ET56WW (1.26 )
dmi.board.asset.tag: Not Available 4180W1H
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr83ET56WW(1.26):bd05/13/2011:svnLENOVO:pn4180W1H:pvrThinkPadT420:rvnLENOVO:rn4180W1H:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: 4180W1H
dmi.product.version: ThinkPad T420
dmi.sys.vendor: LENOVO

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
mejo (jonas-freesources) wrote :

i still discover this bug on a lenovo thinkpad t420. most of the time suspend fails and leads to a crash. sometimes it seems to work.

mejo (jonas-freesources) wrote :

This is a severe issue, as it might lead to damaged hardware. Suspend to RAM is the default for several situations (closing lid, idling in battery mode, ...). To me it already happend twice that I didn't recognize the crash immediately. The laptop got extremely hot as the cpu seems to run crazy in these crashes.

mejo (jonas-freesources) wrote :

Btw. I use the internal intel graphics, the discrete nvidia graphics is disabled in BIOS.

Now gave the kernel from a try, and indeed it seems to fix the problem for me. If I got it right, then the 2.6.39-11 kernel from proposed-updates contains the relevant patch as well. Not sure about that though.

I'm not using ubuntu here, but since this is a BIOS problem I guess I'd share my experience as well.

I own an Asus P8H67M-Pro with a i3-2100 running with no extra cards and using integrated video.
The system is running a gentoo-sources 3.0.4 kernel.

The motherboard had BIOS revision 0806 and the suspend/hibernate bug was present on it.
Reading various reports in the net, I just tried upgrading the BIOS to revision 1003 which is the latest available from the Asus website and it still fails to resume.

Symptoms are unchanged, machine wakes up for a few seconds, reboots and hangs there doing nothing.
Pressing the reset button makes it reset in loop.
Power cycle required to get back to a working state.

I'll give a shot at previously mentioned patches if I can find some updated on top of latest 3.0 kernel series.

I tried applying the patch and building a kernel with them, but I got no positive results. Running kernel 3.1 now and still having the problem.

This bug also affects me.

Asus P8H67-V motherboard, BIOS version 0806
Ubuntu 11.10 32-bit
External NVidia 250 GTS GPU

booting linux with init=/bin/bash (i.e. no GPU/USB3 modules loaded, and typing
  echo mem > /sys/power/state
will suspend the system successfully, but upon resume the system will reboot 2-3 times and then hang with blank screen.

Tried also
  echo 1 > /sys/power/pm_trace
  echo mem > /sys/power/state
Same results, and found no "hash matches" in dmesg log (this done with init=/bin/bash too). Actually, the RTC time was still set correctly. So did it crash before any checkpoint was reached?

Also tried to set memory_corruption_check_size=128K (also 256K) on kernel command line, but no effect.

All /sys/power/pm_test tests work fine, in both mem and disk modes. So, to me this bug seems to be somewhere in passing control from BIOS from linux resume handler. Could be very well a bug in BIOS. Haven't tried windows suspend yet.

Hope this is of some help. I can provide more details if needed.

beta992 (beta992) wrote :

Has anyone solve this issue? I have the same motherboard as a few here: Asus P8H67M-PRO v3.0.
I have installed the latest BIOS, and latest linux-kernel: (Archlinux)
Linux * 3.1.6-1-ARCH #1 SMP PREEMPT Thu Dec 22 09:11:48 CET 2011 x86_64 Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz GenuineIntel GNU/Linux

I'm using the intergrated Intel GPU, maybe that is the problem?
I have SSD OGZ Vetrex 2.

Thanks, and hope we can solve this in the new year. :)

I gave up on this for now. I'll try to switch to EFI booting in the next months and see if it fixes anything but for traditional bios based boot, looks like there is to do but to wait for asus to fix their mess or some kernel dev to implement a workaround.

tags: added: maverick

tdeering, thank you for reporting this and helping make Ubuntu better. This bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please provide the information noted in ? As well, can you try with the latest development release of Ubuntu? ISO CD images are available from .

If it remains an issue, could you run the following command in the development release from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux <replace-with-bug-number>

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.

Please let us know your results. Thanks in advance.

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
tags: added: needs-upstream-testing
tdeering (tomdeering7) wrote :

In my latest testing, I no longer experience this issue (in Oneiric). Not sure about Natty with the latest updates applied.

tags: added: kernel-fixed-upstream
Phillip Susi (psusi) wrote :

Glad to hear it has been fixed.

Changed in linux (Ubuntu):
status: Incomplete → Fix Released

FTR, I confirm the problem appears to be fixed with linux 3.4 on my system.
Big thanks to whoever made this happen :)

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

Other bug subscribers

Related questions

Remote bug watches

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