https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #9 from Guillaume Outters <guillaume-free...@outters.eu> --- OK, I was wrong thinking the compiler eating mem induced rtw88 into error: now I'm convinced that rtw88 ate so much mem that clang hadn't enough anymore. Twice this week I observed lpkiskb going rogue, unfortunately without detecting the precise moment it became Mr Hyde. But (as seen in https://bz-attachments.freebsd.org/attachment.cgi?id=256704), I managed to test a loop of a 2 MB scp every minute, while watching vmstat -m | grep lkpiskb, with surprising results: A. Before going rogue Each scp added to the req counter, but memory stayed remarkably stable, at 16 MB. I didn't even noticed any temporary increase of mem use during scps (and statistically, my probe every 10 seconds should have happened multiple times simultaneously with my 4 seconds lasting download). B. After having gone rogue Now the reqs are still there (hopefully!), but **mem use increases of ~ 3,4 MB** per scp of 2 MB (/!\ those are file bytes, not bandwidth; and I don't know the bandwidth / file bytes ratio of scp) And having the server lag helped saw something more interesting, due to multiple probes occurring during the transfer: the 3,4 MB didn't follow a monotonic growth, but instead the mem use increased considerably, and _only some_ mem got freed once scp finished. -------------------------------------------------------------------------------- Here a one-go increase (probes at :45 and :56, scp occured around between :47 and :51) (+ 3,4 MB): 2025-01-14 01:06:45 lkpiskb 329256 1361215488 9513310 +2 +8192 +212 2025-01-14 01:06:56 lkpiskb 330093 1364643840 9517636 +837 +3428352 +4326 2025-01-14 01:07:06 lkpiskb 330095 1364652032 9517845 +2 +8192 +209 Here a two-go (+ 5 MB - 1,6 MB): 2025-01-14 01:07:47 lkpiskb 330115 1364733952 9518743 +5 +20480 +223 2025-01-14 01:07:57 lkpiskb 331360 1369833472 9522027 +1245 +5099520 +3284 2025-01-14 01:08:07 lkpiskb 330958 1368186880 9523298 -402 -1646592 +1271 2025-01-14 01:08:17 lkpiskb 330964 1368211456 9523527 +6 +24576 +229 Another one-go (+ 6,8 MB - 3,4 MB): 2025-01-14 01:10:00 lkpiskb 331828 1371750400 9529814 +2 +8192 +217 2025-01-14 01:10:10 lkpiskb 333506 1378623488 9534152 +1678 +6873088 +4338 2025-01-14 01:10:20 lkpiskb 332671 1375203328 9534368 -835 -3420160 +216 2025-01-14 01:10:30 lkpiskb 332674 1375215616 9534584 +3 +12288 +216 Here periodic security on the server made it really hard for scp to finish, and let rtw88 free its mem: 2025-01-14 07:21:34 lkpiskb 586598 2415288320 11209247 +291 +1191936 +933 2025-01-14 07:21:57 lkpiskb 587114 2417401856 11210910 +516 +2113536 +1663 2025-01-14 07:22:23 lkpiskb 587579 2419306496 11212416 +465 +1904640 +1506 2025-01-14 07:22:45 lkpiskb 587877 2420527104 11213510 +298 +1220608 +1094 2025-01-14 07:23:07 lkpiskb 588170 2421727232 11214571 +293 +1200128 +1061 2025-01-14 07:23:29 lkpiskb 588474 2422972416 11215673 +304 +1245184 +1102 2025-01-14 07:23:49 lkpiskb 587441 2418741248 11216292 -1033 -4231168 +619 -------------------------------------------------------------------------------- while true ; do date "+%Y-%m-%d %H:%M:%S" ; vmstat -m | grep lkpi ; sleep 10 ; done | tee -a ~/tmp/depuisboot.log awk < ~/tmp/depuisboot.log '/^2025-/{h=$0}/lkpiskb/{variation="+"(-use+$2)"\t+"(-mem+$3)"\t+"(-req+$4);gsub(/[+]-/,"-",variation);gsub(/ +/,"\t");print h"\t"$0"\t"variation;use=0+$2;mem=0+$3;req=0+$4}' | less -- You are receiving this mail because: You are on the CC list for the bug.
