Bug 25752 - Lenovo y530 suspend/hibernate
Lenovo y530 suspend/hibernate
Status: RESOLVED INSUFFICIENT_DATA
Product: Drivers
Classification: Unclassified
Component: USB
All Linux
: P1 high
Assigned To: Alan Stern
https://bugs.launchpad.net/ubuntu/+so...
:
Depends on:
Blocks: 7216
  Show dependency treegraph
 
Reported: 2010-12-28 12:01 UTC by Tomasz
Modified: 2012-08-14 15:11 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.36-2
Tree: Mainline
Regression: No


Attachments
script (715 bytes, text/plain)
2010-12-28 12:01 UTC, Tomasz
Details
dmesg.log (54.95 KB, text/plain)
2010-12-28 12:46 UTC, Tomasz
Details
syslog (4.72 KB, text/plain)
2011-01-06 13:23 UTC, Tomasz
Details
sysllog after "echo devices >/sys/power/pm_test" command (1.90 KB, text/plain)
2011-01-06 13:25 UTC, Tomasz
Details
kern.log (60.53 KB, text/plain)
2011-01-07 18:47 UTC, Tomasz
Details
dmesg_resume (55.92 KB, text/plain)
2011-01-07 20:39 UTC, Tomasz
Details
suspend_success (33.16 KB, text/plain)
2011-01-07 20:40 UTC, Tomasz
Details

Description Tomasz 2010-12-28 12:01:56 UTC
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?
Comment 1 Tomasz 2010-12-28 12:46:39 UTC
Created attachment 41812 [details]
dmesg.log
Comment 2 Rafael J. Wysocki 2010-12-28 13:33:44 UTC
This is an USB problem, so reassigning to USB.
Comment 3 Rafael J. Wysocki 2010-12-29 23:59:41 UTC
Please check if the issue is still there in 2.6.37-rc8.
Comment 4 Tomasz 2010-12-30 11:58:52 UTC
The issue still occurs in 2.6.37-rc8.
Comment 5 Alan Stern 2011-01-05 21:26:25 UTC
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?
Comment 6 Tomasz 2011-01-06 13:21:35 UTC
(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.
Comment 7 Tomasz 2011-01-06 13:23:56 UTC
Created attachment 42532 [details]
syslog
Comment 8 Tomasz 2011-01-06 13:25:00 UTC
Created attachment 42542 [details]
sysllog after "echo devices >/sys/power/pm_test" command
Comment 9 Alan Stern 2011-01-06 16:23:59 UTC
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.
Comment 10 Tomasz 2011-01-07 09:38:55 UTC
I couldn't find logs from that so I'm putting a photo:
http://img641.imageshack.us/img641/2641/imagexjz.jpg
Comment 11 Alan Stern 2011-01-07 15:34:15 UTC
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.
Comment 12 Tomasz 2011-01-07 18:47:52 UTC
Created attachment 42732 [details]
kern.log
Comment 13 Tomasz 2011-01-07 18:50:19 UTC
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.
Comment 14 Alan Stern 2011-01-07 19:07:14 UTC
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.
Comment 15 Tomasz 2011-01-07 19:44:26 UTC
Ok, so again a photo:
http://img815.imageshack.us/img815/1285/imageuc.jpg
After last line it hangs.
Comment 16 Alan Stern 2011-01-07 19:54:32 UTC
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.
Comment 17 Tomasz 2011-01-07 20:39:40 UTC
Created attachment 42752 [details]
dmesg_resume
Comment 18 Tomasz 2011-01-07 20:40:51 UTC
Created attachment 42762 [details]
suspend_success
Comment 19 Tomasz 2011-01-07 20:41:10 UTC
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
Comment 20 Alan Stern 2011-01-07 21:33:23 UTC
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?
Comment 21 Tomasz 2011-01-07 22:11:22 UTC
(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.
Comment 22 Rafael J. Wysocki 2011-01-17 23:10:46 UTC
Just an idea.  Can you try to suspend with acpi_sleep=old_ordering and see
if that helps?
Comment 23 Tomasz 2011-01-18 22:59:44 UTC
No it doesn't help. The machine hangs as before.
Comment 24 Alan 2012-06-14 17:39:35 UTC
Is this bug still seen with modern kernels ?
Comment 25 Alan Stern 2012-06-14 18:44:17 UTC
And what is the output from "lspci -v"?

Note You need to log in before you can comment on or make changes to this bug.