NetBSD Problem Report #10571

Received: (qmail 7699 invoked from network); 12 Jul 2000 01:22:15 -0000
Message-Id: <200007120122.TAA07144@loop.home>
Date: Tue, 11 Jul 2000 19:22:09 -0600 (MDT)
From: swp@alumni.rice.edu
Reply-To: swp@alumni.rice.edu
To: gnats-bugs@gnats.netbsd.org
Subject: process statistics bug
X-Send-Pr-Version: 3.95

>Number:         10571
>Category:       port-hp300
>Synopsis:       process time stats can be wildly bogus
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-hp300-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jul 12 01:23:00 +0000 2000
>Closed-Date:    Tue May 24 17:17:47 +0000 2005
>Last-Modified:  Tue May 24 17:17:47 +0000 2005
>Originator:     Steve Peurifoy
>Release:        NetBSD 1.5_ALPHA (20000624)
>Organization:
>Environment:
System: NetBSD loop 1.5_ALPHA NetBSD 1.5_ALPHA (loop) #0: Wed Jun 28 03:37:23 MDT 2000 swp@loop:/usr/src/sys/arch/hp300/compile/loop hp300


>Description:
    If a newly created process runs for just the right length of time
    before mi_switch() is invoked, its time statistics can be set to
    ridiculous values.  This is because mi_switch() calls microtime()
    at splstatclock (== splclock) or splhigh.  This can result in
    catching the timer just after it rolls over but before the value
    of the global time is updated, thus making time "go backward" as
    compared to the time value in spc->spc_runtime.  Running calcru()
    on the resulting p->p_rtime produces bogus results (a -1 long
    converted to a u_quad_t becomes a big number).

>How-To-Repeat:
    Running "time find /usr -type f -exec ls -l {} \; >/dev/null" on
    my 380 reliably produces numbers such as -28092518 seconds of
    system or user time because several of the child processes trip
    on this bug and wreak havoc on the job totals.  This particular
    test may not be reliable for other testers though.

>Fix:
    The following patch to sys/arch/hp300/hp300/clock.c
    isn't all that pretty but it works for me.  Doing
    something more correct for the hp300 would be possible
    but quite a bit more complicated.  Perhaps a sanity
    check in calcru() as well wouldn't be a bad idea.

*** /tmp/clock.c	Tue Jul 11 15:20:24 2000
--- /tmp/newclock.c	Tue Jul 11 19:11:57 2000
***************
*** 320,325 ****
--- 320,326 ----
  {
  	volatile struct clkreg *clk;
  	int s, u, t, u2, s2;
+ 	static struct timeval prevtime = {0, 0};

  	/*
  	 * Read registers from slowest-changing to fastest-changing,
***************
*** 342,351 ****
--- 343,361 ----
  	} while (u != u2 || s != s2);

  	u += (clkint - t) * CLK_RESOLUTION;
+ 	/*
+ 	 * If called with clock interrupts blocked, the timer can
+ 	 * roll over without the global time being updated.  Try
+ 	 * to adjust for this.
+ 	 */
+ 	if ((u <= prevtime.tv_usec) && (s == prevtime.tv_sec))
+ 		u += tick;
  	if (u >= 1000000) {		/* normalize */
  		s++;
  		u -= 1000000;
  	}
+ 	prevtime.tv_sec = s;
+ 	prevtime.tv_usec = u;
  	tvp->tv_sec = s;
  	tvp->tv_usec = u;
  }

>Release-Note:
>Audit-Trail:

Date: Fri, 2 May 2003 08:25:21 +0100
From: David Laight <david@l8s.co.uk>
Sender: gnats-bugs-owner@netbsd.org
Message-Id: <20030502082521.Q26297@snowdrop.l8s.co.uk>
To: Gregory McGarry <g.mcgarry@ieee.org>
In-Reply-To: <20030502184659.A18946@ieee.org>
Subject: Re: PR#10571
References: <20030502184659.A18946@ieee.org>

 On Fri, May 02, 2003 at 06:46:59PM +1200, Gregory McGarry wrote:
 > Do we still have this problem?
 > 
 > http://www.NetBSD.org/cgi-bin/query-pr-single.pl?number=10571

 There have been many changes, but I'm not sure anything I've
 done specifically addresses that one.

 Most of the microtime() functions DTRT and check for a pending
 clock interrupt and add it in - so maybe this is an Alpha bug.

 OTOH having mi_switch and calcru ignore -ve time intervals
 is sensible since setting the clock will cause a jump.

 But maybe the clock should be calculated by adding the 'boot time'
 to the 'time since boot' and any time setting code would adjuct the
 'boot time' value leaving a monatonic 'time since boot'.

 	David

 -- 
 David Laight: david@l8s.co.uk

State-Changed-From-To: open->closed
State-Changed-By: tsutsui@netbsd.org
State-Changed-When: Tue, 24 May 2005 17:17:47 +0000
State-Changed-Why:
Applied the similar fix.


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.