[also Cc: original reporter] On 7/2/23 10:31, Bagas Sanjaya wrote: > Hi, > > I notice a regression report on Bugzilla [1]. Quoting from it: > >> I've spent the last week on debugging a problem with my attempt to upgrade my kernel from 6.2.8 to 6.3.8 (now also with 6.4.0 too). >> >> The lenghty and detailed bug reports with all aspects of git bisect are at >> https://bugs.gentoo.org/909066 >> >> A summary: >> - if I do not configure wg0, the kernel does not hang >> - if I use a kernel older than commit fed8d8773b8ea68ad99d9eee8c8343bef9da2c2c, it does not hang >> >> The commit refers to code that seems unrelated to the problem for my naiive eye. >> >> The hardware is a Dell PowerEdge R620 running Gentoo ~amd64. >> >> I have so far excluded: >> - dracut for generating the initramfs is the same version over all kernels >> - linux-firmware has been the same >> - CPU microcode has been the same >> >> It's been a long time since I seriously involved with software development and I have been even less involved with kernel development. >> >> Gentoo maintainers recommended me to open a bug with upstream, so here I am. >> >> I currently have no idea how to make progress, but I'm willing to try things. > > See Bugzilla for the full thread. > > Anyway, I'm adding it to regzbot to make sure it doesn't fall through cracks > unnoticed: > > #regzbot introduced: fed8d8773b8ea6 https://bugzilla.kernel.org/show_bug.cgi?id=217620 > #regzbot title: correcting acpi_is_processor_usable() check causes RCU stalls with wireguard over bonding+igb > #regzbot link: https://bugs.gentoo.org/909066 > satmd: Can you repeat bisection to confirm that fed8d8773b8ea6 is really the culprit? Thorsten: It seems like the reporter concluded bisection to the (possibly) incorrect culprit. What can I do in this case besides asking to repeat bisection? -- An old man doll... just what I always wanted! - Clara
