Hello Salvatore, I had some strugles with the bisect, as I found that after doing a cold boot of the Acemagician AM06 pro and the Wavlink USB hub (where 2x Display Port, 1x HDMI screens and USB wired mouse, keyboard, webcam and RJ45/ethernet are connected) that some "bad" kernels behaved ok so I reset the bisect and started over, then tried multiple reboots for each of the 9 bisect steps and tried to even stay longer connected. The commit found here seems not linked to my issue, but I still share here...
git bisect start '--first-parent' # status: waiting for both good and bad commits # good: [f717995cb7dcd8998ab15516b8006aea09cfde0d] Linux 6.12.107 git bisect good f717995cb7dcd8998ab15516b8006aea09cfde0d # status: waiting for bad commit, 1 good commit known # bad: [7fdb7c1824a1f9979d648d7ae28ac446bcee9c6e] Linux 6.12.113 git bisect bad 7fdb7c1824a1f9979d648d7ae28ac446bcee9c6e # good: [fd3e91512cb1e2274f5b70cf7f21ea6b753f0a24] Bluetooth: btusb: Add Realtek RTL8922AE VID/PID 0bda/d922 git bisect good fd3e91512cb1e2274f5b70cf7f21ea6b753f0a24 # good: [17cdb196c6716e06871b96309f684d5e2ddfbdc1] HID: asus: fortify keyboard handshake git bisect good 17cdb196c6716e06871b96309f684d5e2ddfbdc1 # bad: [ccd28394c5ea1e29e1a678e9cf9ef4108396517e] super: make iterate_supers_type() deletion-safe git bisect bad ccd28394c5ea1e29e1a678e9cf9ef4108396517e # good: [2313ff69bd237aad264a5913907f374f958335a2] ring-buffer: Fix subbuf resize race with ring_buffer_alloc_read_page() git bisect good 2313ff69bd237aad264a5913907f374f958335a2 # good: [3531acab86dd181d750c180c1dafc27a26ba36f0] f2fs: Convert clear_node_page_dirty() to clear_node_folio_dirty() git bisect good 3531acab86dd181d750c180c1dafc27a26ba36f0 # bad: [5f3e616f90ead774795313ead59894111381ab22] eth: bnxt: store rx buffer size per queue git bisect bad 5f3e616f90ead774795313ead59894111381ab22 # good: [7a6d4f7a9c81992fb36f2f4e21e879513eefc906] EDAC/altera: Use ECC manager compatible to select A10/S10 IRQ layout git bisect good 7a6d4f7a9c81992fb36f2f4e21e879513eefc906 # bad: [f83062983984e4b7f3c90c7083a9d343f3f44c3f] idpf: introduce idpf_q_vec_rsrc struct and move vector resources to it git bisect bad f83062983984e4b7f3c90c7083a9d343f3f44c3f # bad: [d73975c121f56fe3fcbbfcfe3ea8853b9f597ab3] drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batches git bisect bad d73975c121f56fe3fcbbfcfe3ea8853b9f597ab3 # bad: [696459029f3b65c070c91b729478475582f1dcdf] io_uring/rw: end write accounting from ->ki_complete git bisect bad 696459029f3b65c070c91b729478475582f1dcdf # bad: [6e4d746e55c83c240cffce92356763d16b236af5] genetlink: pin family module during policy dump git bisect bad 6e4d746e55c83c240cffce92356763d16b236af5 # good: [8325ecf3f16d764a0e0ba42c95b63f08e38710a8] EDAC/altera: Use parent device for devres in altr_portb_setup() git bisect good 8325ecf3f16d764a0e0ba42c95b63f08e38710a8 # first bad commit: [6e4d746e55c83c240cffce92356763d16b236af5] genetlink: pin family module during policy dump 6e4d746e55c83c240cffce92356763d16b236af5 is the first bad commit commit 6e4d746e55c83c240cffce92356763d16b236af5 Author: XingWang Xiang <[email protected] mailto:[email protected] > Date: Wed Sep 16 16:16:12 2026 -0400 genetlink: pin family module during policy dump [ Upstream commit 6a1094c34d176827b2b173e163dcc964a13af93f ] The generic netlink controller's policy dump keeps pointers to the target family's operation and policy tables in its callback state. A dump may be split across multiple skbs and remain pending after the initial request. Netlink pins the module which owns the dump callback, but in this case that is the controller's owner rather than the target family's owner. The target family can consequently be unregistered and its module unloaded while a policy dump is pending. Advancing the dump then dereferences policy memory from the unloaded module. Take a reference to the target family's module when the dump starts. Drop it from the error and done paths. This matches the lifetime for which the dump context retains the family and policy pointers. Fixes: d07dcf9aadd6 ("netlink: add infrastructure to expose policies to userspace") Cc: [email protected] mailto:[email protected] Signed-off-by: XingWang Xiang <[email protected] mailto:[email protected] > Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected] mailto:[email protected] > [ Adjusted context to retain kmalloc(sizeof(*ctx->op_iter), GFP_KERNEL) instead of kmalloc_obj(*ctx->op_iter). ] Signed-off-by: Sasha Levin <[email protected] mailto:[email protected] > Signed-off-by: Greg Kroah-Hartman <[email protected] mailto:[email protected] > net/netlink/genetlink.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) Please let me know if you would like me to supply any other troubleshooting output. Now that I have a workaround, even if not ideal, I am kind of ok to continue with the latest linux-image-6.12.113+deb13-amd64 version. Thank you! October 24, 2026 at 5:06 PM, "Salvatore Bonaccorso" <[email protected] mailto:[email protected]?to=%22Salvatore%20Bonaccorso%22%20%3Ccarnil%40debian.org%3E > wrote: > > Control: tags -1 + moreinfo upstream > > Hi, > > On Sat, Oct 24, 2026 at 02:47:14PM +0200, youl wrote: > > > > > Source: linux > > Version: 6.12.113-1 > > Severity: important > > X-Debbugs-Cc: [email protected] > > > > Dear Maintainer, > > > > --- Details --- > > A regression has been introduced in kernel version 6.12.113 > > affecting the AMD Renoir xHCI USB controllers [1022:1639]. USB > > hotplug detection completely breaks after boot, though all devices > > connected at boot enumerate successfully. > > > As you are experiencing the regression from 6.12.107-1 can you please > bisect the changes upstream and report back what is the causing > change. > > git clone --single-branch -b linux-6.12.y > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git > cd linux-stable > git checkout v6.12.107 > cp /boot/config-$(uname -r) .config > yes '' | make localmodconfig > make savedefconfig > mv defconfig arch/x86/configs/my_defconfig > > # test 6.12.107 to ensure this is "good" > make my_defconfig > make -j $(nproc) bindeb-pkg > ... install the resulting .deb package and confirm problem does not exist > > # test 6.12.113 to ensure this is "bad" > git checkout v6.12.113 > make my_defconfig > make -j $(nproc) bindeb-pkg > ... install the resulting .deb package and confirm problem exists > > With that confirmed, the bisection can start: > > git bisect start --first-parent > git bisect good v6.12.107 > git bisect bad v6.12.113 > > In each bisection step git checks out a state between the oldest > known-bad and the newest known-good commit. In each step test using: > > make my_defconfig > make -j $(nproc) bindeb-pkg > ... install, verify if problem exists > > and if the problem is hit run: > > git bisect bad > > and if the problem doesn't trigger run: > > git bisect good > > . Please pay attention to always select the just built kernel for > booting, it won't always be the default kernel picked up by grub. > > Iterate until git announces to have identified the first bad commit. > > Then provide the output of > > git bisect log > > In the course of the bisection you might have to uninstall previous > kernels again to not exhaust the disk space in /boot. Also in the end > uninstall all self-built kernels again. > > Regards, > Salvatore >
