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

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



>>> On 20.11.14 at 21:07, <sflist@xxxxxxxxx> wrote:
> Running with mwait-idle=0 solves (hides?) the problem. Next step is to 
> fiddle with the C states?

For that I'd first of all like to know how much use of C states the
system still makes with that option in place. For that I'd need the
output of "xenpm get-cpuidle-states" (actually for comparison
purposes seeing it once with and once without that option in
place would be best). Or alternatively 'c' debug key output.

>> Interesting - all CPUs are executing stuff from Dom1, which be itself 
>> is not indicating a problem, but may (considering the host hang) hint 
>> at guest vCPU-s not getting de-scheduled anymore on one or more of the 
>> CPUs. The 'a' debug key output would hopefully give us enough 
>> information to know whether that's the case. Ideally do 'd' and 'a' a 
>> couple of times each (alternating, and with a few seconds in between). 
> 
> Here ya go (as before, from 9a727a81). I had to pick and choose what 
> parts to pull from the log because it was getting spammed with kernel 
> complaints about the disk subsystem being locked up, so the hypervisor 
> debugging info was hard to read amidst the kernel errors. As ever, let 
> me know if you need more.

Pretty strange: While the first 'a' output suggests that several CPUs
are idle, the first 'd' output contradicts. While this isn't wrong by itself,
it may provide a hint I'm simply unable to interpret yet. In any event
I didn't find what I expected - timers the expiry of which was in the
past.

Jan


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


 


Rackspace

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