On Tue, 10 Oct 2023 at 15:22, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Mon, 2023-10-09 at 16:56 +0100, James Dutton wrote: > > > > Looking at this, it can be one of two things: > > 1) local->hw.wiphy->bands[band]; is NULL > > Yes, I think that's it. > > > 2) bands is an array of 6 items, making band valid for values 0-5. > > If band >= 6, it would cause problems. > > Highly unlikely. > [snip] > > _Maybe_ change it to WARN_ON_ONCE(!sband || !sband->bitrates) there, but > really I think we should prevent this in the first place. > > > Is this, by any chance, a device without 2.4 GHz? > Hi, I have the same device that is reported to be crashing. My device does not actually crash, so I personally have not seen the problem. My device is what I would call unstable (not crashing, just not forwarding packets) though. My work around is to switch on/off airplane mode on the client, and it continues forwarding packets again. Some of the wifi device drivers have some not very portable use of bit fields that looks suspicious to me, but again no proof yet of what causes my stability problems. It is why a lot of access to bit fields in the kernel correctly uses portable accessors like STA_STATS_GET() and friends. I have seen this though: https://github.com/openwrt/openwrt/issues/13198 Which has reports of a few other people seeing the crash. The device has both 2.4 and 5G wifi. >From what I can see, the band information originates from what the wifi card received over the RF. So, theoretically, it might be caused by a bogus wifi packet being received. I agree that it is unlikely for "band" to get to 6 or above, but until one of the users who are seeing the problem runs a kernel with the extra printk or WARN statements in it, I don't think we are going to know the cause for certain. I think it prudent to put the if statements in to catch both edge cases.
