From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Olivier B." Subject: Re: BUG: unable to handle kernel paging request at ffff8803bb6ad000 Date: Tue, 06 Mar 2012 21:22:45 +0100 Message-ID: <4F567215.5070705@daevel.fr> References: <1316524835.4122.8.camel@deadeye> <1316526058.3891.65.camel@zakaz.uk.xensource.com> <20110922190018.GA16678@phenom.oracle.com> <20111001025030.GA5198@elie.sbx02827.chicail.wayport.net> <1317460798.11991.2.camel@dagon.hellion.org.uk> <20111003184722.GB15608@phenom.oracle.com> <1317667984.11991.6.camel@dagon.hellion.org.uk> <20111010164920.GA30351@phenom.oracle.com> <4E940744020000780005A9F9@nat28.tlf.novell.com> <1318320174.21903.485.camel@zakaz.uk.xensource.com> <4E941C48020000780005AA80@nat28.tlf.novell.com> <1318322620.21903.507.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1318322620.21903.507.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 11/10/2011 10:43, Ian Campbell wrote: > On Tue, 2011-10-11 at 09:36 +0100, Jan Beulich wrote: >>>>> On 11.10.11 at 10:02, Ian Campbell wrote: >>> On Tue, 2011-10-11 at 08:07 +0100, Jan Beulich wrote: >>>>>>> On 10.10.11 at 18:49, Konrad Rzeszutek Wilk 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? >>>>> >>>>> >>>> >>>> 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). >>> >>> That all sounds familiar... In mainline we have (in >>> xen_init_cpuid_mask): >>> >>> ... >>> xsave_mask = >>> (1<< (X86_FEATURE_XSAVE % 32)) | >>> (1<< (X86_FEATURE_OSXSAVE % 32)); >>> >>> /* Xen will set CR4.OSXSAVE if supported and not disabled by force >>> */ >>> if ((cx& xsave_mask) != xsave_mask) >>> cpuid_leaf1_ecx_mask&= ~xsave_mask; /* disable XSAVE& >>> OSXSAVE */ >>> >>> Which I think implements something similar to what you describe? IOW >>> unless both XSAVE and OSXSAVE are available both are forcibly disabled. >> >> Apart from the need to disable XSAVEOPT, yes. > > Oh, right, I hadn't noticed it was a different/third flag. > >>> While grepping I noticed that the kernel command line parameter to >>> disable xsave appears to be "noxsave" rather than "xsave=0", Rush is >>> that something you could try? (GRUB_CMDLINE_LINUX is the place to add >>> it) >> >> Or "noxsaveopt" (if that's the problem, i.e. Rush's CPUs have that >> capability). > > Right, Rush can you try both "noxsave" and "noxsaveopt" independently > please. If those work then we need to update the above logic to mask > xsaveopt as well. > > Thanks, > Ian. > For the record, same problem here with Xen 4.0 and an Intel Xeon CPU E31220 with "microcode 0x14". (and the problem doesn't exists with a CPU E31220 without that microcode). The xen parameter "noxsaveopt" solved it. Olivier