Search Linux Wireless

Re: wifi: rtw88: 8821CU hangs after some number of power-off/on cycles

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

 



wt., 4 cze 2024 o 02:50 Ping-Ke Shih <pkshih@xxxxxxxxxxx> napisał(a):
>
> Marcin Ślusarz <marcin.slusarz@xxxxxxxxx> wrote:
> > > >
> > > > 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 :).
>
> The patch "wifi: rtw88: usb: drop rx skbs when device is not running" is
> to drop all skb it receives. USB is still working, so I don't prefer this.
>
> "wifi: rtw88/usb: stop rx work before potential power off" seems to stop
> RX. But how rtw_usb_cancel_rx_bufs() can stop RX? Remove RX urb to stop it?

Yes, URBs are removed, so the buffers will not be filled in, and
completion callbacks will not be called.

> Not sure if this is regular method for USB devices?

I'm not sure, either. Ideally, it should be disabled in hardware, but
AFAIK there's no public documentation for this chip, so no way for me
to figure out how to do it, and we are dealing with a case of power
management failure here.

> By the way, please take and refine my v2 patch into your patchset. That will
> be easier to me to merge patches finally.
>
> Ping-Ke
>





[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