Created attachment 73571 [details] log of pm-suspsend When i try to suspending my Desktop PC to RAM. I get an blicking cursor and i have to push the reset button to reboot. This used to work in kernel 2.6.22 or so,...
Created attachment 73572 [details] Hardware info
2.6.22 was 5 years ago! Quite a bit has changed between then and 3.2.. Can you test any of the kernels between to suggest if this is a recent or an old regression? how about the latest kernel, it is currently 3.5... One thing that has changed is that your kernel is now using nouveau to talk to NVIDIA, which didn't exist 5 years ago... what do you see when you follow the debugging steps in Documentation/power/basic-pm-debugging.txt ?
I've tested all mainline kernel from 2.6.24 to 3.5 RC1. The problem appeared between kernel 2.6.22 and 2.6.24. P5N-E SLI is able to suspend with 2.6.22m but isn't able to suspend from 2.6.24 to 3.5rc1 At the same time the module asus_acpi.ko has been replaced by asus_laptop.ko. I think there could be a relationship between these things. I will try the debugging steps tonight and i'll post my results then.
Hi I've tried all the different test and with each of the test i'm getting the same result, black screen, fans still turning, i have to hard reboot. The only one which worked a little bit was platform test, where i could suspend but the PC could not wake up after that. I'll try now to unload some drivers. What else can i do?
I have unloaded all the drivers i can, because i don't know how to unload modules which are needed by other modules. These are the drivers my system is using after i have unloaded the modules without dependencies. bnep 18281 2 bluetooth 180104 7 bnep binfmt_misc 17540 1 snd_hda_codec_hdmi 32474 4 snd_hda_intel 33773 2 snd_hda_codec 127706 2 snd_hda_codec_hdmi,snd_hda_intel snd_hwdep 13668 1 snd_hda_codec snd_pcm 97188 3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec snd_timer 29990 1 snd_pcm nouveau 774571 3 ttm 76949 1 nouveau snd 78855 10 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer drm_kms_helper 46978 1 nouveau soundcore 15091 1 snd snd_page_alloc 18529 2 snd_hda_intel,snd_pcm drm 242038 5 nouveau,ttm,drm_kms_helper i2c_algo_bit 13423 1 nouveau mxm_wmi 12979 1 nouveau wmi 19256 1 mxm_wmi video 19596 1 nouveau sata_nv 32286 3 I think the nouveau driver can be excluded, because the same card is able to suspend in another system and because the system is freezing even when using the binary nvidia driver
After that i have installed an ide drive instead of an sata drive, sot that sata_nv was disabled, the system suspend without any problems. So i think the problem is the sata_nv. I tested it with kernel 3.2, 3.4.3 and 3.5rc3
reassign to sata experts.
Hi, Is this bug still being looked at? I am wondering if this bug is related to Bug 48101? https://bugzilla.kernel.org/show_bug.cgi?id=48101 I used to own ASUS P5N-E SLI myself and noticed problems related to USB and ACPI S3 State (Suspend to RAM). After lots and lots of experiments, it appears to be an issue with ASUS made mainboards with NVIDIA or SiS OHCI USB controller. It turns out, this is a bug that started in Linux 3.1 or 3.2 kernel with USB 1.1 devices like USB keyboard or mouse, but it does not seem to affect USB 2.0 device like a USB flash storage stick. Anyway, Bug 48101 has been declared a duplicate of Bug 43081. https://bugzilla.kernel.org/show_bug.cgi?id=43081 Setting USB jumpers to +5VSB rather than +5V seems to help workaround the bug. For this, refer to ASUS mainboard manuals. Regards, fpgahardwareengineer
Hi, this bug affects me too - and it's pretty annoying. There have been plenty of bug reports on several Distributions till now, but none seemes to have reached the kernel-dev team? It would be awesome if this one gets finally fixed. Here's my description: STR stalls with blinking cursor. HardDisks spin down and shut off, all Fans are still active, only hard reset will bring the computer back to life. This bug is definately not a duplicate of Bug 43081 nor Bug 48101. These are related to Computers not waking up from STR correctly. So setting USB jumpers to +5VSB rather than +5V was _not_ a workaround for me. acpi_sleep=old_ordering solved the issue back when I had an IDE harddisk only. Now with SATA it's up again. Disconnecting all USB-devices as suggested in several Threads was not a solution either. Hope you get an eye on this. Regards
Created attachment 107389 [details] output of lspci -vvnn
Created attachment 107390 [details] output of dmesg
I found this issue during a Debian upgrade from kernel 3.2.x to 3.16.x. Details are in the Debian bugreport: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774036 Kind regards Rainer