https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #16 from Bjoern A. Zeeb <b...@freebsd.org> ---
(In reply to Guillaume Outters from comment #15)
This is interesting. The reason I was thinking that it cannot be here is that
the TX SKBs have an mbuf attached to them which is only freed (as you can see
in lkpi_ieee80211_free_txskb and the function called from there) just before
the SKB is freed. Given we do not seem to leak mbufs according to netstat -m
output provided before it seemed unlikely that these SKBs are leaked.
But also 170 bytes is really not much each time.
Did you also instrument the RX path?
Are your SCPs pushing or pulling data? as in do you copy a file off from the
rtw88 device or do you copy a file to the rtw88 device?
BTW. you do not have to patch the kernel for this. Dtrace provides adequate
tracing functionality in this case.
Here's a sample I shared earlier on which you can probably use as a start:
# dtrace -s rtw88-skb.d -o rtw88-skb.results
--- 8< 8< 8< rtw88-skb.d -----------------------------------------------
#!/usr/sbin/dtrace -s
/*-
* SPDX-License-Identifier: BSD-2-Clause
* Copyright (c) 2024 Bjoern A. Zeeb
*
* 20241224 -- rtw88 SKB leak debugging.
*/
#pragma D option quiet
#pragma D option switchrate=2
#pragma D option bufsize=4M
fbt:kernel:linuxkpi_alloc_skb:entry
{
@[ probefunc, stack() ] = count();
}
/* fbt:kernel:linuxkpi_alloc_skb:return */
fbt:kernel:linuxkpi_kfree_skb:entry
{
@[ probefunc, stack() ] = count();
}
/* fbt:kernel:linuxkpi_kfree_skb:return */
/* end */
--- 8< 8< 8< -----------------------------------------------------------
You could add the relevant functions and see where things are no longer called.
Given you are on a fairly low bandwidth it's likely fine but eventually the
overhead will be noticeable and DTrace may drop records.
--
You are receiving this mail because:
You are on the CC list for the bug.
