https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #28 from Guillaume Outters <guillaume-free...@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.
