Date: Sat, 30 Aug 2014 13:58:20 -0400 From: John Baldwin <jhb@freebsd.org> To: src-committers@freebsd.org Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r270850 - in head/sys: i386/i386 i386/include i386/isa x86/acpica Message-ID: <58768837.sIF65g1iXL@ralph.baldwin.cx> In-Reply-To: <201408301748.s7UHmc6H059701@svn.freebsd.org> References: <201408301748.s7UHmc6H059701@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?58768837.sIF65g1iXL>