Re: acpi suspend debugging techniques?

hi,

Try disabling hardware one at a time. Ie, unload usb; unload wifi;
leave kms loaded for mostly obvious reasons.

I hit a few of these which turned out to be an issue in the suspend
path of a driver - and once I found it was the USB hardware but the
BIOS itself that was hanging - FreeBSD put USB hardware into S3, but
the ACPI BIOS requested S2 and just hung if we had USB in S3. :(



-adrian


On 30 August 2015 at 23:33, Garrett Cooper <yaneurabeya_at_gmail.com> wrote:
>
>> On Aug 30, 2015, at 23:13, Andriy Gapon <avg_at_FreeBSD.org> wrote:
>>
>>
>> I would appreciate any pointers at how to debug an ACPI suspend problem that I have.
>>
>> What I have so far.  The system hangs when I try to suspend it and it gets reset
>> by a watchdog.  Setting debug.acpi.suspend_bounce=1 does not make any
>> difference, so the hang happens before the final sleep code is executed.  I
>> think that the device suspend stage is executed, because disks get spun down and
>> video signals gets cut off.
>>
>> I could enable / add some debug printfs, but I suppose that their output would
>> get lost due to the above.  RAM content unfortunately does not survive across
>> the resets.
>
> When I last had to do this to figure out what magic formula was required to get my netbook working, I did something like this:
>
> 1. Stripped down the kernel to just the storage driver and core pieces.
> 2. Loaded all other modules after boot, if necessary.
> 3. Called zzz with the appropriate ACPI tunables/sysctls set.
>
> That got me pointed in the right direction (IIRC it was psm at the time). What I did to get a real smoking gun was I put printf statements in subr_bus.c (IIRC) to track device quiescing at suspend and reawakening at resume.
>
> There’s `options BUS_DEBUG` too, which may or may not help.
>
> FWIW I found debug.acpi.suspend_bounce less useful, but it still exercised the quiesce->reawaken cycle, sorta.
>
> There’s also `hw.acpi.reset_video` and `debug.acpi.resume_beep`.
>
> You might need to hack /etc/rc.resume and /etc/rc.suspend, BTW, depending on what you discover (switching my vty was definitely required in order for X11 to come back in a sane manner at resume).
>
> Cheers,
> -NGie
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"