Quick extra regression report listing regression which available fixes

Quick extra regression report listing regression which available fixes

[Thorsten Leemhuis]

Hi Linus, as you might release the final on Sunday, here is a quick
"extra" report in case you want to know about a few unfixed regressions
introduced during the 6.10 cycle. By chance this list only contains
issues for which a fix is already available; I track a few more
regression, but they are IMHO not worth mentioning for one reason or
another.

There are two issues that worry me somewhat:

* A btrfs regression that leads to increased execution time of the
kswapd0 process and symptoms as if there is not enough memory; at least
two people are affected by this -- but there are indicators that this is
only the tip of the iceberg. Luckily Filipe Manana a few days ago
submitted a patch-set to fix this. It might or might not be picked up by
David and sent to you this week:
https://lore.kernel.org/lkml/CABXGCsMmmb36ym8hVNGTiU8yfUS_cGvoUmGCcBrGWq9OxTrs%2BA@mail.gmail.com/
https://lore.kernel.org/linux-btrfs/cover.1720448663.git.fdmanana@suse.com/

* bpf: build error with CONFIG_WERROR and CONFIG_BPF. Known for 8 weeks
now since a patch to fix this was posted; my recent prodding was
ignored; luckily two -mm developers yesterday convinced Alexei that it
might be worth fixing for 6.10 with a updated patch from Vlastimil Babka:
https://lore.kernel.org/bpf/20240516072411.42016-1-sheharyaar48@gmail.com/
https://lore.kernel.org/all/20240710100521.15061-2-vbabka@suse.cz/


There are a few regressions with available fixes, which seem to be
unlikely to be submitted for mainline inclusion during this week afaics:

* net: dsa: mt7530-mdio: mt7531 switch on Bananapi-R64 not detected
(known for 8 weeks already):
https://lore.kernel.org/lkml/20240516204847.171029-1-linux@fw-web.de/
https://lore.kernel.org/lkml/f485d1d4f7b34cc2ebf3d60030d1c67b4016af3c.1720107535.git.daniel@makrotopia.org/

* drm/qxl: VM graphics often malfunction after boot and sometimes
shutdowns occur (known for 5 weeks already):
https://lore.kernel.org/regressions/DS7PR12MB57665F9F4BDF0598D7CC53DD94FF2@DS7PR12MB5766.namprd12.prod.outlook.com/
https://lore.kernel.org/dri-devel/20240708142208.194361-1-tzimmermann@suse.de/


There are a few regressions for which fixes are available, but those
might or might not will be submitted for mainline inclusion during this
week:

* ASoC: SOF: Intel: Lenovo Thinkpad X1 Carbon Gen 10 first S2idle fails,
S0ix not even tried to enter from there on:
https://github.com/thesofproject/linux/issues/5072
https://bugzilla.kernel.org/show_bug.cgi?id=218961#c10

* of/irq: identification of ATA drives with P.A. Semi Nemo boards broke:
https://lore.kernel.org/lkml/3ab66fab-c3f2-4bed-a04d-a10c57dcdd9b@xenosoft.de/
https://lore.kernel.org/lkml/c8010a06-9d8d-466a-9a83-ee25950f1885@xenosoft.de/

* e1000e: s2idle and S3 broken. That's the issue I highlighted a few
days ago in a separate mail, but I never got a reply. Anyway, looks like
a patch finally is submitted for inclusion into net (five weeks after
the issue was reported, which is related to another issue that is in 6.9
and 6.6.y kernels):
https://bugzilla.kernel.org/show_bug.cgi?id=218936
https://bugzilla.kernel.org/show_bug.cgi?id=218940
https://lore.kernel.org/all/0b96edcc-6b5f-447f-8023-440427a9fff2@leemhuis.info/
https://lore.kernel.org/all/20240709203123.2103296-1-anthony.l.nguyen@intel.com/

* pinctrl: rockchip: boot broke on RK3328 / Rock64
https://lore.kernel.org/all/705544af-d615-4ff0-a54c-72a69140ce6d@eh5.me/
https://lore.kernel.org/lkml/20240709105428.1176375-1-i@eh5.me/


There furthermore are a few regressions with available fixes in next
through -fixes branches, which thus will likely be submitted for
mainline inclusion during this week:

