[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

Great!
> 
> 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.

Ok.
> 
> Best regards.
> 
> 
> -- 
> Andreas Olsowski
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.