Kernel Bug Tracker – Bug 9313
suspend to RAM with "echo mem > /sys/power/state" do not reach S3 state
Last modified: 2008-01-10 19:19:11 UTC
Most recent kernel where this bug did not occur:
But occur on this:
I tried this on OpenSuSE 10.3 and Kubuntu 7.10 (on both distros the same bug!)
(on OpenSuse 10.2 and Kubuntu 7.04 works well!)
mobo: Asus K8N SLi Deluxe (chipset NVIDIA NForce 4 SLi)
Proc: AMD Athlon XP64 3500+
Graph:ATI Radeon X300 PCI-e (1x)
SATA disks 2x(no RAID)
2 GB RAM
KDE environment but tried with runlevel 3 & 1
When I typed on command line "echo mem > /sys/power/state" the system do not goes to S3 state (turn off fans, monitor, power supply) but only hard disks are turned off.
Of course, I can not resume machine from this "middle state". I must reset PC.
In distros with older kernel works fine!
I tried with noapic boot option but without effects.
Can you test the 2.6.23 kernel, or better the 2.6.24-rc2 one?
I'm just working on this :) but for this I need a couple of days...
When I test both of them I'll notify here...
I tried 2.6.23 version but do not work (same problem as in previous version)
My next idea is testing all versions of kernel between 2.6.18 and 2.6.22.
Starting with 126.96.36.199 (the latest known good kernel) and going with steps to the last working kernel.
In case that version 188.8.131.52 do not work on ubuntu 7.10 maybe isn't kernel responsible for problems. (Maybe problem lying in DSDT or something else...)
Huh, I'm finished for now and here are the results:
Kernel 184.108.40.206 - can put PC to suspend correctly (S3 state), but can not resume
Kernel 220.127.116.11 - can put PC to suspend and resume correctly! (The best working)
Kernel 18.104.22.168 - can not put PC to suspend correctly
Kernel 22.214.171.124 - can not put PC to suspend correctly
Kernel 2.6.24-rc2- can not put PC to suspend correctly
When testing, I initialy used config file from Live CD Kubuntu 7.04 (with kernel 126.96.36.199) and renew config with "make oldconfig", with default settings for new options.
I do not know what can be wrong in other kernels than 188.8.131.52, but obviously something is wrong.
Please see if the 2.6.22 (vanilla) kernel suspends and resumes correctly.
If that is the case, you can run a git bisection of the kernels between 2.6.22 and 2.6.23 to find the commit that made it stop working.
Is the kernel version 2.6.22 what I can find on www.kernel.org - Vanilla kernel?
Or Vanilla Kernel I must download on some other site?
(In reply to comment #6)
> Is the kernel version 2.6.22 what I can find on www.kernel.org - Vanilla
Yes, this is the one.
I tested 2.6.22 (Vanilla) kernel but do not suspend correctly.
The latest version which works good is the 184.108.40.206 kernel
So, must be something what is new in 2.6.22 kernel.
For better recognizing what is wrong I'll sent to part of my config file with newer options and how its set (options of 2.6.22 kernel).
# CONFIG_KINGSUN_DONGLE is not set
# CONFIG_AF_RXRPC_DEBUG is not set
# CONFIG_RXKAD is not set
# CONFIG_CFG80211 is not set
# CONFIG_MAC80211 is not set
# CONFIG_RFKILL is not set
# CONFIG_MTD_NAND_MUSEUM_IDS is not set
# CONFIG_MTD_NAND_PLATFORM is not set
# CONFIG_MTD_UBI is not set
# CONFIG_PHANTOM is not set
# CONFIG_THINKPAD_ACPI is not set
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_DM_DELAY is not set
# CONFIG_FIREWIRE is not set
# CONFIG_MACINTOSH_DRIVERS is not set
# CONFIG_WLAN_PRE80211 is not set
# CONFIG_WLAN_80211 is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_JOYSTICK_XPAD is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_TINY_USB is not set
# CONFIG_SPI_SPIDEV is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_APPLESMC is not set
# CONFIG_VIDEO_IVTV is not set
# CONFIG_USB_ZR364XX is not set
# CONFIG_DVB_USB_OPERA1 is not set
# CONFIG_DISPLAY_SUPPORT is not set
# CONFIG_FB_HECUBA is not set
# CONFIG_FB_NVIDIA_DEBUG is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_SND_USB_CAIAQ is not set
# CONFIG_OSS_OBSOLETE is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
# CONFIG_MLX4_INFINIBAND is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_SUNRPC_BIND34 is not set
# CONFIG_AFS_DEBUG is not set
# CONFIG_SYSV68_PARTITION is not set
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRC_ITU_T is not set
Maybe some of these options must be disabled (or enabled). Please give me some hint for my investigation...
thanks & bye...
Please build as many drivers as you can as modules. Then, please boot with init=/bin/bash and try to suspend/resume (you'll need to mount /sys and /proc manually for that).
I will try. The last what I tried it was disabling all new options in kernel 2.6.22, but without successfully effects...
Do you have any trick how I can set up all drivers to build as modules with one click (or I must do this manually :( ) in xconfig?
When I loading system with /bin/bash, and with modprobe -r ohci_hcd unload ohci_hcd USB module I can suspend to RAM normaly.
So something wrong is in ohci_hcd module.
What next? I need this module for my USB devices!
Let's add some addresses to the CC list.
Try building a kernel with CONFIG_DISABLE_CONSOLE_SUSPEND and CONFIG_USB_DEBUG enabled. (You may need to use 2.6.23 to get both options; I don't remember when DISABLE_CONSOLE_SUSPEND was first added.) Before suspending, do
echo 9 >/proc/sys/kernel/printk
Then see what shows up on the screen when you suspend the system.
CONFIG_DISABLE_CONSOLE_SUSPEND has been removed in 2.6.24-rc . Now, there's the no_console_suspend command line switch which is available if CONFIG_PM_DEBUG is set.
(In reply to comment #13)
> Try building a kernel with CONFIG_DISABLE_CONSOLE_SUSPEND and CONFIG_USB_DEBUG
> enabled. (You may need to use 2.6.23 to get both options; I don't remember
> when DISABLE_CONSOLE_SUSPEND was first added.) Before suspending, do
> echo 9 >/proc/sys/kernel/printk
> Then see what shows up on the screen when you suspend the system.
Here, what is on the screen:
ACPI device: xx (hex numbers countdown to 01):suspend
ACPI PNP 0C0C:00:suspend
processor ACPI 0007:01:suspend
processor ACPI 0007:00:suspend
When I disabled USB Legacy Support in BIOS, then system suspend normally (with ohci_hcd module loaded) but my USB devices connected to ohci do not work.
Here is one link what I found on internet with the same problem as mine: https://lists.ubuntu.com/archives/kernel-bugs/2007-July/028280.html
my motherboard has nvidia chipsets, too! (NVIDIA nforce 4 SLi)
This makes it sound like there's a bug in the ACPI BIOS. Have you tried to see if a BIOS upgrade is available?
Yes, the latest BIOS is uploaded in my motherboard's chipset, and please note that in kernel version 220.127.116.11 this ohci module works properly with my motherboard and BIOS! This problems occur from kernel 2.6.22 and up...
If this be a ACPI BIOS bug than this module should make problems with the earlier kernel versions. Isn't it?
I think that is something new in ohci module of kernel 2.6.22. what makes trouble with nvidia's chipsets when system suspending. I do not know what changed in this ohci module from version 18.104.22.168 to 2.6.22. but something do not work correctly.
Have you tried the various intermediate kernels? In particular, you should try 2.6.22-rc1.
Maybe what changed between 2.6.21 and 2.6.22 wasn't in the ohci-hcd module at all but somewhere else, like the ACPI driver. That's where you saw the system stop working in comment #15.
Yes, I tried many kernels:
all with the same problem.
Oh, sorry, now I see what you ask me. You want that I try versions between 22.214.171.124 and 2.6.22 Vanilla.
I understand that ohci module maybe is not responsible for crashing in suspend.
I do not know what changed between 126.96.36.199 and 2.6.22. I look at the changelog, but there is many new and changed things! :)
For example, my USB scanner do not working properly with kernel 188.8.131.52, but work very well with 2.6.22 and up.
OK, I'll try subversions of kernel 2.6.22 (rc1 to rc7) and stop when I found problem. After that testing, I'll note here. OK?
Eh, btw in my (not so likely as Linux) Windows Vista Suspend to RAM works fine, too. So, I yet thinking that ACPI BIOS is all right.
I finished with testing RSs of kernel 2.6.22 and results are:
2.6.22-RC1 - works normaly
2.6.22-RC2 and up - DO NOT works normaly
Conclusion - Something goes wrong in RC2.
Can this info helps to solving problem?
Okay, that's good. There are even more intermediate kernels you can test between 2.6.22-rc1 and 2.6.22-rc2. They are 2.6.22-rc1-git1 through 2.6.22-rc1-git8, and you can find the patches for them in
(These patches all apply on top of 2.6.22-rc1.)
Ok, I will test this gits, but something interesting happened.
I tried yet once disabling USB Legacy support in my BIOS (this option is useful only if you have USB keyboard and/or mouse and you work in DOS, or windows safe mode or similar. I do not have USB keyboard neither mouse and this BIOS option isn't important to me) and I was loading official kubuntu's kernel (ver. 184.108.40.206-generic). After booting I tried USB devices and its work, tried suspend to ram and its WORKS! Works everything. For now this is solved my problems, but now I'm curious, is it the kernel bug or not. If you want I can continue testing.
I'm thinking that is the bug because earlier versions of kernels work with USB legacy enabled, and Vista works with this option enabled.
So, what are you thinking?
I don't remember any changes that would make Linux less compatible with USB Legacy support. So yes, I'm curious to see if you can find a particular change responsible for the problem.
OK than, I'll back to testing.
Please, tell me are this gits have a cumulative changes (git2 has all of git1+something new) or not?
This important for create strategy of testing :)
(In reply to comment #25)
> OK than, I'll back to testing.
> Please, tell me are this gits have a cumulative changes (git2 has all of
> git1+something new)
kernel 2.6.22-rc1-git4 - Works!
kernel 2.6.22-rc1-git5 - DO NOT works!
If I can do something yet - just say :)
Created attachment 13732 [details]
Subpatch from 2.6.22-rc1-git4-git5
Are you really certain about that? There are no changes at all to the USB drivers between 2.6.22-rc1-git4 and -git5. In fact, the only change I can see which might be relevant is for kernel/power/main.c -- I have attached that single change.
You could try adding this patch to 2.6.22-rc1-git4 to see if it causes a failure, and remove this patch from 2.6.22-rc1-git5 to see if it then starts working.
I tried once again enable/disable USB Legacy support in my BIOS and it's true, when I disable USB legacy support suspend works perfectly and vice versa.
I tried this on git4 and git5 with init=/bin/bash at logon.
I tried your subpatch and, when I apply them to git4 then git4 do not work and of course, when I remove patch from git5 then git5 works!
Conclusion: This subpatch is responsible for my not working suspend.
I hope that you will find why is that.
Well, unfortunately this is the code ordering change that we can't revert and it's related to the order in which ACPI methods are executed on your system.
With this patch applied the ordering is actually the right one according to the ACPI specification.
Is there any "S3 suspend support" switch in your system's BIOS?
Hmmm. in this case my only option is turn off USB lecacy support, because then everything works well.
Yes, I have S3 option in BIOS:
ACPI suspend type: can be S1(POS), S3(STR) and S1&S3. (set to S3(STR))
ACPI APIC support: Enable (I tried Disable but without effect)
So, if patch following right one ordering of ACPI execution, than my BIOS has fail in that... but why this working fine in Windows?? Must be something what is not directly bonded with my BIOS... (just thinking :) )
(In reply to comment #31)
> Hmmm. in this case my only option is turn off USB lecacy support, because then
> everything works well.
> Yes, I have S3 option in BIOS:
> ACPI suspend type: can be S1(POS), S3(STR) and S1&S3. (set to S3(STR))
You may try to set that to S1&S3. I'll be surprised if that helps, but well ...
> ACPI APIC support: Enable (I tried Disable but without effect)
> So, if patch following right one ordering of ACPI execution, than my BIOS has
> fail in that... but why this working fine in Windows?? Must be something what
> is not directly bonded with my BIOS... (just thinking :) )
There may be a missing ACPI hook somewhere, but that need not be USB drivers.
OK, but why it works when I unload ohci module or disable USB Legacy. Both of this options are directly linked to USB support??
Maybe your BIOS has buggy USB support.
Worse thing is that Asus do not very much like Linux, so... what I have - I have!
Rafael, will your ACPI-1.0 vs. ACPI-3.0 ordering changes affect this issue? There are a few other bug reports that seem to be related as well...
Yes, I think this issue may be related.
Zarko, can you please test the 2.6.24-rc6 kernel with the patch series from:
Yes, I can but which patches exactly?? All of them or only selected?
eh, btw Marry Christmas and Happy New Year :)
(In reply to comment #38)
> Yes, I can but which patches exactly?? All of them or only selected?
All of them, please.
> eh, btw Marry Christmas and Happy New Year :)
Thanks, and to you too. :-)
All of them... ufff it will be a job! OK, but I need more then few days :)
Just say to me, what we finding? Just a one what works or couple of them?
Or, if I found one that works, must I probe others? (There is patches for some hibernation problems. Hibernation and Suspend to RAM is two difference things...
Well, it's easy. Download the last snapshot from:
unpack it in the kernel source directory, rename "hibernation_and_suspend" to "patches" and run "quilt push -a".
Well, this bug is most probably a duplicate of Bug #9528.
*** This bug has been marked as a duplicate of bug 9528 ***
I looked at Bug 9528 and the same things happened to Carlos Corbacho. Same (or very similar) chipset, unloading ohci module makes the error go away.
Please, could you tell Carlos to try disabling USB Legacy support in BIOS?
BTW, I do not find free time to compiling kernel as you suggested to me, but I will! Perhaps in next few days!
Sorry one again.