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

Re: [Xen-devel] xenbus and the message of doom



On Tue, Dec 20, Ian Campbell wrote:

> What's wrong with only doing this reset if we know we are kexec'd? If
> that can't be automatically detected then e.g. using an explicit
> reset_watches command line option. You could even make a tenuous
> argument for hanging this off reset_devices?

The kexec kernel does not know that it was loaded via kexec.
We could make the reset_devices option mandatory for kexec in PVonHVM
guests, so the change to drivers/xen/xenbus/xenbus_xs.c would be very
small, like "if (hvm && reset_devices) xs_reset_watches();"

> > Perhaps we should figure out what exactly EC2 is using as host and why
> > it only breaks with upstream kernels.
> 
> and in the meantime we leave upstream (and any distros which picks up a
> new enough kernel) on EC2? I think at this stage in the rc cycle we'd be
> better off reverting and trying again for 3.3.

If EC2 is unable to fix it in time (or provide info what exactly they
use), I'm ok with reverting/disabling the call to xs_reset_watches().
I can continue to work on this next year.

Olaf

_______________________________________________
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®.