public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Andi Kleen <ak@linux.intel.com>
Cc: "Jörg Otte" <jrg.otte@googlemail.com>,
	linux-kernel@vger.kernel.org, "Len Brown" <lenb@kernel.org>
Subject: Re: [v3.4-rc1] ACPI regression bisected
Date: Tue, 3 Apr 2012 10:11:36 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LFD.2.02.1204031001510.2542@ionos> (raw)
In-Reply-To: <20120402235412.GD16303@tassilo.jf.intel.com>

On Mon, 2 Apr 2012, Andi Kleen wrote:

> >  ACPI: Added _OSI(Processor Aggregator Device)
> >  ACPI: EC: EC description table is found, configuring boot EC
> > 
> > Comparing this with the displays of kernel v3.3 the next expected
> > outputs would be:
> > 
> >  ACPI: Interpreter enabled
> >  ACPI: (supports S0 S5)
> > 
> > 
> > I bisected the problem to commit:
> > 6fe0d0628245fdcd6fad8b837c81e8f7ebc3364d  "ACPI: Make ACPI interrupt threaded"
> 
> Hmm, that's odd. It should not really change any semantics. I assume you double
> checked you hit the right commit?

Well it does change the semantics depending on the type of the
interrupt. The above commit does:

-       if (request_irq(irq, acpi_irq, IRQF_SHARED, "acpi", acpi_irq)) {
+       if (request_threaded_irq(irq, NULL, acpi_irq, IRQF_SHARED, "acpi",
+                                acpi_irq)) {

which creates a threaded handler and the primary handler is the
default core one which merily returns IRQ_WAKE_THREAD. Though that
leaves the interrupt line unmasked and for level type interrupts this
is not working. So you either need a primary handler which masks the
irq at the device level or you can add IRQF_ONESHOT to let the core
code deal with the mask/unmask business. See patch below.

Now the problem with this approach is that if this is really a shared
interrupt the core code will either reject this request or the one of
the other device which shares that interrupt line, depending which one
request first. The reason is that we require all devices to agree on
that flag - otherwise a long running/waiting/sleeping threaded handler
might block out the other device for a long time.

If it's never shared, nothing to worry about. Otherwise you need to
provide a primary handler which silences the interrupt at the device
level and unmask it when your threaded handler is done.

Thanks,

	tglx

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index ba14fb9..1b81bc9 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -607,7 +607,8 @@ acpi_os_install_interrupt_handler(u32 gsi, acpi_osd_handler handler,
 
 	acpi_irq_handler = handler;
 	acpi_irq_context = context;
-	if (request_threaded_irq(irq, NULL, acpi_irq, IRQF_SHARED, "acpi",
+	if (request_threaded_irq(irq, NULL, acpi_irq,
+				 IRQF_SHARED | IRQF_ONESHOT, "acpi",
 				 acpi_irq)) {
 		printk(KERN_ERR PREFIX "SCI (IRQ%d) allocation failed\n", irq);
 		acpi_irq_handler = NULL;

  reply	other threads:[~2012-04-03  8:11 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-02 15:05 [v3.4-rc1] ACPI regression bisected Jörg Otte
2012-04-02 23:54 ` Andi Kleen
2012-04-03  8:11   ` Thomas Gleixner [this message]
2012-04-12  8:35     ` Jörg Otte
2012-04-12  8:57       ` Thomas Gleixner
2012-04-12 11:42         ` Paul Bolle
2012-04-12 17:06           ` Thomas Gleixner
2012-04-12 21:52             ` Paul Bolle
2012-04-12 14:29         ` Matthew Garrett
2012-04-12 17:04           ` Thomas Gleixner
2012-04-12 17:09             ` Thomas Gleixner
2012-04-12 19:26               ` Andi Kleen
2012-04-12 20:42                 ` Thomas Gleixner
2012-04-18  9:25                   ` Paul Bolle
2012-04-18 10:29                     ` Thomas Gleixner
2012-04-18 11:07                       ` Paul Bolle
2012-04-18 17:24                       ` Linus Torvalds
2012-04-18 19:25                         ` Thomas Gleixner
2012-04-19  9:30                 ` Thomas Gleixner
2012-04-03  9:13   ` Jörg Otte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.02.1204031001510.2542@ionos \
    --to=tglx@linutronix.de \
    --cc=ak@linux.intel.com \
    --cc=jrg.otte@googlemail.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox