|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Assertion 'cpu < nr_cpu_ids' failed at .../src/new/xen-unstable/xen/include/xen/cpumask.h:97
On 23/02/15 10:06, Jan Beulich wrote:
>>>> On 23.02.15 at 10:27, <linux@xxxxxxxxxxxxxx> wrote:
>> While shutting down all guests to go for a host reboot i encountered the
>> splat below.
>> This was running on Xen with:
>> xen_changeset: Fri Feb 20 16:21:10 2015 +0100 git:24b2b8d-dirty
> "-dirty" meaning what?
>
>> (XEN) [2015-02-23 09:16:26.292] Assertion 'cpu < nr_cpu_ids' failed at
>> .../src/new/xen-unstable/xen/include/xen/cpumask.h:97
> Since with debug=y the callstack entries should be reliable, I can't
> see how this matches up with ...
>
>> (XEN) [2015-02-23 09:16:26.292] Xen call trace:
>> (XEN) [2015-02-23 09:16:26.292] [<ffff82d08012c018>]
>> cpu_raise_softirq+0xd7/0xeb
> ... this, since
>
> void cpu_raise_softirq(unsigned int cpu, unsigned int nr)
> {
> unsigned int this_cpu = smp_processor_id();
>
> if ( test_and_set_bit(nr, &softirq_pending(cpu))
> || (cpu == this_cpu)
> || arch_skip_send_event_check(cpu) )
> return;
>
> if ( !per_cpu(batching, this_cpu) || in_irq() )
> smp_send_event_check_cpu(cpu);
> else
> set_bit(nr, &per_cpu(batch_mask, this_cpu));
> }
>
> doesn't indicate any use of cpumask functions. If, however,
> arch_skip_send_event_check()'s call to cpumask_test_cpu()
> didn't get inlined, that might be the cause. Albeit that would mean
> smp_processor_id() returned an out-of-range value... In any
> event we'll need to know what exactly above code location refers
> to inside the entire function.
Are you sure your code is up to date?
Current staging has
void cpu_raise_softirq(unsigned int cpu, unsigned int nr)
{
unsigned int this_cpu = smp_processor_id();
if ( test_and_set_bit(nr, &softirq_pending(cpu))
|| (cpu == this_cpu)
|| arch_skip_send_event_check(cpu) )
return;
if ( !per_cpu(batching, this_cpu) || in_irq() )
smp_send_event_check_cpu(cpu);
else
__cpumask_set_cpu(nr, &per_cpu(batch_mask, this_cpu));
}
And furthermore, I think the final __cpumask_set_cpu(...) appears
wrong. The first parameter should be 'cpu' rather than 'nr'. I am not
surprised that the ASSERT() is firing.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |