DragonFly BSD
DragonFly bugs List (threaded) for 2004-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Problems with clock on 1.1-CURRENT


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, 19 Jul 2004 21:18:31 -0700 (PDT)

: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
    is one.

    So if you cvsup, update, compile up a new kernel and reboot, we can
    hopefully diagnose some of these issues.

    The sysctl is:

    sysctl hw.i8254.timestamp

    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:

    #!/bin/csh
    #
    set i = 0
    while ( $i < 50 ) 
	sysctl hw.i8254.timestamp
	@ i = $i + 1
    end

    And maybe we can figure out what is going on.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]