linux-kernel - Re: Linux regressions report for mainline [2023-07-30]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJZ5v0jZ0YHfnxJ7BTEFAZHb+0NO9YAoQ9hypZ66cqpcJsmXYQ@mail.gmail.com>
Date:   Mon, 31 Jul 2023 09:50:32 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     "Regzbot (on behalf of Thorsten Leemhuis)" 
        <regressions@...mhuis.info>, Rafael Wysocki <rafael@...nel.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Mario Limonciello <mario.limonciello@....com>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux regressions mailing list <regressions@...ts.linux.dev>
Subject: Re: Linux regressions report for mainline [2023-07-30]

On Sun, Jul 30, 2023 at 9:41 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Sun, 30 Jul 2023 at 10:20, Regzbot (on behalf of Thorsten Leemhuis)
> <regressions@...mhuis.info> wrote:
> >
> > One thing you might be interested in: seems the Ryzen keyboard problems
> > that a9c4a912b7d ("ACPI: resource: Remove "Zen" specific match and
> > quirks") [v6.5-rc1] was supposed to fix once and for all kinda came
> > back, as the new approach apparently still doesn't work on all machines:
>
> Gaah.
>
> We must be doing something fundamentally wrong in the irq overrides,
> this is ridiculous. One step forwards, two steps back.
>
> Right now all our entries in that override table say "don't override".
>
> In fact, right now they all seem to be about the legacy keyboard irq.
> I get the feeling that we are just doing something horribly horribly
> wrong wrt the override thing, and that all these quirks come from
> that.
>
> I get the feeling that maybe we simply should strive to use the values
> the BIOS has _programmed_, not the DSDT or MADT values at all?

I'm not sure why we don't do that, it all has started way in the past.

> After all, the BIOS has presumably set things up so that the keyboard works,
> so us taking values from the BIOS tables (which are clearly
> unreliable) is a bit suspect.

Yeah, fair enough.

> IOW, maybe we should simply never touch the irq setup for irq 1?
>
> Does anybody have any idea what MS does?

I've never got a coherent answer to this question TBH.  Let me ask
around and see what I can find.

Cheers,
Rafael