I investigated this bug some time ago. I didn't do a git bisect as it
takes forever to compile again and again, but I used GDB over SWD to
debug this on a Raspberry Pi 5.
https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/2063365 -
specifically the 8th, 9th and 10th comment.
The regdom flags set in brcmf_setup_wiphybands (which happens during
startup) get wiped off by restore_custom_reg_settings and the
corresponding orig_flags contain outdated/invalid data. During a new
disconnect-reconnect cycle, these flags retain their invalid data from
orig_flags.
I have suggested 2 possible fixes (not patches) and I am not sure what
the tradeoffs would be in both of those cases. One possible fix is
changing the orig_flags for the channels at the end of
brcmf_setup_wiphybands (which I don't think is a neat idea), the other
is to call brcmf_setup_wiphybands during every disconnect - reconnect cycle.
I think any of these fixes is better than the current suggested
workaround of turning of DUMP_OBSS feature. I think my findings will
help fix this. Please suggest which of these approaches would be a more
appropriate fix, or feel free to suggest a better approach.
Regards
Pragyansh
On 11/25/24 17:07, Stefan Wahren wrote:
Am 25.11.24 um 07:49 schrieb Renjaya Raga Zenta:
On 11/23/24 4:54 PM, Arend Van Spriel wrote:
This was reported earlier by Stefan Wahren, but the thread ran dry.
Yes, I've read the whole thread. I guess what I've found is similar
to what Stefan found. Those channels are disabled by the driver in
brcmf_construct_chaninfo() but are re-enabled in reg.c.
I see there hasn't been any conclusion yet, so I just bumped this
thread.
Stefan did a workaround by modifying brcmf_construct_chaninfo() to store
the IEEE80211_CHAN_DISABLED flag within orig_flags in case the flags had
it. I see no further ACK, so I think that's not the proper solution.
Unfortunately I'm don't have much Wifi knowledge & time to push this
further. So I'm would be happy, if someone take care of about this
annoyance.
So what changed a couple of days ago? System upgrade?
Well, I use the latest OS from Raspberry Pi, it still uses 6.6.51. I
guess
there is no significant changes from what Stefan tried.
I think it should be mentioned, there is no usable Raspberry Pi 5
support in Mainline yet. So the mention version is a vendor kernel tree.
Regards
Regards,
Renjaya
