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 <i...@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-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: > http://lists.debian.org/1359367066.6559.23.ca...@zakaz.uk.xensource.com > -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130129115449.GA2416@idun
