linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Maximilian Luz <luzmaximilian@gmail.com>
To: Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>, Sachi King <nakato@nakato.io>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	David Laight <David.Laight@aculab.com>
Cc: "x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH] x86/i8259: Work around buggy legacy PIC
Date: Mon, 17 May 2021 21:25:51 +0200	[thread overview]
Message-ID: <b509418f-9fff-ab27-b460-ecbe6fdea09a@gmail.com> (raw)
In-Reply-To: <87a6otfblh.ffs@nanos.tec.linutronix.de>

On 5/17/21 8:40 PM, Thomas Gleixner wrote:
> Max,
> 
> On Sat, May 15 2021 at 00:47, Maximilian Luz wrote:
>> I believe the theory was that, while the PIC is advertised in ACPI, it
>> might be expected to not be used and only present for some legacy reason
>> (therefore untested and buggy). Which I believe led to the question
>> whether we shouldn't prefer IOAPIC on systems like that in general. So I
>> guess it comes down to how you define "systems like that". By Tomas'
>> comment, I guess it should be possible to implement this as "systems
>> that should prefer IOAPIC over legacy PIC" quirk.
>>
>> I guess all modern machines should have an IOAPIC, so it might also be
>> preferable to expand that definition, maybe over time and with enough
>> testing.
> 
> I just double checked and we actually can boot just fine without the
> PIC even when it is advertised, but disfunctional.
> 
> Can you please add "apic=verbose" to the kernel command line and provide
> full dmesg output for a kernel w/o your patch and one with your patch
> applied?

I don't actually own an affected device, but I'm sure Sachi can provide
you with that.

As far as we can tell, due to the NULL PIC being chosen nr_legacy_irqs()
returns 0. That in turn causes mp_check_pin_attr() to return false
because is_level and active_low don't seem to match the expected values.
That check is essentially ignored if nr_legacy_irqs() returns a high
enough value. I guess that might also be a firmware bug here? Not sure
where the expected values come from.

Due to this, mp_map_pin_to_irq() fails with -EBUSY which causes
acpi_register_gsi() to fail. That fails in acpi_dev_get_irqresource(),
which causes the IRQ resource to be marked as disabled.

Down the line, this then causes platform_get_irq() to return -EINVAL,
because the IRQ we're trying to get has the IORESOURCE_DISABLED bit set.

Sachi can probably walk you through this a bit better as she's the one
who tracked this down. See also [1, 2] and following comments.

Regards,
Max

[1]: https://github.com/linux-surface/linux-surface/issues/425#issuecomment-835309201
[2]: https://github.com/linux-surface/linux-surface/issues/425#issuecomment-835261784

  reply	other threads:[~2021-05-17 19:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-12 21:04 [PATCH] x86/i8259: Work around buggy legacy PIC Maximilian Luz
2021-05-13  8:10 ` David Laight
2021-05-13 10:11   ` Maximilian Luz
2021-05-13 10:36     ` David Laight
2021-05-14 13:01       ` Thomas Gleixner
2021-05-14 13:13         ` David Laight
2021-05-14 16:19           ` Ingo Molnar
2021-05-14 19:41       ` Sachi King
2021-05-14 10:51         ` David Laight
2021-05-14 11:58         ` Maximilian Luz
2021-05-14 17:32           ` Thomas Gleixner
2021-05-14 17:35             ` H. Peter Anvin
2021-05-14 22:47               ` Maximilian Luz
2021-05-17 18:40                 ` Thomas Gleixner
2021-05-17 19:25                   ` Maximilian Luz [this message]
2021-05-17 23:27                     ` Thomas Gleixner
2021-05-18  8:28                       ` Andy Shevchenko
2021-05-18 19:58                       ` Sachi King
2021-05-18 15:45                         ` Thomas Gleixner
2021-05-14 13:44     ` Thomas Gleixner
2021-05-14 16:12       ` David Laight
2021-05-14 17:28         ` H. Peter Anvin

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=b509418f-9fff-ab27-b460-ecbe6fdea09a@gmail.com \
    --to=luzmaximilian@gmail.com \
    --cc=David.Laight@aculab.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nakato@nakato.io \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@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;
as well as URLs for NNTP newsgroup(s).