Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 30 Aug 2015 23:33:10 -0700
From:      Garrett Cooper <yaneurabeya@gmail.com>
To:        Andriy Gapon <avg@FreeBSD.org>
Cc:        FreeBSD Current <freebsd-current@FreeBSD.org>, "freebsd-acpi@freebsd.org" <freebsd-acpi@FreeBSD.org>
Subject:   Re: acpi suspend debugging techniques?
Message-ID:  <F685F242-21A2-4063-B5A6-75EA17EFCFC0@gmail.com>
In-Reply-To: <55E3F098.9060806@FreeBSD.org>
References:  <55E3F098.9060806@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help


> On Aug 30, 2015, at 23:13, Andriy Gapon <avg@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


Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F685F242-21A2-4063-B5A6-75EA17EFCFC0>