From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Stefan Bader <stefan.bader@canonical.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: xenbus and the message of doom
Date: Tue, 20 Dec 2011 14:15:33 +0100 [thread overview]
Message-ID: <20111220131533.GA7800@aepfle.de> (raw)
In-Reply-To: <1324375910.23729.31.camel@zakaz.uk.xensource.com>
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
next prev parent reply other threads:[~2011-12-20 13:15 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-15 19:20 xenbus and the message of doom Stefan Bader
2011-12-15 19:39 ` Konrad Rzeszutek Wilk
2011-12-15 19:45 ` Stefan Bader
2011-12-16 11:33 ` Olaf Hering
2011-12-16 15:25 ` Konrad Rzeszutek Wilk
2012-01-02 9:32 ` Stefan Bader
2011-12-20 10:11 ` Ian Campbell
2011-12-20 13:15 ` Olaf Hering [this message]
2011-12-20 14:16 ` Konrad Rzeszutek Wilk
2011-12-20 17:29 ` Ian Jackson
2011-12-20 20:19 ` Ian Campbell
2012-01-02 17:16 ` Olaf Hering
2012-01-03 11:01 ` Ian Campbell
2012-01-04 15:57 ` Olaf Hering
2012-01-04 16:22 ` Ian Campbell
2012-01-04 16:27 ` Olaf Hering
2012-01-05 9:26 ` Ian Campbell
2012-01-05 18:43 ` Olaf Hering
2012-01-02 9:29 ` Stefan Bader
2011-12-15 20:53 ` Ian Campbell
2011-12-16 9:18 ` Stefan Bader
2011-12-16 9:31 ` Ian Campbell
2011-12-16 17:01 ` Olaf Hering
2011-12-16 21:26 ` Alessandro Salvatori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111220131533.GA7800@aepfle.de \
--to=olaf@aepfle.de \
--cc=Ian.Campbell@citrix.com \
--cc=konrad.wilk@oracle.com \
--cc=konrad@darnok.org \
--cc=stefan.bader@canonical.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.