Date: Thu, 09 Jan 2025 10:40:53 +0000 From: bugzilla-noreply@freebsd.org To: wireless@FreeBSD.org Subject: [Bug 283903] rtw88: possible skb leak Message-ID: <bug-283903-21060-wikPFMys3f@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-283903-21060@https.bugs.freebsd.org/bugzilla/> References: <bug-283903-21060@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283903 --- Comment #5 from Guillaume Outters <guillaume-freebsd@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 a= lloc 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 f= or 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 exha= ust 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 --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-283903-21060-wikPFMys3f>