WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: BUG: unable to handle kernel paging request at ffff8

To: "rush" <rush1503@xxxxxxxxx>, "Konrad Rzeszutek Wilk" <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: BUG: unable to handle kernel paging request at ffff8803bb6ad000
From: "Jan Beulich" <JBeulich@xxxxxxxx>
Date: Tue, 11 Oct 2011 08:07:16 +0100
Cc: Jonathan Nieder <jrnieder@xxxxxxxxx>, 642154@xxxxxxxxxxxxxxx, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ben Hutchings <ben@xxxxxxxxxxxxxxx>, Ian Campbell <ijc@xxxxxxxxxxxxxx>
Delivery-date: Tue, 11 Oct 2011 00:08:12 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20111010164920.GA30351@xxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1316524835.4122.8.camel@deadeye> <1316526058.3891.65.camel@xxxxxxxxxxxxxxxxxxxxxx> <20110922190018.GA16678@xxxxxxxxxxxxxxxxx> <20111001025030.GA5198@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <CA+rvmvLkBVseDCKyfbd_mGSCrRUvov5Km_2Uoo6CZPZOG7ybvA@xxxxxxxxxxxxxx> <1317460798.11991.2.camel@xxxxxxxxxxxxxxxxxxxx> <CA+rvmv+yU0=nEuvLSqkE44RFqeaQw504MkD-sxjXV3D3nkme_g@xxxxxxxxxxxxxx> <20111003184722.GB15608@xxxxxxxxxxxxxxxxx> <1317667984.11991.6.camel@xxxxxxxxxxxxxxxxxxxx> <CA+rvmvJ_i4Ta+GV5PQ0U7+2yPxT2oJXtnE_fq0j8Faa7GcUxqw@xxxxxxxxxxxxxx> <20111010164920.GA30351@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 10.10.11 at 18:49, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
> On Sat, Oct 08, 2011 at 10:13:14AM +0400, rush wrote:
>> OK, I tried it again, but Oops didn't gone.
> .. snip..
>>         echo    'Loading Xen 4.0-amd64 ...'
>>         multiboot       /boot/xen-4.0-amd64.gz placeholder xsave=0
> .. snip..
>> Was it right?
> 
> Yup. I think.. this is a bit embarrassing. It took a bit of time for Intel
> folks to get the xsave part right and I remember seeing this error about a
> year ago with xsave on a Dell Optiplex 780. Hence I wonder if the fixes that
> ultimately went in 4.1.1 did not get ported over to 4.0 and you are just
> hitting that.
> 
> Can I ask you to do one more thing? Can you upgrade to the xen-4.1.1 in
> the testing and try with the xsave (or without) and see if it works?
> 
> <holds his fingers hoping it is the xsave feature>

Are both of you certain this isn't the problem of the kernel only
looking at the xsaveopt feature flag (implying that this means
xsave is also available)? I found it necessary to force-clear that
flag in the kernel when OSXSAVE is not set (by calling
x86_xsave_setup() when !cpu_has_xsave, which in turn was
modified to look at X86_FEATURE_OSXSAVE rather than
X86_FEATURE_XSAVE under Xen - all of which I'm afraid would
need to be done differently in pv-ops).

If it is, the problem could be worked around by *en*abling xsave
in Xen (which is off by default prior to 4.2), assuming none of the
incomplete functionality would cause other headaches.

But yes, the CPUID handling code in 4.1.1 should properly hide
XSAVEOPT when XSAVE is disabled, so just using this version
ought to also get things going.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel