19 Feb, 2008
2 commits
-
The default_disable() function was changed in commit:
76d2160147f43f982dfe881404cfde9fd0a9da21
genirq: do not mask interrupts by defaultIt removed the mask function in favour of the default delayed
interrupt disabling. Unfortunately this also broke the shutdown in
free_irq() when the last handler is removed from the interrupt for
those architectures which rely on the default implementations. Now we
can end up with a enabled interrupt line after the last handler was
removed, which can result in spurious interrupts.Fix this by adding a default_shutdown function, which is only
installed, when the irqchip implementation does provide neither a
shutdown nor a disable function.[@stable: affected versions: .21 - .24 ]
Pointed-out-by: Michael Hennerich
Signed-off-by: Thomas Gleixner
Acked-by: Ingo Molnar
Cc: stable@kernel.org
Tested-by: Michael Hennerich -
The functions time_before, time_before_eq, time_after, and
time_after_eq are more robust for comparing jiffies against other
values.So following patch implements usage of the time_after() macro, defined
at linux/jiffies.h, which deals with wrapping correctlySigned-off-by: S.Caglar Onur
Acked-by: Ingo Molnar
Signed-off-by: Thomas Gleixner
09 Feb, 2008
2 commits
-
Probing non-ISA interrupts using the handle_percpu_irq as their handle_irq
method may crash the system because handle_percpu_irq does not check
IRQ_WAITING. This for example hits the MIPS Qemu configuration.This patch provides two helper functions set_irq_noprobe and set_irq_probe to
set rsp. clear the IRQ_NOPROBE flag. The only current caller is MIPS code
but this really belongs into generic code.As an aside, interrupt probing these days has become a mostly obsolete if not
dangerous art. I think Linux interrupts should be changed to default to
non-probing but that's subject of this patch.Signed-off-by: Ralf Baechle
Acked-and-tested-by: Rob Landley
Cc: Alan Cox
Cc: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Harvey Harrison
Acked-by: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
30 Jan, 2008
3 commits
-
these bugs are harder to find than they seem, a stackdump helps.
make it dependent on CONFIG_DEBUG_SHIRQ so that people can turn it off
if it annoys them.Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
This is useful to debug problems with interrupt handlers that return
sometimes IRQ_NONE.Signed-off-by: Andi Kleen
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
This allows to change them at runtime using sysfs. No need to
reboot to set them.I only added aliases (kernel.noirqdebug etc.) so the old options
still work.Signed-off-by: Andi Kleen
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner
19 Dec, 2007
1 commit
-
In commit 76d2160147f43f982dfe881404cfde9fd0a9da21 lazy irq disabling
was implemented, and the simple irq handler had a masking set to it.Remy Bohmer discovered that some devices in the ARM architecture
would trigger the mask, but never unmask it. His patch to do the
unmasking was questioned by Russell King about masking simple irqs
to begin with. Looking further, it was discovered that the problems
Remy was seeing was due to improper use of the simple handler by
devices, and he later submitted patches to fix those. But the issue
that was uncovered was that the simple handler should never mask.This patch reverts the masking in the simple handler.
Signed-off-by: Steven Rostedt
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner
Acked-by: Russell King
15 Nov, 2007
1 commit
-
In __do_IRQ(), the normal case is that IRQ_DISABLED is checked and if set
the handler (handle_IRQ_event()) is not called.Earlier in __do_IRQ(), if IRQ_PER_CPU is set the code does not check
IRQ_DISABLED and calls the handler even though IRQ_DISABLED is set. This
behavior seems unintentional.One user encountering this behavior is the CPE handler (in
arch/ia64/kernel/mca.c). When the CPE handler encounters too many CPEs
(such as a solid single bit error), it sets up a polling timer and disables
the CPE interrupt (to avoid excessive overhead logging the stream of single
bit errors). disable_irq_nosync() is called which sets IRQ_DISABLED. The
IRQ_PER_CPU flag was previously set (in ia64_mca_late_init()). The net
result is the CPE handler gets called even though it is marked disabled.If the behavior of not checking IRQ_DISABLED when IRQ_PER_CPU is set is
intentional, it would be worthy of a comment describing the intended
behavior. disable_irq_nosync() does call chip->disable() to provide a
chipset specifiec interface for disabling the interrupt, which avoids this
issue when used.Signed-off-by: Russ Anderson
Cc: "Luck, Tony"
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Bjorn Helgaas
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
24 Oct, 2007
1 commit
-
As it is some callers of synchronize_irq rely on memory barriers
to provide synchronisation against the IRQ handlers. For example,
the tg3 driver doestp->irq_sync = 1;
smp_mb();
synchronize_irq();and then in the IRQ handler:
if (!tp->irq_sync)
netif_rx_schedule(dev, &tp->napi);Unfortunately memory barriers only work well when they come in
pairs. Because we don't actually have memory barriers on the
IRQ path, the memory barrier before the synchronize_irq() doesn't
actually protect us.In particular, synchronize_irq() may return followed by the
result of netif_rx_schedule being made visible.This patch (mostly written by Linus) fixes this by using spin
locks instead of memory barries on the synchronize_irq() path.Signed-off-by: Herbert Xu
Acked-by: Benjamin Herrenschmidt
Signed-off-by: Linus Torvalds
17 Oct, 2007
2 commits
-
Compiling handle_percpu_irq only on uniprocessor generates an artificial
special case so a typical use like:set_irq_chip_and_handler(irq, &some_irq_type, handle_percpu_irq);
needs to be conditionally compiled only on SMP systems as well and an
alternative UP construct is usually needed - for no good reason.This fixes uniprocessor configurations for some MIPS SMP systems.
Signed-off-by: Ralf Baechle
Acked-by: Thomas Gleixner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Andy Gospodarek pointed out that because we return in the middle of the
free_irq() function, we never actually do call the IRQ handler that just
got deregistered. This should fix it, although I expect Andrew will want
to convert those 'return's to 'break'. That's a separate change though.Signed-off-by: David Woodhouse
Cc: Andy Gospodarek
Cc: Fernando Luis Vzquez Cao
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
31 Aug, 2007
1 commit
-
Mariusz Kozlowski reported lockdep's warning:
> =================================
> [ INFO: inconsistent lock state ]
> 2.6.23-rc2-mm1 #7
> ---------------------------------
> inconsistent {in-hardirq-W} -> {hardirq-on-W} usage.
> ifconfig/5492 [HC0[0]:SC0[0]:HE1:SE1] takes:
> (&tp->lock){+...}, at: [] rtl8139_interrupt+0x27/0x46b [8139too]
> {in-hardirq-W} state was registered at:
> [] __lock_acquire+0x949/0x11ac
> [] lock_acquire+0x99/0xb2
> [] _spin_lock+0x35/0x42
> [] rtl8139_interrupt+0x27/0x46b [8139too]
> [] handle_IRQ_event+0x28/0x59
> [] handle_level_irq+0xad/0x10b
> [] do_IRQ+0x93/0xd0
> [] common_interrupt+0x2e/0x34
...
> other info that might help us debug this:
> 1 lock held by ifconfig/5492:
> #0: (rtnl_mutex){--..}, at: [] mutex_lock+0x1c/0x1f
>
> stack backtrace:
...
> [] _spin_lock+0x35/0x42
> [] rtl8139_interrupt+0x27/0x46b [8139too]
> [] free_irq+0x11b/0x146
> [] rtl8139_close+0x8a/0x14a [8139too]
> [] dev_close+0x57/0x74
...This shows that a driver's irq handler was running both in hard interrupt
and process contexts with irqs enabled. The latter was done during
free_irq() call and was possible only with CONFIG_DEBUG_SHIRQ enabled.
This was fixed by another patch.But similar problem is possible with request_irq(): any locks taken from
irq handler could be vulnerable - especially with soft interrupts. This
patch fixes it by disabling local interrupts during handler's run. (It
seems, disabling softirqs should be enough, but it needs more checking
on possible races or other special cases).Reported-by: Mariusz Kozlowski
Signed-off-by: Jarek Poplawski
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
23 Aug, 2007
1 commit
-
If we're going to run the handler from free_irq() then we must do it with
local irq's disabled. Otherwise lockdep complains that the handler is taking
irq-safe spinlocks in a non-irq-safe fashion.Cc: Ingo Molnar
Cc: David Woodhouse
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
13 Aug, 2007
2 commits
-
Level type interrupts are resent by the interrupt hardware when they are
still active at irq_enable().Suppress the resend mechanism for interrupts marked as level.
Signed-off-by: Thomas Gleixner
Signed-off-by: Linus Torvalds -
Commit 5a43a066b11ac2fe84cf67307f20b83bea390f83: "genirq: Allow fasteoi
handler to retrigger disabled interrupts" was erroneously applied to
handle_level_irq(). This added the irq retrigger / resend functionality
to the level irq handler.Revert the offending bits.
Signed-off-by: Thomas Gleixner
Signed-off-by: Linus Torvalds
09 Aug, 2007
1 commit
-
This reverts commit 0fc4969b866671dfe39b1a9119d0fdc7ea0f63e5. It was
always meant to be temporary, but it's generating more useless noise
than anything else, and we probably should never have done it in the
generic kernel (only had the people involved test it on their own).Signed-off-by: Linus Torvalds
02 Aug, 2007
1 commit
-
Marcin Slusarz reported a ne2k-pci "hung network interface" regression.
delayed disable relies on the ability to re-trigger the interrupt in the
case that a real interrupt happens after the software disable was set.
In this case we actually disable the interrupt on the hardware level
_after_ it occurred.On enable_irq, we need to re-trigger the interrupt. On i386 this relies
on a hardware resend mechanism (send_IPI_self()).Actually we only need the resend for edge type interrupts. Level type
interrupts come back once enable_irq() re-enables the interrupt line.I assume that the interrupt in question is level triggered because it is
shared and above the legacy irqs 0-15:17: 12 IO-APIC-fasteoi eth1, eth0
Looking into the IO_APIC code, the resend via send_IPI_self() happens
unconditionally. So the resend is done for level and edge interrupts.
This makes the problem more mysterious.The code in question lib8390.c does
disable_irq();
fiddle_with_the_network_card_hardware()
enable_irq();The fiddle_with_the_network_card_hardware() might cause interrupts,
which are cleared in the same code path again,Marcin found that when he disables the irq line on the hardware level
(removing the delayed disable) the card is kept alive.So the difference is that we can get a resend on enable_irq, when an
interrupt happens during the time, where we are in the disabled region.Signed-off-by: Ingo Molnar
Signed-off-by: Linus Torvalds
29 Jul, 2007
1 commit
-
Signed-off-by: Al Viro
Acked-by: Jeff Garzik
Signed-off-by: Linus Torvalds
22 Jul, 2007
1 commit
-
Otherwise smp_affinity would only update after the next interrupt
on x86 systems.Cc: Thomas Gleixner
Cc: Ingo Molnar
Signed-off-by: Andi Kleen
Signed-off-by: Linus Torvalds
17 Jul, 2007
1 commit
-
Currently we handle spurious IRQ activity based upon seeing a lot of
invalid interrupts, and we clear things back on the base of lots of valid
interrupts.Unfortunately in some cases you get legitimate invalid interrupts caused by
timing asynchronicity between the PCI bus and the APIC bus when disabling
interrupts and pulling other tricks. In this case although the spurious
IRQs are not a problem our unhandled counters didn't clear and they act as
a slow running timebomb. (This is effectively what the serial port/tty
problem that was fixed by clearing counters when registering a handler
showed up)It's easy enough to add a second parameter - time. This means that if we
see a regular stream of harmless spurious interrupts which are not harming
processing we don't go off and do something stupid like disable the IRQ
after a month of running. OTOH lockups and performance killers show up a
lot more than 10/second[akpm@linux-foundation.org: cleanup]
Signed-off-by: Alan Cox
Cc: Ingo Molnar
Cc: Thomas Gleixner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
24 May, 2007
1 commit
-
With irqpoll enabled, trying to test the IRQF_IRQPOLL flag in the
actions would cause a NULL pointer dereference if no action was
installed (for example, the driver might have been unloaded with
interrupts still pending).So be a bit more careful about testing the flag by making sure to test
for that case.(The actual _change_ is trivial, the patch is more than a one-liner
because I rewrote the testing to also be much more readable.Original (discarded) bugfix by Bernhard Walle.
Cc: Bernhard Walle
Tested-by: Vivek Goyal
Signed-off-by: Linus Torvalds
12 May, 2007
1 commit
-
On SN, only allow one bit to be set in the smp_affinty mask when
redirecting an interrupt. Currently setting multiple bits is allowed, but
only the first bit is used in determining the CPU to redirect to. This has
caused confusion among some customers.[akpm@linux-foundation.org: fixes]
Signed-off-by: John Keller
Signed-off-by: Andrew Morton
Signed-off-by: Tony Luck
10 May, 2007
1 commit
-
A linuxdoc comment had fallen out of date - it refers to an argument which no
longer exists.Signed-off-by: Jeff Dike
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
09 May, 2007
4 commits
-
irqpoll is broken on some architectures that don't use the IRQ 0 for the timer
interrupt like IA64. This patch adds a IRQF_IRQPOLL flag.Each architecture is handled in a separate pach. As I left the irq == 0 as
condition, this should not break existing architectures that use timer_irq ==
0 and that I did't address with that patch (because I don't know).This patch:
This patch adds a IRQF_IRQPOLL flag that the interrupt registration code could
use for the interrupt it wants to use for IRQ polling.Because this must not be the timer interrupt, an additional flag was added
instead of re-using the IRQF_TIMER constant. Until all architectures will
have an IRQF_IRQPOLL interrupt, irq == 0 will stay as alternative as it should
not break anything.Also, note_interrupt() is called on CPU-specific interrupts to be used as
interrupt source for IRQ polling.Signed-off-by: Bernhard Walle
Cc: Russell King
Cc: Kyle McMartin
Cc: Matthew Wilcox
Cc: Grant Grundler
Cc: Paul Mundt
Cc: "Luck, Tony"
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Alan Cox
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
We noticed a drop in n/w performance due to the irq_desc being cacheline
aligned rather than internode aligned. We see 50% of expected performance
when two e1000 nics local to two different nodes have consecutive irq
descriptors allocated, due to false sharing.Note that this patch does away with cacheline padding for the UP case, as
it does not seem useful for UP configurations.Signed-off-by: Ravikiran Thirumalai
Signed-off-by: Shai Fultheim
Cc: "Siddha, Suresh B"
Cc: Ingo Molnar
Cc: Thomas Gleixner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
An irqaction structure won't be added to an IRQ descriptor irqaction list if
it doesn't agree with other irqactions on the IRQF_PERCPU flag. Don't check
for this flag to change IRQ descriptor `status' for every irqaction added to
the list, Doing the check only for the first irqaction added is enough.Signed-off-by: Ahmed S. Darwish
Cc: Ingo Molnar
Cc: Thomas Gleixner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
setup_irq() releases a desc->lock before calling register_handler_proc(), so
the iteration over the IRQ action list is not protected.(akpm: the check itself is still racy, but at least it probably won't oops
now).Cc: Ingo Molnar
Cc: Thomas Gleixner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
03 May, 2007
1 commit
-
set_irq_msi() currently connects an irq_desc to an msi_desc. The archs call
it at some point in their setup routine, and then the generic code sets up the
reverse mapping from the msi_desc back to the irq.set_irq_msi() should do both connections, making it the one and only call
required to connect an irq with it's MSI desc and vice versa.The arch code MUST call set_irq_msi(), and it must do so only once it's sure
it's not going to fail the irq allocation.Given that there's no need for the arch to return the irq anymore, the return
value from the arch setup routine just becomes 0 for success and anything else
for failure.Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman
08 Apr, 2007
1 commit
-
devres should be deallocated with devres_free() not kfree(). This bug
corrupts slab on IRQ request failure. Fix it.Signed-off-by: Tejun Heo
Cc: Andrew Morton
Cc: Greg KH
Signed-off-by: Linus Torvalds
27 Feb, 2007
1 commit
-
move_native_irqs tries to do the right thing when migrating irqs
by disabling them. However disabling them is a software logical
thing, not a hardware thing. This has always been a little flaky
and after Ingo's latest round of changes it is guaranteed to not
mask the apic.So this patch fixes move_native_irq to directly call the mask and
unmask chip methods to guarantee that we mask the irq when we
are migrating it. We must do this as it is required by
all code that call into the path.Since we don't know the masked status when IRQ_DISABLED is
set so we will not be able to restore it. The patch makes the code
just give up and trying again the next time this routing is called.Signed-off-by: Eric W. Biederman
Acked-by: Suresh Siddha
Signed-off-by: Linus Torvalds
17 Feb, 2007
5 commits
-
Use mask_ack_irq() where possible.
Signed-off-by: Jan Beulich
Cc: Thomas Gleixner
Cc: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Fix kernel-doc warnings in IRQ management.
Signed-off-by: Randy Dunlap
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Never mask interrupts immediately upon request. Disabling interrupts in
high-performance codepaths is rare, and on the other hand this change could
recover lost edges (or even other types of lost interrupts) by conservatively
only masking interrupts after they happen. (NOTE: with this change the
highlevel irq-disable code still soft-disables this IRQ line - and if such an
interrupt happens then the IRQ flow handler keeps the IRQ masked.)Mark i8529A controllers as 'never loses an edge'.
Signed-off-by: Ingo Molnar
Cc: Thomas Gleixner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Provide funtions to:
- check, whether an interrupt can set the affinity
- pin the interrupt to a given cpuNecessary for the ability to setup clocksources more flexible (e.g. use the
different HPET channels per CPU)[akpm@osdl.org: alpha build fix]
Signed-off-by: Thomas Gleixner
Signed-off-by: Ingo Molnar
Cc: john stultz
Cc: Roman Zippel
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Add a flag so we can prevent the irq balancing of an interrupt. Move the
bits, so we have room for more :)Necessary for the ability to setup clocksources more flexible (e.g. use the
different HPET channels per CPU)Signed-off-by: Thomas Gleixner
Signed-off-by: Ingo Molnar
Cc: john stultz
Cc: Roman Zippel
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
15 Feb, 2007
1 commit
-
The obsolete SA_xxx interrupt flags have been used despite the scheduled
removal. Fixup the remaining users.Signed-off-by: Thomas Gleixner
Acked-by: Ingo Molnar
Cc: "Luck, Tony"
Cc: Roman Zippel
Cc: Geert Uytterhoeven
Cc: Jeff Garzik
Cc: Wim Van Sebroeck
Cc: Roland Dreier
Cc: Alessandro Zummo
Cc: James Bottomley
Cc: Greg KH
Cc: Dave Airlie
Cc: James Simmons
Cc: "Antonino A. Daplas"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
13 Feb, 2007
2 commits
-
The problem is various drivers legally validly and sensibly try to claim
IRQs but the kernel insists on vomiting forth a giant irrelevant debugging
spew when the types clash.Edit kernel/irq/manage.c go down to mismatch: in setup_irq() and ifdef out
the if clause that checks for mismatches. It'll then just do the right
thing and work sanely.For the current -mm kernel this will do the trick (and moves it into shared
irq debugging as in debug mode the info spew is useful). I've had a
variant of this in my private tree for some time as I got fed up on the
mess on boxes where old legacy IRQs get reused.Signed-off-by: Alan Cox
Cc: Arjan van de Ven
Cc: Ingo Molnar
Cc: David Woodhouse
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Drivers registering IRQ handlers with SA_SHIRQ really ought to be able to
handle an interrupt happening before request_irq() returns. They also
ought to be able to handle an interrupt happening during the start of their
call to free_irq(). Let's test that hypothesis....[bunk@stusta.de: Kconfig fixes]
Signed-off-by: David Woodhouse
Cc: Arjan van de Ven
Signed-off-by: Jesper Juhl
Signed-off-by: Ingo Molnar
Signed-off-by: Adrian Bunk
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
12 Feb, 2007
1 commit
-
* Split the implementation-agnostic stuff in separate files.
* Make sure that targets using non-default request_irq() pull
kernel/irq/devres.o
* Introduce new symbols (HAS_IOPORT and HAS_IOMEM) defaulting to positive;
allow architectures to turn them off (we needed these symbols anyway for
dependencies of quite a few drivers).
* protect the ioport-related parts of lib/devres.o with CONFIG_HAS_IOPORT.Signed-off-by: Al Viro
Signed-off-by: Linus Torvalds