Re: [Xen-devel] Assertion 'cpu < nr_cpu_ids' failed at .../src/new/xen-unstable/xen/include/xen/cpumask.h:97

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.02.15 at 11:38, <andrew.cooper3@xxxxxxxxxx> wrote:
> 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

Ah, I looked at master, not staging.

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

No, the conversion to __cpumask_set_cpu() was wrong here in
the first place - this ought to be __set_bit(). Will submit a fix in a
minute.

Jan


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