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
2 commits
-
* 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 -
Bug: pnx8550 code creates directory but resets ->nlink to 1.
create_proc_entry() et al will correctly set ->nlink for you.
Signed-off-by: Alexey Dobriyan
Cc: Ralf Baechle
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Jeff Dike
Cc: Corey Minyard
Cc: Alan Cox
Cc: Kyle McMartin
Cc: Martin Schwidefsky
Cc: Greg KH
Cc: Ingo Molnar
Cc: Thomas Gleixner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
10 Feb, 2007
1 commit
-
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).This patch adds devres core including documentation and the following
managed interfaces.* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()Signed-off-by: Tejun Heo
Signed-off-by: Jeff Garzik
08 Feb, 2007
1 commit
-
We need to be able to get from an irq number to a struct msi_desc.
The msi_desc array in msi.c had several short comings the big one was
that it could not be used outside of msi.c. Using irq_data in struct
irq_desc almost worked except on some architectures irq_data needs to
be used for something else.So this patch adds a msi_desc pointer to irq_desc, adds the appropriate
wrappers and changes all of the msi code to use them.The dynamic_irq_init/cleanup code was tweaked to ensure the new
field is left in a well defined state.Signed-off-by: Eric W. Biederman
Acked-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
24 Jan, 2007
1 commit
-
Any newly added irq handler may obviously make any old spurious irq
status invalid, since the new handler may well be the thing that is
supposed to handle any interrupts that came in.So just clear the statistics when adding handlers.
Pointed-out-by: Alan Cox
Acked-by: Thomas Gleixner
Acked-by: Ingo Molnar
Signed-off-by: Linus Torvalds
11 Jan, 2007
1 commit
-
o noirqdebug_setup() is __init but it is being called by
quirk_intel_irqbalance() which if of type __devinit. If CONFIG_HOTPLUG=y,
quirk_intel_irqbalance() is put into text section and it is wrong to
call a function in __init section.o MODPOST flags this on i386 if CONFIG_RELOCATABLE=y
WARNING: vmlinux - Section mismatch: reference to .init.text:noirqdebug_setup from .text between 'quirk_intel_irqbalance' (at offset 0xc010969e) and 'i8237A_suspend'
o Make noirqdebug_setup() non-init.
Signed-off-by: Vivek Goyal
Signed-off-by: Andi Kleen
23 Dec, 2006
1 commit
-
The sanity check for no_irq_chip in __set_irq_hander() is unconditional on
both install and uninstall of an handler. This triggers false warnings and
replaces no_irq_chip by dummy_irq_chip in the uninstall case.Check only, when a real handler is installed.
Signed-off-by: Thomas Gleixner
Acked-by: Ingo Molnar
Acked-by: Sylvain Munaut
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
21 Dec, 2006
1 commit
-
__set_irq_handler: Kill a bogus space
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Linus Torvalds
09 Dec, 2006
1 commit
-
While running my MCA test (hardware error injection) on 2.6.19,
I got some warning like following:> BUG: warning at kernel/irq/migration.c:27/move_masked_irq()
>
> Call Trace:
> [] show_stack+0x40/0xa0
> sp=e00000006b2578d0 bsp=e00000006b2510b0
> [] dump_stack+0x30/0x60
> sp=e00000006b257aa0 bsp=e00000006b251098
> [] move_masked_irq+0xb0/0x240
> sp=e00000006b257aa0 bsp=e00000006b251070
> [] move_native_irq+0xe0/0x180
> sp=e00000006b257aa0 bsp=e00000006b251040
> [] iosapic_end_level_irq+0x30/0xe0
> sp=e00000006b257aa0 bsp=e00000006b251020
> [] __do_IRQ+0x170/0x400
> sp=e00000006b257aa0 bsp=e00000006b250fd8
> [] ia64_handle_irq+0x1b0/0x260
> sp=e00000006b257aa0 bsp=e00000006b250fa8
> [] ia64_leave_kernel+0x0/0x280
> sp=e00000006b257aa0 bsp=e00000006b250fa8
> [] _spin_unlock_irqrestore+0x30/0x60
> sp=e00000006b257c70 bsp=e00000006b250f90It comes from:
[kernel/irq/migration.c]
26 if (CHECK_IRQ_PER_CPU(desc->status)) {
27 WARN_ON(1);
28 return;
29 }By putting some printk in kernel, I found that irqbalance is trying to
move CPEI which is handled as PER_CPU irq. That's why.CPEI(Corrected Platform Error Interrupt) is ia64 specific irq, is
allowed to pin to particular processor which selected by the platform, and
even it is PER_CPU but it has set_affinity handler (=iosapic_set_affinity)
as same as other IO-SAPIC-level interrupts. (I don't know why, but
I guess that there would be typical situation where the handler for
migration is needed, such as hotplug - the processor going to be
offline/hot-removed.)To shut up this warning, there are 2 way at least:
a) fix CPEI stuff
b) prohibit setting affinity to PER_CPU irqI'm not sure what stuff of CPEI need to be fixed, but I think that
returning error to attempting move PER_CPU irq is useful for all
applications since it will never work.Following small patch takes b) style.
It works, the warning disappeared and irqbalance still runs well.Signed-off-by: Hidetoshi Seto
Cc: Arjan van de Ven
Acked-by: Ingo Molnar
Acked-by: Thomas Gleixner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
08 Dec, 2006
1 commit
-
Name some of the remaning 'old_style_spin_init' locks
Signed-off-by: Peter Zijlstra
Acked-by: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
23 Nov, 2006
1 commit
-
This reverts commit f72fa707604c015a6625e80f269506032d5430dc, and solves
the problem that it tried to fix by simply making "__do_IRQ()" call the
note_interrupt() function without the lock held, the way everybody else
does.It should be noted that all interrupt handling code must never allow the
descriptor actors to be entered "recursively" (that's why we do all the
magic IRQ_PENDING stuff in the first place), so there actually is
exclusion at that much higher level, even in the absense of locking.Acked-by: Vivek Goyal
Acked-by:Pavel Emelianov
Cc: Andrew Morton
Cc: Ingo Molnar
Cc: Adrian Bunk
Signed-off-by: Linus Torvalds
17 Nov, 2006
1 commit
-
I got an oops when booting 2.6.19-rc5-mm1 on my ia64 machine.
Below is the log.
Oops 11012296146944 [1]
Modules linked in: binfmt_misc dm_mirror dm_multipath dm_mod thermal processor f
an container button sg eepro100 e100 miiPid: 0, CPU 0, comm: swapper
psr : 0000121008022038 ifs : 800000000000040b ip : [] Not
tainted
ip is at __do_IRQ+0x371/0x3e0
unat: 0000000000000000 pfs : 000000000000040b rsc : 0000000000000003
rnat: 656960155aa56aa5 bsps: a00000010058b890 pr : 656960155aa55a65
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c0270033f
csd : 0000000000000000 ssd : 0000000000000000
b0 : a0000001000e1390 b6 : a0000001005beac0 b7 : e00000007f01aa00
f6 : 000000000000000000000 f7 : 0ffe69090000000000000
f8 : 1000a9090000000000000 f9 : 0ffff8000000000000000
f10 : 1000a908ffffff6f70000 f11 : 1003e0000000000000909
r1 : a000000100fbbff0 r2 : 0000000000010002 r3 : 0000000000010001
r8 : fffffffffffbffff r9 : a000000100bd8060 r10 : a000000100dd83b8
r11 : fffffffffffeffff r12 : a000000100bcbbb0 r13 : a000000100bc4000
r14 : 0000000000010000 r15 : 0000000000010000 r16 : a000000100c01aa8
r17 : a000000100d2c350 r18 : 0000000000000000 r19 : a000000100d2c300
r20 : a000000100c01a88 r21 : 0000000080010100 r22 : a000000100c01ac0
r23 : a0000001000108e0 r24 : e000000477980004 r25 : 0000000000000000
r26 : 0000000000000000 r27 : e00000000913400c r28 : e0000004799ee51c
r29 : e0000004778b87f0 r30 : a000000100d2c300 r31 : a00000010005c7e0Call Trace:
[] show_stack+0x40/0xa0
sp=a000000100bcb760 bsp=a000000100bc4f40
[] show_regs+0x840/0x880
sp=a000000100bcb930 bsp=a000000100bc4ee8
[] die+0x250/0x320
sp=a000000100bcb930 bsp=a000000100bc4ea0
[] ia64_do_page_fault+0x8d0/0xa20
sp=a000000100bcb950 bsp=a000000100bc4e50
[] ia64_leave_kernel+0x0/0x290
sp=a000000100bcb9e0 bsp=a000000100bc4e50
[] __do_IRQ+0x370/0x3e0
sp=a000000100bcbbb0 bsp=a000000100bc4df0
[] ia64_handle_irq+0x170/0x220
sp=a000000100bcbbb0 bsp=a000000100bc4dc0
[] ia64_leave_kernel+0x0/0x290
sp=a000000100bcbbb0 bsp=a000000100bc4dc0
[] ia64_pal_call_static+0x90/0xc0
sp=a000000100bcbd80 bsp=a000000100bc4d78
[] default_idle+0x90/0x160
sp=a000000100bcbd80 bsp=a000000100bc4d58
[] cpu_idle+0x1f0/0x440
sp=a000000100bcbe20 bsp=a000000100bc4d18
[] rest_init+0xc0/0xe0
sp=a000000100bcbe20 bsp=a000000100bc4d00
[] start_kernel+0x6a0/0x6c0
sp=a000000100bcbe20 bsp=a000000100bc4ca0
[] __end_ivt_text+0x6d0/0x6f0
sp=a000000100bcbe30 bsp=a000000100bc4c00
Kernel panic - not syncing: Aiee, killing interrupt handler!The root cause is that some irq_chip variables, especially ia64_msi_chip,
initiate their memeber end to point to NULL. __do_IRQ doesn't check
if irq_chip->end is null and just calls it after processing the interrupt.As irq_chip->end is called at many places, so I fix it by reinitiating
irq_chip->end to dummy_irq_chip.end, e.g., a noop function.Signed-off-by: Zhang Yanmin
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "Luck, Tony"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
15 Nov, 2006
1 commit
-
When we get a mismatch between handlers on the same IRQ, all we get is "IRQ
handler type mismatch for IRQ n". Let's print the name of the
presently-registered handler with which we got the mismatch.Cc: Ingo Molnar
Cc: Thomas Gleixner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
13 Nov, 2006
1 commit
-
While testing kernel on machine with "irqpoll" option I've caught such a
lockup:__do_IRQ()
spin_lock(&desc->lock);
desc->chip->ack(); /* IRQ is ACKed */
note_interrupt()
misrouted_irq()
handle_IRQ_event()
if (...)
local_irq_enable_in_hardirq();
/* interrupts are enabled from now */
...
__do_IRQ() /* same IRQ we've started from */
spin_lock(&desc->lock); /* LOCKUP */Looking at misrouted_irq() code I've found that a potential deadlock like
this can also take place:1CPU:
__do_IRQ()
spin_lock(&desc->lock); /* irq = A */
misrouted_irq()
for (i = 1; i < NR_IRQS; i++) {
spin_lock(&desc->lock); /* irq = B */
if (desc->status & IRQ_INPROGRESS) {2CPU:
__do_IRQ()
spin_lock(&desc->lock); /* irq = B */
misrouted_irq()
for (i = 1; i < NR_IRQS; i++) {
spin_lock(&desc->lock); /* irq = A */
if (desc->status & IRQ_INPROGRESS) {As the second lock on both CPUs is taken before checking that this irq is
being handled in another processor this may cause a deadlock. This issue
is only theoretical.I propose the attached patch to fix booth problems: when trying to handle
misrouted IRQ active desc->lock may be unlocked.Acked-by: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Oct, 2006
1 commit
-
Introduce desc->name and eliminate the handle_irq_name() hack. Add
set_irq_chip_and_handler_name() to set the flow type and name at once.Signed-off-by: Ingo Molnar
Acked-by: Thomas Gleixner
Cc: "Eric W. Biederman"
Cc: Matthew Wilcox
Cc: Kyle McMartin
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
12 Oct, 2006
1 commit
-
lib/bitmap.c:bitmap_parse() is a library function that received as input a
user buffer. This seemed to have originated from the way the write_proc
function of the /proc filesystem operates.This has been reworked to not use kmalloc and eliminates a lot of
get_user() overhead by performing one access_ok before using __get_user().We need to test if we are in kernel or user space (is_user) and access the
buffer differently. We cannot use __get_user() to access kernel addresses
in all cases, for example in architectures with separate address space for
kernel and user.This function will be useful for other uses as well; for example, taking
input for /sysfs instead of /proc, so it was changed to accept kernel
buffers. We have this use for the Linux UWB project, as part as the
upcoming bandwidth allocator code.Only a few routines used this function and they were changed too.
Signed-off-by: Reinette Chatre
Signed-off-by: Inaky Perez-Gonzalez
Cc: Paul Jackson
Cc: Joe Korty
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 Oct, 2006
1 commit
-
With the following patch, the ixp4xxdefconfig builds correctly. I'll
test some more configs if I get some time.Signed-off-by: Frederik Deweerdt
Signed-off-by: Linus Torvalds
05 Oct, 2006
3 commits
-
Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
of passing regs around manually through all ~1800 interrupt handlers in the
Linux kernel.The regs pointer is used in few places, but it potentially costs both stack
space and code to pass it around. On the FRV arch, removing the regs parameter
from all the genirq function results in a 20% speed up of the IRQ exit path
(ie: from leaving timer_interrupt() to leaving do_IRQ()).Where appropriate, an arch may override the generic storage facility and do
something different with the variable. On FRV, for instance, the address is
maintained in GR28 at all times inside the kernel as part of general exception
handling.Having looked over the code, it appears that the parameter may be handed down
through up to twenty or so layers of functions. Consider a USB character
device attached to a USB hub, attached to a USB controller that posts its
interrupts through a cascaded auxiliary interrupt controller. A character
device driver may want to pass regs to the sysrq handler through the input
layer which adds another few layers of parameter passing.I've build this code with allyesconfig for x86_64 and i386. I've runtested the
main part of the code on FRV and i386, though I can't test most of the drivers.
I've also done partial conversion for powerpc and MIPS - these at least compile
with minimal configurations.This will affect all archs. Mostly the changes should be relatively easy.
Take do_IRQ(), store the regs pointer at the beginning, saving the old one:struct pt_regs *old_regs = set_irq_regs(regs);
And put the old one back at the end:
set_irq_regs(old_regs);
Don't pass regs through to generic_handle_irq() or __do_IRQ().
In timer_interrupt(), this sort of change will be necessary:
- update_process_times(user_mode(regs));
- profile_tick(CPU_PROFILING, regs);
+ update_process_times(user_mode(get_irq_regs()));
+ profile_tick(CPU_PROFILING);I'd like to move update_process_times()'s use of get_irq_regs() into itself,
except that i386, alone of the archs, uses something other than user_mode().Some notes on the interrupt handling in the drivers:
(*) input_dev() is now gone entirely. The regs pointer is no longer stored in
the input_dev struct.(*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does
something different depending on whether it's been supplied with a regs
pointer or not.(*) Various IRQ handler function pointers have been moved to type
irq_handler_t.Signed-Off-By: David Howells
(cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit) -
Typedef the IRQ handler function type.
Signed-Off-By: David Howells
(cherry picked from 1356d1e5fd256997e3d3dce0777ab787d0515c7a commit) -
Typedef the IRQ flow handler function type.
Signed-Off-By: David Howells
(cherry picked from 8e973fbdf5716b93a0a8c0365be33a31ca0fa351 commit)
04 Oct, 2006
4 commits
-
Currently msi.c is doing sanity checks that make certain before an irq is
destroyed it has no more users.By adding irq_has_action I can perform the test is a generic way, instead of
relying on a msi specific data structure.By performing the core check in dynamic_irq_cleanup I ensure every user of
dynamic irqs has a test present and we don't free resources that are in use.In msi.c this allows me to kill the attrib.state member of msi_desc and all of
the assciated code to maintain it.To keep from freeing data structures when irq cleanup code is called to soon
changing dyanamic_irq_cleanup is insufficient because there are msi specific
data structures that are also not safe to free.Signed-off-by: Eric W. Biederman
Cc: Ingo Molnar
Cc: Tony Luck
Cc: Andi Kleen
Cc: Thomas Gleixner
Cc: Greg KH
Cc: Benjamin Herrenschmidt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
With the msi support comes a new concept in irq handling, irqs that are
created dynamically at run time.Currently the msi code allocates irqs backwards. First it allocates a
platform dependent routing value for an interrupt the ``vector'' and then it
figures out from the vector which irq you are on.This msi backwards allocator suffers from two basic problems. The allocator
suffers because it is trying to do something that is architecture specific in
a generic way making it brittle, inflexible, and tied to tightly to the
architecture implementation. The alloctor also suffers from it's very
backwards nature as it has tied things together that should have no
dependencies.To solve the basic dynamic irq allocation problem two new architecture
specific functions are added: create_irq and destroy_irq.create_irq takes no input and returns an unused irq number, that won't be
reused until it is returned to the free poll with destroy_irq. The irq then
can be used for any purpose although the only initial consumer is the msi
code.destroy_irq takes an irq number allocated with create_irq and returns it to
the free pool.Making this functionality per architecture increases the simplicity of the irq
allocation code and increases it's flexibility.dynamic_irq_init() and dynamic_irq_cleanup() are added to automate the
irq_desc initializtion that should happen for dynamic irqs.Signed-off-by: Eric W. Biederman
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Benjamin Herrenschmidt
Cc: Rajesh Shah
Cc: Andi Kleen
Cc: "Protasevich, Natalie"
Cc: "Luck, Tony"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Currently move_native_irq disables and renables the irq we are migrating to
ensure we don't take that irq when we are actually doing the migration
operation. Disabling the irq needs to happen but sometimes doing the work is
move_native_irq is too late.On x86 with ioapics the irq move sequences needs to be:
edge_triggered:
mask irq.
move irq.
unmask irq.
ack irq.
level_triggered:
mask irq.
ack irq.
move irq.
unmask irq.We can easily perform the edge triggered sequence, with the current defintion
of move_native_irq. However the level triggered case does not map well. For
that I have added move_masked_irq, to allow me to disable the irqs around both
the ack and the move.Q: Why have we not seen this problem earlier?
A: The only symptom I have been able to reproduce is that if we change
the vector before acknowleding an irq the wrong irq is acknowledged.
Since we currently are not reprogramming the irq vector during
migration no problems show up.We have to mask the irq before we acknowledge the irq or else we could
hit a window where an irq is asserted just before we acknowledge it.Edge triggered irqs do not have this problem because acknowledgements
do not propogate in the same way.Signed-off-by: Eric W. Biederman
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Benjamin Herrenschmidt
Cc: Rajesh Shah
Cc: Andi Kleen
Cc: "Protasevich, Natalie"
Cc: "Luck, Tony"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The primary aim of this patchset is to remove maintenances problems caused by
the irq infrastructure. The two big issues I address are an artificially
small cap on the number of irqs, and that MSI assumes vector == irq. My
primary focus is on x86_64 but I have touched other architectures where
necessary to keep them from breaking.- To increase the number of irqs I modify the code to look at the (cpu,
vector) pair instead of just looking at the vector.With a large number of irqs available systems with a large irq count no
longer need to compress their irq numbers to fit. Removing a lot of brittle
special cases.For acpi guys the result is that irq == gsi.
- Addressing the fact that MSI assumes irq == vector takes a few more
patches. But suffice it to say when I am done none of the generic irq code
even knows what a vector is.In quick testing on a large Unisys x86_64 machine we stumbled over at least
one driver that assumed that NR_IRQS could always fit into an 8 bit number.
This driver is clearly buggy today. But this has become a class of bugs that
it is now much easier to hit.This patch:
This is a minor space optimization. In practice I don't think this has any
affect because of our alignment constraints and the other fields but there is
not point in chewing up an uncessary word and since we already read the flag
field this should improve the cache hit ratio of the irq handler.Signed-off-by: Eric W. Biederman
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Benjamin Herrenschmidt
Cc: Rajesh Shah
Cc: Andi Kleen
Cc: "Protasevich, Natalie"
Cc: "Luck, Tony"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
30 Sep, 2006
2 commits
-
Signed-off-by: Yoichi Yuasa
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Signed-off-by: Yoichi Yuasa
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
26 Sep, 2006
1 commit
-
Permit __do_IRQ() to be dispensed with based on a configuration option.
Signed-off-by: David Howells
Cc: Benjamin Herrenschmidt
Cc: Thomas Gleixner
Cc: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
19 Sep, 2006
1 commit
-
while porting the -rt tree to 2.6.18-rc7 i noticed the following
screaming-IRQ scenario on an SMP system:2274 0Dn.:1 0.001ms: do_IRQ+0xc/0x103
Signed-off-by: Thomas Gleixner
Acked-by: Benjamin Herrenschmidt
Signed-off-by: Linus Torvalds
17 Sep, 2006
1 commit
-
Fix a bug where the IRQ_PENDING flag is never cleared and the ISR is called
endlessly without an actual interrupt.Signed-off-by: Imre Deak
Acked-by: Thomas Gleixner
Acked-by: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
02 Sep, 2006
1 commit
-
Adds the description of the parameters from handle_bad_irq().
Signed-off-by: Henrik Kretzschmar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
