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: >=20 >=20 > I would appreciate any pointers at how to debug an ACPI suspend = problem that I have. >=20 > 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=3D1 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. >=20 > 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=E2=80=99s `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=E2=80=99s 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>