>>> On 17.05.17 at 16:59, <boris.ostrov...@oracle.com> wrote:
> On 05/16/2017 06:43 PM, osstest service owner wrote:
>> flight 109469 linux-linus real [real]
>> Regressions :-(
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>> test-amd64-i386-libvirt 6 xen-boot fail REGR. vs.
> This looks like some sort of a deadlock with CPU2 waiting for remote
> call to complete while CPU0 waiting for flush_lock.
But these two don't block each other, as both run with interrupts
enabled (i.e. are available to process IPIs the other might have
> Only two CPUs are dumped though.
That's bad. CPU4 sitting at the final loop in flush_area_mask()
makes clear that's the flush_lock holder, but we can imply it has
IRQs on just like CPUs 0 and 2. While the place CPU2 was
caught also doesn't allow us to deduce which other CPU(s)
is/are not responding, the main candidate would appear to be
CPU1, of which we know nothing except that it also sits in
_spin_lock(). Neither flush_lock nor call_lock would ever be
acquired with IRQs off, so I'd conclude there must be a 3rd
lock involved here.
Therefore I'm afraid the only way we could obtain a more
complete picture would be if this re-occurred and if at that
time we'd have "async-show-all" in place on the hypervisor
Xen-devel mailing list