On Friday, July 10, 2015 04:48:28 PM Eric McCorkle wrote: > Complete dmesg trace attached > > Correction: it looks like it tries to save the state after the power's > been turned off. > > Possibly related: the SD card reader started failing to come back up at > the same patch.
Note that while vga0 is later in the suspend, it is actually more of a dummy device on isa0. I think it is sc/vt that actually save/restore the frame buffer. Still, can you add a debug printf in bus_generic_suspend_child() in sys/kern/subr_bus.c to note when DEVICE_SUSPEND() is called for each device (something like 'device_printf(child, "calling device_suspend()\n");' above DEVICE_SUSPEND())? You can also try setting hw.pci.do_power_suspend=0 as a workaround. If that fixes it, then I think it lends credence to your suggestion. Hmm, certainly in the syscons case this is probably just exposing a old bug in that sc0 is hung off of isa0 which is not going to be in the same part of the hierarchy as the "real" VGA device. Usually isa0 is off of isab0 which is often the "last" device on pci0, so normally syscons will suspend after the VGA device is powered down. I think vt(4) should in theory do this better, though it might only do so if you have a drm driver loaded. When drm is loaded and there is a drm-specific vt(4) backend, then it will be suspended as part of the tree under the real VGA device. -- John Baldwin _______________________________________________ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"