[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: BUG: unable to handle kernel paging request at ffff8803bb6ad000
On Tue, 2011-10-11 at 08:07 +0100, Jan Beulich wrote: > >>> 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). 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. 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) Ian. > 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 -- Ian Campbell Current Noise: Zyklon - Hammer Revelation The ultimate game show will be the one where somebody gets killed at the end. -- Chuck Barris, creator of "The Gong Show" _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |