[Ubuntu Wiki] Update of "DebuggingKernelSuspend" by brian-murray

Ubuntu Wiki noreply at ubuntu.com
Tue Mar 1 21:46:58 UTC 2011


Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification.

The following page has been changed by brian-murray:
http://wiki.ubuntu.com/DebuggingKernelSuspend?action=diff&rev1=33&rev2=34

------------------------------------------------------------------------------
  
  This page describes how to debug Suspend to RAM/Resume problems on your computer. Do not confuse this with Suspend to disk (also known as hibernate).  [[UnderstandingSuspend]] may have useful background information on where problems can occur.
  
- 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.
+ 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. Usually problems occur 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.
  
- The debugging procedure described below requires a linux kernel 2.6.20 (and newer) for the ability of "/sys/power/pm_trace". FeistyFawn and later release have a new enough kernel version.  You can check the version of the kernel you are running by {{{uname -r}}} from a terminal.  You can also just look in the directory /sys/power/ (from a terminal type {{{ls /sys/power/}}})
- to see if a file called pm_trace exists; it will only do so if the kernel supports the following debugging procedure.
+ The debugging procedure described below requires a linux kernel with the capability of "/sys/power/pm_trace". You can ensure that pm_trace'ing is possible by looking in the directory /sys/power/ (from a terminal type {{{ls /sys/power/}}})
+ to see if a file called pm_trace exists.
  
  = "resume-trace" debugging procedure for finding buggy drivers =
- Resume problems are difficult to debug.  The approach used here needs to make notes on progress during resume and be able to recover it after a manual reboot.  But 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), so that is what is used. For those that want to know the details, 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.  But first you'll want to use 'tune2fs -l <device>' to get the current information of your settings - look at the "Check interval" setting.
+ Resume problems are difficult to debug.  The approach used here needs to make notes on progress during resume and be able to recover them after a manual reboot.  But 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), so that is what is used. For those that want to know the details, 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.  But first you'll want to use 'tune2fs -l <partition>' to find your current settings - look at the "Check interval" setting.
+ 
- From a fresh Hardy install, the default time interval is 15552000, which is 6 months.
+ From a fresh install, the default time interval is 15552000, which is 6 months.
  
  Remember that when you are all done, you'll want to set your RTC clock back.  Note that NTP by itself is not sufficient to recover the correct time of day, since by default NTP is configured to do nothing if the time is off by more than 1000 seconds. You must first use the 'ntpdate' or 'date' command to get the clock close.
  
@@ -35, +36 @@

  dmesg > dmesg.txt
  }}}
  
- You can edit this file and find line similar to these:
+ You can edit this file and find lines similar to these:
  
  {{{
  [   11.323206]   Magic number: 0:798:264



More information about the Ubuntu-bugsquad mailing list