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

Re: [Xen-devel] dump with xen-unstable & linux 3.2.17

On Mon, May 21, 2012 at 10:55 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 17.05.12 at 23:20, Ben Guthro <ben@xxxxxxxxxx> wrote:
>> I'm attempting to update the Xen I'm using, and am having an issue with S3.
>> Konrad - I know you've been down this path before - so I'm hoping you
>> might have some insight, given the stack below
>> The linux tree also has an older version of Konrad's acpi-s3
>> development branches (it was v7)
>> Upon resuming from S3 - Xen panics with the following stack. I'm
>> guessing it has something to do with some of the pcpu work going on
>> recently - but haven't been tracking this too closely, so am not sure.
> I don't think that's related, the more that if anything that work
> was on the Dom0 kernel side, not the hypervisor (or not
> recently).


>> The same kernel with Xen 4.0.x works OK.
> Anything known regarding 4.1.x?

Not at this time.

I'm attempting to update the hypervisor (and patches) used in
XenClient Enterprise (was NxTop)

Since we have a stack of patches that are not necessarily appropriate
for upstream (and some that just haven't been submitted yet) - there
is some porting involved in getting things running to the point that I
can test it.

If we can't figure this out with the logs - I can try to bisect, and
figure out where things broke...but that could be rather time
consuming, if I have to re-port those patches each time.

>> (XEN) Assertion '!cpumask_empty(&cpus) && cpumask_test_cpu(cpu,
>> &cpus)' failed at sched_credit.c:477
> Assuming this is reproducible, could you try to get your serial
> console problems sorted out so that you can obtain a full log
> (there are quite a few dropped characters here).
> At least I can't tell anything from the dumped data alone (other
> than the first part of the ASSERT() expression being redundant
> with the second part), so I'd also like to ask that you attach (or
> make accessible another way) the xen-syms binary corresponding
> to the xen.gz one used, so one can locate and analyze individual
> variables in the registers and on stack.

Please find a new log, xen.gz & syms here:


(I didn't want to attach large files to the mailing list)

FWIW, this is on an Intel Ivybridge SDP - but also seems to happen on
older platforms, as well.

Any insight is greatly appreciated.


Xen-devel mailing list



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