1. 17 2月, 2007 1 次提交
  2. 08 2月, 2007 1 次提交
    • E
      msi: Kill the msi_desc array. · 5b912c10
      Eric W. Biederman 提交于
      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: NEric W. Biederman <ebiederm@xmission.com>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      5b912c10
  3. 23 12月, 2006 1 次提交
  4. 21 12月, 2006 1 次提交
  5. 17 11月, 2006 1 次提交
    • Z
      [PATCH] some irq_chip variables point to NULL · b86432b4
      Zhang, Yanmin 提交于
      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 mii
      
      Pid: 0, CPU 0, comm:              swapper
      psr : 0000121008022038 ifs : 800000000000040b ip  : [<a0000001000e1411>]    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 : a00000010005c7e0
      
      Call Trace:
       [<a000000100014600>] show_stack+0x40/0xa0
                                      sp=a000000100bcb760 bsp=a000000100bc4f40
       [<a000000100014f00>] show_regs+0x840/0x880
                                      sp=a000000100bcb930 bsp=a000000100bc4ee8
       [<a000000100037fb0>] die+0x250/0x320
                                      sp=a000000100bcb930 bsp=a000000100bc4ea0
       [<a00000010005e5f0>] ia64_do_page_fault+0x8d0/0xa20
                                      sp=a000000100bcb950 bsp=a000000100bc4e50
       [<a00000010000caa0>] ia64_leave_kernel+0x0/0x290
                                      sp=a000000100bcb9e0 bsp=a000000100bc4e50
       [<a0000001000e1410>] __do_IRQ+0x370/0x3e0
                                      sp=a000000100bcbbb0 bsp=a000000100bc4df0
       [<a000000100011f50>] ia64_handle_irq+0x170/0x220
                                      sp=a000000100bcbbb0 bsp=a000000100bc4dc0
       [<a00000010000caa0>] ia64_leave_kernel+0x0/0x290
                                      sp=a000000100bcbbb0 bsp=a000000100bc4dc0
       [<a000000100012390>] ia64_pal_call_static+0x90/0xc0
                                      sp=a000000100bcbd80 bsp=a000000100bc4d78
       [<a000000100015630>] default_idle+0x90/0x160
                                      sp=a000000100bcbd80 bsp=a000000100bc4d58
       [<a000000100014290>] cpu_idle+0x1f0/0x440
                                      sp=a000000100bcbe20 bsp=a000000100bc4d18
       [<a000000100009980>] rest_init+0xc0/0xe0
                                      sp=a000000100bcbe20 bsp=a000000100bc4d00
       [<a0000001009f8ea0>] start_kernel+0x6a0/0x6c0
                                      sp=a000000100bcbe20 bsp=a000000100bc4ca0
       [<a0000001000089f0>] __end_ivt_text+0x6d0/0x6f0
                                      sp=a000000100bcbe30 bsp=a000000100bc4c00
       <0>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: NZhang Yanmin <yanmin.zhang@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b86432b4
  6. 17 10月, 2006 1 次提交
  7. 05 10月, 2006 2 次提交
    • D
      IRQ: Maintain regs pointer globally rather than passing to IRQ handlers · 7d12e780
      David Howells 提交于
      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: NDavid Howells <dhowells@redhat.com>
      (cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
      7d12e780
    • D
      IRQ: Typedef the IRQ flow handler function type · 57a58a94
      David Howells 提交于
      Typedef the IRQ flow handler function type.
      Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      (cherry picked from 8e973fbdf5716b93a0a8c0365be33a31ca0fa351 commit)
      57a58a94
  8. 04 10月, 2006 2 次提交
    • E
      [PATCH] msi: simplify msi sanity checks by adding with generic irq code · 1f80025e
      Eric W. Biederman 提交于
      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: NEric W. Biederman <ebiederm@xmission.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Greg KH <greg@kroah.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1f80025e
    • E
      [PATCH] genirq: irq: add a dynamic irq creation API · 3a16d713
      Eric W. Biederman 提交于
      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: NEric W. Biederman <ebiederm@xmission.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rajesh Shah <rajesh.shah@intel.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3a16d713
  9. 30 9月, 2006 2 次提交
  10. 19 9月, 2006 1 次提交
    • I
      [PATCH] genirq core: fix handle_level_irq() · 86998aa6
      Ingo Molnar 提交于
      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  <= (ret_from_intr+0x0/0xf)
       2274  0Dn.:1 0.010ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
       2274  0Dn.:1 0.020ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
       2274  0Dn.:1 0.029ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
       2274  0Dn.:1 0.039ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
       2274  0Dn.:1 0.048ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
       2274  0Dn.:1 0.058ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
       2274  0Dn.:1 0.068ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
       2274  0Dn.:1 0.077ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
       2274  0Dn.:1 0.087ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
       2274  0Dn.:1 0.097ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
      
      as it turns out, the bug is caused by handle_level_irq(), which if it
      races with another CPU already handling this IRQ, it _unmasks_ the IRQ
      line on the way out. This is not how 2.6.17 works, and we introduced
      this bug in one of the early genirq cleanups right before it went into
      -mm. (the bug was not in the genirq patchset for a long time, and we
      didnt notice the bug due to the lack of -rt rebase to the new genirq
      code. -rt, and hardirq-preemption in particular opens up such races much
      wider than anything else.)
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      86998aa6
  11. 03 7月, 2006 1 次提交
  12. 02 7月, 2006 1 次提交
  13. 30 6月, 2006 3 次提交