> On Aug 30, 2015, at 23:13, Andriy Gapon <a...@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
> 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
> 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).
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"