Attempting to diagnose suspend/resume issue

[John Baldwin]

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