Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Feb 2002 10:46:12 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        <freebsd-current@FreeBSD.ORG>
Subject:   Re: 'microuptime() went backwards ...' using ACPI timer.  Shouldn't that be impossible?
Message-ID:  <200202171846.g1HIkCQ71367@apollo.backplane.com>
References:   <20020217184436.M934-100000@gamplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
:I just wrote the following fix for some of the overflow problems.

    I don't understand how this code is supposed to handle overflows.
    You seem only to be checking to see if the master timecounter has
    changed to a different type.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

:%%%
:Index: kern_tc.c
:===================================================================
:RCS file: /home/ncvs/src/sys/kern/kern_tc.c,v
:retrieving revision 1.113
:diff -c -2 -r1.113 kern_tc.c
:*** kern_tc.c	7 Feb 2002 21:21:55 -0000	1.113
:--- kern_tc.c	17 Feb 2002 06:25:14 -0000
:***************
:*** 108,114 ****
:  	struct timecounter *tc;
:
:! 	tc = timecounter;
:! 	*bt = tc->tc_offset;
:! 	bintime_addx(bt, tc->tc_scale * tco_delta(tc));
:  }
:
:--- 95,129 ----
:  	struct timecounter *tc;
:
:! 	/*
:! 	 * The loop is to handle changes of timecounter underneath us.
:! 	 * Such changes may even become normal for preemptive kernels.
:! 	 * It is quite reasonable for idle priority processes to not
:! 	 * run for many seconds, and if they are not running after
:! 	 * being preempted here, the timecounter may cycle many times
:! 	 * underneath them.  An NTIMECOUNTER of > 2 is neither necessary
:! 	 * or sufficient for fixing this problem, unless NTIMECOUNTER is
:! 	 * preposterously large.  NTIMECOUNTER == 2 suffices for most
:! 	 * cases, and something more is required to fix the general case.
:! 	 *
:! 	 * I hope this also fixes problems with overflow of the
:! 	 * multiplication.  We depend on tc not becoming stale by more
:! 	 * than 1 second.  We will now normally see such staleness
:! 	 * because it will cause the timecounter to change many times
:! 	 * underneath us.  There will only be problems if hardclock()
:! 	 * doesn't run for many seconds, but hardclock() is a very
:! 	 * high priority interrupt, so such problems "can't happen".
:! 	 *
:! 	 * XXX should use a generation count.
:! 	 *
:! 	 * XXX problems with hardclock() can happen, e.g., at boot time
:! 	 * if you have fixed hardclock() to not be a broken fast interrupt
:! 	 * handler, or if you sit at the ddb prompt for several seconds.
:! 	 * Should do something to make them harmless.
:! 	 */
:! 	do {
:! 		tc = timecounter;
:! 		*bt = tc->tc_offset;
:! 		bintime_addx(bt, tc->tc_scale * tco_delta(tc));
:! 	} while (tc != timecounter);
:  }
:
:%%%
:
:Bruce

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202171846.g1HIkCQ71367>