From owner-svn-src-all@FreeBSD.ORG Sat Aug 30 19:22:21 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4D93821; Sat, 30 Aug 2014 19:22:21 +0000 (UTC) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 62D981ED9; Sat, 30 Aug 2014 19:22:21 +0000 (UTC) Received: by mail-qg0-f51.google.com with SMTP id i50so3722423qgf.10 for ; Sat, 30 Aug 2014 12:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=YNstv4RmJe8RoBC2QcB21tAMgMwPgUPEV+7SIgQFl7Y=; b=oXx6rZ3RiCr1RR0/fe9yvBLWzgSVgkUAraZFa3JOwk3s6BoYdr7SZwNv0B1LAXQG3S 0cZLCzoUpRhtzp45Au6pKv+EMHbF/LgNLA5R7nbILW2DRYoXajkEjZojj+T5ciL9gMes ZfyFJIe9syOxAjMLsHLfTwfAidmPY+niGbDc3xjLkWPkWz7EI2zL+GoA4RS5BS5JAHOR q+SS0cRa2pskyAznhhr/y8Kg9F0f1XNHWL8gnc9jj1iF4qlRL/JG1FZKWgLdX9bRV+0s yJzL/rWja8X7WWtEjfhjb3RaWFLsI1Y6QK4KfjrawelKpDQBDuJ5nPJ9jvlC/qJ39A5q Xdyg== MIME-Version: 1.0 X-Received: by 10.224.75.73 with SMTP id x9mr30432729qaj.63.1409426540456; Sat, 30 Aug 2014 12:22:20 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Sat, 30 Aug 2014 12:22:20 -0700 (PDT) In-Reply-To: <58768837.sIF65g1iXL@ralph.baldwin.cx> References: <201408301748.s7UHmc6H059701@svn.freebsd.org> <58768837.sIF65g1iXL@ralph.baldwin.cx> Date: Sat, 30 Aug 2014 12:22:20 -0700 X-Google-Sender-Auth: sT1KcNz4UvCuaiwoUDKrthwRyyw Message-ID: Subject: Re: svn commit: r270850 - in head/sys: i386/i386 i386/include i386/isa x86/acpica From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 19:22:22 -0000 On 30 August 2014 10:58, John Baldwin 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