Asus EB1007 can't wake up from suspend when suspended using pm-suspend

[TienFu Chen]

The Asus EeeBox PC EB1007 can suspend and resume just fine when selecting 'Suspend' from the indicator-session menu. When suspended using the pm-suspend script, the screen does not come back on after resuming and the system appears to be crashed (cannot be pinged or ssh'ed to)

[TienFu Chen (ctf)]

tried below command on test case3, can't wake up.
sudo /usr/sbin/pm-suspend

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 907188

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Colin Ian King (colin-king)]

OK, I can't see any thing obvious in those logs. Perhaps the desktop is passing down some quirks which we aren't passing into pm-suspend when we run it standalone.

Can you add the following to /usr/sbin/pm-suspend just after the #!/bin/bash line:

echo $@ >> /root/pmsuspend-args.log

and the run suspend from the desktop again and then post into the bug the contents of /root/pmsuspend-args.log

thanks

[Brendan Donegan (brendan-donegan)]

Tim,

Can you also try these tests with Natty?

[TienFu Chen (ctf)]

no arguments are passed to /usr/sbin/pm-suspend while triggering suspend on desktop.
Tested with Natty installer live, both desktop and running pm-suspend directly are ok.

[TienFu Chen (ctf)]

I observed the desktop suspend will bring down network interfaces(/usr/lib/pm-utils/sleep.d/55NetworkManager), so I bring down ethernet manually with: ifconfig eth4 down, then did pm-suspend. The resuming is ok.(unplug the ethernet cable also does the trick)

By checking pm-suspend.log.desktop and pm-suspend.log.vt, there's slightly difference.
--- pm-suspend.log.vt
/usr/lib/pm-utils/sleep.d/55NetworkManager suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/60_wpa_supplicant suspend suspend:
Selected interface 'wlan3'
OK
--- pm-suspend.log.desktop
/usr/lib/pm-utils/sleep.d/55NetworkManager suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/60_wpa_supplicant suspend suspend:
Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory
-----------------
No matter run pm-suspend manually or run from desktop, pm-suspend is called, but I think there's still some difference which may make the system wake up unsuccessfully.
----------------
Tested Natty full installation, both desktop and running pm-suspend directly are ok.
---
The ethernet controller information.
03:00.0 Ethernet controller [0200]: JMicron Technology Corp. JMC250 PCI Express Gigabit Ethernet Controller [197b:0250] (rev 03)
 Subsystem: ASUSTeK Computer Inc. Device [1043:8429]
 Flags: bus master, fast devsel, latency 0, IRQ 46
 Memory at fbffc000 (32-bit, non-prefetchable) [size=16K]
 I/O ports at ec00 [size=128]
 I/O ports at e800 [size=256]
 Capabilities: [68] Power Management version 3
 Capabilities: [50] Express Legacy Endpoint, MSI 00
 Capabilities: [40] MSI-X: Enable- Count=8 Masked-
 Capabilities: [70] MSI: Enable+ Count=1/8 Maskable+ 64bit+
 Kernel driver in use: jme
 Kernel modules: jme

[TienFu Chen (ctf)]

Test Natty with fully updated(kernel: 2.6.38-13.53), both desktop and running pm-suspend directly are ok.

[TienFu Chen (ctf)]

same problem reproduced in precise alpha 1.
Noticed there's kernel message shown on console, not sure if it's related to the problem: jme: Disable TX engine timeout.

[TienFu Chen (ctf)]

Tried Natty SRU(kernel: 2.6.38-13.54), both desktop and running pm-suspend directly are failed.

[TienFu Chen (ctf)]

The suspend success or not depends on network status on this EeeBox, if the gnome network manager is in charge of the wired networking, then the suspend will be ok, otherwise, it fails.
/etc/network/interface and /etc/udev/rules.d/70-persistent-net.rules can both effect the network manager.
The /etc/network/interface is changed to remove the control of eth0 from network manager(installed from satellite).
If I remove the "auto eth0" section in /etc/network/interface, then the suspend won't fail.

[Brendan Donegan (brendan-donegan)]

I would leave a linux task open for this. This is still probably a genuine bug, albeit one we won't fail certification over and can maybe workaround in our lab automation setup.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 907188

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Brendan Donegan (brendan-donegan)]

The apport logs are present in https://bugs.launchpad.net/checkbox-satellite/+bug/907188/comments/2

[Daniel Manrique (roadmr)]

Great diagnostic work finding out that the changes in eth0 are triggering this problem!

I think the system should suspend correctly even if the user has an interface declared in /etc/network/interfaces. The fact that having an auto eth0 interface breaks pm-suspend should constitute a genuine bug, but not necessarily one having to do with checkbox, as we're just doing stuff that a user could be reasonably expected to do (I use pm-suspend all the time).

Also, for manual cert testing we usually remove that section in interfaces, to let NetworkManager handle things.

Would it make sense to add a task for pm-utils, as it seems that pm-suspend and accompanying scripts are the ones failing to do the right thing before suspending?

[Jeff Lane  (bladernr)]

Is there any reason why this is opened against satellite? It looks to be an issue with pm-suspend, not checkbox or satellite, in agreement with Daniel. Should we mark this invalid for satellite and leave it to Linux and pm-utils?

[Brendan Donegan (brendan-donegan)]

I'd just delete the checkbox-satellite task, not sure why it was ever opened there in the first place

[penalvch (penalvch)]

Tim Chen, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11-rc5

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.