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;
User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3
Mime-Version: 1.0
Message-Id: <96085c8a-b144-4fd3-b1fb-45763b5b64a4@www.fastmail.com>
In-Reply-To: <87lfeiiy10.fsf@nanos.tec.linutronix.de>
References: <20201126074734.12664-1-lnicola@dend.ro>
 <875z5rk68z.fsf@nanos.tec.linutronix.de>
 <ea40c3e8-0be1-4783-ba1e-86c96cf8e4af@www.fastmail.com>
 <87lfeiiy10.fsf@nanos.tec.linutronix.de>
Date:   Mon, 30 Nov 2020 19:22:12 +0200
From:   =?UTF-8?Q?Lauren=C8=9Biu_Nicola?= <lnicola@dend.ro>
To:     "Thomas Gleixner" <tglx@linutronix.de>
Cc:     mingo@kernel.org, bp@alien8.de, x86@kernel.org, trivial@kernel.org,
        LKML <linux-kernel@vger.kernel.org>,
        "Tom Lendacky" <thomas.lendacky@amd.com>
Subject: Re: [PATCH] x86/irq: Lower unhandled irq error severity
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


On Mon, Nov 30, 2020, at 18:56, Thomas Gleixner wrote:
> Laurentiu,
>=20
> On Fri, Nov 27 2020 at 10:03, Lauren=C8=9Biu Nicola wrote:
> > On Fri, Nov 27, 2020, at 02:12, Thomas Gleixner wrote:
> >> On Thu, Nov 26 2020 at 09:47, Lauren=C8=9Biu Nicola wrote:
> >> > These messages are described as warnings in the MSI code.
> >>=20
> >> Where and what has MSI to do with these messages?
> >
> > There's a comment referring to it as a warning, but an error seemed =
a more appropriate severity:
> >
> >      * If the vector is unused, then it is marked so it won't
> >      * trigger the 'No irq handler for vector' warning in
> >      * common_interrupt().
>=20
> That's a description for the logic in the MSI code which is required t=
o
> _NOT_ trigger the 'No irq handler' message. If that message appears th=
en
> something _is_ badly wrong. Either the kernel screwed up or something =
in
> the BIOS/firmware/hardware is bonkers.

Agreed, just pointing out that the MSI code refers to it as a warning (a=
s opposed to a critical error).

>=20
> >> > Spotted because they break quiet boot on a Ryzen 5000 CPU.
> >>=20
> >> They don't break the boot.
> >>=20
> >> The machine boots fine, but having interrupts raised on a vector wh=
ich
> >> is unused is really bad.
> >
> > That's right, sorry. It still boots, but it's no longer "quiet",
> > that's what I meant.
>=20
> Right, but surpressing that is not a solution.

I'm just downgrading it from "emergency" to "error". It will still be di=
splayed for most users snd anyone looking in dmesg. But I'm unlikely to =
convince my motherboard manufacturer to fix this in the BIOS, and the er=
rors are basically unactionable and uninformative (unlike say "can't set=
 up page mappings" or "your CPU might be on fire" which would really imp=
ly a crash soon).

The messages themselves are only a cosmetic issue -- they replace the BI=
OS logo that would otherwise stay up until the display manager started.

But if you think this should really be an "emerg" message, I'm not going=
 to insist anymore. I'm sure you have more important patches to review :=
-).

Thanks,
Lauren=C8=9Biu