This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [SPAM] Re: kernel BUG at arch/x86/xen/mmu.c:1860!

> Both only apply to 2.6.32 when running under eitehr xen4.0.1 or 4.1.

OK, so Xen hypervisor is not at fault here.
> On its own the kernel works fine.
> Kernel 2.6.38 ran fine on both hypervisors as well as on its own.

> One other issue occured that i didnt expect:
> With the same .config (make oldconfig), 2.6.38 left my screen black
> after loading the kernel, on both hypervisors.

Um, that is surprising. If you have a radeon VGA driver, what happens
if you do 'radeon.modeset=0'?

> The servers worked just fine, i just didnt see any output on their
> VGA ports.
> I hope this information helps you to hunt this bug down as it
> effectively makes the "default" Xen unusable in server situations
> where the device mapper is involved.
> It is puzzling to me why noone did notice it last year, am i the
> only one running xen on server hardware (Dell R610, 710 and 2950)
> with centralized storage (FibreChannel or iSCSI) and using it as
> environment for production.
> Is multipathing two links to a centralized storage and using LVM2 to
> split it up for virtual machines running on two or more servers
> really such a rare thing to find Xen running on?

It is for kernel engineers. That equipment isn't cheap.

It is very difficult for us to fix bugs we don't see on our equipment.
> Btw, who is currently working on the remus implementation?

Frank Pan <frankpzh@xxxxxxxxx>
> If you should need any more testing from me, feel free to ask.

> Best regards.
> -- 
> Andreas Olsowski

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>