On 2020-01-09 10:59, Poul-Henning Kamp wrote: > I noticed yesterday that M_TEMP stats are screwed up, and rebooted my > laptop for reasons of safety. > > However, it's back again now: > > critter phk> vmstat -m | grep temp > temp 18446744073709546036 18014398509476380K - 963239 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536 > > FreeBSD critter.freebsd.dk 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r355131M: Wed Nov 27 16:44:48 UTC 2019 root_at_critter.freebsd.dk:/usr/obj/freebsd/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 > > I mentioned this on IRC yesterday and noted I had a "disk full" on > a tmpfs mount, but that can now be disregarded as a false lead. > > On this kernel I have had an instance where X got killed for > out-of-swap, at a time where that certainly should not have been > the case. > > Am I the only one seeing this ? > Hi, 2**64 - 18446744073709546036 ans = 6144 Someone likely freed to M_TEMP which were not supposed to free there. You could use dtrace to narrow this down and you can also add a kdb_backtrace() for the first couple of users of free() when the stats is negative. Else: grep -r M_TEMP /usr/src/sys And do an audit. --HPSReceived on Thu Jan 09 2020 - 09:12:52 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:22 UTC