Bug#642154: 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@oracle.com> 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@lists.xensource.com
> 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"




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1318320174.21903.485.camel@zakaz.uk.xensource.com" >http://lists.debian.org/1318320174.21903.485.camel@zakaz.uk.xensource.com

Bug#642154: BUG: unable to handle kernel paging request at ffff8803bb6ad000
 

>>> On 11.10.11 at 10:02, Ian Campbell <ijc@hellion.org.uk> wrote:
> On Tue, 2011-10-11 at 08:07 +0100, Jan Beulich wrote:
>> >>> On 10.10.11 at 18:49, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 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.

Apart from the need to disable XSAVEOPT, yes.

> 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).

Jan

> 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@lists.xensource.com
>> 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"






--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4E941C48020000780005AA80@nat28.tlf.novell.com">htt p://lists.debian.org/4E941C48020000780005AA80@nat28.tlf.novell.com