[Apple Inc. MacBookAir4,1] suspend/resume failure [non-free: wl]

[Rachel Greenham]

I had shut the lid to suspend the system last night. *After that* I plugged in the mains lead.

Today I unplugged the mains lead and *then* opened the lid, and tried to wake it, only to find it wouldn't do so. Had to force-reboot it. On logging into desktop, this bug report got triggered.

It had been through some suspend/resume cycles already (not many; i only installed it on Friday), so the mains-plug behaviour is where I suspect the problem is.

(Until now Trusty has been behaving impeccably on this laptop. :-)

ProblemType: KernelOops
DistroRelease: Ubuntu 14.04
Package: linux-image-3.13.0-20-generic 3.13.0-20.42
ProcVersionSignature: Ubuntu 3.13.0-20.42-generic 3.13.7
Uname: Linux 3.13.0-20-generic x86_64
NonfreeKernelModules: wl
Annotation: This occured during a previous suspend and prevented it from resuming properly.
ApportVersion: 2.13.3-0ubuntu1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: lightdm 1226 F.... pulseaudio
                      rachel 1832 F.... pulseaudio
CRDA:
 country EU:
  (2402 - 2482 @ 40), (N/A, 20)
  (5170 - 5250 @ 40), (N/A, 20)
  (5250 - 5330 @ 40), (N/A, 20), DFS
  (5490 - 5710 @ 40), (N/A, 27), DFS
