On November 18, 2023 12:43:24 PM Stefan Wahren <wahrenst@xxxxxxx> wrote:
Hi Arend, Am 15.11.23 um 21:09 schrieb Arend van Spriel:On 11/15/2023 7:35 PM, Stefan Wahren wrote:Am 15.11.23 um 10:34 schrieb Arend van Spriel:On 11/13/2023 10:02 PM, Stefan Wahren wrote:Hi Arend, Am 13.11.23 um 10:11 schrieb Arend van Spriel:On 11/11/2023 9:30 PM, Stefan Wahren wrote:Am 11.11.23 um 19:29 schrieb Stefan Wahren:Am 11.11.23 um 18:25 schrieb Arend Van Spriel:On November 11, 2023 5:48:46 PM Stefan Wahren <wahrenst@xxxxxxx> wrote: Again look like these are disabled channels. At least chanspec 0xd022 is 5G channel 34. You say you get this only once so not every 60 seconds?I get this everytime i trigger a reconnect to the wifi network, so not periodically (checked that). Strangely the initial automatic connect doesn't trigger this errors.I additionally placed a WARN_ON_ONCE after the error log and enabled the firmware error log of brcmf_fil_cmd_data(). Maybe this helps.It does a bit. At least it shows this is happening with the dump_survey (again). I don't really understand why though. It implies the channel is not disabled, but unclear why. The channel flags are changed in brcmf_construct_chaninfo() so we probably should focus debug on that function.i placed a pr_err at the start of brcmf_construct_chaninfo and another pr_err into the for loop before the "if (channel->orig_flags & IEEE80211_CHAN_DISABLED) continue". pr_err("%s: Ch num %d, chanspec 0x%x, orig_flags: %x.\n", __func__, ch.control_ch_num, ch.chspec, channel->orig_flags); It seems that brcmf_construct_chaninfo is called two times, but the results are different. I could find 0xd090 in the first run, but not in second. The other chanspecs doesn't seem to occur in both runs. No idea what's going on here.Can you print all wiphy band channels before exiting brcmf_construct_chaninfo() and print both channel->orig_flags and channel->flags?Sure. It seems that in the first call of brcmf_construct_chaninfo the channel 144 is not disabled, but in the second.I am a bit confused. So the chanspec as mentioned in this email subject is no longer observed, but you still see failure in brcmf_set_channel() for other chanspecs?before we dive deeper into this let me summarize my observations from the beginning. From my understanding the errors are triggered for the 5 GHz channels 34, 38, 42, 46, 144 (chanspec: 0xd022, 0xd026, 0xd02a, 0xd090). So i would focus my observations on those. As you said that the channel flags are set in brcmf_construct_chaninfo() i dump them, here is the output of the first call: [ 8.785850] brcmfmac: 5 GHz: 0: hw_value 34: orig_flags: 00080000, flags 00000001 [ 8.785861] brcmfmac: 5 GHz: 2: hw_value 38: orig_flags: 00080000, flags 00000001 [ 8.785872] brcmfmac: 5 GHz: 4: hw_value 42: orig_flags: 00080000, flags 00000001 [ 8.785882] brcmfmac: 5 GHz: 6: hw_value 46: orig_flags: 00080000, flags 00000001 [ 8.785974] brcmfmac: 5 GHz: 23: hw_value 144: orig_flags: 00080000, flags 0000011a All of them except 144 are disabled via flags. Btw wpa_supplicant is configured to country DE within the configuration. The second and last time brcmf_construct_chaninfo() is called is a few seconds later during boot, we get the following: [ 12.490877] brcmfmac: 5 GHz: 0: hw_value 34: orig_flags: 00080000, flags 00000001 [ 12.490891] brcmfmac: 5 GHz: 2: hw_value 38: orig_flags: 00080000, flags 00000001 [ 12.490904] brcmfmac: 5 GHz: 4: hw_value 42: orig_flags: 00080000, flags 00000001 [ 12.490918] brcmfmac: 5 GHz: 6: hw_value 46: orig_flags: 00080000, flags 00000001 [ 12.491031] brcmfmac: 5 GHz: 23: hw_value 144: orig_flags: 00080000, flags 00000001 Now all of them are disabled via flags. So after that i trigger the reconnect to the same 5 GHz network as before. brcmf_construct_chaninfo is never called again, but at the time brcmf_set_channel is called the flags for these channels are completely different: [ 90.010002] brcmfmac: brcmf_set_channel: set chanspec 0xd022 fail, reason -52 [ 90.010017] brcmfmac: hw_value 34, orig_flags: 00080000, flags 00080220 [ 90.120007] ieee80211 phy0: brcmf_fil_cmd_data: Firmware error: (-20) [ 90.120038] brcmfmac: brcmf_set_channel: set chanspec 0xd026 fail, reason -52 [ 90.120053] brcmfmac: hw_value 38, orig_flags: 00080000, flags 00080200 [ 90.230029] ieee80211 phy0: brcmf_fil_cmd_data: Firmware error: (-20) [ 90.230058] brcmfmac: brcmf_set_channel: set chanspec 0xd02a fail, reason -52 [ 90.230073] brcmfmac: hw_value 42, orig_flags: 00080000, flags 00080200 [ 90.340042] ieee80211 phy0: brcmf_fil_cmd_data: Firmware error: (-20) [ 90.340071] brcmfmac: brcmf_set_channel: set chanspec 0xd02e fail, reason -52 [ 90.340086] brcmfmac: hw_value 46, orig_flags: 00080000, flags 00080210 [ 92.100073] ieee80211 phy0: brcmf_fil_cmd_data: Firmware error: (-20) [ 92.100110] brcmfmac: brcmf_set_channel: set chanspec 0xd090 fail, reason -52 [ 92.100126] brcmfmac: hw_value 144, orig_flags: 00080000, flags 00080118 Where does these new flags come from? It's clear that these doesn't come from brcmf_construct_chaninfo(). So what manipulates the flags afterwards? Shouldn't brcmf_construct_chaninfo() called on reconnect?
I suspect it is not the driver, but net/wireless/reg.c. Could you define DEBUG in top of that file and build cfg80211.ko with that. Or if you have CONFIG_DYNAMIC_DEBUG enable debug prints for reg.c through sysfs [1]
Regards, Arend [1] https://www.kernel.org/doc/html/v4.14/admin-guide/dynamic-debug-howto.html
Best regardsbrcmf_construct_chaninfo() is called from brcmf_setup_wiphybands() and that function is called in two places: 1) brcmf_cfg80211_attach(): right after wiphy_register() 2) brcmf_cfg80211_reg_notifier() Can we figure out if brcmf_cfg80211_reg_notifier() is indeed invoked on your platform and what country is being configured. If the country is indeed changed than it can be expected that some channels are disabled or enabled. Regards, Arend
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
