Date: Tue, 31 Jan 2012 12:10:06 -0500 From: Jung-uk Kim <jkim@FreeBSD.org> To: Gavin Atkinson <gavin@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: r230777 - head/sys/amd64/acpica Message-ID: <201201311210.09506.jkim@FreeBSD.org> In-Reply-To: <1328015602.96718.19.camel@buffy.york.ac.uk> References: <201201301828.q0UISvhb097256@svn.freebsd.org> <1328015602.96718.19.camel@buffy.york.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 31 January 2012 08:13 am, Gavin Atkinson wrote: > On Mon, 2012-01-30 at 18:28 +0000, Jung-uk Kim wrote: > > Author: jkim > > Date: Mon Jan 30 18:28:56 2012 > > New Revision: 230777 > > URL: http://svn.freebsd.org/changeset/base/230777 > > > > Log: > > Naturally align a newly added wakeup_fpusave. > > I hadn't noticed this change when it went in initially. Out of > interest, is the save/restore of the FPU state over suspend/resume > likely to fix the panics some people see over a suspend/resume if > they have run VirtualBox or similar before suspend? I've been > assuming that it was related to some CPU state not being > saved/restored, but never dug into it myself. I am actually not sure but FPU state won't be problem. Probably VirtualBox device drivers don't implement suspend/resume methods. In fact, something broke suspend/resume for my desktop recently but I don't have enough free time to dig into it myself. :-( Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201201311210.09506.jkim>