port-i386/44581: MacBook1,1 won't resume after suspend

[Taylor R Campbell <campbell+netbsd%mumble.net@localhost>]

>Number:         44581
>Category:       port-i386
>Synopsis:       MacBook1,1 won't resume after suspend
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-i386-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 15 21:25:00 +0000 2011
>Originator:     Taylor R Campbell <campbell+netbsd%mumble.net@localhost>
>Release:        NetBSD 5.1
>Organization:
>Environment:
System: NetBSD oberon.local 5.1 NetBSD 5.1 (GENERIC) #0: Sun Nov  7 14:39:56 
UTC 2010  
builds%b6.netbsd.org@localhost:/home/builds/ab/netbsd-5-1-RELEASE/i386/201011061943Z-obj/home/builds/ab/netbsd-5-1-RELEASE/src/sys/arch/i386/compile/GENERIC
 i386
Architecture: i386
Machine: i386
>Description:

        Under 5.1, I observe:

                # sysctl hw.acpi machdep | grep acpi
                hw.acpi.root = 1040416
                hw.acpi.supported_states = S0 S3 S4 S5
                machdep.acpi_vbios_reset = 1
                machdep.acpi_beep_on_reset = 0
                machdep.acpiapm.standby = 1
                machdep.acpiapm.suspend = 3

        Suspending and resuming mainbus0 with

                # drvctl -S mainbus0; sleep 10; drvctl -Q mainbus0

        seems to work.  The disk stops spinning, keyboard input stops
        working, the kernel stops replying to pings, and so on.  Ten
        seconds later, the disk spins up again, the kernel sprays a lot
        of messages to the console about device detachment and
        attachment, keyboard input starts working, the kernel starts
        replying to pings, and so on.

        With machdep.acpi_vbios_reset set to 0, 1, or 2,

                # sysctl -w machdep.sleep_state=3; sleep 60; drvctl -Q mainbus0

        prints a kernel message about acpi entering state 3 and about
        flushing disk caches, and suspends the machine.  Neither
        keyboard nor trackpad input wakes it.  Pressing the power
        button causes the optical and magnetic drives to spin up, but
        the display is still dark and the machine unresponsive: no
        replies to pings, pressing the power button again has no
        effect, &c., until I force a reboot by holding the power button
        down for several seconds.



        Under a current kernel as of a couple days ago, I observe:

                # sysctl hw.acpi
                hw.acpi.root = 1040416
                hw.acpi.sleep.state = 0
                hw.acpi.sleep.states = S0 S3 S4 S5
                hw.acpi.sleep.vbios = 1
                hw.acpi.stat.gpe = 17
                hw.acpi.stat.sci = 17
                hw.acpi.stat.fixed = 17
                hw.acpi.stat.method = 17

        Suspending and resuming mainbus0 with

                # drvctl -S mainbus0; sleep 10; drvctl -Q mainbus0

        sometimes works and sometimes hangs the machine.  If I suspend
        all of the children of mainbus0 (cpu0 cpu1 ioapic0 acpi0 pci0)
        and then resume them, it sometimes works and I sometimes get a
        garbled panic, at which point ddb ignores keyboard input and I
        have to forcibly reboot the machine.

        With hw.acpi.sleep.vbios set to 1,

                # sysctl -w hw.acpi.sleep.state=3; sleep 60; drvctl -Q mainbus0

        behaves as in 5.1.  With hw.acpi.sleep.vbios set to 0 or 2,
        after the machine suspends, the display turns on again to
        reveal a number of messages from the kernel, apparently about
        attaching and then detaching the USB keyboard and trackpad --
        yes, in that order: attaching, and then detaching.  At the end
        is a message about attaching fwohci.  I don't see a shell
        prompt, but it could have been pushed off screen by the kernel
        messages.  Keyboard input has no effect, the kernel does not
        reply to pings, and pushing the power button doesn't seem to do
        anything until, as usual, I hold it down for several seconds to
        forcibly reboot the machine.



        Let me know if you'd like to see full dmesg output.  This
        machine has two CPUs.

>How-To-Repeat:

        Try to suspend and resume a MacBook1,1.  Grumble in frustration
        at the failure.

>Fix:

        Yes, please!