* drm/bridge: adv7511: Intermittent EDID failures; the fix after six
weeks finally made it to a branch that likely will be submitted for
mainline inclusion later this week.
https://lore.kernel.org/lkml/20240521011614.496421-1-aford173@gmail.com/
https://lore.kernel.org/lkml/20240630221931.1650565-1-aford173@gmail.com/

* spi: omap2-mcpsi: boot hangs with ocelot_mfd driver and spi:
omap2-mcspi: omap2-mcspi broke, Oops after a timeout.
https://lore.kernel.org/lkml/Zl%2FV0dU6SjAMkpLG@colin-ia-desktop/
https://lore.kernel.org/lkml/20240612170030.3qatttsgrwjg2m5s@joaog-nb/
https://lore.kernel.org/lkml/20240704-spi-revert-omap2-multi-v1-1-69357ef13fdc@kernel.org/

Ciao, Thorsten

Re: Quick extra regression report listing regression which available fixes

[Thorsten Leemhuis]

On 10.07.24 17:15, Thorsten Leemhuis wrote:
> Hi Linus, as you might release the final on Sunday, here is a quick
> "extra" report in case you want to know about a few unfixed regressions
> introduced during the 6.10 cycle. By chance this list only contains
> issues for which a fix is already available; I track a few more
> regression, but they are IMHO not worth mentioning for one reason or
> another.
> [...]


FWIW a quick add-on in case you are interested.

There are two regressions from recent cycles that have available fixes
that afaics will miss 6.10:

