https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #5 from Guillaume Outters <guillaume-free...@outters.eu> --- (In reply to oleg.nauman from comment #4) Yes, I have the same: Dec 31 16:39:14 pasdfric kernel: rtw880: ERROR lkpi_80211_txq_tx_one: skb alloc failed as you, with a sysctl compat.linuxkpi.skb.mem_limit to 1 too. In my case they start interleaved with, or sometimes hours after, some: Dec 31 16:35:26 pasdfric kernel: pid 54454 (clang++), jid 0, uid 1001, was killed: failed to reclaim memory But once I started having some "skb alloc failed", the situation degrades for rtw88, *even when pressure on memory has decreased* (no "failed to reclaim memory" anymore). So it is inexact that it occurs "when VM is exhausted", it is more that it occurs "when the system got through at least one VM exhaust since booting". If I take another session of December 31 from /var/log/messages, from boot to crash, I get: 18:47:20 boot 19:41:08 two kills after VM exhaust 20:19:51 first skb alloc failed (repeated hundreds of times until a reboot) In this case there were no interleaves of skb alloc with the VM exhaust, it came after. Maybe the problem is not about going into virtual mem, but instead just crossing the 4 GB border, which would explain why the problem occurs even after the memory pressure diminished. I would say that: 1. either a fisrt failed allocation, due to memory exhaust, let the driver in a dirty state it is unable to recover from even after memory became available again (the structure it wanted to allocate was crucial for later operations); but if it was the case you should find memory exhaust related logs in your /var/log/messages, between the boot and the first skb alloc failed 2. or that, once the kernel allocates at adresses > 4 GB, LinuxKPI declines the allocs -- You are receiving this mail because: You are on the CC list for the bug.
