Hi, I am not sure if I classified this bug correctly ... I get not output, but a hanging process when doing : cat /sys/class/power_supply/BAT0/status I can't provide further details because all other files I tried so far within the /BAT0/ dir are inaccessible. Please let me know what else I can provide as useful info and/or if there is a way to get more debug into the kernel-log, because so far there is nothing in journalctl when trying to access these files under /sys/class/power_supply/BAT0/. Thank you very much in advance for any hint / help. Tormen
acpidump and dmesg please: # acpidump > acpidump.txt $ dmesg > dmesg.txt
Dear Aaron, Since I posted this I had the idea to try a NVRAM and a SMC reset. Then I restarted and tried a cat /sys/class/power_supply/BAT0/manufacturer, which took 13 seconds (!) to come back, but came back. Since you answered me I tried several things, but I am not able to reproduce the problem anymore: Now every read access to /sys/class/power_supply/BAT0/(manufacturer|status) comes back /instantly/ like one would expect. But I am sure there is a problem somehow ! I just don't know yet under what conditions ! ... or it was really the SMC reset that helped. But as I also still have another power related issue with the machine: Suspend does not work! The machine suspends for 4-5 seconds and then comes back on again by itsself! And from time to time when I then open the lid the machine asks for the cryptsetup hdd encryption password, which it does only at BOOT-UP ... so the machine must have rebooted "spontaniously" :(( I'll still attach the two requested infos. Tormen
Created attachment 183191 [details] dmesg aka journalctl -b0|grep -v brcmfmac As in the dmesg buffer you only see brcmfmac debug output as there is also a WIFI related issue with this Macbook Pro, I ended up doing a journalctl -b0|grep -v "brcmfmac\|brcmutil\|kernel: 000000[0123]0: ">journalctl_b0.log instead.
Created attachment 183201 [details] acpidump
per comment #2 re-naming this bug, since the battery issue is no longer re-producible. Assigning to alex, who has some wakeup-source patches that may be useful in debugging what is waking the system early.
Hi. OK, thanks! ... And perfectly spotted, because there is indeed a very annoying problem with the suspend: I can never rely on the suspend to work under Linux so far. In 99.5% of all cases the suspend reliably does NOT work, meaning: The notebook seemingly goes to suspend (display goes off ;)), but comes back out of suspend (4-5 seconds after the display backlight went off) without any apparent reason. Also sometimes the notebook wakes up hours later and then (sometimes) goes off again... I was unable so far to determine a pattern / deduce any related factors. For the (immediately) non-working suspend I tried to look through the journalctl output and saw things that make sense, but am lacking the kernel suspend knowledge to determine what is missing / wrong : Jul 20 22:35:00 banana kernel: PM: noirq suspend of devices complete after 32.836 msecs Jul 20 22:35:00 banana kernel: ACPI: Preparing to enter system sleep state S3 Jul 20 22:35:00 banana kernel: ACPI : EC: EC stopped Jul 20 22:35:00 banana kernel: PM: Saving platform NVS memory Jul 20 22:35:00 banana kernel: Disabling non-boot CPUs ... Jul 20 22:35:00 banana kernel: intel_pstate CPU 1 exiting Jul 20 22:35:00 banana kernel: kvm: disabling virtualization on CPU1 Jul 20 22:35:00 banana kernel: smpboot: CPU 1 is now offline ... Jul 20 22:35:00 banana kernel: smpboot: CPU 3 is now offline # AND THEN ... things seem to start a resume: Jul 20 22:35:00 banana kernel: ACPI: Low-level resume complete Jul 20 22:35:00 banana kernel: ACPI : EC: EC started Jul 20 22:35:00 banana kernel: PM: Restoring platform NVS memory Jul 20 22:35:00 banana kernel: Enabling non-boot CPUs ... Jul 20 22:35:00 banana kernel: x86: Booting SMP configuration: Jul 20 22:35:00 banana kernel: smpboot: Booting Node 0 Processor 1 APIC 0x2 Jul 20 22:35:00 banana kernel: kvm: enabling virtualization on CPU1 Jul 20 22:35:00 banana kernel: cache: parent cpu1 should not be sleeping Jul 20 22:35:00 banana kernel: CPU1 is up I'll attach the full output.
Created attachment 185011 [details] journalctl output of non-working suspend Again cleared from the brcmfmac debug output. Please let me know if I can do anything further to help! Thanks a lot in advance, Tormen
From what people have been reporting on Arch and Ubuntu forums the immediate and random wakeups have been caused by the default power settings allowing bluetooth devices to wake up the computer (which with the broken bluetooth driver currently results in unexpected wakeups). Consensus seems to be that disabling XHC1 in /proc/acpi/wakeup. I'm not sure if this is related to this bug, or if I should open a separate one. But on the 12,1 macbook I got the other day I can't get suspend to work reliably at all. 9/10 times it will either sleep and not wake up, or fail to sleep (it's hard to tell with no outward lights/anything from the laptop). I managed to get it to wake up a single time, which it then froze 30-40 seconds later. On both 4.1.5 and 4.2.0RC7 kernels.
Hi. I am still trying to make sense from all this. Thanks Justin for the input. I am glad for any hint helping me to put together the bits and pieces. But disabling XHC1 should disable USB from being able to wakeup, no ? And as the keyboard and trackpad are USB XHCI devices too on the MacBookPro ... this means you can't wake up with a keystroke :( Bluetooth: I disabled/unloaded all bluetooth drivers, so not sure if bluetooth can still interfere? ------------- After a fresh boot, I have: cat /proc/acpi/wakeup|grep enabled ARPT S4 *enabled pci:0000:03:00.0 XHC1 S3 *enabled pci:0000:00:14.0 LID0 S4 *enabled platform:PNP0C0D:00 ARPT = ? power-button ?? I disabled XHC1 (echo disable XHC1 >/proc/acpi/wakeup) (so left LID0 and ARPT enabled) and did a suspend using: systemctl suspend The system suspended. But I was unable to wake it up again. I tried opening and closing the lid. I tried pressing keys, the powerkey (which is integrated in the keyboard ... !?) Nothing worked. Had to force a reboot. And in the logs I don't see anything about that ... I don't understand :( Please see the attached the kernel log (journalctl) (w.txt and w2.txt)
Created attachment 185461 [details] journalctl output of suspend trial (w.txt -- see comments) (boot, opened and closed the lid a a few times to test the suspend and finally did a systemctl suspend -- please see comments about w.txt)
Created attachment 185471 [details] journalctl output of suspend trial (w2.txt -- see comments) (boot, did a systemctl suspend -- please see comments about w2.txt)
Addition (In reply to Tormen from comment #9) > > The system suspended. But I was unable to wake it up again. > I tried opening and closing the lid. > I tried pressing keys, the powerkey (which is integrated in the keyboard ... > !?) > Nothing worked. > > Had to force a reboot. > > And in the logs I don't see anything about that ... I don't understand :( > > Please see the attached the kernel log (journalctl) (w.txt and w2.txt) Precision: I pressed the powerkey several times short (up to 1-2 seconds MAX). But only when holding it down for 8 seconds to KILL OFF the machine I was able to turn it on again. This was the case after the "systemctl suspend" and was the last thing I did for both "boot-ups" (so the traces of it should be at the end of w.txt and w2.txt).
Otherwise the reason why I added w.txt is: I noticed a kernel complaint when sleeping by closing the LID : Aug 22 16:24:23 banana kernel: Freezing user space processes ... Aug 22 16:24:23 banana kernel: Freezing of tasks failed after 20.006 seconds (1 tasks refusing to freeze, wq_busy=0) Please see the full version attached the kernel log (journalctl) (w.txt) But I did not see this output for the "systemctl suspend", but only when sleeping with KDE by closing the LID, there seems to be (at least) another problem, I'd clonclude ? Tormen
Possibly related bug: https://bugzilla.kernel.org/show_bug.cgi?id=103211
Blacklisting brcmfmac module /seems/ [*] helping to get SUSPEND to work: When booting with brcmfmac blacklisted then /proc/acpi/wakeup contains 2 enabled devices: XHC1 and LID0. (so ARPT should be connected to the brcmfmac driver ?) Sleep did NOT work RELIABLY. The first time (by closing the LID) it /seemed/ [*] to have worked (waited >1min.). Whereas the following times (both triggered by closing the LID or by executing "systemctl suspend") the sleep did NOT work anymore. Then I disabled XHC1. Sleep did /seem/ [*] to work, but ONLY by closing the LID! When executing "systemctl suspend" and by waiting while NOT moving the LID the machine always came back after 2-3 seconds of display backlight off (only indicator at the MacBookPro if the machine is running or not while the LID is closed). See for instance: Aug 25 00:13:30 banana kernel: ACPI: Low-level resume complete Aug 25 00:13:30 banana kernel: ACPI : EC: EC started Aug 25 00:13:30 banana kernel: PM: Restoring platform NVS memory [*] I wrote "/seems/", "/seemed/", "/seem/ to work" because the display backlight stayed OFF for over 1 min. But lookging through the journalctl -b0 for all my suspend trials I only saw all these lines following with the same timestamp: Aug 25 00:07:14 banana kernel: smpboot: CPU 3 is now offline Aug 25 00:07:14 banana kernel: ACPI: Low-level resume complete Aug 25 00:07:14 banana kernel: ACPI : EC: EC started Aug 25 00:07:14 banana kernel: PM: Restoring platform NVS memory Aug 25 00:07:14 banana kernel: Enabling non-boot CPUs ... Which seems not right to me as I would expect that between the CPU offline and the RESUME / start / Restoring messages there should be a JUMP in the timestamp if the suspend really worked, no ???
Created attachment 185751 [details] journalctl_-b0___with-blacklisted-brcmfmac-module.txt
(In reply to Tormen from comment #15) > Blacklisting brcmfmac module /seems/ [*] helping to get SUSPEND to work: > > When booting with brcmfmac blacklisted then /proc/acpi/wakeup contains 2 > enabled devices: XHC1 and LID0. > > (so ARPT should be connected to the brcmfmac driver ?) Should be so. > > Sleep did NOT work RELIABLY. The first time (by closing the LID) it /seemed/ > [*] to have worked (waited >1min.). > Whereas the following times (both triggered by closing the LID or by > executing "systemctl suspend") the sleep did NOT work anymore. What's the symptom? Does it fail at the suspend phase or it couldn't resume? > > Then I disabled XHC1. > > Sleep did /seem/ [*] to work, but ONLY by closing the LID! > > When executing "systemctl suspend" and by waiting while NOT moving the LID > the machine always came back after 2-3 seconds of display backlight off > (only indicator at the MacBookPro if the machine is running or not while the > LID is closed). See for instance: > > Aug 25 00:13:30 banana kernel: ACPI: Low-level resume complete > Aug 25 00:13:30 banana kernel: ACPI : EC: EC started > Aug 25 00:13:30 banana kernel: PM: Restoring platform NVS memory From the log, there is a wakeup signal that caused the resume, maybe it's the LID? If you disable LID0, will "systemctl suspend" work then? > [*] I wrote "/seems/", "/seemed/", "/seem/ to work" because the display > backlight stayed OFF for over 1 min. But lookging through the journalctl -b0 > for all my suspend trials I only saw all these lines following with the same > timestamp: > > Aug 25 00:07:14 banana kernel: smpboot: CPU 3 is now offline > Aug 25 00:07:14 banana kernel: ACPI: Low-level resume complete > Aug 25 00:07:14 banana kernel: ACPI : EC: EC started > Aug 25 00:07:14 banana kernel: PM: Restoring platform NVS memory > Aug 25 00:07:14 banana kernel: Enabling non-boot CPUs ... I would not use journalctl to see timestamps, as that involves writing things into disk/filesystem. When the CPU is being offlined, the filesystem/disk has been already suspended, so I doubt the log write happened after resume and all those un-written kernel logs are written to the log file all at once. Just my guess, not entirely sure about systemd's journal handling. Please use dmesg instead. > > Which seems not right to me as I would expect that between the CPU offline > and the RESUME / start / Restoring messages there should be a JUMP in the > timestamp if the suspend really worked, no ??? No I'm afraid, if you use dmesg, you will see the resume started from where suspend finished. I think it's because that, once suspended, the kernel's time counting is stopped, so when resumed, it starts from where it's stopped. This is not something dmesg can solve though. Anyway, please use dmesg whenever possible, journal has too many information there.
Dear Aaron, Thanks a lot for your comments ! (In reply to Aaron Lu from comment #17) > (In reply to Tormen from comment #15) > > > > Sleep did NOT work RELIABLY. The first time (by closing the LID) it > /seemed/ > > [*] to have worked (waited >1min.). > > Whereas the following times (both triggered by closing the LID or by > > executing "systemctl suspend") the sleep did NOT work anymore. > > What's the symptom? Does it fail at the suspend phase or it couldn't resume? Good question, I forgot to mention that: I am not sure if you are familiar with the MacbookPro: There are no LED indicators for power, battery or "on/off state" like one finds usually with other notebooks. Which makes the screen backlight (also lighting the "apple" on the LID) the only indicator for "on" or "off". So I I had looked at the lighted apple to determine: The first suspend (by closing the LID) the apple went off and stayed off. Whereas the follwing times: It went off for ~3 sec. and than came back on. Screenbacklight ON ==> Apple ON. But as the screen backlight can be controlled (and turned off/on) independently of the wake-state: It could be possible that the screen backlight goes off and the computer does not actually sleep. That's why I was trying to find the truth in the timestamps. --> No problem to use dmesg. Thanks for the explanations around journalctl! You mentioned that the timestamps might all be from the wakeup phase and in the absense of hardware LED indicators: Is there anything that I can use to "proof" the successfull sleeping (other than looking at the state of the lighted apple ? (or waiting if the notebook cools off ;)) > > > > Then I disabled XHC1. > > > > Sleep did /seem/ [*] to work, but ONLY by closing the LID! > > > > When executing "systemctl suspend" and by waiting while NOT moving the LID > > the machine always came back after 2-3 seconds of display backlight off > > (only indicator at the MacBookPro if the machine is running or not while > the > > LID is closed). See for instance: > > > > Aug 25 00:13:30 banana kernel: ACPI: Low-level resume complete > > Aug 25 00:13:30 banana kernel: ACPI : EC: EC started > > Aug 25 00:13:30 banana kernel: PM: Restoring platform NVS memory > > From the log, there is a wakeup signal that caused the resume, maybe it's > the LID? If you disable LID0, will "systemctl suspend" work then? Good question. I disabled everything in /proc/acpi/wakup. Retested with the LID and systemctl suspend. I was only able to wakeup through power-button. And things seemed to work as they should :) After echo enable LID0>/proc/acpi/wakeup: 1.) Closing the LID did NOT trigger the sleep anymore (even though it did right after boot!). 2.) Executing "systemctl suspend", while the LID is open and while NOT moving the LID [*]: * Once FAILED (did not work at all) See: dmesg___all_wakeup-disabled_except_LID0,_systemctl-suspend,_sleep-FAILED.txt The console output of systemctl was: A dependency job for suspend.target failed. See 'journalctl -xn' for details. See: journalctl_-b0___for_FAILED-suspend.txt --> Again (already happened, see former comment) 1 task refusing to sleep: Aug 25 08:27:46 banana kernel: Freezing of tasks failed after 20.001 seconds (1 tasks refusing to freeze, wq_busy=0): Aug 25 08:27:46 banana kernel: upowerd D ffff88046ec16740 0 2494 1 0x00000084 Aug 25 08:27:46 banana kernel: ffff88008770baa8 ffffffff81e15480 ffff88043c46e090 ffffffff8214e9c0 Aug 25 08:27:46 banana kernel: ffff88008770c000 000000010022312c ffffffff8214e9c0 0000000000000001 Aug 25 08:27:46 banana kernel: ffff88045bce6220 ffff88008770bac8 ffffffff8169e2e7 ffffffff8214e9c0 Aug 25 08:27:46 banana kernel: Call Trace: Aug 25 08:27:46 banana kernel: [<ffffffff8169e2e7>] schedule+0x37/0x90 Aug 25 08:27:46 banana kernel: [<ffff88045bd52750>] 0xffff88045bd52750 Aug 25 08:27:46 banana kernel: DWARF2 unwinder stuck at 0xffff88045bd52750 * Otherwise did not work in the sense that the backlight came back-on by itsself See: dmesg___all_wakeup-disabled_except_LID0,_systemctl-suspend,_sleep(screenbackligh)_ended-after-around-3-seconds.txt 3.) Executing "sleep 3; systemctl suspend", allowing to close the LID before the "systemctl suspend" is issued: * once led to the above FAIL again * once seemingly(because not sure if with backlight off, it REALLY sleeps) worked (opening the LID activated the notebook!) :) dmesg___all_wakeup-disabled_except_LID0,_sleep3,_systemctl-suspend,_sleep-seemingly-worked.txt [*] Is this the best way to trigger the suspend manually ? or should I use echo to /sys/... or /proc/... (don't remember the accept path at the top of my head) ? > > Please use dmesg instead. Thanks for the explications and no problem! > > Which seems not right to me as I would expect that between the CPU offline > > and the RESUME / start / Restoring messages there should be a JUMP in the > > timestamp if the suspend really worked, no ??? > > No I'm afraid, if you use dmesg, you will see the resume started from where > suspend finished. Yes... makes sense, I understand. Tormen
Created attachment 185781 [details] dmesg___all_wakeup-disabled,_lid_closed,_wakeup-through-power-button.txt I had forgotten to refer to this file in my posting: I disabled everything in /proc/acpi/wakup. Retested with the LID and systemctl suspend. I was only able to wakeup through power-button. And things seemed to work as they should :) ** See: dmesg___all_wakeup-disabled,_lid_closed,_wakeup-through-power-button.txt **
Created attachment 185791 [details] dmesg___all_wakeup-disabled_except_LID0,_sleep3,_systemctl-suspend,_sleep-seemingly-worked.txt
Created attachment 185801 [details] dmesg___all_wakeup-disabled_except_LID0,_systemctl-suspend,_sleep-FAILED.txt
Created attachment 185811 [details] journalctl_-b0___for_FAILED-suspend.txt
Created attachment 185821 [details] dmesg___all_wakeup-disabled_except_LID0,_systemctl-suspend,_sleep(screenbackligh)_ended-after-around-3-seconds.txt
(In reply to Tormen from comment #18) > Is there anything that I can use to "proof" the successfull sleeping (other > than looking at the state of the lighted apple ? (or waiting if the notebook > cools off ;)) I don't find any software method except by checking the dmesg log. > [*] Is this the best way to trigger the suspend manually ? or should I use > echo to /sys/... or /proc/... (don't remember the accept path at the top of > my head) ? use systemctl suspend is OK.
(In reply to Tormen from comment #21) > Created attachment 185801 [details] > dmesg___all_wakeup-disabled_except_LID0,_systemctl-suspend,_sleep-FAILED.txt [ 1944.952967] PM: Syncing filesystems ... done. [ 1945.011091] PM: Preparing system for mem sleep [ 1945.011264] Freezing user space processes ... [ 1964.991569] Freezing of tasks failed after 20.000 seconds (1 tasks refusing to freeze, wq_busy=0): [ 1964.991592] upowerd D ffff88046ec16740 0 2494 1 0x00000084 [ 1964.991597] ffff88008770baa8 ffffffff81e15480 ffff88043c46e090 ffffffff8214e9c0 [ 1964.991602] ffff88008770c000 0000000100196f8b ffffffff8214e9c0 0000000000000001 [ 1964.991605] ffff88045bce6220 ffff88008770bac8 ffffffff8169e2e7 ffffffff8214e9c0 [ 1964.991608] Call Trace: [ 1964.991618] [<ffffffff8169e2e7>] schedule+0x37/0x90 [ 1964.991622] [<ffffffff816a0bd4>] schedule_timeout+0x154/0x2d0 [ 1964.991627] [<ffffffff813e671c>] acpi_ec_transaction+0x346/0x44c [ 1964.991631] [<ffffffff813e6875>] acpi_ec_read+0x53/0x5f [ 1964.991635] [<ffffffff813e68ab>] ec_read+0x2a/0x42 [ 1964.991650] [<ffffffffa04a5253>] smb_check_done+0x1d/0x31 [sbshc] [ 1964.991659] [<ffffffffa04a53f9>] acpi_smbus_transaction+0x192/0x27f [sbshc] [ 1964.991665] [<ffffffffa02720d9>] acpi_battery_get_state+0x6b/0x7f [sbs] [ 1964.991670] [<ffffffffa0272937>] acpi_sbs_battery_get_property+0x30/0x315 [sbs] [ 1964.991675] [<ffffffff8154b3e5>] power_supply_show_property+0x45/0x200 [ 1964.991680] [<ffffffff8148121c>] dev_attr_show+0x1c/0x60 [ 1964.991685] [<ffffffff81257ffc>] sysfs_kf_seq_show+0xcc/0x1e0 [ 1964.991691] [<ffffffff81202332>] seq_read+0xe2/0x370 [ 1964.991696] [<ffffffff811deb43>] __vfs_read+0x23/0xf0 [ 1964.991701] [<ffffffff811df17d>] vfs_read+0x7d/0x130 [ 1964.991705] [<ffffffff811dff92>] SyS_read+0x42/0xb0 [ 1964.991709] [<ffffffff816a21b2>] system_call_fastpath+0x16/0x75 [ 1964.991719] [<00007f4339e22d2d>] 0x7f4339e22d2d [ 1964.991742] Restarting tasks ... done. The upowerd process is doing some IO(get battery status I guess) and can not enter freeze state and caused the sleep failed.
Do you have any battery related issue? I don't think it's normal the upowerd process stay in uninterruptable state for that long. BTW, I'm adding Chris Bainbridge, who has experience in Apple's SBS related stuff. Chris, Do you have any idea why the upowerd would block the sleep? Thanks.
Thanks a lot for the feedback! (In reply to Aaron Lu from comment #26) > Do you have any battery related issue? Good point: I guess we are back to square one : See my initial description + Comment 2. I just tried again: time cat /sys/class/power_supply/BAT0/manufacturer DP cat /sys/class/power_supply/BAT0/manufacturer 0.00s user 10.97s system 8% cpu 2:14.86 total 2 minutes 14 ... yeahie ;) So my initial "unaccessible" judgement (in the "description") was most likely wrong. I just did not wait long enough ! > I don't think it's normal the upowerd > process stay in uninterruptable state for that long.
From your dmesg, you should be using kernel v4.1.3. Chris has a patch: commit 3349fb64b2927407017d970dd5c4daf3c5ad69f8 Author: Chris Bainbridge <chris.bainbridge@gmail.com> Date: Wed Apr 29 21:21:40 2015 +0100 ACPI / SBS: Add 5 us delay to fix SBS hangs on MacBook that entered v4.1 so I think you are already using that, perhaps Chris can shed some light on this issue? Maybe you need an even longer delay?
Yes, currently 4.1.3 (I am just updating to 4.1.6). I also explicitly checked and can confirm that I am currently already using the changes introduced to drivers/acpi/sbshc.c by the commit 3349fb64b2927407017d970dd5c4daf3c5ad69f8. I saw that there is a debug output: pr_debug("Detected MacBook, enabling workaround\n"); What do I need to do (kernel parameter ?) to be able to see this output ?
pr_debug uses the dynamic debugging interface, see https://lwn.net/Articles/434833/ and https://www.kernel.org/doc/Documentation/dynamic-debug-howto.txt You can enable comments from individual files (e.g. sbshc.c) with: echo 'file sbshc.c +p' > /sys/kernel/debug/dynamic_debug/control Or at module load or boot time with a parameter: insmod sbshc.ko dyndbg=+pmlf For simple debugging you can add printk commands and then watch the kernel log when you do the `cat /sys/class/power_supply/BAT0/manufacturer` and figure out where it is hanging based on the last output. There is a small patch which adds some debugging information which will probably print an error code if a hang occurs: https://bugzilla.kernel.org/attachment.cgi?id=177001&action=diff Use that patch and add printks to the entry and exit points of each function and you should be able to figure out exactly where it hangs. If it is the same bug I had then it will be at the calls to acpi_smbus_read in acpi_battery_get_info() or acpi_battery_get_state() in sbs.c. If it is the same problem as bug #94651 you could try increasing the delay from 5ms. As a workaround you can also try to prevent the thread from sleeping by changing ec.c as in https://bugzilla.kernel.org/attachment.cgi?id=174791&action=diff - e.g. change if (EC_FLAGS_MSI || irqs_disabled()) { to if (1) { And test. The change will invoke a busy wait loop instead of sleeping, so in the case that the SBS hardware controller has crashed, the kernel won't hang. It's more of a workaround though, it's better to not crash the controller in the first place. Another possibility is that it could be a hardware/firmware issue. Try updating OS X to the latest (which will update the SMC and battery firmware) and reset the SMC.
Thanks a LOT for all your feedback and input! Will try it all and post results / findings :) Might take a few days. Tormen
Created attachment 186021 [details] dmesg_from_8_suspend-tests_from_2015-08-27.tar.gz Hi. I updated MacOSX to Yosemite 10.10.5. Did a reset of NVRAM then SMC. (reblessed the refind efi boot img ;)) Same kernel 4.1.3. Now the access to /sys/class/power_supply/BAT0 seems to work fine (for now): time cat /sys/class/power_supply/BAT0/manufacturer DP cat /sys/class/power_supply/BAT0/manufacturer 0.00s user 0.00s system 12% cpu 0.023 total I'll eventually will keep an eye on this with a suspend script. So the sleep FAIL problem is solved. Now I did 8 (2 by 4) systematic tests: (i) suspend by closing LID (ii) suspend by calling "systemctl suspend" for each of the following constallations of LID0 and XHC1 (tested in this order): (a) all /proc/acpi/wakeup disabled except LID0 and XHC1 (b) all /proc/acpi/wakeup disabled except XHC1 (c) ALL /proc/acpi/wakeup disabled (d) all /proc/acpi/wakeup disabled except LID0 And each time I captured the dmesg. Here are the results: (a) all /proc/acpi/wakeup disabled except LID0 and XHC1 (i - LID): sleep(screenbacklight)_ended-after-around-3-seconds (ii - systemctl): sleep-OK_and_wakeup-possible-with-shift-key-press --> (i) should NOT be as LID was not moved and no key was pressed --> (ii) OK, unfortunately I did not try if wakeup by moving LID was possible (b) all /proc/acpi/wakeup disabled except XHC1 (i - LID) + (ii - systemctl): sleep(according to screenbacklight)_ended-after-around-3-seconds --> WHY ?? - should not be as no keyboard key was pressed, no ? (c) ALL /proc/acpi/wakeup disabled (i - LID) + (ii - systemctl): sleep OK and wake-up (as to be expected only possible by power-button, so unable to wakeup by LID movements) --> OK :) (d) all /proc/acpi/wakeup disabled except LID0 (i - LID) + (ii - systemctl): sleep-OK__BUT_wakeup-ONLY-possible-by-power-button(so_opening-and-closing-the-lid,once-sleeping-did-nothing_even-though-LID0-was-ENABLED) --> WHY ?? - should not be as the LID should wakeup :( ... this is actually the most annoying case as sleeping by closing the LID + waking up by opening the LID is (at least my personal MOST-COMMON) use-case of suspend Tormen
(In reply to Tormen from comment #32) > (a) all /proc/acpi/wakeup disabled except LID0 and XHC1 > (i - LID): > sleep(screenbacklight)_ended-after-around-3-seconds > (ii - systemctl): > sleep-OK_and_wakeup-possible-with-shift-key-press > --> (i) should NOT be as LID was not moved and no key was pressed > --> (ii) OK, unfortunately I did not try if wakeup by moving LID was > possible > > (b) all /proc/acpi/wakeup disabled except XHC1 > (i - LID) + (ii - systemctl): > sleep(according to screenbacklight)_ended-after-around-3-seconds > --> WHY ?? - should not be as no keyboard key was pressed, no ? > > (c) ALL /proc/acpi/wakeup disabled > (i - LID) + (ii - systemctl): > sleep OK and wake-up (as to be expected only possible by > power-button, so unable to wakeup by LID movements) > --> OK :) > > (d) all /proc/acpi/wakeup disabled except LID0 > (i - LID) + (ii - systemctl): > > sleep-OK__BUT_wakeup-ONLY-possible-by-power-button(so_opening-and-closing- > the-lid,once-sleeping-did-nothing_even-though-LID0-was-ENABLED) > --> WHY ?? - should not be as the LID should wakeup :( ... this is > actually the most annoying case as sleeping by closing the LID + waking up > by opening the LID is (at least my personal MOST-COMMON) use-case of suspend From your above test, it sounds like there are two problems: 1 XHC1 is causing spurious wakeup signal; 2 LID0 doesn't generate wakeup signal. You may file a new bug against Drivers/USB category for problem 1, we can track problem 2 here though I don't have any idea why... BTW, I wonder if acpidump would change after you upgrade the MacOS?
Created attachment 186061 [details] acpi dump with latest mac osx updates installed attached is acpidump with latest mac osx updates (as of last week at least) installed. the problem i'm seeing seems different from what Tormen is reporting though -- I have the screen backlight/apple logo turn off, but the force touch touchpad is still responsive ("clicky"), and if i put the machine in my bag it gets extremely hot & fans run hard. It also refuses to wake from this almost-suspended-state. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1487919 I haven't blacklisted brcmfmac because I need wireless to work... is that the main difference? should I file a separate bug for what I'm seeing?
Created attachment 186111 [details] acpidump after including all updates - including MacOS Yosemite 10.10.5 Dear Aaron, thanks a lot for your feedback. Good point about the acpidump. I updated mine. I'll file the 2nd bug about the spurious wakeup signal caused by XHC1.
(In reply to thejoe from comment #34) > the problem i'm seeing seems different from what Tormen is reporting though > -- I have the screen backlight/apple logo turn off, but the force touch > touchpad is still responsive ("clicky"), and if i put the machine in my bag > it gets extremely hot & fans run hard. It also refuses to wake from this > almost-suspended-state. > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1487919 > > I haven't blacklisted brcmfmac because I need wireless to work... is that > the main difference? Yes! Because with brcmfmac loaded I have the same problems + behaviour than you (except that I am not yet using the force feedback function) > should I file a separate bug for what I'm seeing? IMHO No, because: * Beside this bug and the new bug I'll create about the XHC1 and the * Brcmfmac bug(s) report which is filed and open under: https://bugzilla.kernel.org/show_bug.cgi?id=100201 I really do expect that you should be a happy camper once they'll be resolved. Did you try disable everything under /proc/acpi/wakeup ? (echo disable LID0 >/proc/acpi/wakeup; echo disable XHC1 >/proc/acpi/wakeup) Because doing so I am at least - even with brcmfmac loaded - able to suspend by closing the LID (if I execute systemctl suspend, my system still HANGS every time !). Otherwise: What kernel version (uname -a) are you using?
(In reply to Aaron Lu from comment #33) > (In reply to Tormen from comment #32) > ... > From your above test, it sounds like there are two problems: > 1 XHC1 is causing spurious wakeup signal; > 2 LID0 doesn't generate wakeup signal. > > ... we can track problem 2 here though I don't have any idea why... @Aaron: I forgot to ask: Anything I can still try or will it be my job to dig into the kernel code now ?
(In reply to Tormen from comment #37) > @Aaron: I forgot to ask: > Anything I can still try or will it be my job to dig into the kernel code > now ? I don't have any suggestions now, it's usually not easy, if not impossible, to find out the cause why some device doesn't generate wakeup signal.
(In reply to Tormen from comment #32) > I updated MacOSX to Yosemite 10.10.5. > Did a reset of NVRAM then SMC. > (reblessed the refind efi boot img ;)) > Same kernel 4.1.3. > Now the access to /sys/class/power_supply/BAT0 seems to work fine (for now): > > time cat /sys/class/power_supply/BAT0/manufacturer > DP > cat /sys/class/power_supply/BAT0/manufacturer 0.00s user 0.00s system 12% > cpu 0.023 total > Now I got again : time cat /sys/class/power_supply/BAT0/manufacturer DP cat /sys/class/power_supply/BAT0/manufacturer 0.00s user 0.71s system 1% cpu 43.438 total So I will (have to) dig into the code that Christ pointed me on.
(In reply to Aaron Lu from comment #38) > (In reply to Tormen from comment #37) > > @Aaron: I forgot to ask: > > Anything I can still try or will it be my job to dig into the kernel code > > now ? > > I don't have any suggestions now, it's usually not easy, if not impossible, > to find out the cause why some device doesn't generate wakeup signal. I guess it does not change your assessment (not easy / impossible), but I realized that the LID0 has actually two problems: In some cases (c), (d) : LID doesn't generate wakeup signal. But in other cases (a) : the LID is causing spurious wakeup signal (and (b) is the spurious wakeup signal of XHC1) As I am not a kernel developer I would need a hint in what file to look for what (round about). Then I would be able to put in printk's to trace for instance... But without any hint where to start, I would (have to) drop the LID problem. (( but I will continue with what I said in comment 39, and also still open the bug about the spurious wakeup signal of XHC1 ! )) Tormen
(In reply to Tormen from comment #40) > As I am not a kernel developer I would need a hint in what file to look for > what (round about). Then I would be able to put in printk's to trace for > instance... The only thing kernel has control of these wakeup signals is the enable/disable GPE of the wakeup capable devices, i.e. LID and XHC. I believe they are all enabled by default, and the /proc/acpi/wakeup is where the user can decide if they want them enabled/disabled. If you look at the dmesg, you should find some lines like this: [59790.593726] PM: suspend of devices complete after 122.154 msecs [59790.612681] PM: late suspend of devices complete after 18.940 msecs [59790.617678] ehci-pci 0000:00:1d.0: System wakeup enabled by ACPI [59790.617920] ehci-pci 0000:00:1a.0: System wakeup enabled by ACPI [59790.618683] e1000e 0000:00:19.0: System wakeup enabled by ACPI [59790.632675] PM: noirq suspend of devices complete after 19.980 msecs Pay attention to the "System wakeup enabled by ACPI" lines, that means the kernel has enabled the GPE for those devices for wakeup purpose. The relevant code is at: drivers/acpi/device_pm.c: acpi_pm_device_sleep_wake and drivers/acpi/wakeup.c: acpi_enable_wakeup_devices > But without any hint where to start, I would (have to) drop the LID problem. > > (( but I will continue with what I said in comment 39, and also still open > the bug about the spurious wakeup signal of XHC1 ! )) > > Tormen
Some ideas: Presumably everything works ok in OS X? Did you try any earlier kernels? In particular, you could try reverting 7bc5a2bad0b8 which was merged from 3.18 onwards and which makes Linux claim to be Darwin. Not an ideal fix, but it would at least help identify why this problem has appeared now. The Arch wiki mentions using "options xhci_hcd quirks=0x80" on 3.18+ to workaround some problems with XHCI and suspend. https://wiki.archlinux.org/index.php/MacBookPro11,x (different mbp version, but possibly similar problem) Also there are relevant-looking notes on fixing XHCI wakeup in a gnome-power-manager option and also disabling wake from S3 at XHC1 at https://wiki.archlinux.org/index.php/MacBook#Suspend_and_Hibernate Related to the Gnome power manager issue, it may be worth testing suspend/resume directly from command line (no Xorg/desktop running).
(In reply to Chris Bainbridge from comment #42) > Some ideas: > > Presumably everything works ok in OS X? > > Did you try any earlier kernels? In particular, you could try reverting > 7bc5a2bad0b8 which was merged from 3.18 onwards and which makes Linux claim > to be Darwin. Not an ideal fix, but it would at least help identify why this > problem has appeared now. > Everything works for me in OSX on my 11,5. I built a 4.2.0 kernel with 7bc5a2bad0b8 reverted and without brcmfmac and see the same issues.
@Tim: Thanks for the feedback ! @Chris : Thanks a lot for the xhci_hcd quirks hint, I somehow missed that. I'll check that out and at the same time shut down X :) For now I used this work-around for acpi spurious wakeup signals / sleep problems echo disable XHC1 >/proc/acpi/wakeup echo disable LID0 >/proc/acpi/wakeup which makes suspend work <4.1 with brcmfmac module blacklisted and with 4.2 kernel just like this. Just since recently (not able to pinpoint since what change) : I have a new problem where the macbook won't wake up from sleep... but maybe also only the screen stays blank, difficult to say :/... nothing odd seems to show up in journalctl when this happens :( I was then forced to hold pressed the power-button.
Hello, From the comments I see, there are 2 siturations (I'll merge with mine); 1) Not being able to suspend (because of random wakeups) 2) Hang while trying to suspend (My case). The second one is quite confusing between not waking up, since there is no power state indicator on the machine. But I do my checks with cooling fans. And it is definitely not sleeping, fans are running. ( Can other people confirm? ) For my situration; - Debian 8, Gnome 3.14, upowerd, systemd, linux 4.2.1 - MacbookPro 11,5 - Using the i915 GPU, thanks to apple_set_os.efi, radeon module still loaded but radeon is switched off using kernel's vga_switheroo interface - results wasn't different even if I'm using radeon GPU I can access /sys/class/power_supply/BAT0/status with no problem at all. Actually I am continously accessing that for my power monitor every second. (Not open in all my suspend attempts) I have tried to evacuate some system logs before trying suspend, through network or anything, but couldn't see any output (network and screen was down before I could see anything) I saw some kernel arguments for debugging this a bit more, not sure if I can catch logs but I'll try and share the result. (debug ignore_loglevel log_buf_len=10M print_fatal_signals=1 LOGLEVEL=8 sched_debug) Will share more when I have info.
(In reply to Furkan Mustafa from comment #45) > Hello, > > From the comments I see, there are 2 siturations (I'll merge with mine); > 1) Not being able to suspend (because of random wakeups) > 2) Hang while trying to suspend (My case). Did you try rule out brcmfmac ? As I wrote: suspend works with <4.1 with brcmfmac module blacklisted and with 4.2 kernel just like this (normal brcmfmac usage) tormen
(In reply to Tormen from comment #46) > > Did you try rule out brcmfmac ? > > As I wrote: > suspend works with <4.1 with brcmfmac module blacklisted > and with 4.2 kernel just like this (normal brcmfmac usage) > Hi. This may be true for 12,1, but I am unable to find a combination that successfully suspends my 11,5 machine. Like Furkan, I listen for the fans and they continue and often speed-up after attempting to sleep. thanks! tim
(In reply to Tim Sammut from comment #47) > (In reply to Tormen from comment #46) > > > > Did you try rule out brcmfmac ? > > > > As I wrote: > > suspend works with <4.1 with brcmfmac module blacklisted > > and with 4.2 kernel just like this (normal brcmfmac usage) > > > > Hi. > > This may be true for 12,1, but I am unable to find a combination that > successfully suspends my 11,5 machine. Like Furkan, I listen for the fans > and they continue and often speed-up after attempting to sleep. > > thanks! > tim I've got a MBP 11,5 and kernel 4.2 as well and experience the exact same behaviour.
But still, given the fact that brcmfmac has the ability to create a HANG during suspend, I'd give it a shot to rmmod or blacklist the module and test.
(In reply to Tormen from comment #49) > But still, given the fact that brcmfmac has the ability to create a HANG > during suspend, I'd give it a shot to rmmod or blacklist the module and test. Yeah, I wish it helped, but I built a kernel without brcmfmac and it does not change the behavior.
> Yeah, I wish it helped, but I built a kernel without brcmfmac and it does > not change the behavior. Have you also tried hibernate?
(In reply to ttt45 from comment #51) > > Yeah, I wish it helped, but I built a kernel without brcmfmac and it does > > not change the behavior. > > Have you also tried hibernate? I have not. I use an encrypted swap with a random per-boot key and that breaks hibernate. I might be swayed from that config if we knew hibernate worked...
I believe that there is no reason for hibernation not to work, that's a whole different story. I did a bit more testing, and apparently (in my case), it's not even reaching a state that is related with kernel, or it not being logged. I have unloaded/blacklisted all suspectible modules, I have killed almost all running services, and tried 'pm-suspend' from virtual console. Well, usually, just before it's actually suspending, it is supposed to run a chain of preparations, like at least syncing disks, and logs used to have a message saying "syncing disks". There is nothing in logs. For example, just to be able to track, I have run "rmmod btusb" and saw the output of that command in the logs. Then I've run "pm-suspend". Black screen, all external(usb) devices gets turned of somehow, fans running, getting a bit hotter. turning off with holding power button again. And on the next run I check the logs, and last thing I can find is the output of "rmmod btusb". nothing else. Maybe I'm not able to see anything because of how systemd handles these stuff, but I'm not sure since I don't see anything. I have put a script myself to /etc/pm/sleep.d/. To check at least if that is called. And it was being called, saved some log into a file, saying "sleeping". Aside from my scripts output, there was nothing else. Can it be somehow video driver locking up before it was able to do anything else? Is there a way to properly debug / log what's going on?
And now I've tried with "systemctl suspend", and only logs I'm getting is, Sep 26 11:54:37 fmxlnx systemd[1]: Starting Sleep. Sep 26 11:54:37 fmxlnx systemd[1]: Reached target Sleep. Sep 26 11:54:37 fmxlnx systemd[1]: Starting Suspend... nothing else and result is same. hang.
(In reply to Furkan Mustafa from comment #53) [..] > Can it be somehow video driver locking up before it was able to do anything > else? > > Is there a way to properly debug / log what's going on? That is an interesting train of thought since the videoadapter is another big difference between the 11,5 and 12,1. The 11,5 has an AMD Radeon R9 M370X videocard compared to the Intel Iris Pro 6100 in the 12,1. On the 11,5, the AMD drivers are not that stable (I notice quite some screen distortion from time to time). Perhaps they cause issues during suspend/resume as well?
I think I remembered seeing people with an 11,4 (which does not have the GPU) having the same problems. For instance see this: https://bbs.archlinux.org/viewtopic.php?pid=1550990#p1550990
I can confirm the same behaviour on 11,4. Also see https://bugzilla.kernel.org/show_bug.cgi?id=103211
My MBP12,1 with Ubuntu Wily and Linux 4.2.0 is by default resuming immediately after suspending. Disabling ACPI wakeup per the Arch Wiki instructions in comment 42 fixed this for me. I am also unloading the brcmfmac module prior to suspend because of the errors it reports during suspend/resume.
(In reply to arjen.veenhuizen from comment #48) > (In reply to Tim Sammut from comment #47) > > (In reply to Tormen from comment #46) > > > > > > Did you try rule out brcmfmac ? > > > > > > As I wrote: > > > suspend works with <4.1 with brcmfmac module blacklisted > > > and with 4.2 kernel just like this (normal brcmfmac usage) > > > > > > > Hi. > > > > This may be true for 12,1, but I am unable to find a combination that > > successfully suspends my 11,5 machine. Like Furkan, I listen for the fans > > and they continue and often speed-up after attempting to sleep. > > > > thanks! > > tim > > I've got a MBP 11,5 and kernel 4.2 as well and experience the exact same > behaviour. I am also unable to find a combination to get my MBP 11,5 to suspend correctly. I'm running Ubuntu 14.04 with kernel 3.19.9-25. Specifically, it runs the suspend actions without any noticable errors, and then just hangs. Attempting to hibernate (running sudo pm-hibernate) causes the hibernate actions to start, following by the screen/keybord turning off for a moment, then returning right back to the desktop. I've posted more information in an askubuntu post here: http://askubuntu.com/questions/672750/standby-and-shutdown-hang-on-macbook-pro-11-5 I'm at a loss as to how and continue and debug this. Any updates on this thread? Or ideas on how to best proceed?
Any update on this issue?
On MacBookPro 12.1 I am still investigating. For now I can suspend on lid-close with systemctl suspend and can wake-up from suspend with power-button. But from time to time there are still things that seem odd and unexplainable for now... (machine hangs on wakup or on sleep, screen black, but machine on, ... nothing possible except hard-reset via power-button)... but I will only post here once I am able to pin-point more precisely ! For the time being I am trying to see if / how things are reproducible.
I have recently identified an issue in the SBS driver that might be responsible for some of the reports here (hangs on boot or accessing /sys/class/power_supply/BAT0) - see https://lkml.org/lkml/2015/11/6/776 - there is a patch there if anyone who is experiencing these problems would like to try it out (alternatively, build a kernel without the sbshc module and make sure it isn't on your initrd or in /lib/modules). It seems unlikely that the ACPI SBS issues would be related to the brcmfmac issues though.
fwiw, rmmoding sbshc (and sbs) as well as brcmfmac before suspend still results in the same behavior for me (screen black, but machine on, ... nothing possible except hard-reset via power-button) 100% of the time on my MacBookPro11,4. adding sbshc to /etc/modprobe.d/blacklist had no apparent effect (sbs and sbshc modules were both loaded, probably before the blacklist was available?)
I applied the patch to 4.3.0, but the suspend/poweroff issue remains. We'll how the battery detection issues addressed in the patch work out. Thanks.
Hi, Is it useful to treat the MacBookPro11,4 within the same bug together with the MacBookPro12,1 ? The hardware should be different and thus the potential problems and behaviour as well ? Tormen
@Tormen The hardware is more similar than not (same ACPI, BIOS, etc.). It makes sense to consider the problem to be the same bug unless there is a way to tell the symptoms apart - either by identifying the bug as affecting one specific piece of hardware, or show that a reproducible test affects one hardware but not the other. I have a new patch at https://lkml.org/lkml/2015/11/12/526 - it should fix the problem seen in your log (from comment #25 above). There is a recent article on 01.org which provides some help for debugging suspend: https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues
@Chris Bainbridge I'm on Ubuntu 14.04, kernel 3.19 HWE LTS Vivid, MacBookPro11,5, and interestingly enough I don't have the hang problem mentioned by your commit. naftuli@macbook-nkay:~$ ls /sys/class/power_supply/ ADP1 I don't have BAT0, interestingly enough. I'm not seeing things hang on access to this. My MacBook Pro 11,5 has a hybrid Intel and ATI graphics mode, I'm currently using radeon (FGLRX hasn't worked for me here, tried multiple times) and I've blacklisted i915 due to a black screen at boot otherwise. I've used rEFInd's hack for spoofing the OSX version to get the i915 card online, but it doesn't seem too useful at all. Last time I checked, suspend didn't work. If there was a specific list of things you'd like me to perform, I'd be happy to work through things. There's a lot of good stuff linked above at 01.org, please let me know which things I should try and run and report back here. I'm happy to report all progress, hoping to get suspend working here.
Also, when I hit suspend, I never see the keyboard backlight go off here, so I'm theorizing that I never actually drop to suspend; either that or the LEDs don't turn off during S3.
I'm not sure how helpful this is, but I booted into the GRUB console and ran the 'halt' command and it successfully powers off the system. I have a MacBookPro11,4 and suspend/poweroff hang like others have reports. The last message I see is 'acpi_power_off called'.
I never experienced poweroff hangs. But I do experience from time to time extended power-on hangs (before REFInd menu) ! Does anyone here also experience from time to time a loooong blank (+1 minute) (screen backlight on, but nothing visible on screen) after power-on ? (In reply to Naftuli Tzvi Kay from comment #68) > Also, when I hit suspend, I never see the keyboard backlight go off here, so > I'm theorizing that I never actually drop to suspend; either that or the > LEDs don't turn off during S3. MacbookPro 12,1: Real Suspend is possible (LED keyboard backlight OFF) ! Within "/proc/acpi/wakeup" I have disabled everything except: ARPT S4 *enabled pci:0000:03:00.0 @Chris: I am just changing OS, once I migrated, I'll look into this again. Thanks a lot for the debugging link ! Tormen
@Chris: And thanks a lot for the patch ! (which I'll test soon together with the NVME harddisk patch :))
@Torman I have poweroff hangs here, and like I said, suspend simply doesn't work. I get a black screen and I'm only able to hard-kill it with the power button. Can you validate that my settings are similar to yours? See http://pastebin.com/kxn83TBd @Chris: Here's some information regarding my current setup: http://pastebin.com/kxn83TBd
(In reply to Naftuli Tzvi Kay from comment #72) > @Torman > > I have poweroff hangs here, and like I said, suspend simply doesn't work. I > get a black screen and I'm only able to hard-kill it with the power button. > Can you validate that my settings are similar to yours? See > http://pastebin.com/kxn83TBd What about brcmfmac ? Did you read all the bug comments ? Can you try 4.2 kernel ? I prefer to help you by mail and not in the thread. Please contact me by mail for further questions. > @Chris: Here's some information regarding my current setup: > http://pastebin.com/kxn83TBd Same URL ?
Hi, Any updates on this issue? I am using Fedora23 with kernel 4.2.6 on a Macbook Pro 11,4 and suspend/poweroff don't work for me. Also, systemctl suspend suspends but I can never wakeup from suspend with the power button. Do you need any specific info from my system to debug this further and fixing it?
(In reply to Vamsi Subhash Achanta from comment #74) > Hi, > > Any updates on this issue? I am using Fedora23 with kernel 4.2.6 on a > Macbook Pro 11,4 and suspend/poweroff don't work for me. The fix for the SBS HC issue (comment #25) is in kernel 4.4-rc4 (commit add68d6aa9e2). But there may be some other issue on more recent hardware. Perhaps someone who experiences this bug could re-test the latest linux git. (In reply to Tormen from comment #70) > I never experienced poweroff hangs. > > But I do experience from time to time extended power-on hangs > (before REFInd menu) ! The Macbook will hang for 30 seconds at boot if the NVRAM boot entry points to an unbootable partition, resetting the NVRAM should fix it. Though when I've seen this stall, it happens at every boot, so your issue is probably something different. Link http://www.rodsbooks.com/refind/installing.html#sluggish
> The fix for the SBS HC issue (comment #25) is in kernel 4.4-rc4 (commit > add68d6aa9e2). But there may be some other issue on more recent hardware. > Perhaps someone who experiences this bug could re-test the latest linux git. > I have macbook pro 11,4 with archlinux , linux-mainline 4.4-rc4 Still hangs at suspend/poweroff :(
Hi all, Could any of the developers please look into this? I am not a kernel developer nor am I into driver development. It would be really great if one of the devs looks into this. Without suspend and wakeup working, laptop is mostly un-usable as it can't be portable to close and wake up when required. I could share the required settings or can test the patch if someone comes up with it. Thanks.
(In reply to Vamsi Subhash Achanta from comment #77) > Hi all, > > Could any of the developers please look into this? I am not a kernel > developer nor am I into driver development. It would be really great if one > of the devs looks into this. Without suspend and wakeup working, laptop is > mostly un-usable as it can't be portable to close and wake up when required. > > I could share the required settings or can test the patch if someone comes > up with it. Thanks. Ditto, This is a particularly annoying bug that makes using Linux on this Macbook model incredibly difficult. Is there anything else us users can do to help the developers fix this?
Just a note that workaround in Comment #44 works for 12,1 with kernel 4.3.3.
The Comment #44 workaround doesn't appear to work on 12,4 macbooks on 4.3.x for me.
A follow up on this issue on 12,1 with kernel 4.3.3 in Arch Observations are as follow: - Disabling XHC is not needed. - Disabling LID0 is needed. - After disable LID0, system able to suspend automatically when lid is closed. When reopen lid, a key press is required to resume.
That is good news :) I guess thanks to the Intel XHC guys is in order! Unfortunately I won't be able to test right away myself, but I'll see to it.
I tried disabling LID0 and suspending via systemctl and via shutting the lid, and had the same results as the very start of this thread, using Arch on mainline 4.4 kernel on my 11,5 mid-2015 macbook pro
I just tried as well, and my 11,5 with 4.3.3 (4.3.3-hardened-r7 from gentoo) does not suspend on lid close or systemctl suspend.
This thread is quite long, can someone please tell me the latest result? Anyway I'll check from the first comment til the last one, and I have a Mac pro in hand,will report back later.
On Macbook Pro 11,5 retina none of the current suggestions work: disabling LID0 has no effect, I had assumed this would prevent closing the lid from doing anything but the result is the same as always: - When the lid is closed, the machine appears to suspend (the apple logo light turns off) - During suspension the laptop gets very hot (so it's likely that suspend causes some kind of infinite loop) - When re-opening the lid, the screen is blank and there is no way to resume, the only fix is holding down the power button to do a complete reset.
Please keep in mind that, suspend problems for 12,1 and 11,5 is quite different. We have both 11,5 and 12,1 in our company. We also have an older (8,1 or 9,1) macbook pro, with again dual GPUs like 11,5. There is not a single solution on this for 11,5. Trying solutions for 12,1 won't work (until we get to that stage). Because 11,5 hangs before being able to actually suspend. It turns of the screen and does also some more steps of suspending (syncing disks, etc.), but somehow hangs before suspending, therefore the macbook is getting hot and the fans are still running. I believe this has to do something with having two GPUs. I think that's the biggest difference between 11,5 and 12,1. On the other hand, 12,1 is actually able to suspend most of the time. On some setups and sometimes randomly macbook wakes up immediately *after* suspending "successfully" (If you'd call it a success). This is apparently being solved with the solutions above. With our 12,1 we didn't have to do any setup, and it was able to sleep *most* of the time. (Using kernels 4.1, 4.2, ..) And. One more important note, the 2011 Macbook Pro I have, also has two GPUs, and i7 CPU like 11,5, But it never had any problems with suspend/wake-up, was working oob. So the differences that matter between the 2011 mbp and (2015) 11,5 are, I guess; - Apple GMUX version is newer (1.9.35 [classic] on 2011 one, 4.0.20 [indexed] on the 2015 one) - Discrete Radeon GPU model (1002:6741 on 2011 one, 1002:6821 on 2015 one) - CPU (And Integrated Intel GPU) could have some differences. (i7-2820QM on 2011 one, i7-4870HQ on 2015 one) From time to time, I still try the newest RC kernel on our 11,5, but with no luck (and with other unrelated regressions, like loss of direct rendering because of vga arbitration thing) It would be really nice if we could hear from any kernel developer to at least how to help debug/fix it.
(In reply to Furkan Mustafa from comment #87) > There is not a single solution on this for 11,5. Trying solutions for 12,1 > won't work (until we get to that stage). Because 11,5 hangs before being > able to actually suspend. It turns of the screen and does also some more > steps of suspending (syncing disks, etc.), but somehow hangs before > suspending, therefore the macbook is getting hot and the fans are still > running. I believe this has to do something with having two GPUs. I think > that's the biggest difference between 11,5 and 12,1. I have 11,5 (mid 2015) without second GPU and i have the same symptoms: hangs on going to suspend. So i don't think the problem is related to double GPUs.
(In reply to Furkan Mustafa from comment #87) > Please keep in mind that, suspend problems for 12,1 and 11,5 is quite > different. > We have both 11,5 and 12,1 in our company. We also have an older (8,1 or > 9,1) macbook pro, with again dual GPUs like 11,5. > > There is not a single solution on this for 11,5. Trying solutions for 12,1 > won't work (until we get to that stage). Because 11,5 hangs before being > able to actually suspend. It turns of the screen and does also some more > steps of suspending (syncing disks, etc.), but somehow hangs before > suspending, therefore the macbook is getting hot and the fans are still > running. I believe this has to do something with having two GPUs. I think > that's the biggest difference between 11,5 and 12,1. I have the 11,4 model without discrete GPU and also problems with suspend and shutdown.
(In reply to Chen Yu from comment #85) > This thread is quite long, can someone please tell me the latest result? > Anyway I'll check from the first comment til the last one, and I have a Mac > pro in hand,will report back later. Hi Chen, Yes it is and getting longer and longer ;) I think it is not practical to treat all of the MacbookPro models in the same thread. Chris mentioned: @Tormen The hardware (12,1 and 11,4) is more similar than not (same ACPI, BIOS, etc.). It makes sense to consider the problem to be the same bug unless there is a way to tell the symptoms apart - either by identifying the bug as affecting one specific piece of hardware, or show that a reproducible test affects one hardware but not the other. So it would be useful to determine which models should be treated here (beside the original 12,1 model in the threads name) and then change the name of the thread accordingly. As far as a detailed update on the 12,1 issues goes I will need a bit time, but will get there eventually! Tormen
I also made a typo before; mine is an 11,4 without the discrete GPU and has these issues.
Thank you for a lot of investigation from Furkan! I have archlinux kernel 4.3.3 installed on rMBP 11,5 with i7/dual GPUs(irs/radeon), and experiencing the same problem with suspending for months. After closing the lid, the screen blacks out, the machine hangs and get extremely hot. Had to press power button to turn off. Solution in Comment #44 seems to be a workaround for immediately wake-up, doesn't fit the problem with 11,5. I'm not sure how to get dmesg during suspending, but love to help if any instructions. Hope this pain can be fixed soon!
Bug #111781 may be relevant - "Macbook Apple firmware boot leaves wifi DMA on resulting in chaos". Try adding kernel parameters "iommu=force intel_iommu=on" to grub config.
(In reply to Chris Bainbridge from comment #93) > Bug #111781 may be relevant - "Macbook Apple firmware boot leaves wifi DMA > on resulting in chaos". Try adding kernel parameters "iommu=force > intel_iommu=on" to grub config. That unfortunately did not work in my case :/ (11,5 kernel 4.4.1)
Didn't work for me either. (11,4, kernel 4.5.0-rc2)
Can we create a new bug report for 11,4 and 11,5 for this issue and congregate around that? It's obviously a different problem as nobody on 11,4 or 11,5 has gotten suspend working. I'm on 11,5, kernel 4.2.0 on Ubuntu 14.04 with HWE to Wily kernel.
On 11,4 I've not gotten poweroff to work either. (I have to hold the power key to force a machine poweroff)
There is already a bug for the lack of shutdown on 11,4: https://bugzilla.kernel.org/show_bug.cgi?id=103211 Apparently it is still in NEEDINFO. but there are 22 people on the CC list now. Just no real movement otherwise.
I'm on an 11,5 machine and willing to provide any information to get this issue solved. It is a huge problem that prevents me from using Linux as my daily driver.
If I understand correctly, there are two problems in 11,5(4), one is the poweroff issue which is tracked in https://bugzilla.kernel.org/show_bug.cgi?id=103211 mentioned in Comment98, another is the S3 suspend/resume failure, since most people in this thread have problems on suspend/resume on 11,4 and 11,5, I'd suggest we file a new bug on this since the current thread only concentrates on 12,1 mode , which is working well according to Comment87. As for all suspend/resume issue on 11,4(5), I would suggest try the follow step to narrow down the scope: 1. recompile the kernel with CONFIG_PM_TRACE_RTC=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_EHCI_HCD=y 2. cmdline : init=/bin/bash initcall_debug ignore_loglevel no_console_suspend nomodeset modprobe.blacklist=brcmfmac,i915 3. rtcwake -m mem -s 30 if step 3 does not work, please try /sys/power/pm_test from 'freezer' util 'core'
Chen, in comment #85 you said that you had a MBP to test and would report back later - did you manage to reproduce the issue?
Chen, I'll try your suggestions. For now I've started Bug 113831
(In reply to Chris Bainbridge from comment #101) > Chen, in comment #85 you said that you had a MBP to test and would report > back later - did you manage to reproduce the issue? Chris, I have a Pro 12,1 MBP121.0167, and did not have the problem on suspend/resume, I'll make a double check tomorrow
That's interesting. The above comments suggested that there were still problems on MBP12,1: - Comment #87 said that suspend and resume on MBP12,1 is still unreliable (no kernel version mentioned): "sometimes randomly macbook wakes up immediately *after* suspending" "it was able to sleep *most* of the time" - Comment #81 said that suspend on MBP12,1 with linux-4.3.3 does not work properly unless LID0 is disabled. Has anyone with MBP12,1 tested a more recent kernel?
Hello Chen, I also agree with separating the bugs since the issue is 100% different between 12,1 and 11,4 - 11,5 ones. Thanks for the debugging instructions. I have tested with the latest rc kernel 4.5.0-rc6. The system still hangs trying to suspend, and again temperature and fan speeds rises. But this time, I have console output. Last log line is; > PM: Calling lapic_suspend+0x0/0x1c0 (and hangs like that) Attaching the full log output as a photo. Thanks
Created attachment 207861 [details] 20160306 MBP11,5 Suspend Test Logs
I have placed even more verbose logging into lapic_suspend function, to understand where it exactly hangs. It appears to be it's proceeding until `local_irq_restore`. That is last point I can confirm.
My MBP12,1 is now on 4.4.3, and I noticed most of the time the "disable LID0" trick no longer works. I'm unsure why.
(In reply to Chris Bainbridge from comment #104) > That's interesting. The above comments suggested that there were still > problems on MBP12,1: > > - Comment #87 said that suspend and resume on MBP12,1 is still unreliable > (no kernel version mentioned): > > "sometimes randomly macbook wakes up immediately *after* suspending" > "it was able to sleep *most* of the time" Sometimes device such as brcmac or xhci may wake up the system, I've tried 4.5.0-rc2 on S3 with 10 rounds by echo mem > /sys/power/state and wake up by power button, seems working well. I'll keep testing. > > - Comment #81 said that suspend on MBP12,1 with linux-4.3.3 does not work > properly unless LID0 is disabled. here's my /proc/acpi/wakeup @MacBookPro-A1502:/home/chenyu# cat /proc/acpi/wakeup Device S-state Status Sysfs node PEG0 S3 *disabled EC S4 *disabled platform:PNP0C09:00 HDEF S3 *disabled pci:0000:00:1b.0 RP01 S3 *disabled pci:0000:00:1c.0 RP02 S3 *disabled pci:0000:00:1c.1 RP03 S3 *disabled pci:0000:00:1c.2 ARPT S4 *disabled pci:0000:03:00.0 RP05 S3 *disabled pci:0000:00:1c.4 RP06 S3 *disabled pci:0000:00:1c.5 SPIT S3 *disabled XHC1 S3 *enabled pci:0000:00:14.0 ADP1 S4 *disabled platform:ACPI0003:00 LID0 S4 *enabled platform:PNP0C0D:00 > > Has anyone with MBP12,1 tested a more recent kernel?
(In reply to Furkan Mustafa from comment #107) > I have placed even more verbose logging into lapic_suspend function, to > understand where it exactly hangs. It appears to be it's proceeding until > `local_irq_restore`. That is last point I can confirm. I think this is the same issue as the poweroff on 11,4 the last step of suspend-to-mem is to enter _S3 state, and it hangs there, just as the poweroff hangs when trying to enter _S5, which invokes acpi_enter_sleep_state(S3) and acpi_enter_sleep_state(S5) respectively. It seems to be a BIOS issue to me..
(In reply to Sian Lerk Lau from comment #108) > My MBP12,1 is now on 4.4.3, and I noticed most of the time the "disable > LID0" trick no longer works. I'm unsure why. humm, could you try latest kernel ?
I have Macbook Pro 11,1 (mid-2014), latest mainline kernel 4.5.0 (on Ubuntu) and I also have troubles with suspend - it does not hang but wakes up immediately after closing the lid. Disabling XHC1 in /proc/acpi/wakeup seems to prevent that but at the same time this breaks wakeup on lid opening (LID0 is still enabled). The other thing is that this happens only every other time. So I close the lid, the laptop goes to sleep, wakes up after 4 seconds, I open the lid and close it again and this time it stays suspended and resumes properly. Next suspend will again wake up immediately and another one will work fine. I have found nothing of interest in the logs. Let me know if I can provide any more data (or if I should provide them elsewhere).
(In reply to Sian Lerk Lau from comment #108) > My MBP12,1 is now on 4.4.3, and I noticed most of the time the "disable > LID0" trick no longer works. I'm unsure why. Do you mean the system wake up immediately even lid set to disabled in /proc/acpi/wakeup?
(In reply to Martin Klapetek from comment #112) > I have Macbook Pro 11,1 (mid-2014), latest mainline kernel 4.5.0 (on Ubuntu) > and I also have troubles with suspend - it does not hang but wakes up > immediately after closing the lid. > > Disabling XHC1 in /proc/acpi/wakeup seems to prevent that but at the same > time this breaks wakeup on lid opening (LID0 is still enabled). > > The other thing is that this happens only every other time. So I close the > lid, the laptop goes to sleep, wakes up after 4 seconds, I open the lid and > close it again and this time it stays suspended and resumes properly. Next > suspend will again wake up immediately and another one will work fine. I > have found nothing of interest in the logs. > > Let me know if I can provide any more data (or if I should provide them > elsewhere). For pro 11 issues, Please go to https://bugzilla.kernel.org/show_bug.cgi?id=103211 The problem is that on pro 11 the pci io reassign has broken the ACPI sleep region..
ping...
Some infos for posterity. I was experiencing the same issues with my Mackbook 12,1 (2015). I was initially able to sort of resolve them by unloading brcmfmac before suspend. Here's the systmed script I used to achieve that: ################################################################### # File: /etc/systemd/system/modules-sleep.service [Unit] Description=Module unload/load on sleep/resume Before=sleep.target StopWhenUnneeded=yes [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/sbin/rmmod brcmfmac ExecStop=/usr/sbin/modprobe brcmfmac [Install] WantedBy=sleep.target ################################################################### Though this was not always reliable, but somewhere around kernel 4.6.5 suspend behaviour became rock solid. Then 4.6.6 and 4.6.7 came along and completely broke everything and unloading brcmfmac did not help. This was the point at which I started to query the issue on the MBP 11,4 thread https://bugzilla.kernel.org/show_bug.cgi?id=103211. Yesterday I just got a firmware upgrade and now everything is rock solid again. (Not sure which one is relevant.) linux-firmware-20160609-66.gita4bbc811 -> 20160816-67.git7c3dfc0b iwl100-firmware-39.31.5.1-66 -> 39.31.5.1-67 iwl105-firmware-18.168.6.1-66 -> 18.168.6.1-67 iwl135-firmware-18.168.6.1-66 -> 18.168.6.1-67 iwl2000-firmware-18.168.6.1-66 -> 18.168.6.1-67 iwl2030-firmware-18.168.6.1-66 -> 18.168.6.1-67 iwl3945-firmware-15.32.2.9-66 -> 15.32.2.9-67 iwl4965-firmware-228.61.2.24-66 -> 228.61.2.24-67 iwl5000-firmware-8.83.5.1_1-66 -> 8.83.5.1_1-67 iwl5150-firmware-8.24.2.2-66 -> 8.24.2.2-67 iwl6000-firmware-9.221.4.1-66 -> 9.221.4.1-67 iwl6000g2a-firmware-18.168.6.1-66 -> 18.168.6.1-67 iwl6000g2b-firmware-18.168.6.1-66 -> 18.168.6.1-67 iwl6050-firmware-41.28.5.1-66 -> 41.28.5.1-67 iwl1000-firmware-1:39.31.5.1-66 -> 1:39.31.5.1-67 iwl3160-firmware-1:25.30.13.0-66 -> 1:25.30.13.0-67 iwl7260-firmware-1:25.30.13.0-66 -> 1:25.30.13.0-67 Wondering if this is related to the IOMMU issues in https://bugzilla.kernel.org/show_bug.cgi?id=111781 that were resolved at kernel 4.6.6.