[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] BUG: unable to handle kernel paging request at ffff8803bb6ad000
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<ijc@xxxxxxxxxxxxxx> 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@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.
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
