Created attachment 41802 [details] script Suspend to ram hibernate isn't working on that machine. Suspend: System is switching to console, fan, disk, and all leds are still on. During this freeze system doesn't responds to any keys, screen is black with backlight and single underscore character(non blinking). Hibernate: The same as in suspend. Hibernate isn't turning off the machine. After manually powering off it resumes property. All needed data should be in URL that forwards to the previous bug description. Temporary solution: Making a script (in attachment) that take care of "ehci_hcd" before and after the suspend/hibernate. But I think that should kernel do?
Created attachment 41812 [details] dmesg.log
This is an USB problem, so reassigning to USB.
Please check if the issue is still there in 2.6.37-rc8.
The issue still occurs in 2.6.37-rc8.
Try building a kernel with CONFIG_PM_VERBOSE and CONFIG_USB_DEBUG enabled. Boot with no_console_suspend on the command line, and let's see what happens when you suspend without using the script. Also, try doing: echo devices >/sys/power/pm_test before starting the suspend. Does the machine still hang?
(In reply to comment #5) > Also, try doing: > > echo devices >/sys/power/pm_test > > before starting the suspend. Does the machine still hang? No, it returns to desktop after few seconds. Without this command it hangs. I've attached some syslogs. Maybe this will somehow help.
Created attachment 42532 [details] syslog
Created attachment 42542 [details] sysllog after "echo devices >/sys/power/pm_test" command
What do you see on the screen when the system hangs, that is, when you don't write anything to /sys/power/pm_test? Be certain you boot with "no_console_suspend" on the kernel command line.
I couldn't find logs from that so I'm putting a photo: http://img641.imageshack.us/img641/2641/imagexjz.jpg
Oh, I forgot to mention that you also have to do echo 8 >/proc/sys/kernel/printk before starting the suspend. Also, make sure that you're testing the kernel built with CONFIG_PM_VERBOSE.
Created attachment 42732 [details] kern.log
I attached a log (kern.log) after doing "echo devices >/sys/power/pm_test" because I don't see any logs stored from start of suspend to hang.
A log showing what happens when everything works is not useful -- I need to find out what happens when things _don't_ work! That means I need to know what's left on the screen after the machine hangs. The last thing it did should indicate where the problem is.
Ok, so again a photo: http://img815.imageshack.us/img815/1285/imageuc.jpg After last line it hangs.
Hmm... The picture doesn't pinpoint the problem. Can you go through a similar suspend, with the same kernel and boot command line, but this time using your script so that it succeeds? I'd like to see the output from dmesg following the resume.
Created attachment 42752 [details] dmesg_resume
Created attachment 42762 [details] suspend_success
Log from dmesg is in "dmesg_resume" and from suspend process in "suspend_succes". I've manually entered from the script only the part responsible for suspend: echo -n "0000:00:1a.7" | tee /sys/bus/pci/drivers/ehci_hcd/unbind echo -n "0000:00:1d.7" | tee /sys/bus/pci/drivers/ehci_hcd/unbind
One last question (I should have asked this earlier): Are there any USB devices attached to the EHCI controllers? The log shows only a wireless mouse, which is attached to a UHCI controller. Rafael, I'm stuck. The tests show that Tomasz's system hangs very late during the suspend procedure, after all the log messages have been sent to the screen (that is, the first missing line is "Back to C!"). Clearly the problem is some low-level interaction between the PCI controllers and the rest of the system, but it doesn't seem to be USB-specific. Do you have any ideas for other tests to try?
(In reply to comment #20) > One last question (I should have asked this earlier): Are there any USB > devices attached to the EHCI controllers? The log shows only a wireless > mouse, > which is attached to a UHCI controller. Only the mouse is connected, but disconnecting it doesn't help.
Just an idea. Can you try to suspend with acpi_sleep=old_ordering and see if that helps?
No it doesn't help. The machine hangs as before.
Is this bug still seen with modern kernels ?
And what is the output from "lspci -v"?