Subject: kern/15688: p_stats->p_cru.ru_utime.tv_sec may become negative
To: None <gnats-bugs@gnats.netbsd.org>
From: Martin Husemann <martin@duskware.de>
List: netbsd-bugs
Date: 02/21/2002 20:48:57
>Number:         15688
>Category:       kern
>Synopsis:       p_stats->p_cru.ru_utime.tv_sec may become negative
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Feb 21 11:50:03 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Martin Husemann
>Release:        NetBSD 1.5ZA
>Organization:
>Environment:
System: NetBSD night-porter.duskware.de 1.5ZA NetBSD 1.5ZA (PORTER) #0: Tue Feb 12 21:59:35 CET 2002 martin@insomnia.duskware.de:/usr/src/sys/arch/i386/compile/PORTER i386
Architecture: i386
Machine: i386
>Description:

When you step the time backwards (or have ntpd runing causing this, i.e. just
after booting a machine, on first sync to the next timeserver), processes
started before this step may get a negative cummulated child cpu time.

Example from my sparc64 system:

168 ?? S    0:-2.74 /usr/pkg/sbin/upsmon 

This has been started just before ntpd, and ntpd did a few time resets
initially:

Feb 21 19:08:28 setting-sun ntpd[143]: time reset 5.511258 s
Feb 21 19:08:28 setting-sun ntpd[143]: kernel pll status change 41
Feb 21 19:28:51 setting-sun ntpd[143]: time reset 0.574144 s
Feb 21 19:49:19 setting-sun ntpd[143]: time reset 0.132181 s

I'm not sure fixing the scheduler to correctly handle this situation are
worth the additional context switch time.

>How-To-Repeat:
s/a
>Fix:
n/a
>Release-Note:
>Audit-Trail:
>Unformatted: