DragonFly bugs List (threaded) for 2004-07
Re: Problems with clock on 1.1-CURRENT
:On the P166, it occurs whenever I run a buildworld. And I've had it
:happen a few times during a cvsup of the ports tree using a Linksys
:16-bit PCCard NIC using the ed(4) driver.
:On the Celeron, it occurs about every third time I start XFree86. I
:can start top in one virtual terminal and watch as XFree86 loads, and
:just as KDE starts initialising devices, the clock goes crazy. It
:also happened once during the initial buildworld (the make output just
:flew by onscreen, a hell of a lot faster than it should have).
:The laptops are at work right now. I can make dmesg and vmstat output
:available tomorrow if need be.
:Freddie Cash, CCNT CCLP Helpdesk / Network Support Tech.
I'll do you one better... I just committed some in-kernel timer
diagnostics. The kernel will now unconditionally report its timer
calibration at boot (dmesg | fgrep clock), and, even better, I added
a sysctl which will dump the current 8254 timer 2 counter which is used
as a basis for system timing, and it will even throw in the TSC if there
So if you cvsup, update, compile up a new kernel and reboot, we can
hopefully diagnose some of these issues.
The sysctl is:
The output looks like this (in a tight loop):
hw.i8254.timestamp: 14b59d0f 000000a3728d614b
hw.i8254.timestamp: 14b59ec3 000000a3729916b0
hw.i8254.timestamp: 14b5a08a 000000a372a54eeb
hw.i8254.timestamp: 14b5a23e 000000a372b10450
The first number is the 8254 timer 2 expanded to 32 bits (the upper 16
bits being software generated, the lower 16 bits inverted so it counts up
instead of down). The second number is the current TSC (if the system
has a TSC).
I would like you to run a script before and after the problem occurs:
set i = 0
while ( $i < 50 )
@ i = $i + 1
And maybe we can figure out what is going on.