FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 10-03-2011, 06:53 PM
Ian Campbell
 
Default Bug#642154: BUG: unable to handle kernel paging request at ffff8803bb6ad000

On Mon, 2011-10-03 at 14:47 -0400, Konrad Rzeszutek Wilk wrote:
> > echo 'Loading Xen 4.0-amd64 ...'
> > multiboot /boot/xen-4.0-amd64.gz placeholder
>
> Oops. I meant to try it in the hypervisor - so right after placeholder add "xsave=0"

Which in grub2 means add GRUB_CMDLINE_XEN="xsave=0" to /etc/default/grub
(there is no commented out example in this case) and re-run update-grub.

Ian.

--
Ian Campbell


Many a bum show has been saved by the flag.
-- George M. Cohan
 
Old 10-10-2011, 04:49 PM
Konrad Rzeszutek Wilk
 
Default Bug#642154: 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-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111010164920.GA30351@phenom.oracle.com">http://lists.debian.org/20111010164920.GA30351@phenom.oracle.com
 
Old 10-10-2011, 09:11 PM
rush
 
Default Bug#642154: BUG: unable to handle kernel paging request at ffff8803bb6ad000

2011/10/10, Konrad Rzeszutek Wilk <konrad.wilk@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-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CA+rvmvJhxnqA_L5OXw8P_Vuqjq0ps-0Ux7nELEhoSCO_MuguRA@mail.gmail.com">http://lists.debian.org/CA+rvmvJhxnqA_L5OXw8P_Vuqjq0ps-0Ux7nELEhoSCO_MuguRA@mail.gmail.com
 
Old 10-11-2011, 07:07 AM
"Jan Beulich"
 
Default Bug#642154: BUG: unable to handle kernel paging request at ffff8803bb6ad000

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

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-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4E940744020000780005A9F9@nat28.tlf.novell.com">htt p://lists.debian.org/4E940744020000780005A9F9@nat28.tlf.novell.com
 

Thread Tools




All times are GMT. The time now is 12:50 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org