Impact: cleanup, futureproof
In fact, all cpumask ops will only be valid (in general) for bit
numbers < nr_cpu_ids. So use that instead of NR_CPUS in various
places.
This is always safe: no cpu number can be >= nr_cpu_ids, and
nr_cpu_ids is initialized to NR_CPUS at boot.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Mike Travis <travis@sgi.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
Impact: cleanup, update to new cpumask API
Irq_desc.affinity and irq_desc.pending_mask are now cpumask_var_t's
so access to them should be using the new cpumask API.
Signed-off-by: Mike Travis <travis@sgi.com>
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
Impact: cleanup, update to new cpumask API
Irq_desc.affinity and irq_desc.pending_mask are now cpumask_var_t's
so access to them should be using the new cpumask API.
Signed-off-by: Mike Travis <travis@sgi.com>
Impact: build fix
Ingo Molnar wrote:
> tip/arch/blackfin/kernel/irqchip.c: In function 'show_interrupts':
> tip/arch/blackfin/kernel/irqchip.c:85: error: 'struct kernel_stat' has no member named 'irqs'
> make[2]: *** [arch/blackfin/kernel/irqchip.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
>
So could move kstat_irqs array to irq_desc struct.
(s390, m68k, sparc) are not touched yet, because they don't support genirq
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
trivial fixes:
- use KERN_WARNING for printk()
- use BUG_ON() instead of "if (xx) BUG();"
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Impact: change existing irq_chip API
Not much point with gentle transition here: the struct irq_chip's
setaffinity method signature needs to change.
Fortunately, not widely used code, but hits a few architectures.
Note: In irq_select_affinity() I save a temporary in by mangling
irq_desc[irq].affinity directly. Ingo, does this break anything?
(Folded in fix from KOSAKI Motohiro)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Mike Travis <travis@sgi.com>
Reviewed-by: Grant Grundler <grundler@parisc-linux.org>
Acked-by: Ingo Molnar <mingo@redhat.com>
Cc: ralf@linux-mips.org
Cc: grundler@parisc-linux.org
Cc: jeremy@xensource.com
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
The timer interrupt had accidentally been marked IRQ_DISABLED since
IRQ_PER_CPU had been OR-ed in, instead of set. This had been working
by accident for quite a while.
Commit c642b8391c changed the behaviour of
IRQ_PER_CPU interrupts, which previously weren't checked for IRQ_DISABLED.
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
Kudos to Thibaut Varene for spotting the (mis)use of appropriately named
global_ack_eiem. This took a long time to figure out and both insight
from myself, Kyle McMartin, and James Bottomley were required to narrow
down which bit of code could have this race condition.
The symptom was interrupts stopped getting delivered while some workload
was generating IO interrupts on two different CPUs. One of the interrupt
sources would get masked off and stay unmasked. Problem was global_ack_eiem
was accessed with read/modified/write sequence and not protected by
a spinlock.
PA-RISC doesn't need a global ack flag though. External Interrupts
are _always_ delivered to a single CPU (except for "global broadcast
interrupt" which AFAIK currently is not used.) So we don't have to worry
about any given IRQ vector getting delivered to more than one CPU.
Tested on a500 and rp34xx boxen. rsync to/from gsyprf11 (a500)
would lock up the box since NIC (tg3) interrupt and SCSI (sym2)
were on "opposite" CPUs (2 CPU system). Put them on the same CPU
or apply this patch and 10GB of data would rsync completely.
Please apply the following critical patch.
thanks,
grant
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Acked-by: Thibaut VARENE <T-Bone@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
Add IRQF_IRQPOLL to the timer interrupt on parisc.
Signed-off-by: Bernhard Walle <bwalle@suse.de>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Cc: Matthew Wilcox <willy@debian.org>
Cc: Grant Grundler <grundler@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Our prior mode of operation didn't allow nested interrupts
because it makes the interrupt code much simpler. However,
nested interrupts are better for latency.
This code uses the EIEM register to simulate level interrupts
and thus achieve nesting.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
Use the new IRQF_ constants and remove the SA_INTERRUPT define
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Add ->retrigger() irq op to consolidate hw_irq_resend() implementations.
(Most architectures had it defined to NOP anyway.)
NOTE: ia64 needs testing. i386 and x86_64 tested.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Consolidation: remove the irq_affinity[NR_IRQS] array and move it into the
irq_desc[NR_IRQS].affinity field.
[akpm@osdl.org: sparc64 build fix]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch-queue improves the generic IRQ layer to be truly generic, by adding
various abstractions and features to it, without impacting existing
functionality.
While the queue can be best described as "fix and improve everything in the
generic IRQ layer that we could think of", and thus it consists of many
smaller features and lots of cleanups, the one feature that stands out most is
the new 'irq chip' abstraction.
The irq-chip abstraction is about describing and coding and IRQ controller
driver by mapping its raw hardware capabilities [and quirks, if needed] in a
straightforward way, without having to think about "IRQ flow"
(level/edge/etc.) type of details.
This stands in contrast with the current 'irq-type' model of genirq
architectures, which 'mixes' raw hardware capabilities with 'flow' details.
The patchset supports both types of irq controller designs at once, and
converts i386 and x86_64 to the new irq-chip design.
As a bonus side-effect of the irq-chip approach, chained interrupt controllers
(master/slave PIC constructs, etc.) are now supported by design as well.
The end result of this patchset intends to be simpler architecture-level code
and more consolidation between architectures.
We reused many bits of code and many concepts from Russell King's ARM IRQ
layer, the merging of which was one of the motivations for this patchset.
This patch:
rename desc->handler to desc->chip.
Originally i did not want to do this, because it's a big patch. But having
both "desc->handler", "desc->handle_irq" and "action->handler" caused a
large degree of confusion and made the code appear alot less clean than it
truly is.
I have also attempted a dual approach as well by introducing a
desc->chip alias - but that just wasnt robust enough and broke
frequently.
So lets get over with this quickly. The conversion was done automatically
via scripts and converts all the code in the kernel.
This renaming patch is the first one amongst the patches, so that the
remaining patches can stay flexible and can be merged and split up
without having some big monolithic patch act as a merge barrier.
[akpm@osdl.org: build fix]
[akpm@osdl.org: another build fix]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Make the "redirecting irq" message to not display on the console by
setting the severity to KERN_DEBUG. The console was basically unusable.
Signed-off-by: Ryan Bradetich <rbrad@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
irq_affinityp[] only available for SMP builds, make code that uses
it conditional on CONFIG_SMP.
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
This really only adds them for the machines I can check SMP on, which
is CPU interrupts and IOSAPIC (so not any of the GSC based machines).
With this patch, irqbalanced can be used to maintain irq balancing.
Unfortunately, irqbalanced is a bit x86 centric, so it doesn't do an
incredibly good job, but it does work.
Signed-off-by: James Bottomley <jejb@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
Since irq.c uses smp_send_all_nop, we must define it for UP builds
as well. Make it a static inline so it gets optimized away. This forces
irq.c to include <asm/smp.h> though.
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
Fix our interrupts not to use smp_call_function
On K and D class smp, the generic code calls this under an irq
spinlock, which causes the WARN_ON() message in smp_call_function()
(and is also illegal because it could deadlock).
The fix is to use a new scheme based on the IPI_NOP.
Signed-off-by: James Bottomley <jejb@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
Disable nesting of interrupts - still has holes
The offending sequence starts out like this:
1) take external interrupt
2) set_eiem() to only allow TIMER_IRQ; local interrupts still disabled
3) read the EIRR to get a "list" of pending interrupts
4) clear EIRR of pending interrupts we intend to handle
5) call __do_IRQ() to handle IRQ.
6) handle_IRQ_event() enables local interrupts (I-Bit)
7) take a timer interrupt
8) read EIRR to get a new list of pending interrupts
9) clear EIRR of pending interrupts we just read
10) handle pending interrupts found in (8)
11) set_eiem(cpu_eiem) and return
[ TROUBLE! all enabled CPU IRQs are unmasked. }
12) handle remaining interrupts pending from (3)
e.g. call __do_IRQ() -> handle_IRQ_event()..etc
[ TROUBLE! call to handle_IRQ_event() can now enable *any* IRQ. }
13) set_eiem(cpu_eiem) and return
The problem is we now get into ugly race conditions with Timer and IPI
interrupts at this point. I'm not exactly sure what happens when
things go wrong (perhaps nest calls to IPI or timer interrupt?).
But I'm certain it's not good.
This sequence will break sooner if (10) would accidentally leave
interrupts enabled.
I'm pretty sure the right answer is now to make cpu_eiem
a per CPU variable since all external interrupts on parisc
are per CPU. This means we will NOT need to send an IPI to
every CPU in the system when enabling or disabling an IRQ
since only one CPU needs to change it's EIEM.
Thanks to James Bottomley for (once again) pointing out the problem.
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
Fix a longstanding smp bug
The problem is that both the timer and ipi interrupts are being called
with interrupts enabled, which isn't what anyone is expecting.
The IPI issue has just started to show up by causing a BUG_ON in the
slab debugging code. The timer issue never shows up because there's an
eiem work around in our irq.c
The fix is to label both these as SA_INTERRUPT which causes the generic
irq code not to enable interrupts.
I also suspect the smp_call_function timeouts we're seeing might be
connected with the fact that we disable IPIs when handling any other
type of interrupt. I've put a WARN_ON in the code for executing
smp_call_function() with IPIs disabled.
Signed-off-by: James Bottomley <jejb@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Kyle McMartin