Bug#660425: Possible bugg in linux-image-3.2.0-0.bpo.4-amd64 (resent)
Hi!
I have rebooted the server, dom0 is now running the 3.2.35-2 image
from backports, with the "nosmap" command line option as suggested.
Previous oopses occurred after some time, a few days or so, so I'll watch and
see what happens.
Thanks for taking the time.
BR
// Mattias
Den 28 January 2013, 09:57, skrev Ian Campbell <ijc@hellion.org.uk>:
> Thanks Ben, not sure how I missed 660425 the first time around.
>
> On Wed, 2013-01-23 at 14:50 +0000, Ben Hutchings wrote:
> > On Tue, 2013-01-22 at 10:15 +0100, Mattias Eriksson wrote:
> > > Hi!
> > >
> > > I have switched back to the current stable kernel in squeeze, 2.6.32-46, since I need the
> > > machine to be up and running. And now it is just as stable as it was before.
> > >
> > > Even though I have never had any real issues using xen and VIA nano (64bit), the
> > > CPU is officially not supported by xen, as far as I can see:
> > >
> > > (XEN) Domain heap initialised
> > > (XEN) CPU: Vendor unknown, using generic init.
> > > (XEN) CPU: Your system may be unstable.
> > > (XEN) Processor #0 6:15 APIC version 20
> > >
> > > So, I think there are to many "uncertainties" for me to dig into this further.
> > [...]
> >
> > Yes, there may be quirks and bugs in VIA/Centaur processors that Xen
> > should handle (which I couldn't find any documentation about).
>
> There was a bit of work done to support VIA stuff in, I think, the 4.2
> release.
>
> I think it is probably not relevant to this specific EFLAGS.AC issue,
> although it may cause other problems of course.
>
> > However: <http://bugs.debian.org/660425> is a report of an alignment check
> > under Xen while running Linux 2.6.32, and Jonathan Nieder found (message
> > #17) more reports of this - on Intel and AMD processors. In all these
> > cases (and yours) the AC flag is shown as enabled, so alignment checks
> > should be expected.
> >
> > The connection to Xen is this: the AC flag can be set by any program,
> > but the processor ignores it when running code at the maximum privilege
> > level. So normally the kernel is not affected, but under Xen it is
> > running at lower privilege and therefore it is affected. Xen has to
> > clear the AC flag whenever it switches from user mode to a (PV) guest
> > kernel.
>
> A bug of this type was fixed in the 4.0.0-rc9 timeframe, but that is
> before the version of Xen being used here.
>
> It's interesting that the kernel version appears to be a relevant
> factor, but I expect it is simply exposing a hypervisor bug.
>
> It seems that the new SMAP (Supervisor Mode Access Prevention) CPU
> feature reuses the EFLAGS.AC bit, that might explain why we are seeing
> this bit set in kernel mode with newer kernels. However it looks like
> this was added in 3.7 and I can't see it backported in either the
> kernel.org 3.2.y stable kernels or Debian's patch queue. SMEP is in 3.2
> but I don't think that involves EFLAGS.AC.
>
> It would be great if you could try the 3.2.0 kernel again with the
> "nosmap" kernel option though.
>
> > I don't think the guest kernel itself needs to be aware of this
> > because there is never a direct transition from user mode to kernel
> > mode.
>
> Agreed, with a 64-bit PV kernel you always have to pass through the
> hypervisor when transitioning from user to supervisor mode (which both
> run in Ring 3 under Xen)
>
> Ian.
> --
> Ian Campbell
> Current Noise: Isis - Threshold Of Transformation
>
> Be incomprehensible. If they can't understand, they can't disagree.
>
>
> --
> To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 1359367066.6559.23.camel@zakaz.uk.xensource.com">http://lists.debian.org/[🔎] 1359367066.6559.23.camel@zakaz.uk.xensource.com
>
Reply to: