DebuggingKernelSuspend

Differences between revisions 8 and 9
Revision 8 as of 2007-03-06 14:51:52
Size: 2903
Editor: cF5A6BF51
Comment: use standard name space
Revision 9 as of 2007-03-06 14:56:42
Size: 3653
Editor: cF5A6BF51
Comment: new template form
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from KernelSuspendDebugging ||<tablestyle="float:right; font-size: 0.9em; width:30%; background:#F1F1ED; background-image: url('https://librarian.launchpad.net/1812570/bugsquad.png'); background-repeat: no-repeat; background-position: 98% 0.5ex; margin: 0 0 1em 1em; padding: 0.5em;">'''Contents'''[[BR]][[TableOfContents]]||

= Introduction =
Line 5: Line 8:

= Debugging procedure =
Line 14: Line 19:
sync; echo 1 > /sys/power/pm_trace; /etc/acpi/sleep.sh force {{{sync; echo 1 > /sys/power/pm_trace; /etc/acpi/sleep.sh force
}}}
Line 20: Line 26:
dmesg > dmesg.txt {{{dmesg > dmesg.txt
}}}
Line 24: Line 31:
[ 11.323206] Magic number: 0:798:264
{{{[ 11.323206] Magic number: 0:798:264
Line 27: Line 33:
}}}
Line 30: Line 37:
hash matches device i2c-9191 {{{hash matches device i2c-9191
}}}
Line 33: Line 41:

= Known bugs =

Description of known issues, how to recognise them and stock responses/actions.

'''Open'''
||<rowbgcolor="#eeeeee"> '''Bug#''' || '''Description''' || '''Action''' ||
|| TBD. || TBD. || TBD. ||

'''Closed'''
||<rowbgcolor="#eeeeee"> '''Bug#''' || '''Description''' || '''Action''' ||
|| TBD. || TBD. || TBD. ||

= Non-bugs =

TBD.

------
'''Also see:'''

 * DebuggingProcedures

Introduction

This page describes how to debug Suspend to RAM/Resume problems on your computer. Do not confuse this with Suspend to disk.

Suspend and Resume use facilities within your BIOS called ACPI, or Advanced Configuration and Power Interface. Linux provides an ACPI subsystem that manages the suspend and resume process. The usual problem occurs when resuming, and normally the culprit is a device driver that does not recover from a powered down state. If your computer successfully performs a suspend, then it is quite likely any resume problems are due to another device driver and not the ACPI subsystem.

Debugging procedure

Resume problems are difficult to debug since there is no non-volatile storage available at the time resume is bringing up your computer. The only hardware on a PC motherboard that retains information across power cycles is the real time clock (RTC). For those that just have to know, read Documentation/power/s2ram.txt in your kernel sources. The implementation of suspend/resume debug trace is in drivers/base/power/trace.c.

Caveat Emptor: Using the following debug suggestions will radically change the values in your RTC chip, so much so that your file system will think it has been eons since the last fsck. You can avoid a long fsck delay by using 'tune2fs'. For example, 'tune2fs -i 0 /dev/sda1' disables fsck on boot.

NTP is not sufficient to recover the correct time of day. By default NTP is configured to to only correct for about an hour drift. You must use the 'date' command to get the RTC value within the drift tolerance.

In order to stimulate your suspend/resume process, enter the following commands (as root):

{{{sync; echo 1 > /sys/power/pm_trace; /etc/acpi/sleep.sh force }}}

At this point your computer should enter the suspend state within a few seconds. Usually the power LED will slowly flash when in the suspended state. When that has happened, initiate the resume process by pressing the power button. Observe closely if the disk light comes on briefly. This indicates that resume has begun. If resume fails to complete, then press the power button until the computer turns off. Power on your computer making sure that it loads the same kernel that exhibited the resume problem. You have about 3 minutes to start this boot process before the information saved in the RTC gets corrupted.

Start a console and enter:

{{{dmesg > dmesg.txt }}}

You can edit this file and find line similar to these:

{{{[ 11.323206] Magic number: 0:798:264 [ 11.323257] hash matches drivers/base/power/resume.c:46 }}}

There may well be another 'hash matches' line beyond that. If so, then you are in luck because the last one is the likely culprit. For example:

{{{hash matches device i2c-9191 }}}

The only way to prove this is to remove the module prior to initiating suspend. Repeat as needed...

Known bugs

Description of known issues, how to recognise them and stock responses/actions.

Open

Bug#

Description

Action

TBD.

TBD.

TBD.

Closed

Bug#

Description

Action

TBD.

TBD.

TBD.

Non-bugs

TBD.


Also see:


CategoryBugSquad

DebuggingKernelSuspend (last edited 2019-01-28 21:01:56 by penalvch)