Date: Sun Mar 30 15:54:36 2014
ExecutablePath: /usr/share/apport/apportcheckresume
Failure: suspend/resume
InstallationDate: Installed on 2014-03-28 (1 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Beta amd64+mac (20140326)
InterpreterPath: /usr/bin/python3.4
MachineType: Apple Inc. MacBookAir4,1
ProcCmdline: /usr/bin/python3 /usr/share/apport/apportcheckresume
ProcEnviron:
 TERM=linux
 PATH=(custom, no user)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: \boot\vmlinuz-3.13.0-20-generic root=UUID=c2167b45-d81a-4d7f-9017-36858344eef8 ro quiet splash vt.handoff=7 initrd=boot\initrd.img-3.13.0-20-generic
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-20-generic N/A
 linux-backports-modules-3.13.0-20-generic N/A
 linux-firmware 1.126
SourcePackage: linux
Title: [Apple Inc. MacBookAir4,1] suspend/resume failure [non-free: wl]
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

dmi.bios.date: 01/24/2012
dmi.bios.vendor: Apple Inc.
dmi.bios.version: MBA41.88Z.0077.B0F.1201241549
dmi.board.asset.tag: Base Board Asset Tag#
dmi.board.name: Mac-C08A6BB70A942AC2
dmi.board.vendor: Apple Inc.
dmi.board.version: MacBookAir4,1
dmi.chassis.type: 10
dmi.chassis.vendor: Apple Inc.
dmi.chassis.version: Mac-C08A6BB70A942AC2
dmi.modalias: dmi:bvnAppleInc.:bvrMBA41.88Z.0077.B0F.1201241549:bd01/24/2012:svnAppleInc.:pnMacBookAir4,1:pvr1.0:rvnAppleInc.:rnMac-C08A6BB70A942AC2:rvrMacBookAir4,1:cvnAppleInc.:ct10:cvrMac-C08A6BB70A942AC2:
dmi.product.name: MacBookAir4,1
dmi.product.version: 1.0
dmi.sys.vendor: Apple Inc.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.14 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-trusty/

[Rachel Greenham (rachel-strangenoises)]

No objection in principle to trying. Our main problem here is that the bug may not even be reliably repeatable with the current kernel *anyway*, though before doing that upgrade I'll give it a go (having been avoiding the sequence of events that I *think* triggered it the one time it did happen).

So I'll just try to reliably repeat the problem first.

[Rachel Greenham (rachel-strangenoises)]

After a number of attempts I only managed to repeat it once, and that was with plugging in mains immediately after (practically simultaneously) closing the lid; so possibly while suspend mode is being entered. The time it happened, the backlight had gone off, then it came on again briefly, then off. Then when I opened the lid it was dead.

But i couldn't make it happen again, so it may be *extremely* timing-sensitive and rare.

Anyway I'll install the 3.14 kernel, but it's going to be hard to prove the negative given the positive is so chancy... But I suppose if it *does* happen, that tells us something and I could at least tag it kernel-bug-exists-upstream.

[Rachel Greenham (rachel-strangenoises)]

3.14 installed. in case it means something, i *did* manage, twice, to get the timing right to cause that backlight flash that, before, signalled^Wcoincided with the crash, but both times the machine resumed normally afterwards.

But hesitant to mark it fixed upstream as I couldn't reproduce the error on demand on the original kernel.

[Rachel Greenham (rachel-strangenoises)]

OK, it happened on 3.14. Confirmed that, as with the first time, the pattern was close lid (observe backlight goes off, then momentarily flashes on again) *then* plug in power; the next morning, unplug power, open lid. *Keyboard* backlight is on, screen does not wake.

[Rachel Greenham (rachel-strangenoises)]

odd coda to add here: Today I've been back using the Mac side of this computer. So far two out of two times, I've seen the same problem resuming from suspend in Mac OS X; requiring the same power cycle to continue.

I don't know what to make of this. It never did this before I made this machine dual-boot, but given we're talking about *suspend* as opposed to say, hibernate, I have no idea why this should be related at all. Maybe just a complete coincidence of an unrelated but similar *looking* issue. But I reckoned I'd record the observation here, in case it means something to someone.

[Rachel Greenham (rachel-strangenoises)]

On further googling the problem may lie with rEFInd. It looks like the problem discussed here: http://askubuntu.com/questions/295105/refind-breaks-standby-mode-on-macbook-air-5-2

Am currently running without rEFInd (though it does mean having to select "Windows" to boot Linux, which isn't pretty!) to confirm the problem disappears with rEFInd not in the mix.

[Cloudane (cloudane)]

Same issue here, even on the 3.15 rc mainline kernels. Well, for me the power lead doesn't make any difference. Maybe 1 in 5 times, attempting to suspend the laptop results in it freezing with the keyboard illuminated.

I haven't been able to replicate the issue if X isn't running (i.e. stop the lightdm service and issue "echo mem | sudo tee /sys/power/state"), but if X is running then it happens quite predictably. Updating to the latest graphics stack builds from the xorg-edgers PPA didn't help either.

Did you have any luck?
This is a bit of a showstopper for me, it's looking likely I'll have to revert to OS X.

I did have rEFInd installed at one point, but it got lost in an OS X update. I've been booting directly into Ubuntu via EFI.

[Rachel Greenham (rachel-strangenoises)]

My problem definitely was rEFInd; and i resolved it by using the new --ownhfs install option as discussed on their discussion forum. However I don't have hibernate working at all on the linux side, so it may be that for you too.

[Cloudane (cloudane)]

Okay thank you for the update. I just checked my EFI partition and it only contained GRUB and nothing else, so I guess for me it's a different issue (though it's the same model).

I will have to try completely nuking the SSD with ATA_SECURE_ERASE and installing from a totally clean slate without any OS X at all, on the offchance there's some remnant of rEFInd lurking undetected. I have tried everything else.

[Cloudane (cloudane)]

FYI I did a complete bit wipe of the SSD and started again. Still freezing about 1 in 5 suspends here, unfortunately. Consider yourself lucky :)

[Cloudane (cloudane)]

 I realise this is probably unrelated to the bug then, I think my problem lies within the Intel graphics driver somewhere in the kernel. But for the benefit of anyone searching, I have found a workaround for my version of the problem...

For me it only freezes on suspend if X is showing at the time. If it's on any of the virtual terminals, it's fine. So I created /etc/pm/sleep.d/5_crashfix containing:
#! /bin/sh
case $1 in
  suspend|suspend_hybrid|hibernate)
    /bin/chvt 1
    ;;
  resume|thaw)
    /bin/chvt 7
    ;;
esac

Then chmod +x to the 5_crashfix file.

This changes to VT1 on suspend, and changes back to X on resume, which bypasses the bug.

Unfortunately I don't know "what I'm doing" well enough to try and report anything upstream, I think it's too vague for them to do anything useful with.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]