Re: vt_suspend / vt_resume
On 09.10.2014 17:09, Andriy Gapon wrote: > I looked at the vt code and I was not able to figure out what would be the > proper place there. > Initially I thought that vt_allocate() would be it, but then it seems that > vt_allocate() might not be called. So, perhaps vtterm_cnprobe() ? Something > else? What about vt_upgrade()? It's called later in the boot process: /* Delay until all devices attached, to not waste time. */ SYSINIT(vt_early_cons, SI_SUB_INT_CONFIG_HOOKS, SI_ORDER_ANY, vt_upgrade, &vt_consdev); However, it's called from vt_allocate() too, so you would need a flag in struct vd_device->vd_flags to record the fact the handlers are registered. The core handlers would then call backend-specific handlers, if the backend provides them. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: vt_suspend / vt_resume
On 03/10/2014 18:21, Nathan Whitehorn wrote: > > On 10/03/14 08:13, Andriy Gapon wrote: >> 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. I looked at the vt code and I was not able to figure out what would be the proper place there. Initially I thought that vt_allocate() would be it, but then it seems that vt_allocate() might not be called. So, perhaps vtterm_cnprobe() ? Something else? Thanks! -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vt_suspend / vt_resume
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 1msec drmn0: warning: GPU lockup (waiting for 0x00269544 last fence id 0x00269523) 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: 0x0003 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-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vt_suspend / vt_resume
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 1msec drmn0: warning: GPU lockup (waiting for 0x00269544 last fence id 0x00269523) 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: 0x0003 The patch (I am not sure if fbd_attach is the right place to register the event handlers): 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 } }; -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
vt_suspend / vt_resume
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? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"