Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Maximilian Luz <luzmaximilian@gmail.com>,
        "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
In-Reply-To: <087c418e-53fb-b3a6-0d9b-e738e4c821c7@gmail.com>
Date:   Mon, 17 May 2021 20:40:10 +0200
Message-ID: <87a6otfblh.ffs@nanos.tec.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

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?

Thanks,

        tglx