* copy_from_kernel_nofault_allowed() breaks MMUless devices:
https://bugzilla.kernel.org/show_bug.cgi?id=218953
Known for 4 weeks. Caused by 169f9102f9198b ("ARM: 9350/1: fault:
Implement copy_from_kernel_nofault_allowed()") [v6.9-rc1]. Fix is in
-next as 3ccea4784fddd9 ("ARM: Remove address checking for MMUless
devices") since earlier this week:
https://lore.kernel.org/all/20240611100947.32241-1-yangyj.ee@gmail.com/

* fs/ntfs3: memory corruption when page_size changes (like from Windows
-> RasPi5)
https://lore.kernel.org/ntfs3/20240529064053.2741996-1-chenhuacai@loongson.cn/
https://lore.kernel.org/all/20240614155437.2063380-1-popcornmix@gmail.com/
Known since the end of May. Caused by 865e7a7700d930 ("fs/ntfs3: Reduce
stack usage") [v6.8-rc4, v6.6.19]. Fix is in -next as 68ef5b8c612b0c
("fs/ntfs3: Update log->page_{mask,bits} if log->page_size changed"
(likely for 3+ weeks already, not sure, did not verify):
https://lore.kernel.org/ntfs3/20240529064053.2741996-2-chenhuacai@loongson.cn/

* perf jevents: DDR controller metrics are completely unavailable on
i.MX8M* systems
https://lore.kernel.org/linux-perf-users/20240531194414.1849270-1-l.stach@pengutronix.de/
Known since the end of May through a proposed fix which fell through the
cracks once already -- and maybe that happened again, as since a week
nothing happened.


And while at it and in case you care, there are also a few regressions
from recent cycles where the culprit is identified for more than three
weeks now, but there still is no fix in sight or in -next:

* 9p: autopkgtest qemu jobs broken
https://bugzilla.kernel.org/show_bug.cgi?id=218916
https://lore.kernel.org/lkml/Zj0ErxVBE3DYT2Ea@gpd/
https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/2056461
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072004
Known upstream for 2 months now. To quote a complaint about it I got
today: "[this is] causing the testing infrastructure of two distros to
grind to a halt, requiring pinning old kernels (Ubuntu) or simply
disabling all tests that require qemu (Debian). The reporters have
analyzed it, root caused it, found the commit causing it, provided
reproducers, reported to mailing list and bugzilla, provided tentative
patches. On the kernel side? Crickets."

* x86/bugs: dosemu crashes on some x86-32 machines
https://bugzilla.kernel.org/show_bug.cgi?id=218707
https://lore.kernel.org/lkml/IdYcxU6x6xuUqUg8cliJUnucfwfTO29TrKIlLGCCYbbIr1EQnP0ZAtTxdAM2hp5e5Gny_acIN3OFDS6v0sazocnZZ1UBaINEJ0HoDnbasSI=@protonmail.com/
Known for 13 weeks. Fixes are under review for some time, but review is
slow. Latest proposed fix is:
https://lore.kernel.org/lkml/20240710-fix-dosemu-vm86-v4-1-aa6464e1de6f@linux.intel.com/

* can: m_can: kernel hang
https://lore.kernel.org/lkml/e72771c75988a2460fa8b557b0e2d32e6894f75d.camel@ew.tq-group.com/
Known for three weeks now and no fix in sight because people are
apparently busy with other stuff. But likely not something many people
care about.

Ciao, Thorsten

Re: Quick extra regression report listing regression which available fixes

[Thorsten Leemhuis]

Quick update:

On 10.07.24 17:15, Thorsten Leemhuis wrote:

> There are two issues that worry me somewhat:
> 
> * A btrfs regression that leads to increased execution time of the
> kswapd0 process and symptoms as if there is not enough memory;
> [...]
> * bpf: build error with CONFIG_WERROR and CONFIG_BPF. 

Fixers for those to were mainlined, yeah. \o/

> There are a few regressions with available fixes, which seem to be
> unlikely to be submitted for mainline inclusion during this week afaics:
> 
> * net: dsa: mt7530-mdio: mt7531 switch on Bananapi-R64 not detected
> (known for 8 weeks already):
> https://lore.kernel.org/lkml/20240516204847.171029-1-linux@fw-web.de/
> https://lore.kernel.org/lkml/f485d1d4f7b34cc2ebf3d60030d1c67b4016af3c.1720107535.git.daniel@makrotopia.org/

No progress here afaics. This BTW is caused by 868ff5f4944aa9 ("net:
dsa: mt7530-mdio: read PHY address of switch from device tree")
[v6.10-rc1], which brings support for MT7530 and is part of a small
patch-set:
https://lore.kernel.org/all/20240418-b4-for-netnext-mt7530-phy-addr-from-dt-and-simplify-core-ops-v3-0-3b5fb249b004@arinc9.com/
Makes me wonder if this could be fixed through a temporary revert; I
argued for that some time ago, but in the end found no support for it:
https://lore.kernel.org/lkml/2cac4cf68304e81abffbd9ff0387ee100323c2b7.camel@redhat.com/

> * drm/qxl: VM graphics often malfunction after boot and sometimes
> shutdowns occur (known for 5 weeks already):
> https://lore.kernel.org/regressions/DS7PR12MB57665F9F4BDF0598D7CC53DD94FF2@DS7PR12MB5766.namprd12.prod.outlook.com/
> https://lore.kernel.org/dri-devel/20240708142208.194361-1-tzimmermann@suse.de/

That issue is caused by b33651a5c98dbd ("drm/qxl: Do not pin buffer
objects for vmap") [v6.10-rc1]; the fix was queued for -next a few days
ago as c537fb4e3d36e7 ("drm/qxl: Pin buffer objects for internal
mappings") [next-20240711]

> There are a few regressions for which fixes are available, but those
> might or might not will be submitted for mainline inclusion during this
> week:
> 
> * ASoC: SOF: Intel: Lenovo Thinkpad X1 Carbon Gen 10 first S2idle fails,
> S0ix not even tried to enter from there on:
> https://github.com/thesofproject/linux/issues/5072
> https://bugzilla.kernel.org/show_bug.cgi?id=218961#c10

This issue is caused by d5263dbbd8af02 ("ASoC: SOF: Intel: don't ignore
IOC interrupts for non-audio transfers"); the fix "ASOC: SOF: Intel:
hda-loader: only wait for HDaudio IOC for IPC4 devices" is in a github
repo for more than a week already:
https://github.com/plbossart/sound/commit/7a8379a0d960ea48ef4ec8e682f0ea46e27e8020

> * pinctrl: rockchip: boot broke on RK3328 / Rock64
> https://lore.kernel.org/all/705544af-d615-4ff0-a54c-72a69140ce6d@eh5.me/
> https://lore.kernel.org/lkml/20240709105428.1176375-1-i@eh5.me/

That fix is still waiting for review.

> * drm/bridge: adv7511: Intermittent EDID failures; the fix after six
> weeks finally made it to a branch that likely will be submitted for
> mainline inclusion later this week.
> https://lore.kernel.org/lkml/20240521011614.496421-1-aford173@gmail.com/
> https://lore.kernel.org/lkml/20240630221931.1650565-1-aford173@gmail.com/

That fix is in the DRM PR airlied sent on Friday morning.

Ciao, Thorsten