Hi Larry, Thorsten. Sorry I'm a bit late, been really busy with work lately. Haven't had time to continue bisecting, hopefully I can find some time this sunday. I still think this is a kernel regression - I don't believe I'm using the driver from Larry's repo. This is a stock Fedora 35 installation, I've not installed the driver from Larry's repo, and I don't believe Fedora packages it by default. The reason I used "rtw_8822ce" in the title is because "rtw_8822ce" is printed by my kernel. However, thinking about it a bit, I think that string may not be the driver name, but rather, maybe the device name printed by the kernel? See here: https://github.com/torvalds/linux/blob/38f80f42147ff658aff218edb0a88c37e58bf44f/drivers/net/wireless/realtek/rtw88/mac.c#L968 >rtw_warn(rtwdev, "timed out to flush queue %d\n", prio_queue); It prints the rtwdev variable, which in my case is "rtw_8822ce". And looking some more, I can see this: https://github.com/torvalds/linux/blob/38f80f42147ff658aff218edb0a88c37e58bf44f/drivers/net/wireless/realtek/rtw88/rtw8822ce.c#L24 >.name = "rtw_8822ce", So at least some name inside the driver itself is "rtw_" instead of "rtw88_". Furthermore, here's what lsmod has to say: >[nico@fedora linux]$ lsmod | grep 88 >rtw88_8822ce 16384 0 >rtw88_8822c 487424 1 rtw88_8822ce >rtw88_pci 28672 1 rtw88_8822ce >rtw88_core 167936 2 rtw88_pci,rtw88_8822c >mac80211 1179648 2 rtw88_pci,rtw88_core >kvm 1036288 1 kvm_amd >cfg80211 1024000 2 rtw88_core,mac80211 So I still believe this is a regression somewhere in the net stack - maybe in wireless/ or wireless/rtw88/, but could be elsewhere as well, as there are quite a few moving pieces involved with this machinery. I tried to trace the logic leading to the function "__rtw_mac_flush_prio_queue", but it becomes pretty difficult considering all the places where the struct "ieee80211_ops rtw_ops" member ".flush" in mac80211.c is handled. Add to that my poor understanding of C, and the difficulty of bisecting this, it's not easy to pinpoint where the regression came from. I'll try latest -RC, and if it doesn't work, I'll try bisecting the net merge commits as soon as I have time. p.s. sorry for top posting, writing this in a hurry in gmail web client. On Fri, Mar 4, 2022 at 8:33 AM Thorsten Leemhuis <regressions@xxxxxxxxxxxxx> wrote: > > Hi, this is your Linux kernel regression tracker. > > On 28.02.22 23:07, Larry Finger wrote: > > On 2/28/22 08:30, Thorsten Leemhuis wrote: > > [...] > > > > Your use of rtw_8822ce in the title finally registered on me. With that > > driver in use, that means that you are using my GitHub repo; however, > > newer kernels have the driver built in, but with names such as > > rtw88_8822ce. The difference in the name is deliberate. > > Many thx for this, the names already had made me a bit suspicious, but > wasn't aware of this! > > > If you want to > > use the GitHub version, you must blacklist the ones from the kernel. > > > > To check this, run 'lsmod | grep 88'. If you see a mixture of rtw_xxx > > and rtw88_xxx, then this is your problem. > > Nico didn't reply to your mail, so I'll assume for now that this is not > a kernel regression: > > #regzbot invalid: seems it's a regression in a external module of > similar name > > @Yan-Hsuan Chuang: sorry for the noise! > > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) > > P.S.: As the Linux kernel's regression tracker I'm getting a lot of > reports on my table. I can only look briefly into most of them and lack > knowledge about most of the areas they concern. I thus unfortunately > will sometimes get things wrong or miss something important. I hope > that's not the case here; if you think it is, don't hesitate to tell me > in a public reply, it's in everyone's interest to set the public record > straight. > > >
