czw., 30 maj 2024 o 05:13 Ping-Ke Shih <pkshih@xxxxxxxxxxx> napisał(a): > > Marcin Ślusarz <marcin.slusarz@xxxxxxxxx> wrote: > > śr., 29 maj 2024 o 03:52 Ping-Ke Shih <pkshih@xxxxxxxxxxx> napisał(a): > > > > > > Marcin Ślusarz <marcin.slusarz@xxxxxxxxx> wrote: > > > > wt., 28 maj 2024 o 05:52 Ping-Ke Shih <pkshih@xxxxxxxxxxx> napisał(a): > > > > > > > > > > Marcin Ślusarz <marcin.slusarz@xxxxxxxxx> wrote: > > > > > > > > > > > > I found out that the reason for those hangs is a power-off+on sequence that's > > > > > > triggered by the above steps. > > > > > > > > > > To avoid power-off/on sequence once device becomes idle, I would like to add > > > > > a ips_disabled helper. Please revert your changes and apply my attached patch. > > > > > > > > My first attempt was very similar, and it fixed some cases but not all of them. > > > > > > > > This is due to the existence of a second source of power-offs - rtw_ops_stop, > > > > which is called, e.g., on downing the interface (ifconfig wlan0 down). > > > > > > Please try attached v2 patch. I would like to have an explicit helper > > > (i.e. always_power_on in v2) to have this fix, so days later people can be easy > > > to understand how it works. Not prefer adjusting existing flags to implicitly > > > have behavior you want. > > > > So, do you think this is a chip issue, not just some driver misconfiguration? > > I asked internal USB WiFi people who say vendor drivers of USB/SDIO can't > power-on/-off frequently but not very sure if hardware issue or driver issue. > > > > > I'm asking because if we are going in this direction, there's something > > more to fix... With your v2, very frequently, I hit WARN_ON(!local->started) in > > ieee80211_rx_napi (in wireless-next, the code was moved to ieee80211_rx_list). > > > > With my patch, I checked and hit that WARN_ON, too, but very occasionally. > > > > I think the difference is in what happens in rtw_ips_enter - I disabled only > > the power_off, but you also disabled everything else, including the cancelation > > of work_structs. > > > > The warning itself sounds harmless, but I think users should never see such > > warnings, so this needs to be fixed somehow. Probably some additional > > work_struct(s) need to be canceled? > > > > I forgot to say my patch is compiled test only, and I didn't consider flow > too much, just to close the behavior of your patches. You can improve my patch > to be more reliable to avoid WARN_ON(). Two variants of the patch that fix this issue will follow. They are built on top of yours v2 and my "wifi: rtw88: schedule rx work after everything is set up" from the other thread. Please choose the one you like more :).
