Ubuntu
linux package

suspend sometimes takes 60+ seconds; other times fails

Bug #1102784 reported by tecu on 2013-01-22

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	linux (Ubuntu)	Incomplete	Medium	Unassigned

Bug Description

Hi.

For a long time now, possibly years, I have been having issues suspending my computer to RAM. This is what happens:

- I use a dbus command to attempt to suspend
- (it sounds like) The disks spin down almost immediately
- The screen and fans stay on for about 60 seconds

Then either:
- The computer suspends
OR
- The computer resumes immediately

I have no idea why this happens. I know that it does not happen with Windows Vista on the same machine, but that it does happen with other linux distros (well, at least Arch). I think it started around the time the 3.0 kernel version started getting adopted (give or take an Ubuntu release), but I do not know if that is accurate, let alone relevant.

I posted this as a question at askubuntu:
http://askubuntu.com/questions/245835/suspend-sometimes-takes-60-seconds-other-times-fails
and was directed here.

I am currently using a 'minimal' version of Ubuntu 12.10 (with openbox and lightdm), installed on LVM on top of luks.

The command I use to suspend is:
dbus-send --system --print-reply --dest=org.freedesktop.UPower /org/freedesktop/UPower org.freedesktop.UPower.Suspend

I have attached /var/log/pm-suspend.log for a successful suspend (with the sixty second delay), and I will attach the results of dmesg | grep PM in a minute. If you need more information, please ask.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: linux-image-3.5.0-22-generic 3.5.0-22.34
ProcVersionSignature: Ubuntu 3.5.0-22.34-generic 3.5.7.2
Uname: Linux 3.5.0-22-generic x86_64
NonfreeKernelModules: nvidia
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.25.
ApportVersion: 2.6.1-0ubuntu9
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC1: tecu 1824 F.... pulseaudio
/dev/snd/controlC0: tecu 1824 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory: 'iw'
Card0.Amixer.info:
Card hw:0 'AK5370'/'AKM AK5370 at usb-0000:00:0b.0-2, full speed'
   Mixer name : 'USB Mixer'
   Components : 'USB0556:0001'
   Controls : 2
   Simple ctrls : 1
Card0.Amixer.values:
Simple mixer control 'Mic',0
   Capabilities: cvolume cvolume-joined cswitch cswitch-joined penum
   Capture channels: Mono
   Limits: Capture 0 - 78
   Mono: Capture 78 [100%] [20.00dB] [on]
Card1.Amixer.info:
Card hw:1 'NVidia'/'HDA NVidia at 0xcfff0000 irq 23'
   Mixer name : 'Realtek ALC1200'
   Components : 'HDA:10ec0888,10de0175,00100101'
   Controls : 51
   Simple ctrls : 22
Date: Mon Jan 21 21:19:54 2013
HibernationDevice: RESUME=UUID=c76beaf3-b820-4fa8-b44d-a07f3a2b60df
Lsusb:
Bus 002 Device 002: ID 0556:0001 Asahi Kasei Microsystems Co., Ltd AK5370 I/F A/D Converter
Bus 002 Device 003: ID 06a3:8021 Saitek PLC Eclipse II Keyboard
Bus 002 Device 004: ID 046d:c01e Logitech, Inc. MX518 Optical Mouse
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: EVGA 132-CK-NF78
MarkForUpload: True
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
LANG=en_US.UTF-8
SHELL=/bin/bash
ProcFB:

ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.5.0-22-generic root=/dev/mapper/linux-root ro quiet splash
RelatedPackageVersions:
linux-restricted-modules-3.5.0-22-generic N/A
linux-backports-modules-3.5.0-22-generic N/A
linux-firmware 1.95
RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/30/2009
dmi.bios.vendor: Phoenix Technologies, LTD
dmi.bios.version: P10
dmi.board.name: 132-CK-NF78
dmi.board.vendor: EVGA
dmi.board.version: 2
dmi.chassis.type: 3
dmi.chassis.vendor: EVGA
dmi.chassis.version: 132-CK-NF78
dmi.modalias: dmi:bvnPhoenixTechnologies,LTD:bvrP10:bd12/30/2009:svnEVGA:pn132-CK-NF78:pvr2:rvnEVGA:rn132-CK-NF78:rvr2:cvnEVGA:ct3:cvr132-CK-NF78:
dmi.product.name: 132-CK-NF78
dmi.product.version: 2
dmi.sys.vendor: EVGA

Tags:

Revision history for this message

tecu (tecu) wrote on 2013-01-22:

