[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-bugs
Subject:    Re: Macbook Air7,2 (Early 2015) doesn't suspend on lid close
From:       Mike Larkin <mlarkin () azathoth ! net>
Date:       2016-09-20 21:31:08
Message-ID: 20160920213108.GD82050 () azathoth ! net
[Download RAW message or body]

On Tue, Sep 20, 2016 at 08:40:21PM +0200, Joerg Jung wrote:
> On Sat, Sep 17, 2016 at 11:22:54PM -0700, Mike Larkin wrote:
> > On Sun, Sep 18, 2016 at 09:33:12AM +0530, Sunil Nimmagadda wrote:
> > > On Sat, Sep 17, 2016 at 05:27:16PM -0700, Mike Larkin wrote:
> > > > On Sat, Sep 17, 2016 at 10:10:32PM +0530, Sunil Nimmagadda wrote:
> > > > > Synopsis: Macbook Air7,2 (Early 2015) doesn't suspend on lid close
> > > > > Category: kernel/acpi
> > > > > Environment:
> > > > > 	System      : OpenBSD 6.0
> > > > > 	Details     : OpenBSD 6.0-current (GENERIC.MP) #2461: Fri Sep 16 20:27:42 MDT 2016
> > > > > 			 deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > > > > 
> > > > > 	Architecture: OpenBSD.amd64
> > > > > 	Machine     : amd64
> > > > > Description:
> > > > > 	Macbook Air7,2 fails to suspend on lid close. The screen, keyboard
> > > > > 	backlight and led on urtwn0 are still on after closing the lid.
> > > > > 
> > > > > 	Also, kernel intermittently freezes at this line while booting...
> > > > > 	acpiec0 at acpi0 
> > > > > 
> > > > > 	May be related, wsconsctl display.brightness=60 freezes and top shows...
> > > > > 	6877 root 10 0 272K 220K idle acpilk 0:00% wsconsctl
> > > > > 
> > > > 
> > > > Does regular 'zzz' work?
> > > > 
> > > > -ml
> > > 
> > > Hi,
> > > 
> > > No, zzz/ZZZ doesn't work.
> > > 
> > 
> > Did it work before?
> 
> I own the same device, and I AFAIR it was never working. 
> 
> ...and yes this might be related to wsconsctl and brightness via
> inteldrm.
>  
> > (this conversation is like pulling teeth or playing 20 questions).
> 
> I'm sorry.
> 
> Any news on this? Did Sunil replied in private or something?
> 
> I'm willing to help and test things, so if you guys come up with
> something, e.g. a patch/diff, whatever, or if you need some more
> info/dumps let me know, please. I also own some other MacBook (Air)
> models where I can test things.
> 
> Thanks,
> Regards,
> Joerg (jung@)

No reply, unless I accidentally missed it (which is entirely possible).

zzz and ZZZ and closing the lid work by queueing a sleep task via
acpi_addtask. Regardless of which method you used, you'll end up in
acpi_sleep_task.

From there, we end up in acpi_sleep_state which does the following:

1. sanity checks - does the machine support the Sx state you are requesting?
(S3 in the case of zzz or lidsuspend, S4 in the case of ZZZ).

2. enable the SST_WAKING indicator if the machine has one (eg, start the blinking
moon LED on a thinkpad, or pulse the power LED on some other machines)

3. turns off the screen via wsdisplay_suspend

4. if S4 (ZZZ), flush the buffercache

5. quiesce all devices by walking the device tree, calling the device's
activate method with a QUIESCE parameter. This is done with interrupts still
enabled, to allow certain devices to "pre-suspend" any state they need.

6. stop any I/Os in flight (bufq_quiesce)

7. stop/park any APs (multiprocessor machines)

8. disable interrupts

9. suspend all devices (similar to step 5). Devices are expected to copy their
hardware state somewhere "safe" (like their softc)

10. call ACPI _PTS

11. enable the SST_SLEEPING indicator (eg, the solid moon LED on a thinkpad)

12. call ACPI _GTS

13. clear existing ACPI event status (eg, whack the state of the power button
status)

14. enable wakeup for devices that are listed as "wakeup capable" for the 
selected Sx mode

15. go to sleep


In debugging failure to suspend issues (the above sequence covers only up
to suspend, not resume), read through that and match up the code in acpi.c
where you think your machine is having problems.

Start putting printfs or other debugger output in various places, this is
usually possible until somewhat late in the sequence. You may need to
disable the wsdisplay_suspend call temporarily (to see any printfs you add),
but this can have adverse effects on various machines if suspending from
console or from X and may cause hangs later in the sequence that wouldn't
have otherwise been there, or failures to resume video properly. YMMV.

Once you've identified the step or steps causing problems, come back and
let us know, and we can dig further. This is about all I can suggest without
having access to the hardware.

-ml

[prev in list] [next in list] [prev in thread] [next in thread]