Re: [Xen-devel] Regression, host crash with 4.5rc1

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.11.14 at 20:21, <sflist@xxxxxxxxx> wrote:
> Okay, I did a bisection and was not able to correlate the above error 
> message with the problem I'm seeing. Not saying it's not related, but I 
> had plenty of successful test runs in the presence of that error.
> 
> Took me about a week (sometimes it takes as much as 6 hours to produce 
> the error), but bisect narrowed it down to this commit:
> 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=9a727a813e9b25003e433b3d 
> c3fa47e621f9e238
> 
> What do you think?

Thanks for narrowing this, even if this change didn't show any other
bad effects so far (and it's been widely tested by now), and even if
problems here would generally be expected to surface independent
of the use of PCI pass-through. But a hang (rather than a crash)
would indeed be the most natural result of something being wrong
here. To double check the result, could you, in an up-to-date tree,
simply make x86's arch_skip_send_event_check() return 0
unconditionally? Plus, without said adjustment, first just disable the
MWAIT CPU idle driver ("mwait-idle=0") and then, if that didn't make
a difference, use of C states altogether ("cpuidle=0"). If any of this
does make a difference, limiting use of C states without fully
excluding their use may need to be the next step.

Another thing - now that serial logging appears to be working for
you, did you try whether the host, once hung, still reacts to serial
input (perhaps force input to go to Xen right at boot via the
"conswitch=" option)? If so, 'd' debug-key output would likely be
the piece of most interest. If not, try adding "watchdog" on the Xen
command line (this doesn't always work, but should on the CPU you
originally reported the issue for).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel