this sounds like the timecounter goes backwards issue.

for a long on the sparc port time we saw issues where
getrusage() would return garbage (very large) values for
times.  after a lot of debugging, i tracked it down to
the tc giving a lower value than it should have, without
ever getting close to overflowing, which ends up sending
negative runtime down into the system.

aren't there known issues with the tc you mentioned and
SMP systems?

this is the fix i applied for sparc:

http://mail-index.netbsd.org/source-changes/2018/01/12/msg091064.html

but note that it has a common source, not per-cpu one.


.mrg.

Reply via email to