Search Linux Wireless

Re: brcmfmac: Unexpected brcmf_set_channel: set chanspec 0xd022 fail, reason -52 - Part 2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

brcmf_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


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux