Comments on: How to debugging Linux failure to resume from suspend?

By: Tim H

Tim H — Fri, 28 Dec 2012 07:28:54 +0000

I just “upgraded” from Ubuntu Lucid to precise. Under Lucid, I had 100% success with suspend and resume. Under Precise it kernel panics on resume every time (blinking keyboard lights, no display). It panics about 2 seconds after pressing the power button.

Of course I have no serial port on this computer.

So basically I am screwed, as best I can tell. This is a pretty critical feature for me.

By: John Goerzen

John Goerzen — Wed, 29 Aug 2012 21:36:45 +0000

No, sadly.

By: Paul Menzel

Paul Menzel — Wed, 29 Aug 2012 16:05:47 +0000

Were you able to solve this problem?

By: Christian

Christian — Thu, 02 Aug 2012 10:13:15 +0000

Try adding this to the kernel boot command-line, it solved a similar problem for me. No idea what it does but it doesn’t seem to affect performance.

acpi_osi=linux noapic

By: Aaron Brooks

Aaron Brooks — Fri, 22 Jun 2012 03:23:08 +0000

Because of the disappearance of legacy serial devices, the USB EHCI standard has an optional specification for EHCI debug ports. A good starting point is this page: http://www.coreboot.org/EHCI_Debug_Port though you’ll probably need to dig through the current kernel docs and, if things are in the same state as the last time I used one of these, the kernel sources. (I also had to do some minor patching to get things to work.)

The device I have is a Ajays Tech NET20DC: http://www.ajaystech.com/net20dc.htm . Having worked with several of these I’ve found that they can vary in the orientation of the primary and secondary interfaces in a way not observable from the outer case. You may need to turn things around. The only difference that I’ve found between the primary and secondary interface is that the device draws power from the primary interface and, usually, it’s more convenient to have the primary interface connected to the debugging host rather than the debugee so the device remains powered.

Not all motherboards support these devices but all the ones that I’ve tried so far do. The main trick is to figure out which USB port is the 0th port as only that port will support the debug interface. On desktops this is likely accomplishable. With notebooks, you are at the mercy of the system designer to wire up and provide a USB connector to the 0th port. Note that most motherboards have additional headers for USB interfaces that may not be connected to the backplate or the chassis. Also, the debug device will not work through a hub.

I wish I remembered the details of the correct kernel commandline options for EHCI debug support but those are gone from my memory.

Good luck!

-A.

By: gena2x

gena2x — Sun, 17 Jun 2012 02:11:03 +0000

Treakiest thing in kernel is debugging suspend/resume.

Things to try for ordinary users are:
1. Try different kernel versions. Downgrade, upgrade.
2. Try to disable as much hardware as possible (for example, just move out kernel modules
Kernel hacker would do:
1. Try serial console to view kernel log.
2. Try to save kernel log to some storage and replay on reboot.
3. Try to disable framebuffer to see log
4. Try to enable kernel debugging options.

Hope that options would be enough to entertain you for a few days =)

By: eMHa

eMHa — Fri, 15 Jun 2012 12:13:00 +0000

Have you tried to suspend/resume using an up-to-date Live-CD (Debian, Ubuntu, or any other distro)? Thats what I usually “try on laptops” to figure where the problem might be.

By: Paul Hedderly

Paul Hedderly — Fri, 15 Jun 2012 07:35:12 +0000

Do you have a serial port on that machine? You could try setting kernel logging/console to ttyS0 and watch that with another machine obviously.

If that mobo doesnt have serial… lament!

By: John Goerzen

John Goerzen — Fri, 15 Jun 2012 03:10:27 +0000

Some good tips there, Ben, Thanks.

I don’t think the syslog will help; the problem seems to be on the way up, and the network is broken at that point, though I suppose it wouldn’t hurt to validate that assumption.

By: Ben Hutchings

Ben Hutchings — Fri, 15 Jun 2012 01:36:41 +0000

I don’t know whether you’ve gone through this already, but: http://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt

By: Anonymous

Anonymous — Thu, 14 Jun 2012 22:25:37 +0000

Write up what you tested, and post it to LKML with CCs to Rafael Wysocki and Pavel Machek, requesting assistance debugging the resume failure and offering to try any troubleshooting or information-gathering steps they might suggest.

By: jisakiel

jisakiel — Thu, 14 Jun 2012 22:22:42 +0000

Perhaps you might try netconsole and configuring syslog to logging to a different computer, as it doesn’t seem x related…

By: John Goerzen

John Goerzen — Thu, 14 Jun 2012 21:54:12 +0000

I’ve tried that. In fact, I’ve tried it in single-user mode where X never even had the chance to load. And I’ve tried it with a bunch of modules unloaded. That exact pm-suspend command.

By: David Medberry

David Medberry — Thu, 14 Jun 2012 21:52:56 +0000

How are you suspending? Try going to the first virtual terminal Ctrl-Alt-F1 and the running “sudo pm-suspend”. That should do a proper suspend and then try and wake up.

By: John Goerzen: How to debugging Linux failure to resume from suspend? | Linux-Support.com

Thu, 14 Jun 2012 20:45:11 +0000

[...] source: Go to Source Feed source: http://planet.debian.org/rss20.xml License: The original licenses are retained – [...]