Date: Sat, 30 Aug 2014 12:22:20 -0700 From: Adrian Chadd <adrian@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org> Subject: Re: svn commit: r270850 - in head/sys: i386/i386 i386/include i386/isa x86/acpica Message-ID: <CAJ-Vmo=2Dc=Gmzb0xG0BzhREvM_HjQtFBJKtb4zKhauu946Dvg@mail.gmail.com> In-Reply-To: <58768837.sIF65g1iXL@ralph.baldwin.cx> References: <201408301748.s7UHmc6H059701@svn.freebsd.org> <58768837.sIF65g1iXL@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On 30 August 2014 10:58, John Baldwin <jhb@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=2Dc=Gmzb0xG0BzhREvM_HjQtFBJKtb4zKhauu946Dvg>