DebuggingKernelSuspendHibernateResume
Differences between revisions 15 and 24 (spanning 9 versions)
|
Size: 12101
Comment: Hi,I just wanted to add that most Hibernate/Suspend reported on bug list failed when there was SD card mounted on the system, including myself.So removing worked fine.
|
← 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: |
| <<Include(Kernel/MenuBar)>> ||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>|| = 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. == Bug Validation == Before gathering information on the bug you could consider the questions in this section which will help weed out false reports and duplicates. === 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. If it is the case the user has an encrypted swap, hibernation will currently fail. This is a known issue. See the [[https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume#Failure%20due%20to%20encrypted%20swap|Debugging Hibernate]] section below for more information. === Is this a repetition of a previous failure? === If this is another occurance of a previous reported failure it is best to mark the new bug a duplicate of the first using the Mark Duplicate link on the bug report. == Information Gathering == At a very minimum every sleep/resume bug should contain the answers the questions in this section before being considered Triaged. === 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 instead 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 which 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 resume from Hibernate failures, 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 (see Note 1 below for help with this). 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 = == Failure due to encrypted swap == https://help.ubuntu.com/community/EncryptedHome Users installing from Ubuntu 9.10 and selecting the Encrypted Home option will automatically have encrypted swap space. Other users may have also ran sudo ecryptfs-setup-swap. It is important to note that Hibernation will not work with an encrypted swap at this time. Actually, hibernation will work just fine, but resume will fail. There are ways around this, but it involves choosing a password to use for your swap encryption, and entering that password every time you boot your system, and sharing that password with anyone else that might want to resume the system. This is a known, wishlist issue that we hope to solve for Ubuntu 10.04. If you happen to report or triage this type of issue, please tag the bug '''encrypted-swap'''. For triagers, posting the following comment to a bug may help: {{{ Thank you for taking the time to report this bug and helping to make Ubuntu better. It is currently a known issue that Hibernation will fail to resume due to an encrypted swap. Developers are hoping to resolve this issue for the Lucid Lynx 10.04 release. Please refer to https://help.ubuntu.com/community/EncryptedHome for more information. We will tag this bug "encrypted-swap" so that we can track this issue going forward and possibly request additional testing. Thanks in advance for your patience and cooperation. }}} == 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 (see Note 1 below for help with this). 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 hibernate. To help us investigate the problem please use the following debug test method and report results in the bug. Common method is to take photos of the screen & attach dmesg output to the bug report. == Per sub-system hibernate testing == Again from VT-1 (see above for instructions), first reduce the size of your font with the following commands: {{{ setfont /usr/share/consolefonts/Uni1-VGA8.psf.gz }}} There are three tests listed below: * "devices" test mode in "platform" mode of hibernation * "core" test mode in "platform" mode of hibernation * "core test mode in "reboot" mode of hibernation. The test modes are as follows: * core : test the freezing of processes, suspending of devices, platform global control methods(*), the disabling of nonboot CPUs and suspending of platform/system devices * devices : test the freezing of processes and suspending of devices If you `cat /sys/power/pm_test` and `cat /sys/power/disk` it will list the modes that it supports. Then run the following commands: {{{ $ sudo -i # lsmod > lsmod.output.txt # echo devices > /sys/power/pm_test # echo platform > /sys/power/disk # echo disk > /sys/power/state # dmesg > /tmp/dmesg-devices-platform.txt # echo core > /sys/power/pm_test # echo platform > /sys/power/disk # echo disk > /sys/power/state # dmesg > /tmp/dmesg-core-platform.txt # echo core > /sys/power/pm_test # echo reboot > /sys/power/disk # echo disk > /sys/power/state # dmesg > /tmp/dmesg-core-reboot.txt }}} Please collect the lsmod, full dmesg output files from the failing boot/tests, and attach to the bug report. 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. = Notes = == Note 1: adding and removing options to the kernel command line == Assuming you are using the default boot loader {{{grub}}} you will very likely see the text below straight after the BIOS messages: {{{ GRUB loading stage 1.5. GRUB loading, please wait ... Press 'ESC' to enter the menu ... }}} If you see this you should hit ESC to enter the kernel selection menu. In some cases GRUB will enter the menu directly, in either case you will see something like this: {{{ +-------------------------------------------------------------+ | Ubuntu jaunty (stable), kernel 2.6.28-11-generic | | Ubuntu jaunty (stable), kernel 2.6.28-11-generic (recovery) | | Ubuntu jaunty (stable), kernel 2.6.28-8-generic | | Ubuntu jaunty (stable), kernel 2.6.28-8-generic (recovery) | | Ubuntu jaunty (stable), memtest86+ | +-------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press enter to boot the selected OS, 'e' to edit the commands before booting, or 'c' for a command line. }}} At this point you should use the up and down cursor keys to select the kernel you normally use (if you do not know leave the cursor where it is). Next hit 'e' to edit the line. You will then see something similar to this: {{{ +-------------------------------------------------------------+ | uuid 123456789012345678901234567890 | | kernel /boot/vmlinuz-2.6.28-11-generic root=UUID=12345678> | | initrd /boot/initrd.img-2.6.28-11-generic | | quiet | ... }}} At this point you should cursor down until the line which starts kernel is highlighted, and hit 'e' to edit it. You will then see something like this: {{{ [ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ESC at any time exits. ] <123456789 ro quiet splash _ }}} You can now cursor about in the line using left and right arrows, use delete to remove things you have been asked to get rid of and simply add new options at the end ensuring there is a space between each option. If you make a mistake you can abort all edits with ESC. When you are happy with the new options, hit Return, and then 'b' to boot the system. == Battery drained whilst suspended stock reply == {{{ Thank you for taking the time to report this bug and helping to make Ubuntu better. This report seems to indicate that your battery drained while the machine was suspended. In this case a false bug report is generated, we are therefore closing this bug Invald. Please see https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume#Is%20this%20really%20a%20failure? for more information. }}} * Set status to Incomplete ---- CategoryKernel |
#REFRESH 0 https://wiki.ubuntu.com/DebuggingKernelHibernate |
DebuggingKernelSuspendHibernateResume (last edited 2014-01-22 12:12:32 by penalvch)