https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #19 from Bjoern A. Zeeb <b...@freebsd.org> ---
So I am currently doing minutely transfers (TX) off the rtw881 instance to
another machine.
Coming back after a while I see on the 1 minute update differences for vmstat
-m for lkpiskb (but not mbuf-tags):
Use:
% expr 4071 - 3997
74
Reqs:
% expr 17869937 - 17557380
312557
Memory:
% expr 54423552 - 54120448
303104
# It's exactly one page a time!
% expr 74 \* 4096
303104
The previous logging doesn't catch so it's not that though that's just another
error path without an skb free call (there are more in the driver I fixed in
the past):
I wonder if we are leaking somewhere else inside rtw88 slowly; we should go and
see where skb_allocations are matching a page (like the rsvd page or similar).
It seems it's a small number (0.023676%).
[and while I am writing rtw881 exploded again]
rtw881: failed to dequeue 3908 skb TX queue 1, BD=0xffffffff, rp 183 -> 4095^M
rtw881: pci bus timeout, check dma status^M
rtw881: pci bus timeout, check dma status^M
rtw881: pci bus timeout, check dma status^M
[private note from somehwere later in the the trace: WARNING bw >
RTW_CHANNEL_WIDTH_40 || nrx >= 4 failed at
/sys/contrib/dev/rtw88/rtw8822c.c:4412]
db> show malloc
Type InUse MemUse Requests
lkpiskb 3109 49300K 19622568
bounce 8336 33344K 8336
BPF 34 6150K 48
So maybe using dtrace to find allocations with size of a page (4096) would be
interesting to see where they are coming from and how many they are.
I'll let that run over night and see in the morning. It's just another hunch
(the crystal ball currently doesn't seem to work very well).
--
You are receiving this mail because:
You are on the CC list for the bug.
