DebuggingKernelSuspendHibernateResume
Differences between revisions 1 and 24 (spanning 23 versions)
|
Size: 5074
Comment:
|
← Revision 24 as of 2014-01-22 12:12:32 ⇥
Size: 61
Comment: Redirect to dedicated Hibernate article.
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = Triage and Debug of Kernel Suspend/Hibernate Resume apport bugs = This page is aimed to help you do initial Triage and Debug of Suspend/Resume or Hibernate/Resume bugs as reported by apport. This page presents some background information as to how the reporting works, and then will take you through a series of debug steps recommending information and data which will need to be collected. The primary source of reports of suspend and hibernate failures arrive via apport. Apport checks at boot time whether there was a suspend or hibernate in progress, if we are booting normally then that was never resumed and therefore has failed. This means that the failure may have occured some time before the report is generated. Bear this in mind when answering the questions below. == Information Gathering == At a very minimum every sleep/resume bug should contain the answers the questions in this section before being considered Triaged. === Is this really a failure? === There are some suspend/resume failures which are /expected/. For example if you suspend your laptop and then the battery runs out. When the machine is next started the suspend image is no longer present and a normal boot will occur. This will be detected as a resume failure but there is no bug, other than your battery is not infinite in size. If this occurs you can safely close the bug 'Invalid' and ignore this report. === Did the machine break while going to sleep or waking up? === It is very important to know whether the problem occurs on the way into the sleep state or on the way out. If the machine never makes it to sleep, but wakes up or powers off incorrectly that is a suspend/hibernate failure. If the machine wakes back up from the sleep but then takes you to the login prompt or crashes after that then it is a resume failure. Please indicate in the bug whether it is a sleep or wakeup failure and how you determined this. === Is it reproducible? === Is the problem reproducible. If you do say 10 sleep cycles does the problem occur every time, 1 in 5 etc. Do the symptoms vary at all? Please indicate in the bug how and what you tested. === Did it work before? === Has this sleep type (suspend or hibernate) ever worked in the past. If it has whch kernel release did it work on? Please indicate in the bug whether it worked, and if so include the contents of /proc/version_signature from that release (or the Ubuntu version number if you do not have it). === Do you end up with flashing caps-lock or similar? === If you have flashing caps-lock lights then very likely you are experiencing a kernel panic. Please indicate that in the bug. === Hibernate specific information === For failures to resume from Hibernate, please include the output from the following commands from the boot following the hibernate, this includes information on the search for the resume device etc: 1. {{{dmesg}}} 2. {{{cat /proc/cmdline}}} 3. {{{cat /etc/initramfs-tools/conf.d/resume}}} === Other information === Please include any information as to the circumstances leading up to this failure, anything unsual for example did your battery run out? Did any messages come out? == Debugging Suspend == === Suspending from text mode === The first step for debugging suspend is to determine if the issue occurs when triggered using the pm-suspend command. If possible you should reboot the system with the no_console_suspend option. You should then switch to VT1 by pressing Ctrl-Alt-F1. Login at the prompt there and then run the following commands: {{{ setfont /usr/share/consolefonts/Uni1-VGA8.psf.gz sudo pm-suspend }}} This will select a much smaller font so that you can see more messages should they come out, and then initate the suspend. Please report whether you got any additional messages. Digital photos of the screen are a sensible way to get this into the bug. === Enabling Suspend Debugging === If the previous step produces nothing useful, then you will need to try enabling kernel suspend debugging. See DebuggingKernelSuspend for details. Please report any results to the bug. == Debugging Hibernate == === Hibernating from text mode === The first step for debugging hibernate is to determine if the issue occurs when triggered using the pm-hibernate command. If possible you should reboot the system with the no_console_suspend option. You should then switch to VT1 by pressing Ctrl-Alt-F1. Login at the prompt there and then run the following commands: {{{ setfont /usr/share/consolefonts/Uni1-VGA8.psf.gz sudo pm-hibernate }}} This will select a much smaller font so that you can see more messages should they come out, and then initate the suspend. Please also include a full dmesg output from the failing boot as this includes significant information about the search for the resume device. Please report whether you got any additional messages. Digital photos of the screen are a sensible way to get this into the bug. |
#REFRESH 0 https://wiki.ubuntu.com/DebuggingKernelHibernate |
DebuggingKernelSuspendHibernateResume (last edited 2014-01-22 12:12:32 by penalvch)