Re: time(1) reporting corrupted system time
Mateusz Guzik wrote: > Hi, I failed to find a follow up to this. > > I see someone gave the you the fix for corrupted time accounting. > Did you get around to finding the offending commit? For the corrupted system time, I believe the offending commit was kern_resource.c 1.180, and the fix was 1.182. As for the increased system time taken by release builds, it has happened in multiple steps. I have bisected the largest increases, but analyzing and writing up the results for current-users is still on my "to do" list. -- Andreas Gustafsson, g...@gson.org
Re: time(1) reporting corrupted system time
On 9/29/19, Andreas Gustafsson wrote: > Hi all, > > I'm trying to run a bisection to determine why builds hosted on recent > versions of NetBSD seem to be taking significantly more system time > than they used to, building the same thing. > > My efforts are hampered by time(1) reporting corrupted system times on > certain past versions of -current: > > 2017.01.01.03.06.06/build_8.log: 3562.32 real 15806.10 user > 4893.62 sys > 2018.05.21.10.28.13/build_8.log: 4250.22 real 16835.23 user > 608742554440425.55 sys > 2019.01.30.20.20.36/build_8.log: 4228.25 real 16801.48 user > 700976274808841.24 sys > 2019.09.27.08.57.12/build_8.log: 4488.49 real 16670.79 user > 9279.25 sys > > Does anyone happen to know which commits caused and/or fixed this? > This information could save me a couple of days of bisection run time. Hi, I failed to find a follow up to this. I see someone gave the you the fix for corrupted time accounting. Did you get around to finding the offending commit? -- Mateusz Guzik
Re: time(1) reporting corrupted system time
Michael van Elst wrote: > First there was a change to precent that user/system time are decreasing > in kern-resource.c 1.180. But it shouldn't be related to negative numbers. > > Additionally a possible underflow of user/system time was fixed in > kern_resource.c 1.182. This prevents negative numbers, but IIRC this > would only happen for very small values, not when values already > accumulated to a few thousand seconds. Thanks. I think what happened is that 1.180 caused the bug, and 1.182 fixed it. In any case, I think I now have what I need to back-port the fix and bisect the other bug. -- Andreas Gustafsson, g...@gson.org
