On 2020-01-09 11:12, Hans Petter Selasky wrote: > 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. > > --HPS I actually see the same (r356321M), but I think it is not harmful: temp 18446744073709545743 18014398509476107K - 89826 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536 --HPSReceived on Thu Jan 09 2020 - 09:15:06 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:22 UTC