Bug#642154: [Xen-devel] Re: BUG: unable to handle kernel paging request at ffff8803bb6ad000
On 10.10.11 at 18:49, Konrad Rzeszutek Wilk konrad.w...@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). 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642154: [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.w...@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-de...@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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642154: [Xen-devel] Re: BUG: unable to handle kernel paging request at ffff8803bb6ad000
On 11.10.11 at 10:02, Ian Campbell i...@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.w...@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-de...@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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642154: [Xen-devel] Re: BUG: unable to handle kernel paging request at ffff8803bb6ad000
On Tue, 2011-10-11 at 09:36 +0100, Jan Beulich wrote: On 11.10.11 at 10:02, Ian Campbell i...@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.w...@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. 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. 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-de...@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 ___ Xen-devel mailing list xen-de...@lists.xensource.com http://lists.xensource.com/xen-devel -- Ian Campbell Current Noise: Zyklon - Transcendental War - Battle Between Gods If you tell the truth you don't have to remember anything. -- Mark Twain -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642154: [Xen-devel] Re: BUG: unable to handle kernel paging request at ffff8803bb6ad000
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642154: [Xen-devel] Re: BUG: unable to handle kernel paging request at ffff8803bb6ad000
2011/10/10, Konrad Rzeszutek Wilk konrad.w...@oracle.com: 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? Ok, but I need around a week for it. (some difficulties with access to this server at the moment). holds his fingers hoping it is the xsave feature Thank you (: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
