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?
Gr. AvS
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
