From: Ingo Molnar <mingo@elte.hu>
To: linux-ia64@vger.kernel.org
Subject: Re: [GIT PULL] percpu, cpumask, x86 updates for v2.6.30
Date: Sat, 28 Mar 2009 21:24:34 +0000 [thread overview]
Message-ID: <20090328212434.GA11629@elte.hu> (raw)
In-Reply-To: <alpine.LFD.2.00.0903281341100.3994@localhost.localdomain>
* Ingo Molnar <mingo@elte.hu> wrote:
> > Ingo, I think you ia64 stuff was broken. It used "vector" to get
> > to the irq descriptor. Which is not the same as an "irq" at all.
> >
> > The reason I noticed is that it clashed with the ia64 pull,
> > which had fixed this up.
that's the fallout of:
d2287f5: irq: update all arches for new irq_desc, fix
it's this change:
while (vector != IA64_SPURIOUS_INT_VECTOR) {
+ struct irq_desc *desc = irq_to_desc(vector);
+
if (unlikely(IS_LOCAL_TLB_FLUSH(vector))) {
smp_local_flush_tlb();
- kstat_this_cpu.irqs[vector]++;
+ kstat_incr_irqs_this_cpu(vector, desc);
} else if (unlikely(IS_RESCHEDULE(vector)))
- kstat_this_cpu.irqs[vector]++;
+ kstat_incr_irqs_this_cpu(vector, desc);
and the original code addressed kstat-irqs (which was a [NR_IRQS]
array) via 'vector'.
And i think you are right that there is an irq<->vector mismatch
here. I also think that ia64's use of [vector] there was probably
buggy to begin with - the kstat array is really addressed by 'irq'.
With the irq_to_desc() change we did above it became even more
incorrect.
It didnt crash though: this commit has been in linux-next for 2
months. Maybe nobody noticed because it's "just" about IRQ
statistics? I have no ia64 box to check though, and the code in
arch/ia64/kernel/ivt.S looks rather cryptic.
> >
> > I tried to fix it all up. But I'm just about the last person in
> > the universe who wants to compile ia64, so I have not tested, or
> > even been able to see that it compiles. Somebody should
> > double-check it.
>
> Sure, i'm on it, i'll check your resolution of
> arch/ia64/kernel/irq_ia64.c.
Your version builds fine on ia64 defconfig - and i think the
resolution you did is correct.
Detail: i _think_ you could have picked the ia64-branch version
instead of doing a manual resolution - i.e. could have kept the ia64
version via the patch below. The reason is that IA64 does not
support SPARSE_IRQ yet. But your resolution is cleaner and
sparseirq-correct.
Ingo
diff --git a/arch/ia64/kernel/irq_ia64.c b/arch/ia64/kernel/irq_ia64.c
index acc4d19..977a6ef 100644
--- a/arch/ia64/kernel/irq_ia64.c
+++ b/arch/ia64/kernel/irq_ia64.c
@@ -493,15 +493,16 @@ ia64_handle_irq (ia64_vector vector, struct pt_regs *regs)
saved_tpr = ia64_getreg(_IA64_REG_CR_TPR);
ia64_srlz_d();
while (vector != IA64_SPURIOUS_INT_VECTOR) {
+ struct irq_desc *desc;
int irq = local_vector_to_irq(vector);
- struct irq_desc *desc = irq_to_desc(irq);
+ desc = irq_desc + irq;
if (unlikely(IS_LOCAL_TLB_FLUSH(vector))) {
smp_local_flush_tlb();
kstat_incr_irqs_this_cpu(irq, desc);
- } else if (unlikely(IS_RESCHEDULE(vector))) {
+ } else if (unlikely(IS_RESCHEDULE(vector)))
kstat_incr_irqs_this_cpu(irq, desc);
- } else {
+ else {
ia64_setreg(_IA64_REG_CR_TPR, vector);
ia64_srlz_d();
@@ -552,15 +553,16 @@ void ia64_process_pending_intr(void)
* Perform normal interrupt style processing
*/
while (vector != IA64_SPURIOUS_INT_VECTOR) {
+ struct irq_desc *desc;
int irq = local_vector_to_irq(vector);
- struct irq_desc *desc = irq_to_desc(irq);
+ desc = irq_desc + irq;
if (unlikely(IS_LOCAL_TLB_FLUSH(vector))) {
smp_local_flush_tlb();
kstat_incr_irqs_this_cpu(irq, desc);
- } else if (unlikely(IS_RESCHEDULE(vector))) {
+ } else if (unlikely(IS_RESCHEDULE(vector)))
kstat_incr_irqs_this_cpu(irq, desc);
- } else {
+ else {
struct pt_regs *old_regs = set_irq_regs(NULL);
ia64_setreg(_IA64_REG_CR_TPR, vector);
next prev parent reply other threads:[~2009-03-28 21:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-28 20:53 [GIT PULL] percpu, cpumask, x86 updates for v2.6.30 Linus Torvalds
2009-03-28 20:59 ` Ingo Molnar
2009-03-28 21:24 ` Ingo Molnar [this message]
2009-03-30 15:52 ` Luck, Tony
2009-03-31 10:17 ` Ingo Molnar
2009-03-31 18:39 ` Luck, Tony
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090328212434.GA11629@elte.hu \
--to=mingo@elte.hu \
--cc=linux-ia64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox