On kernel 6.6.27-1-lts, running `iw list` shows that 6GHz channels are supported: Frequencies: * 5955.0 MHz [1] (12.0 dBm) (no IR) * 5975.0 MHz [5] (12.0 dBm) (no IR) * 5995.0 MHz [9] (12.0 dBm) (no IR) * 6015.0 MHz [13] (12.0 dBm) (no IR) * 6035.0 MHz [17] (12.0 dBm) (no IR) * 6055.0 MHz [21] (12.0 dBm) (no IR) * 6075.0 MHz [25] (12.0 dBm) (no IR) * 6095.0 MHz [29] (12.0 dBm) (no IR) * 6115.0 MHz [33] (12.0 dBm) (no IR) * 6135.0 MHz [37] (12.0 dBm) (no IR) * 6155.0 MHz [41] (12.0 dBm) (no IR) * 6175.0 MHz [45] (12.0 dBm) (no IR) * 6195.0 MHz [49] (12.0 dBm) (no IR) * 6215.0 MHz [53] (12.0 dBm) (no IR) * 6235.0 MHz [57] (12.0 dBm) (no IR) * 6255.0 MHz [61] (12.0 dBm) (no IR) * 6275.0 MHz [65] (12.0 dBm) (no IR) * 6295.0 MHz [69] (12.0 dBm) (no IR) * 6315.0 MHz [73] (12.0 dBm) (no IR) * 6335.0 MHz [77] (12.0 dBm) (no IR) * 6355.0 MHz [81] (12.0 dBm) (no IR) * 6375.0 MHz [85] (12.0 dBm) (no IR) * 6395.0 MHz [89] (12.0 dBm) (no IR) * 6415.0 MHz [93] (12.0 dBm) (no IR) * 6435.0 MHz [97] (12.0 dBm) (no IR) * 6455.0 MHz [101] (12.0 dBm) (no IR) * 6475.0 MHz [105] (12.0 dBm) (no IR) * 6495.0 MHz [109] (12.0 dBm) (no IR) * 6515.0 MHz [113] (12.0 dBm) (no IR) * 6535.0 MHz [117] (12.0 dBm) (no IR) * 6555.0 MHz [121] (12.0 dBm) (no IR) * 6575.0 MHz [125] (12.0 dBm) (no IR) * 6595.0 MHz [129] (12.0 dBm) (no IR) * 6615.0 MHz [133] (12.0 dBm) (no IR) * 6635.0 MHz [137] (12.0 dBm) (no IR) * 6655.0 MHz [141] (12.0 dBm) (no IR) * 6675.0 MHz [145] (12.0 dBm) (no IR) * 6695.0 MHz [149] (12.0 dBm) (no IR) * 6715.0 MHz [153] (12.0 dBm) (no IR) * 6735.0 MHz [157] (12.0 dBm) (no IR) * 6755.0 MHz [161] (12.0 dBm) (no IR) * 6775.0 MHz [165] (12.0 dBm) (no IR) * 6795.0 MHz [169] (12.0 dBm) (no IR) * 6815.0 MHz [173] (12.0 dBm) (no IR) * 6835.0 MHz [177] (12.0 dBm) (no IR) * 6855.0 MHz [181] (12.0 dBm) (no IR) * 6875.0 MHz [185] (12.0 dBm) (no IR) * 6895.0 MHz [189] (12.0 dBm) (no IR) * 6915.0 MHz [193] (12.0 dBm) (no IR) * 6935.0 MHz [197] (12.0 dBm) (no IR) * 6955.0 MHz [201] (12.0 dBm) (no IR) * 6975.0 MHz [205] (12.0 dBm) (no IR) * 6995.0 MHz [209] (12.0 dBm) (no IR) * 7015.0 MHz [213] (12.0 dBm) (no IR) * 7035.0 MHz [217] (12.0 dBm) (no IR) * 7055.0 MHz [221] (12.0 dBm) (no IR) * 7075.0 MHz [225] (12.0 dBm) (no IR) * 7095.0 MHz [229] (12.0 dBm) (no IR) * 7115.0 MHz [233] (12.0 dBm) (no IR) Similarly, discovering and connecting to 6GHz APs works fine. However, in recent kernel 6.8.5, running `iw list` shows that 6GHz channels are disabled: Frequencies: * 5955.0 MHz [1] (disabled) * 5975.0 MHz [5] (disabled) * 5995.0 MHz [9] (disabled) * 6015.0 MHz [13] (disabled) * 6035.0 MHz [17] (disabled) * 6055.0 MHz [21] (disabled) * 6075.0 MHz [25] (disabled) * 6095.0 MHz [29] (disabled) * 6115.0 MHz [33] (disabled) * 6135.0 MHz [37] (disabled) * 6155.0 MHz [41] (disabled) * 6175.0 MHz [45] (disabled) * 6195.0 MHz [49] (disabled) * 6215.0 MHz [53] (disabled) * 6235.0 MHz [57] (disabled) * 6255.0 MHz [61] (disabled) * 6275.0 MHz [65] (disabled) * 6295.0 MHz [69] (disabled) * 6315.0 MHz [73] (disabled) * 6335.0 MHz [77] (disabled) * 6355.0 MHz [81] (disabled) * 6375.0 MHz [85] (disabled) * 6395.0 MHz [89] (disabled) * 6415.0 MHz [93] (disabled) * 6435.0 MHz [97] (disabled) * 6455.0 MHz [101] (disabled) * 6475.0 MHz [105] (disabled) * 6495.0 MHz [109] (disabled) * 6515.0 MHz [113] (disabled) * 6535.0 MHz [117] (disabled) * 6555.0 MHz [121] (disabled) * 6575.0 MHz [125] (disabled) * 6595.0 MHz [129] (disabled) * 6615.0 MHz [133] (disabled) * 6635.0 MHz [137] (disabled) * 6655.0 MHz [141] (disabled) * 6675.0 MHz [145] (disabled) * 6695.0 MHz [149] (disabled) * 6715.0 MHz [153] (disabled) * 6735.0 MHz [157] (disabled) * 6755.0 MHz [161] (disabled) * 6775.0 MHz [165] (disabled) * 6795.0 MHz [169] (disabled) * 6815.0 MHz [173] (disabled) * 6835.0 MHz [177] (disabled) * 6855.0 MHz [181] (disabled) * 6875.0 MHz [185] (disabled) * 6895.0 MHz [189] (disabled) * 6915.0 MHz [193] (disabled) * 6935.0 MHz [197] (disabled) * 6955.0 MHz [201] (disabled) * 6975.0 MHz [205] (disabled) * 6995.0 MHz [209] (disabled) * 7015.0 MHz [213] (disabled) * 7035.0 MHz [217] (disabled) * 7055.0 MHz [221] (disabled) * 7075.0 MHz [225] (disabled) * 7095.0 MHz [229] (disabled) * 7115.0 MHz [233] (disabled) And scanning or connecting to 6GHz APs does not work. There's nothing in `dmesg` that differs between boots of the two kernels. On 6.8.5, 6GHz band doesn't work like it did on previous kernels. I can provide more logs or help debug the issue if needed.
Created attachment 306162 [details] Kernel 6.6 dmesg
Created attachment 306163 [details] Kernel 6.6 iw list
Created attachment 306164 [details] Kernel 6.6 iw reg get
Created attachment 306165 [details] Kernel 6.8 dmesg
Created attachment 306166 [details] Kernel 6.8 iw list
Created attachment 306167 [details] Kernel 6.8 iw reg get
Forwarded by mail: https://lore.kernel.org/regressions/e17e5bf2-657a-4a22-a925-94db95fe8ca1@leemhuis.info/T/#u
Still an issue in 6.8.7
I am sorry, that you experience an regression. This should not happen, so thank you for reporting it. > I can provide more logs or help debug the issue if needed. As no developer has responded yet, bisecting the issue would in my opinion really help. As you can easily reproduce the issue, it’d be great if you could find the commit introducing the regression. If you are more experienced, to avoid rebooting you could pass the WLAN device to a QEMU virtual machine, and quickly boot the Linux kernels. In either case, it should not be more than 20 regression steps, I assume.
(In reply to Paul Menzel from comment #9) > As no developer has responded yet, Maybe waiting a day or two more if the forwarding mentioned earlier leads to some results might be wise, maybe it's known by some developer that was out of office in the past few days. > bisecting the issue would in my opinion really help. FWIW, there is a guide: https://docs.kernel.org/admin-guide/verify-bugs-and-bisect-regressions.html > If you are more experienced, to avoid rebooting you could pass the WLAN > device to a QEMU virtual machine [off topic: maybe it would be wise to add instructions about that to above document, too; not sure.]
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #10) > > > bisecting the issue would in my opinion really help. > FWIW, there is a guide: > https://docs.kernel.org/admin-guide/verify-bugs-and-bisect-regressions.html No developer responded, so this is likely needed. Knowing is latest mainline is affected (which the guide makes you check) would be a good start, as that might make some developer look into this.
(In reply to Paul Menzel from comment #9) > I am sorry, that you experience an regression. This should not happen, so > thank you for reporting it. > > > I can provide more logs or help debug the issue if needed. > > As no developer has responded yet, bisecting the issue would in my opinion > really help. As you can easily reproduce the issue, it’d be great if you > could find the commit introducing the regression. If you are more > experienced, to avoid rebooting you could pass the WLAN device to a QEMU > virtual machine, and quickly boot the Linux kernels. In either case, it > should not be more than 20 regression steps, I assume. Thanks for the response, I'll look into doing this as the issue persists. (In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #11) > (In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from > comment #10) > > > > > bisecting the issue would in my opinion really help. > > FWIW, there is a guide: > > https://docs.kernel.org/admin-guide/verify-bugs-and-bisect-regressions.html > > No developer responded, so this is likely needed. Knowing is latest mainline > is affected (which the guide makes you check) would be a good start, as that > might make some developer look into this. Will do, as well.
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #11) > (In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from > comment #10) > > > > > bisecting the issue would in my opinion really help. > > FWIW, there is a guide: > > https://docs.kernel.org/admin-guide/verify-bugs-and-bisect-regressions.html > > No developer responded, so this is likely needed. Knowing is latest mainline > is affected (which the guide makes you check) would be a good start, as that > might make some developer look into this. Compiled and booted into mainline 6.9-rc6 and this problem is still present. I'm unable to use the 6GHz radio.
Built and ran a bunch of kernels, looks like the regression begins to appear in kernel 6.7.0 while it isn't present in 6.6.30.
None of the developers responded, so they have no idea; in that case to get some results you most likely have to use a bisection to find the change that introduced the problem (developers then will be obliged to fix this): https://docs.kernel.org/admin-guide/verify-bugs-and-bisect-regressions.html
I'm also experiencing this issue on a Minisforum UM690 with Mediatek MT7921K (RZ608). Thanks for the pointers, AlexDeLorenzo.dev! I followed up on your findings and did a bisection. The results are like this: 1. [bad] mainline (954a209f431c06b62718a49b403bd4c549f0d6fb) 2. [good] v6.6.30 3. [bad] v6.7.12 4. [good] v6.6 5. [bad] edd8e84ae9514e93368f56c3715b11af52df6c3b 6. [bad] 89ed67ef126c4160349c1b96fdb775ea6170ac90 7. [good] b827ac419721a106ae2fccaa40576b0594edad92 8. [bad] d1a02ed66fe62aa2edd77bd54e270ebc33bd12ff 9. [good] 3abbd0699b678fc48e0100704338cff9180fe4bb 10. [good] 5a423552e0d9bb882f22cb0bf85f520ca2692706 11. [bad] 56a7bb12c78ffa1b02e154b1d779ed2a1555fa3c 12. [good] a3c2dd96487f1dd734c9443a3472c8dafa689813 13. [bad] 089482a06b74a40d45773b1871182e8f04be026b 14. [good] fce9c967820a72f600abbf061d7077861685a14d 15. [good] c948b5da6bbec742b433138e3e3f9537a85af2e5 16. [good] 9585316a2aaf773a67846bdc8bbdd4df1e9622fa 17. [good] 51ba0e3a15eb1643116a93674e230e11b9499592 18. [bad] 09382d8f8641bc12fffc41a93eb9b37be0e653c0 19. [good] 4fc8df50fd41c2762d893211487be0ecb24c6a05 [09382d8f8641bc12fffc41a93eb9b37be0e653c0](https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux/+/09382d8f8641bc12fffc41a93eb9b37be0e653c0) is the first bad commit. Reverting it on top of mainline produces a conflict, but it may be possible to do with a bit more work.
Slavi, thank you for taking the time to find the commit, that was first present in Linux v6.7-rc1. The commit message reads: > wifi: mt76: mt7921: update the channel usage when the regd domain changed > > The 5.9/6GHz channel license of a certain platform device has been > regulated in various countries. That may be difference with standard > Liunx regulatory domain settings. In this case, when .reg_notifier() > called for regulatory change, mt792x chipset should update the channel > usage based on clc or dts configurations. > > Channel would be disabled by following cases. > * clc report the particular UNII-x is disabled. > * dts enabled and the channel is not configured. Are you in a country, where these channels are regulated?
I'm in Bulgaria and `iw reg get` reports this: ``` global country BG: DFS-ETSI (2400 - 2483 @ 40), (N/A, 20), (N/A) (5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS (5725 - 5875 @ 80), (N/A, 13), (N/A) (5945 - 6425 @ 160), (N/A, 23), (N/A), NO-OUTDOOR (57000 - 66000 @ 2160), (N/A, 40), (N/A) ``` For testing purposes, I've also tried switching to another regulatory domain (`US`, `DE`, `SE`, `NL`) via `iw reg set ..`, but the 6 Ghz frequencies remained `disabled`.
Thank you for checking this. I am out of my expertise. You could try to change the hunks from the patch, and also look at your devicetree. But it might be better to send your findings to the patch authors and developers via email: * Felix Fietkau <nbd@nbd.name> * Lorenzo Bianconi <lorenzo@kernel.org> * Ryder Lee <ryder.lee@mediatek.com> * Kalle Valo <kvalo@kernel.org> * Matthias Brugger <matthias.bgg@gmail.com> * AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> * Ming Yen Hsieh <mingyen.hsieh@mediatek.com> * Deren Wu <deren.wu@mediatek.com> * linux-wireless@vger.kernel.org * linux-kernel@vger.kernel.org * linux-arm-kernel@lists.infradead.org * linux-mediatek@lists.infradead.org