1. 03 11月, 2011 1 次提交
  2. 03 6月, 2011 2 次提交
  3. 29 3月, 2011 2 次提交
  4. 28 3月, 2011 1 次提交
  5. 19 2月, 2011 15 次提交
  6. 04 10月, 2010 3 次提交
  7. 15 12月, 2009 1 次提交
  8. 04 12月, 2009 1 次提交
  9. 08 11月, 2009 1 次提交
    • Y
      genirq: try_one_irq() must be called with irq disabled · e7e7e0c0
      Yong Zhang 提交于
      Prarit reported:
      =================================
      [ INFO: inconsistent lock state ]
      2.6.32-rc5 #1
      ---------------------------------
      inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
      swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
       (&irq_desc_lock_class){?.-...}, at: [<ffffffff810c264e>] try_one_irq+0x32/0x138
      {IN-HARDIRQ-W} state was registered at:
       [<ffffffff81095160>] __lock_acquire+0x2fc/0xd5d
       [<ffffffff81095cb4>] lock_acquire+0xf3/0x12d
       [<ffffffff814cdadd>] _spin_lock+0x40/0x89
       [<ffffffff810c3389>] handle_level_irq+0x30/0x105
       [<ffffffff81014e0e>] handle_irq+0x95/0xb7
       [<ffffffff810141bd>] do_IRQ+0x6a/0xe0
       [<ffffffff81012813>] ret_from_intr+0x0/0x16
      irq event stamp: 195096
      hardirqs last  enabled at (195096): [<ffffffff814cd7f7>] _spin_unlock_irq+0x3a/0x5c
      hardirqs last disabled at (195095): [<ffffffff814cdbdd>] _spin_lock_irq+0x29/0x95
      softirqs last  enabled at (195088): [<ffffffff81068c92>] __do_softirq+0x1c1/0x1ef
      softirqs last disabled at (195093): [<ffffffff8101304c>] call_softirq+0x1c/0x30
      
      other info that might help us debug this:
      1 lock held by swapper/0:
       #0:  (kernel/irq/spurious.c:21){+.-...}, at: [<ffffffff81070cf2>]
      run_timer_softirq+0x1a9/0x315
      
      stack backtrace:
      Pid: 0, comm: swapper Not tainted 2.6.32-rc5 #1
      Call Trace:
       <IRQ>  [<ffffffff81093e94>] valid_state+0x187/0x1ae
       [<ffffffff81093fe4>] mark_lock+0x129/0x253
       [<ffffffff810951d4>] __lock_acquire+0x370/0xd5d
       [<ffffffff81095cb4>] lock_acquire+0xf3/0x12d
       [<ffffffff814cdadd>] _spin_lock+0x40/0x89
       [<ffffffff810c264e>] try_one_irq+0x32/0x138
       [<ffffffff810c2795>] poll_all_shared_irqs+0x41/0x6d
       [<ffffffff810c27dd>] poll_spurious_irqs+0x1c/0x49
       [<ffffffff81070d82>] run_timer_softirq+0x239/0x315
       [<ffffffff81068bd3>] __do_softirq+0x102/0x1ef
       [<ffffffff8101304c>] call_softirq+0x1c/0x30
       [<ffffffff81014b65>] do_softirq+0x59/0xca
       [<ffffffff810686ad>] irq_exit+0x58/0xae
       [<ffffffff81029b84>] smp_apic_timer_interrupt+0x94/0xba
       [<ffffffff81012a33>] apic_timer_interrupt+0x13/0x20
      
      The reason is that try_one_irq() is called from hardirq context with
      interrupts disabled and from softirq context (poll_all_shared_irqs())
      with interrupts enabled.
      
      Disable interrupts before calling it from poll_all_shared_irqs().
      Reported-and-tested-by: NPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: NYong Zhang <yong.zhang0@gmail.com>
      LKML-Reference: <1257563773-4620-1-git-send-email-yong.zhang0@gmail.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      e7e7e0c0
  10. 04 11月, 2009 1 次提交
  11. 04 8月, 2009 1 次提交
  12. 17 1月, 2009 1 次提交
    • I
      irq: provide debug_poll_all_shared_irqs() method under CONFIG_DEBUG_SHIRQ · 74296a8e
      Ingo Molnar 提交于
      Provide a shared interrupt debug facility under CONFIG_DEBUG_SHIRQ:
      it uses the existing irqpoll facilities to iterate through all
      registered interrupt handlers and call those which can handle shared
      IRQ lines.
      
      This can be handy for suspend/resume debugging: if we call this function
      early during resume we can trigger crashes in those drivers which have
      incorrect assumptions about when exactly their ISRs will be called
      during suspend/resume.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      74296a8e
  13. 26 12月, 2008 1 次提交
  14. 08 12月, 2008 1 次提交
    • Y
      sparse irq_desc[] array: core kernel and x86 changes · 0b8f1efa
      Yinghai Lu 提交于
      Impact: new feature
      
      Problem on distro kernels: irq_desc[NR_IRQS] takes megabytes of RAM with
      NR_CPUS set to large values. The goal is to be able to scale up to much
      larger NR_IRQS value without impacting the (important) common case.
      
      To solve this, we generalize irq_desc[NR_IRQS] to an (optional) array of
      irq_desc pointers.
      
      When CONFIG_SPARSE_IRQ=y is used, we use kzalloc_node to get irq_desc,
      this also makes the IRQ descriptors NUMA-local (to the site that calls
      request_irq()).
      
      This gets rid of the irq_cfg[] static array on x86 as well: irq_cfg now
      uses desc->chip_data for x86 to store irq_cfg.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0b8f1efa
  15. 16 10月, 2008 4 次提交
  16. 19 7月, 2008 1 次提交
    • E
      genirq: enable polling for disabled screaming irqs · f84dbb91
      Eric W. Biederman 提交于
      When we disable a screaming irq we never see it again.  If the irq
      line is shared or if the driver half works this is a real pain.  So
      periodically poll the handlers for screaming interrupts.
      
      I use a timer instead of the classic irq poll technique of working off
      the timer interrupt because when we use the local apic timers
      note_interrupt is never called (bug?).  Further on a system with
      dynamic ticks the timer interrupt might not even fire unless there is
      a timer telling it it needs to.
      
      I forced this case on my test system with an e1000 nic and my ssh
      session remained responsive despite the interrupt handler only being
      called every 10th of a second.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f84dbb91
  17. 02 5月, 2008 1 次提交
    • T
      genirq: reenable a nobody cared disabled irq when a new driver arrives · 1adb0850
      Thomas Gleixner 提交于
      Uwe Kleine-Koenig has some strange hardware where one of the shared
      interrupts can be asserted during boot before the appropriate driver
      loads. Requesting the shared irq line from another driver result in a
      spurious interrupt storm which finally disables the interrupt line.
      
      I have seen similar behaviour on resume before (the hardware does not
      work anymore so I can not verify).
      
      Change the spurious disable logic to increment the disable depth and
      mark the interrupt with an extra flag which allows us to reenable the
      interrupt when a new driver arrives which requests the same irq
      line. In the worst case this will disable the irq again via the
      spurious trap, but there is a decent chance that the new driver is the
      one which can handle the already asserted interrupt and makes the box
      usable again.
      
      Eric Biederman said further: This case also happens on a regular basis
      in kdump kernels where we deliberately don't shutdown the hardware
      before starting the new kernel.  This patch should reduce the need for
      using irqpoll in that situation by a small amount.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-and-Acked-by: NUwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
      1adb0850
  18. 19 2月, 2008 1 次提交
  19. 30 1月, 2008 1 次提交