[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjQaxmXTR68VnEJvLgB=H2agMTrrF4EXkXT4Hbdf2ZuMQ@mail.gmail.com>
Date: Sun, 16 Apr 2023 13:48:52 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Regzbot (on behalf of Thorsten Leemhuis)"
<regressions@...mhuis.info>, Rafael Wysocki <rafael@...nel.org>,
David Sterba <dsterba@...e.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Linux regressions mailing list <regressions@...ts.linux.dev>
Subject: Re: Linux regressions report for mainline [2023-04-16]
On Sun, Apr 16, 2023 at 10:59 AM Regzbot (on behalf of Thorsten
Leemhuis) <regressions@...mhuis.info> wrote:
>
> Wake-on-lan (WOL) apparently is broken for a huge number of users since
> 6.2 was released[1]. This is known for 8 weeks now and about 4 weeks ago
> it was bisected to commit 5c62d5aab87 ("ACPICA: Events: Support fixed
> PCIe wake event") we immediately could have reverted. The developer that
> looked into this was even willing to do the revert late March, but then
> got discouraged by a maintainer [2]. But well, a fix was apparently[3]
> finally posted for review last week (to the acpica-devel list); with a
> bit of luck your might get it next week. Still a bit sad that 6.2 is
> broken for so long now, as Greg wants to see it fixed in mainline first.
>
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=217069
> [2] https://bugzilla.kernel.org/show_bug.cgi?id=217069#c50
> [3] https://lore.kernel.org/all/754225a2-95a9-2c36-1886-7da1a78308c2@loongson.cn/
I find that bugzilla discussion very confusing, it's not clear what
the status of the patch actually is.
And the sane lkml thread just says "the patch is under review" without
actually saying *where* said patch is, or where the review is.
It sounds like it got perhaps into some internal ACPCICA queue? None
of those links are very clear on any of this.
Rafael?
> Another issue from the 6.2 days still not fixed are a huge number of
> DISCARD request on NVME devices with Btrfs caused by 63a7cb13071
> ("btrfs: auto enable discard=async when possible") [1, 2].
Yeah, automatic discard is a broken idea, and that should just be reverted.
The number of devices that have *horrible* problems with discard is
too high for any kind of "do discard by default" logic.
David, please don't do that. Just because discard happens to work well
on some disk, *you* care about, does not in any way mean that "do
discard by default" is sane.
Discard needs to be opt-in. Not out-opt.
Linus
Powered by blists - more mailing lists