All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jörg Otte" <jrg.otte@googlemail.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Andi Kleen <ak@linux.intel.com>,
	linux-kernel@vger.kernel.org, Len Brown <lenb@kernel.org>
Subject: Re: [v3.4-rc1] ACPI regression bisected
Date: Thu, 12 Apr 2012 10:35:30 +0200	[thread overview]
Message-ID: <CADDKRnAOqfxTjrCp4E5eKFJvVTu6s0xF3Ca3jRJavFkyGpYLmQ@mail.gmail.com> (raw)
In-Reply-To: <alpine.LFD.2.02.1204031001510.2542@ionos>

I tried that patch, for me it works.

Thanks, Joerg


Am 3. April 2012 10:11 schrieb Thomas Gleixner <tglx@linutronix.de>:
> 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-12  8:35 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
2012-04-12  8:35     ` Jörg Otte [this message]
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=CADDKRnAOqfxTjrCp4E5eKFJvVTu6s0xF3Ca3jRJavFkyGpYLmQ@mail.gmail.com \
    --to=jrg.otte@googlemail.com \
    --cc=ak@linux.intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.