Date: Wed, 19 Feb 2025 23:12:21 +0000 From: bugzilla-noreply@freebsd.org To: wireless@FreeBSD.org Subject: [Bug 283903] rtw88: possible skb leak Message-ID: <bug-283903-21060-sEUipUPDRX@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-283903-21060@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903 --- Comment #28 from Guillaume Outters <guillaume-freebsd@outters.eu> --- (In reply to Bjoern A. Zeeb from comment #27) > I believe that was my initial shot in the dark and I wonder if you are still running with the review from there Hmu, I think I've returned to the stock 14.1-RELEASE kernel (my /boot/kernel/kernel was dated 2024-05-31). > and if not if you want to apply the rtw88 parts Are we speaking of review D48723 (dev_kfree_skb_any in rtw_pci_tx_write)? If yes, sadly it doesn't resolve nor mitigates the problem. ---- Now I think I "succeed" in making RTW88 go berserk in 10 to 20 mn after boot, by mixing 10 MB scp with some web browsing. This evening, with Dtrace I noticed that after the tipping point, rtw_c2h_work still gets called (as it is the common entry point to D1.1 and D1.2), but (this time thanks to a custom kernel with a new printf in rtw_c2h_work) ** ITS QUEUE LENGTH IS SYSTEMATICALLY 0 ** after the tipping point, while very rarely before. int n = 0; skb_queue_walk_safe(&rtwdev->c2h_queue, skb, tmp) { ++n; } printf("ERROR Guillaume: queue %p , n = %d\n", &rtwdev->c2h_queue, n); /* Well I just ensure the _pointer_ to the structure does not change, I haven't looked at the _contents_. */ ---- Thank you for your time, and no worry I can manage the reboots until next week or month or summer, I'll consider the reboots a good news as in "now I'm able to reproduce really quickly". -- You are receiving this mail because: You are on the CC list for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-283903-21060-sEUipUPDRX>