/var/log/pm-suspend.log Edit (6.6 KiB, text/plain)
AlsaDevices.txt Edit (710 bytes, text/plain; charset="utf-8")
AplayDevices.txt Edit (281 bytes, text/plain; charset="utf-8")
ArecordDevices.txt Edit (502 bytes, text/plain; charset="utf-8")
BootDmesg.txt Edit (59.8 KiB, text/plain; charset="utf-8")
Card1.Amixer.values.txt Edit (4.5 KiB, text/plain; charset="utf-8")
Card1.Codecs.codec.0.txt Edit (14.6 KiB, text/plain; charset="utf-8")
CurrentDmesg.txt Edit (521 bytes, text/plain; charset="utf-8")
Dependencies.txt Edit (2.9 KiB, text/plain; charset="utf-8")
IwConfig.txt Edit (285 bytes, text/plain; charset="utf-8")
Lspci.txt Edit (20.5 KiB, text/plain; charset="utf-8")
PciMultimedia.txt Edit (570 bytes, text/plain; charset="utf-8")
ProcCpuinfo.txt Edit (3.1 KiB, text/plain; charset="utf-8")
ProcInterrupts.txt Edit (2.5 KiB, text/plain; charset="utf-8")
ProcModules.txt Edit (2.4 KiB, text/plain; charset="utf-8")
PulseList.txt Edit (18.2 KiB, text/plain; charset="utf-8")
UdevDb.txt Edit (133.7 KiB, text/plain; charset="utf-8")
UdevLog.txt Edit (318.7 KiB, text/plain; charset="utf-8")
WifiSyslog.txt Edit (898.4 KiB, text/plain; charset="utf-8")

Revision history for this message

tecu (tecu) wrote on 2013-01-22:

dmesg | grep PM Edit (4.8 KiB, text/plain)

dmesg | grep PM for a successful (sixty second wait) suspend. Something weird is going on here:

...
[36838.168016] PM: suspend of drv:pci dev:0000:00:0f.0 complete after 1607.208 msecs
[36897.413057] PM: suspend of drv:sd dev:0:0:0:0 complete after 60860.420 msecs
...

but I don't know what that means.

Revision history for this message

Brad Figg (brad-figg) wrote on 2013-01-22: Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status:	New → Confirmed

Revision history for this message

Colin Ian King (colin-king) wrote on 2013-01-22:

@tecu, if you can dump out the ACPI tables so I can see what the ACPI _DIS() control is doing during a PCI IRQ disable then that would be useful. To do so run:

sudo acpidump > acpidump.txt

and attach the acpidump.txt to the bug. Thanks!

Changed in linux (Ubuntu):
status:	Confirmed → Incomplete

Revision history for this message

Colin Ian King (colin-king) wrote on 2013-01-22:

Can you provide the output from:

cat /proc/ioports

Thanks

Revision history for this message

tecu (tecu) wrote on 2013-01-22:

acpidump output Edit (174.2 KiB, text/plain)

attached acpidump output

Revision history for this message

tecu (tecu) wrote on 2013-01-22:

cat /proc/ioports output Edit (2.2 KiB, text/plain)

cat /proc/ioports output

Revision history for this message

Colin Ian King (colin-king) wrote on 2013-01-22:

So, looking at the AML errors, I see:

line 2758: Name (_FDE, Package (0x05) // _FDE: Floppy Disk Enumerate
_FDE not used in the kernel, so this error can be ignored.

line 2897: This is a bug in the firmware, but I believe it won't do any harm.

line 4413: Method OCOP: Method does not return a package if non of the conditions are met. I doubt this is a bug, just sloppy coding.

line 5127: Method PROC: Method does not return a package if non of the conditions are met. I doubt this is a bug, just sloppy coding.

line 8862: Method SMBC: This does not release the mutex SMBA, so this is defintiely buggy firmware. However, I can't see any caller of this method, so nothing appears to be using it.

lines 11196, 11210, 11225, 11240, 11254, 11269, 11284: These ignore Mutex acquire timeout failures. Since the acquires block for 1 to 4.095 seconds you may just be lucky 99.9% of the time in that the AML code is fast to execute and any blocked threads never time out, so the races that occur in this buggy code never happen.

11801, 11846, 11908: Methods VGET, TGET, FGET: These methods may return bogus values if called incorrectly, however, the controls that call these methods aren't used by the kernel, so it won't ever fail.

So, apart from the firmware being pooly written, there is little to worry about.

Revision history for this message

Colin Ian King (colin-king) wrote on 2013-01-22:

Oops, please ignore the above posting. I pasted it into the wrong bug. Apologies

Joseph Salisbury (jsalisbury) on 2013-01-22

Changed in linux (Ubuntu):
importance:	Undecided → Medium

Revision history for this message

tecu (tecu) wrote on 2013-03-08:

#10

Hi.

I found a kernel bug report ( https://bugzilla.kernel.org/show_bug.cgi?id=48951 ) with a possible workaround ( https://bugzilla.kernel.org/show_bug.cgi?id=48951#c20 ), but there are some relevant points to make:

- I only found it when running Arch Linux where, for whatever reason, dmesg showed an error code (134217730) that I did not see on Ubuntu. It is possible it did not show up when I did a dmesg | grep PM .

- I do not know if this udev rule (the workaround) has any side effects beyond "making suspend work":
ACTION=="add", SUBSYSTEM=="scsi", ENV{DEVTYPE}=="scsi_target", ATTR{power/async}="disabled"

- I have only tested it on Arch, where it Works For Me.

I can test it out on Ubuntu (within a few days or so) if you'd like, but it sounds like the kernel folks are working on a solution, so maybe that will not be necessary?