https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #26 from Guillaume Outters <guillaume-free...@outters.eu> ---
(I have not progressed; however now that my laptop is my main machine, the bug
starts to be really annoying, with 1 or 2 reboots required by day as you may
have Oleg)
And I've attempted reorganizing my previous comment, which could give a clearer
view of the process.
So, based on my previous path codes A1, A2 for allocations, and D1.1, D1.2, D2
and D3 for deallocs:
(all subsequent distributions apply to RX as well as TX, with only numbers
differing, for an scp of a 10 MiB file)
I. When running normally after a reboot
A1 4364 (RX) / 7251 (TX)
D1.1 same numbers
A2 17870 (RX) / 20255 (TX)
D2 12000 to 13000
D1.2 4364 (RX) / 7251 (TX)
with A1 = D1.1, and A2 = D2 + D1.2
II. When running in anomally
A1 4678 (RX) / 7225 (TX)
(no D1.1)
A2 17869/70
D2 10000 to 13000
(no D1.2)
D3 4678 (RX) / 7225 (TX)
So, no call to D1 (neither D1.1 nor D1.2), but a D3 to compensate __only D1.2__
(and asynchronous: sometimes only 30 s after the corresponding Ax)
III. Conclusion
D3 (softclock_call_cc+0x12c > rtw_tx_report_purge_timer+0x8e) seems to be a
degraded mode under load (no time to call D1 anymore, it is stacked for
later?), which works well but **ONLY COMPENSATES ONE OF THE TWO FREEs NORMALLY
CALLED WITHIN D1**.
Said otherwise: D1 coordinates freeing of SKB allocated within both A2
(lkpi_napi_task+0xf) and A1 (lkpi_80211_txq_task+0x1ec) (which are related, as
we have as many A1-allocated SKB as we have from A2);
while D3 (that seems to be designed to take the relay of D1 in case of heavy
load), only frees one of those two SKB.
--
You are receiving this mail because:
You are on the CC list for the bug.
