Re: Linux regressions report for mainline [2023-04-16]

[Linux regression tracking (Thorsten Leemhuis)]

On 16.04.23 22:48, Linus Torvalds wrote:
> On Sun, Apr 16, 2023 at 10:59 AM Regzbot (on behalf of Thorsten
> Leemhuis) <regressions@xxxxxxxxxxxxx> 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@xxxxxxxxxxx/
> 
> 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?

FWIW, yeah, had the same problems and already had asked for a link to
the patch submission. A few hours ago Jianmin Lv replied and pointed me
here: https://github.com/acpica/acpica/pull/866

/me meanwhile wonders if acpica-devel was abandoned or if its list
archive (https://lists.linuxfoundation.org/pipermail/acpica-devel/ ) is
just broken.

>> 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.

Not my area of expertise, but is this maybe something where we can
automatically enable async discard by default if some easily detectable
conditions are met? E.g. if the device supports PCIe 12.0, NVMe 9.1, or
was produced in 2030 and later (note, I used bogus numbers here on purpose).

Ciao, Thorsten