* Re: Linux 7.1-rc3 regression (Bluetooth) [not found] ` <01ffb0cc-dcf6-4e60-adf3-fbb96e0666d0@leemhuis.info> @ 2026-05-15 2:26 ` August Wikerfors 2026-05-15 5:37 ` Greg KH 0 siblings, 1 reply; 4+ messages in thread From: August Wikerfors @ 2026-05-15 2:26 UTC (permalink / raw) To: Thorsten Leemhuis Cc: linux-kernel, linux-bluetooth, Linux kernel regressions list, stable, Luiz Augusto von Dentz, Pauli Virtanen, Mikhail Gavrilov, markus.suvanto On 2026-05-11 08:30, Thorsten Leemhuis wrote: > On 5/11/26 07:17, markus.suvanto@gmail.com wrote: >> Hello >> >> I upgrade 7.1-rc2 to 7.1-rc3. After that bluetooth didn't start >> hci0: Failed to send wmt func ctrl (-22) >> My fix was to revert commit 634a4408c0615c523cf7531790f4f14a422b9206 > > Thx for your report. FWIW, there are two proposed fixed for this change > floating around: > > https://lore.kernel.org/all/20260508173121.27526-1-mikhail.v.gavrilov@gmail.com/ > https://lore.kernel.org/all/770d36b07311bf88210c187923f243fb9f126f04.1777058551.git.pav@iki.fi/ > > Given that this is the third revert within a short time-frame I wonder > if we should fast-track a fix (once ready) to spare more users the pain > of bisecting & reporting. FYI the commit that caused this regression was backported to the latest stable releases (6.12.88, 6.18.30 and 7.0.7). I encountered it after updating to 7.0.7 and can confirm that the patch from the second link fixes it. That patch is now in the bluetooth tree as e3ac0d9f1a20 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events") and a pull request [1] has been made to the net tree. Unfortunately this seems to have been a few hours too late to make it into the net pull request for 7.1-rc4 [2], so the fix might not get into mainline until next week. As a side note, it is unfortunate that there does not seem to be a process to prevent patches that are known to cause regressions from being backported to stable releases. As far as I can tell, this was added to regzbot tracking [3] a day before the culprit was queued for stable [4], so such a process could have prevented this regression in stable releases. [1] https://lore.kernel.org/all/20260514172340.1515042-1-luiz.dentz@gmail.com/ [2] https://lore.kernel.org/all/20260514142703.267609-1-pabeni@redhat.com/ [3] https://lore.kernel.org/all/8a17737e-ba9b-4842-a429-c4eab3abcdec@leemhuis.info/ [4] https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/?id=7780f283d14c8c6bf40fe9262219ad821a5dae80 Regards, August Wikerfors ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Linux 7.1-rc3 regression (Bluetooth) 2026-05-15 2:26 ` Linux 7.1-rc3 regression (Bluetooth) August Wikerfors @ 2026-05-15 5:37 ` Greg KH 2026-05-15 7:43 ` johannes.goede 0 siblings, 1 reply; 4+ messages in thread From: Greg KH @ 2026-05-15 5:37 UTC (permalink / raw) To: August Wikerfors Cc: Thorsten Leemhuis, linux-kernel, linux-bluetooth, Linux kernel regressions list, stable, Luiz Augusto von Dentz, Pauli Virtanen, Mikhail Gavrilov, markus.suvanto On Fri, May 15, 2026 at 04:26:38AM +0200, August Wikerfors wrote: > On 2026-05-11 08:30, Thorsten Leemhuis wrote: > > On 5/11/26 07:17, markus.suvanto@gmail.com wrote: > > > Hello > > > > > > I upgrade 7.1-rc2 to 7.1-rc3. After that bluetooth didn't start > > > hci0: Failed to send wmt func ctrl (-22) > > > My fix was to revert commit 634a4408c0615c523cf7531790f4f14a422b9206 > > > > Thx for your report. FWIW, there are two proposed fixed for this change > > floating around: > > > > https://lore.kernel.org/all/20260508173121.27526-1-mikhail.v.gavrilov@gmail.com/ > > https://lore.kernel.org/all/770d36b07311bf88210c187923f243fb9f126f04.1777058551.git.pav@iki.fi/ > > > > Given that this is the third revert within a short time-frame I wonder > > if we should fast-track a fix (once ready) to spare more users the pain > > of bisecting & reporting. > > FYI the commit that caused this regression was backported to the latest > stable releases (6.12.88, 6.18.30 and 7.0.7). I encountered it after > updating to 7.0.7 and can confirm that the patch from the second link > fixes it. That patch is now in the bluetooth tree as e3ac0d9f1a20 > ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events") and a pull > request [1] has been made to the net tree. Unfortunately this seems to > have been a few hours too late to make it into the net pull request for > 7.1-rc4 [2], so the fix might not get into mainline until next week. > > As a side note, it is unfortunate that there does not seem to be a > process to prevent patches that are known to cause regressions from > being backported to stable releases. As far as I can tell, this was > added to regzbot tracking [3] a day before the culprit was queued for > stable [4], so such a process could have prevented this regression in > stable releases. You can email stable@vger to let us know to drop a patch, or when the -rcs are released, respond to the offending patch in that list. THat's why we have -rc releases! thanks, greg k-h ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Linux 7.1-rc3 regression (Bluetooth) 2026-05-15 5:37 ` Greg KH @ 2026-05-15 7:43 ` johannes.goede 2026-05-15 8:56 ` Thorsten Leemhuis 0 siblings, 1 reply; 4+ messages in thread From: johannes.goede @ 2026-05-15 7:43 UTC (permalink / raw) To: Greg KH, August Wikerfors Cc: Thorsten Leemhuis, linux-kernel, linux-bluetooth, Linux kernel regressions list, stable, Luiz Augusto von Dentz, Pauli Virtanen, Mikhail Gavrilov, markus.suvanto Hi, On 15-May-26 07:37, Greg KH wrote: > On Fri, May 15, 2026 at 04:26:38AM +0200, August Wikerfors wrote: >> On 2026-05-11 08:30, Thorsten Leemhuis wrote: >>> On 5/11/26 07:17, markus.suvanto@gmail.com wrote: >>>> Hello >>>> >>>> I upgrade 7.1-rc2 to 7.1-rc3. After that bluetooth didn't start >>>> hci0: Failed to send wmt func ctrl (-22) >>>> My fix was to revert commit 634a4408c0615c523cf7531790f4f14a422b9206 >>> >>> Thx for your report. FWIW, there are two proposed fixed for this change >>> floating around: >>> >>> https://lore.kernel.org/all/20260508173121.27526-1-mikhail.v.gavrilov@gmail.com/ >>> https://lore.kernel.org/all/770d36b07311bf88210c187923f243fb9f126f04.1777058551.git.pav@iki.fi/ >>> >>> Given that this is the third revert within a short time-frame I wonder >>> if we should fast-track a fix (once ready) to spare more users the pain >>> of bisecting & reporting. >> >> FYI the commit that caused this regression was backported to the latest >> stable releases (6.12.88, 6.18.30 and 7.0.7). I encountered it after >> updating to 7.0.7 and can confirm that the patch from the second link >> fixes it. That patch is now in the bluetooth tree as e3ac0d9f1a20 >> ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events") and a pull >> request [1] has been made to the net tree. Unfortunately this seems to >> have been a few hours too late to make it into the net pull request for >> 7.1-rc4 [2], so the fix might not get into mainline until next week. >> >> As a side note, it is unfortunate that there does not seem to be a >> process to prevent patches that are known to cause regressions from >> being backported to stable releases. As far as I can tell, this was >> added to regzbot tracking [3] a day before the culprit was queued for >> stable [4], so such a process could have prevented this regression in >> stable releases. > > You can email stable@vger to let us know to drop a patch, or when the > -rcs are released, respond to the offending patch in that list. THat's > why we have -rc releases! That relies on someone actively intervening in the process though, I wonder if it would be an idea to have some CI which checks patches in stable RC releases vs regzbot tracking? This assumes tegzbot tracking includes the mainline git hash of commits causing the regression (if/once known). Regards, Hans ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Linux 7.1-rc3 regression (Bluetooth) 2026-05-15 7:43 ` johannes.goede @ 2026-05-15 8:56 ` Thorsten Leemhuis 0 siblings, 0 replies; 4+ messages in thread From: Thorsten Leemhuis @ 2026-05-15 8:56 UTC (permalink / raw) To: johannes.goede, Greg KH, August Wikerfors Cc: linux-kernel, linux-bluetooth, Linux kernel regressions list, stable, Luiz Augusto von Dentz, Pauli Virtanen, Mikhail Gavrilov, markus.suvanto On 5/15/26 09:43, johannes.goede@oss.qualcomm.com wrote: > On 15-May-26 07:37, Greg KH wrote: >> On Fri, May 15, 2026 at 04:26:38AM +0200, August Wikerfors wrote: >>> On 2026-05-11 08:30, Thorsten Leemhuis wrote: >>>> On 5/11/26 07:17, markus.suvanto@gmail.com wrote: >>>>> I upgrade 7.1-rc2 to 7.1-rc3. After that bluetooth didn't start >>>>> hci0: Failed to send wmt func ctrl (-22) >>>>> My fix was to revert commit 634a4408c0615c523cf7531790f4f14a422b9206 >>>> Thx for your report. FWIW, there are two proposed fixed for this change >>>> floating around: >>>> https://lore.kernel.org/all/20260508173121.27526-1-mikhail.v.gavrilov@gmail.com/ >>>> https://lore.kernel.org/all/770d36b07311bf88210c187923f243fb9f126f04.1777058551.git.pav@iki.fi/ >>> [...] >>> FYI the commit that caused this regression was backported to the latest >>> stable releases (6.12.88, 6.18.30 and 7.0.7). I encountered it after >>> [...] >>> As a side note, it is unfortunate that there does not seem to be a >>> process to prevent patches that are known to cause regressions from >>> being backported to stable releases. As far as I can tell, this was >>> added to regzbot tracking [3] a day before the culprit was queued for >>> stable [4], so such a process could have prevented this regression in >>> stable releases. >> You can email stable@vger to let us know to drop a patch, or when the >> -rcs are released, respond to the offending patch in that list. THat's >> why we have -rc releases! > > That relies on someone actively intervening in the process though, > I wonder if it would be an idea to have some CI which checks patches > in stable RC releases vs regzbot tracking? > > This assumes tegzbot tracking includes the mainline git hash of > commits causing the regression (if/once known). This is the case. And the idea to let regzbot help with preventing what happened here is not new and even written on a todo list. The rough plan was to let regzbot just export the list of mainline commit-ids with unresolved regressions (together with a link to regzbot's webui with more details) -- then all Greg would need to do is something like "curl example.org/unresoved_regressions.txt | grep 1f2e3d4c5b6a" in his apply script to notice potential problems. That was how I envisioned things might be good for Greg -- of course before implementing that I would have talked to him about it. But regzbot development stalled for about two years due to lack of funding; we are currently ramping it up again[1], but it will take some time to get things sorted, so this is likely not something we'll implement tomorrow. :-( [1] https://kernelci.org/blog/2026/05/04/regzbot-joins-kernelci-strengthening-linux-kernel-regression-tracking/ Ciao, Thorsten ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-05-15 9:01 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <f652d5d9841a9b7c100dd19ee97c86099f580724.camel@gmail.com>
[not found] ` <01ffb0cc-dcf6-4e60-adf3-fbb96e0666d0@leemhuis.info>
2026-05-15 2:26 ` Linux 7.1-rc3 regression (Bluetooth) August Wikerfors
2026-05-15 5:37 ` Greg KH
2026-05-15 7:43 ` johannes.goede
2026-05-15 8:56 ` Thorsten Leemhuis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox