regressions report as of Linux 7.1-rc5 post (was: Linux 7.1-rc5)
Thorsten Leemhuis <[email protected]>
| Newsgroups | dev.linux.lists.regressions,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
Hi Linus! On 5/24/26 23:07, Linus Torvalds wrote: > > So I think I'll start being a bit more hardnosed about this kind of > unnecessary churn this late in the game. We are supposed to look for > *regressions*. Non-critical fixes to long-standing issues are simply > not appropriate for this late in the release cycle. Speaking of regressions: I got the feeling the weekly regression reports made way more work then they were worth it up to -rc5. But we are approaching -rc6, so let me give you an overview about some unresolved regressions. ########################################################################### Unresolved regressions from this cycle that could easily get fixed for -rc6 -- but might or might not: --- media: renesas: vsp1: brx: configuration of the DRM pipeline broken https://lore.kernel.org/linux-media/CA%2BV-a8t481xuwava0nb7uY9CUPqFWZ_8EP0xrK3BgumP7HDcLg@mail.gmail.com/ Known for 6 weeks. A patch-series to fix this with reverts is sitting on the list for three weeks now. Prodded there Wednesday, but maintainers did not yet pick things up. Laurent sent a PR on Friday to get them to act, maybe that will do the trick: https://lore.kernel.org/linux-media/[email protected]/ --- drm/i915: backlight problems https://lore.kernel.org/lkml/CADo9pHjr-zZ9C3%2B026y5%[email protected]/ aka https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16015 https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/16043 https://lore.kernel.org/lkml/[email protected]/ aka https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16097 Known since -rc1 and fixed by a revert that sits in -next as f30fddb4402313 ("Revert "drm/i915/backlight: Remove try_vesa_interface"") [next-20260520] -- looks a bit like it's destined to be merged in the next merge window, but with all those cherry-picking in the drm subsystem I might easily be wrong. Asked for the plans on Thursday, no reply yet: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16043#note_3492668 --- soc: imx8m: warning and serial id data missing https://lore.kernel.org/lkml/6593091.DvuYhMxLoT@steina-w/ Known for 9 weeks. The fix was sitting on the list and in next (2c6821657ce3b3 ("soc: imx8m: Fix match data lookup for soc device")) for a while; I prodded on Thursday and it's supposed to be en route to mainline now. ########################################################################### Unresolved regressions from this cycle that are unlikely to get fixed for -rc6: --- drm: amdgpu: handling FreeSync via MCCS broke VRR https://gitlab.freedesktop.org/drm/amd/-/issues/5286 Known for 17 days and reporter proposed a fix shortly afterwards; I prodded the maintainers on Thursday and they want to look into things and get something into next weeks -fixes pull: https://lore.kernel.org/amd-gfx/[email protected]/ https://lore.kernel.org/amd-gfx/BL1PR12MB51447AB016BB28843BAD0216F7092@BL1PR12MB5144.namprd12.prod.outlook.com/ --- cpufreq/amd-pstate: switching to performance profile broke https://bugzilla.kernel.org/show_bug.cgi?id=221505 Known for 18 days, culprit unknown. Mario and colleagues fixed a few bugs in this area in the past few weeks, but seems one problem that affects at least two people on Asus laptops remains -- a fix or a revert to resolve this is sadly not in sight (https://bugzilla.kernel.org/show_bug.cgi?id=221505#c22). --- loop: loop drive broken due to some race exposed by an unknown change https://lore.kernel.org/lkml/[email protected]/ Known since 6 weeks. People are busy trying to get this resolved. ######################################################################### Unresolved regressions from the previous cycle that could easily get fixed for -rc6 -- but might or might not: --- ARM: at91: finding rootfs on raw nand on sam9x60 broken https://lore.kernel.org/lkml/[email protected]/ Known for 5 weeks. Fix was sitting in -next as 754d60ad1c9189 ("memory: atmel-ebi: Allow deferred probing") since next-20260504; prodded on Thursday, now en route to mainline. --- drm/amd/display: screen goes black halfway through the booting proces https://gitlab.freedesktop.org/drm/amd/-/issues/5272 Known for 19 days. Hope the fix will make it to mainline soon: 08236c3ef284cd ("drm/amd/display: Write REFCLK to 48MHz on DCN21") [next-20260528] --- serial: 8250: BREAK + SysRq dispatch broken https://lore.kernel.org/lkml/[email protected]/ Known for 17 days. Hope the fix will make it to mainline soon: 71f42b2149a130 ("serial: 8250: dispatch SysRq character in serial8250_handle_irq()") [next-20260525 (pending-fixes)] --- accel/amdxdna: AMD PMC causes hard hang on s2idle suspend https://gitlab.freedesktop.org/drm/amd/-/issues/5319 Known for 10 days. Hope the fix will make it to mainline soon: a8878e19d2f520 ("accel/amdxdna: Block running when IOMMU is off") [next-20260522 (pending-fixes)] --- ipv6: SSH session gets dropped, usually several times, in the first hour or so https://lore.kernel.org/all/[email protected]/ Known for 8 days. Revert under lively discussion, see thread above and: https://lore.kernel.org/all/[email protected]/ https://lore.kernel.org/all/[email protected]/ ######################################################################### Unresolved regressions from even earlier cycles that could easily get fixed for -rc6, but that's unlikely to happen from what I see: --- e1000e: "Unstable ethernet connection on Dell Pro 16" as well as "PC10 in runtime idle in newer systems prevented" https://lore.kernel.org/all/[email protected]/ https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20250623/048860.html Known for 5 months, and a fix exists, but Intel claims it needs more time: https://lore.kernel.org/all/[email protected]/ https://lore.kernel.org/all/[email protected]/ --- scsi: massive resource usage that can lead to kernel crashes https://lore.kernel.org/lkml/[email protected]/ https://lore.kernel.org/linux-scsi/[email protected]/ Known for 9 weeks. Fixes exists for weeks, but discussion is slow. hch recently ACKed it: https://lore.kernel.org/linux-scsi/[email protected]/ --- rtl8xxxu: RTL8188FTV (0bda:f179) fails to authenticate/configure since 6.19 https://bugzilla.kernel.org/show_bug.cgi?id=221394 https://lore.kernel.org/linux-wireless/[email protected]/ Known for 6 weeks. A fix is sitting in a sub-sub-subsystem tree for a while now that is not even in -next -- and it looks like the developers are unwilling to merge the fix this cycle: https://lore.kernel.org/linux-wireless/[email protected]/ --- x86/fpu: applications that construct signal frames in userspace broke (such as CRIU and gVisor) https://lore.kernel.org/lkml/[email protected]/ Known for 4 weeks. A revert was proposed a month ago (see above), but didn't make any progress; a newer revert was posted this week: https://lore.kernel.org/lkml/[email protected]/ --- NFSv4: mkdir(2) on an NFSv4 mount occasional returns -EEXIST https://lore.kernel.org/lkml/[email protected]/ Known for 4 weeks. A fix exists, but maintainers didn't reply yet and recent prodding by yours truly did not help: https://lore.kernel.org/lkml/[email protected]/ ######################################################################### Unresolved regressions from even earlier cycles that could easily get fixed for -rc6 -- but might or might not: --- parport: race leading to a NULL pointer dereference and a panic https://lore.kernel.org/lkml/[email protected]/ https://bugzilla.kernel.org/show_bug.cgi?id=221526 Known for 6 months now. Culprit is very old, but seems the problem somehow happens more often since some time ago. Hope the fix will make it to mainline soon: ef15ccbb3e8640 ("parport: Fix race between port and client registration") [next-20260525 (pending-fixes)] --- usb: typec: ucsi: laptop does not enter suspend anymore https://lore.kernel.org/lkml/[email protected]/ Known for 10 days. Hope the fix will make it to mainline soon: d98d413ca65d07 ("usb: typec: ucsi: Don't update power_supply on power role change if not connected")