[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


 


Rackspace

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