On 30 August 2014 10:58, John Baldwin <j...@freebsd.org> wrote: > On Saturday, August 30, 2014 05:48:38 PM John Baldwin wrote: >> Author: jhb >> Date: Sat Aug 30 17:48:38 2014 >> New Revision: 270850 >> URL: http://svnweb.freebsd.org/changeset/base/270850 >> >> Log: >> Save and restore FPU state across suspend and resume. In earlier >> revisions of this patch, resumectx() called npxresume() directly, but that >> doesn't work because resumectx() runs with a non-standard %cs selector. >> Instead, all of the FPU suspend/resume handling is done in C. > > This mostly fixes suspend and resume in X on a little 32-bit only netbook I > have. I needed an additional patch to the i915 code to prevent it from > tearing down its interrupt handler in suspend and re-establishing it during > resume (this sort of thing is not needed in drivers and isn't safe because > suspend runs pinned to CPU 0 and unregistering an interrupt needs to bind to > the CPU the IDT vector is assigned to). > > --- //depot/vendor/freebsd/src/sys/dev/drm2/i915/i915_drv.c > +++ //depot/user/jhb/acpipci/dev/drm2/i915/i915_drv.c > @@ -253,7 +253,9 @@ > "GEM idle failed, resume might fail\n"); > return (error); > } > +#if 0 > drm_irq_uninstall(dev); > +#endif > } > > i915_save_state(dev); > @@ -315,7 +317,9 @@ > sx_xlock(&dev->mode_config.mutex); > drm_mode_config_reset(dev); > sx_xunlock(&dev->mode_config.mutex); > +#if 0 > drm_irq_install(dev); > +#endif > > sx_xlock(&dev->mode_config.mutex); > /* Resume the modeset for every activated CRTC */ > > Even with that my one attempt at resuming in X so far seemed to hang in X > (though the machine was fine and worked fine aside from X hanging). > > Curiously, this netbook is able to suspend/resume just fine on the console > with syscons(4), but the LCD is not turned back on if I suspend/resume with > vt(4) using the VGA driver. I think vt(4) should do some of the VESA stuff > for suspend/resume syscons does when using vt_vga (but not when using one of > the KMS backends).
Hm, can you file the DRM patch to get reviewed and put into the tree? That's a good catch. As for vt(4) + VESA - yeah, I think we may have to write VESA extensions for vt_vga, or write vt_vga_vesa. It's sorely lacking. :( -a _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"