RE: Duplicated do_softirq in the interrupt path

From: Chen, Kenneth W <kenneth.w.chen_at_intel.com>
Date: 2004-02-27 09:56:15
OK, this is what I come up with.  The irq_enter need to be moved as
well.  Otherwise, it will increment preempt_count on every interrupt.

- Ken


-----Original Message-----
From: David Mosberger [mailto:davidm@napali.hpl.hp.com] 
Sent: Thursday, February 26, 2004 2:50 PM
To: Chen, Kenneth W
Cc: linux-ia64@vger.kernel.org
Subject: Re: Duplicated do_softirq in the interrupt path


>>>>> On Thu, 26 Feb 2004 14:20:33 -0800, "Chen, Kenneth W"
<kenneth.w.chen@intel.com> said:

  Ken> do_softirq appeared twice in the interrupt path, once in do_IRQ()
and
  Ken> once in the higher level function ia64_handle_irq().  The
condition
  Ken> check for running do_softirq in ia64_handle_irq() doesn't do
preemption
  Ken> check and obviously a leftover code.  But I'm more concerned with
  Ken> softirq being executed while lower priority interrupt is blocked
due
  Ken> to eoi and tpr only gets updated after the return of do_IRQ,
which
  Ken> already executed bottom half for the higher priority interrupt.
Isn't
  Ken> it better to execute all critical part of interrupts (including
lower
  Ken> priority) and batch processing all the bottom half handler?

Absolutely!  In fact, wouldn't that explain the keyboard problems that
were reported for Lion?

I think the correct fix is to move irq_exit() from do_IRQ() to the
point where ia64_handle_irq() calls do_softirq().  Unfortunately, this
makes for one more difference compared to arch/i386/kernel/irq.c but I
don't see any other reasonable way to resolve the problem.

	--david

-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Received on Thu Feb 26 18:02:39 2004

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:22 EST