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

[Ben Guthro <ben@xxxxxxxxxx>]

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).

OK

>
>> 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:

https://citrix.sharefile.com/d/s4ba432974874efd8

(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.

Ben

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