| Message ID | 20120404154020.40C513E09D5@localhost (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
Grant Likely <grant.likely@secretlab.ca> writes: > I bet it is NR_IRQS related. You have SPARSE_IRQ enabled, which means > the maximum number of irq_descs is IRQ_BITMAP_BITS (NR_IRQS + 8192). The actual definition uses NR_IRQS + 8196. Guess that's a typo. (Does it really make sense to add NR_IRQS here?) > diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h > index cf417e51..9edf499 100644 > --- a/arch/powerpc/include/asm/irq.h > +++ b/arch/powerpc/include/asm/irq.h > @@ -20,7 +20,7 @@ > > /* Define a way to iterate across irqs. */ > #define for_each_irq(i) \ > - for ((i) = 0; (i) < NR_IRQS; ++(i)) > + for ((i) = 0; (i) < nr_irqs; ++(i)) There are exactly two uses of for_each_irq, one is related to cpu hotplug, the other to kexec, so that cannot make any difference. Andreas.
Grant Likely <grant.likely@secretlab.ca> writes: > Can you attach console output logs for each of configs above and also > with NR_IRQS=128? That might give me some clues as to which specific > code is causing the issues. It really looks like the issue starts when irq_expand_nr_irqs is called the first time to make nr_irqs bigger than NR_IRQS. Andreas.
On Thu, 5 Apr 2012, Andreas Schwab wrote: > Grant Likely <grant.likely@secretlab.ca> writes: > > > I bet it is NR_IRQS related. You have SPARSE_IRQ enabled, which means > > the maximum number of irq_descs is IRQ_BITMAP_BITS (NR_IRQS + 8192). > > The actual definition uses NR_IRQS + 8196. Guess that's a typo. (Does > it really make sense to add NR_IRQS here?) > > > diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h > > index cf417e51..9edf499 100644 > > --- a/arch/powerpc/include/asm/irq.h > > +++ b/arch/powerpc/include/asm/irq.h > > @@ -20,7 +20,7 @@ > > > > /* Define a way to iterate across irqs. */ > > #define for_each_irq(i) \ > > - for ((i) = 0; (i) < NR_IRQS; ++(i)) > > + for ((i) = 0; (i) < nr_irqs; ++(i)) > > There are exactly two uses of for_each_irq, one is related to cpu > hotplug, the other to kexec, so that cannot make any difference. Though that wants to be fixed nevertheless. Thanks, tglx
On Fri, 6 Apr 2012, Andreas Schwab wrote: > Grant Likely <grant.likely@secretlab.ca> writes: > > > Can you attach console output logs for each of configs above and also > > with NR_IRQS=128? That might give me some clues as to which specific > > code is causing the issues. > > It really looks like the issue starts when irq_expand_nr_irqs is called > the first time to make nr_irqs bigger than NR_IRQS. And it looks like the irqdomain code is the real culprit. void irq_set_virq_count(unsigned int count) { pr_debug("irq: Trying to set virq count to %d\n", count); BUG_ON(count < NUM_ISA_INTERRUPTS); if (count < NR_IRQS) irq_virq_count = count; } That looks simply wrong..... s/NR_IRQS/nr_irqs/ should do the trick. Thanks, tglx
Thomas Gleixner <tglx@linutronix.de> writes: > And it looks like the irqdomain code is the real culprit. > > void irq_set_virq_count(unsigned int count) > { > pr_debug("irq: Trying to set virq count to %d\n", count); > > BUG_ON(count < NUM_ISA_INTERRUPTS); > if (count < NR_IRQS) > irq_virq_count = count; > } > > That looks simply wrong..... There is a single use of irq_set_virq_count, which is only relevant to the PS3. Andreas.
On Fri, 6 Apr 2012, Andreas Schwab wrote: > Thomas Gleixner <tglx@linutronix.de> writes: > > > And it looks like the irqdomain code is the real culprit. > > > > void irq_set_virq_count(unsigned int count) > > { > > pr_debug("irq: Trying to set virq count to %d\n", count); > > > > BUG_ON(count < NUM_ISA_INTERRUPTS); > > if (count < NR_IRQS) > > irq_virq_count = count; > > } > > > > That looks simply wrong..... > > There is a single use of irq_set_virq_count, which is only relevant to > the PS3. Though irq_virq_count is statically initialized to NR_IRQS and it's used in the code more than once.
On Fri, 6 Apr 2012 13:17:04 +0200 (CEST), Thomas Gleixner <tglx@linutronix.de> wrote: > On Fri, 6 Apr 2012, Andreas Schwab wrote: > > > Grant Likely <grant.likely@secretlab.ca> writes: > > > > > Can you attach console output logs for each of configs above and also > > > with NR_IRQS=128? That might give me some clues as to which specific > > > code is causing the issues. > > > > It really looks like the issue starts when irq_expand_nr_irqs is called > > the first time to make nr_irqs bigger than NR_IRQS. > > And it looks like the irqdomain code is the real culprit. > > void irq_set_virq_count(unsigned int count) > { > pr_debug("irq: Trying to set virq count to %d\n", count); > > BUG_ON(count < NUM_ISA_INTERRUPTS); > if (count < NR_IRQS) > irq_virq_count = count; > } > > That looks simply wrong..... > > s/NR_IRQS/nr_irqs/ should do the trick. Yeah, that code is wrong and I'll fix it, but the only purpose of that code is to support the direct mapping on hardware that has limit on the largest irq number that it can handle. That shouldn't be the problem here. g.
diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h index cf417e51..9edf499 100644 --- a/arch/powerpc/include/asm/irq.h +++ b/arch/powerpc/include/asm/irq.h @@ -20,7 +20,7 @@ /* Define a way to iterate across irqs. */ #define for_each_irq(i) \ - for ((i) = 0; (i) < NR_IRQS; ++(i)) + for ((i) = 0; (i) < nr_irqs; ++(i)) extern atomic_t ppc_n_lost_interrupts;