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