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 <yaneurab...@gmail.com> wrote: > >> 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 >> 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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
