suspend/resume failure during a resume with charger attached

Bug #1112726 reported by Para Siva on 2013-02-01
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

This crash occurred during a resume operation with charger being attached .

1. Install raring image using Nexus7 installer
2. sudo apt-get update && sudo apt-get -y dist-upgrade
3. Had firefox left open overnight
4. Connect the charger
5. Press the power button to resume

ProblemType: KernelOops
DistroRelease: Ubuntu 13.04
Package: linux-image-3.1.10-9-nexus7 3.1.10-9.24
Uname: Linux 3.1.10-9-nexus7 armv7l
Annotation: This occured during a previous suspend and prevented it from resuming properly.
ApportVersion: 2.8-0ubuntu3
Architecture: armhf
 /dev/snd/controlC0: ubuntu 1323 F.... pulseaudio
 {"impl": "launchpad",
                             "project": "ubuntu-nexus7",
                             "bug_pattern_url": "",
Date: Sat Jan 1 01:00:52 2000
ExecutablePath: /usr/share/apport/apportcheckresume
Failure: suspend/resume
HibernationDevice: RESUME=UUID=0a96181c-3f8f-4f64-a1a9-6deac994fb2a
InstallationDate: Installed on 2000-01-01 (4780 days ago)
InstallationMedia: Ubuntu Raring Ringtail (development branch) - armhf (20130124-15:18)
InterpreterPath: /usr/bin/python3.3

Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MarkForUpload: True
ProcCmdline: /usr/bin/python3 /usr/share/apport/apportcheckresume
 PATH=(custom, no user)
 0 tegra_fb
 1 tegra_fb
ProcKernelCmdLine: tegra_wdt.heartbeat=30 tegraid= mem=1022M@2048M android.commchip=0 vmalloc=128M androidboot.serialno=015d210982380a15 video=tegrafb no_console_suspend=1 console=none debug_uartport=hsport usbcore.old_scheme_first=1 lp0_vec=8192@0xbddf9000 tegra_fbmem=8195200@0xabe01000 core_edp_mv=0 audio_codec=rt5640 board_info=f41:a00:1:44:2 tegraboot=sdmmc gpt gpt_sector=30535679 androidboot.bootloader=3.34 root=/dev/mmcblk0p9 ro console=tty0 fbcon=rotate:1 access=m2 quiet splash
ProcModules: zram 8348 4 - Live 0xbf000000 (C)
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon.
 linux-restricted-modules-3.1.10-9-nexus7 N/A
 linux-backports-modules-3.1.10-9-nexus7 N/A
 linux-firmware 1.100
SourcePackage: linux-nexus7
StagingDrivers: zram
Title: suspend/resume failure
UpgradeStatus: No upgrade log present (probably fresh install)

Para Siva (psivaa) wrote :
Joseph Salisbury (jsalisbury) wrote :

I believe this is a duplicate of bug 1109795

Can you reproduce this easily, or does it require letting the device run for an extended period of time?

Changed in ubuntu-nexus7:
importance: Undecided → Medium
tags: added: nexus7-kernel
tags: added: suspend-watch
Joseph Salisbury (jsalisbury) wrote :

From SleepLog.txt:

Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory

Para Siva (psivaa) wrote :

This is not easily reproducible. The above step sequence is what was done on the first instance before the crash occurred. One thing though was that the battery power was very low when the crash occurred. I'll keep trying.

Joseph Salisbury (jsalisbury) wrote :

This automatic bug report can be generated if the battery dies while the system is suspended. That could be what happened here since the /usr/share/apport/apportcheckresume script reported this bug.

Changed in ubuntu-nexus7:
status: New → Incomplete

On Mon, Feb 04, 2013 at 07:11:18PM -0000, Joseph Salisbury wrote:
> This automatic bug report can be generated if the battery dies while the
> system is suspended. That could be what happened here since the
> /usr/share/apport/apportcheckresume script reported this bug.

My bug is marked as a duplicate of this one, but I'm pretty sure the
messages I received are in no way correlated with the battery running down
while suspended.

Also, the main bug says "with charger attached", so it seems unlikely to be
caused by the battery dying?

Joseph Salisbury (jsalisbury) wrote :

@Steve, correct, I now see that the device had the charger attached.

During boot, the apport upstart job looks for a flag file named: /var/lib/pm-utils/status. If it finds this file, this automatic bug report is generated. This flag file is generated every time the system is suspended or hibernated. After a successful resume, this file is removed. There could be several things that happen while the system is suspended to prevent a resume, but I don't see anything in the logs that indicate what happened.

Para Siva (psivaa) wrote :

I have had this crash a couple of times with a similar circumstances as that is given in comment #5. The logs from one of such crashes are attached to bug 1118592.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers