svn commit: r270850 - in head/sys: i386/i386 i386/include i386/isa x86/acpica

[Adrian Chadd]

On 30 August 2014 10:58, John Baldwin <jhb at 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