Date: Fri, 03 Oct 2014 08:21:21 -0700 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: freebsd-current@freebsd.org Subject: Re: vt_suspend / vt_resume Message-ID: <542EBEF1.1080200@freebsd.org> In-Reply-To: <542EBD1F.2060604@FreeBSD.org> References: <542A43E1.5010401@FreeBSD.org> <542EBD1F.2060604@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/03/14 08:13, Andriy Gapon wrote:
> On 30/09/2014 08:47, Andriy Gapon wrote:
>> I think that currently vt_suspend / vt_resume are called at quite unsuitable
>> times. For example, vt_suspend performs a vt switch which requires cooperation
>> from an X server, but that could be problematic given that some devices may
>> already be suspended.
>> I believe that it is better to do what sc(4) does and use power_suspend /
>> power_resume event handlers instead of device_suspend / device_resume methods.
>> power_suspend event is posted when a kernel has not entered any special state yet.
>>
>> What do you think?
>>
>
> So, I am now using the following patch and suspend/resume works 100% reliable
> for me, whereas previously there was a quite significant chance that the video
> subsystem would be in a very confused state after resuming.
>
> For example there could be an endless stream of error message and the screen
> would be frozen:
> drmn0: error: couldn't schedule ib
> error: [drm:pid1492:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB !
>
> Or there could be an endless GPU reset loop in the radeon driver:
> drmn0: error: GPU lockup CP stall for more than 10000msec
> drmn0: warning: GPU lockup (waiting for 0x0000000000269544 last fence id
> 0x0000000000269523)
> error: [drm:pid1492:r600_ib_test] *ERROR* radeon: fence wait failed (-11).
> error: [drm:pid1492:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on
> GFX ring (-11).
> drmn0: error: ib ring test failed (-11).
> drmn0: info: GPU softreset: 0x00000003
>
> The patch (I am not sure if fbd_attach is the right place to register the event
> handlers):
It's not, I don't think, since fbd_attach() isn't called for all vt
backends (e.g. the VGA and EFI backends don't call it). vt_fb_suspend()
also only calls vt_suspend(), so it's probably best to put this in the
core vt code.
-Nathan
> diff --git a/sys/dev/fb/fbd.c b/sys/dev/fb/fbd.c
> index ff2488d..923292a 100644
> --- a/sys/dev/fb/fbd.c
> +++ b/sys/dev/fb/fbd.c
> @@ -316,6 +316,11 @@ fbd_attach(device_t dev)
> return (ENXIO);
> err = fbd_register(sc->sc_info);
>
> + EVENTHANDLER_REGISTER(power_suspend, vt_fb_suspend, NULL,
> + EVENTHANDLER_PRI_ANY);
> + EVENTHANDLER_REGISTER(power_resume, vt_fb_resume, NULL,
> + EVENTHANDLER_PRI_ANY);
> +
> return (err);
> }
>
> @@ -332,22 +337,6 @@ fbd_detach(device_t dev)
> return (err);
> }
>
> -static int
> -fbd_suspend(device_t dev)
> -{
> -
> - vt_fb_suspend();
> - return (bus_generic_suspend(dev));
> -}
> -
> -static int
> -fbd_resume(device_t dev)
> -{
> -
> - vt_fb_resume();
> - return (bus_generic_resume(dev));
> -}
> -
> static device_method_t fbd_methods[] = {
> /* Device interface */
> DEVMETHOD(device_probe, fbd_probe),
> @@ -355,8 +344,6 @@ static device_method_t fbd_methods[] = {
> DEVMETHOD(device_detach, fbd_detach),
>
> DEVMETHOD(device_shutdown, bus_generic_shutdown),
> - DEVMETHOD(device_suspend, fbd_suspend),
> - DEVMETHOD(device_resume, fbd_resume),
>
> { 0, 0 }
> };
>
>
>
>
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?542EBEF1.1080200>