From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 08:52:52 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCE00EC2; Tue, 25 Nov 2014 08:52:52 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 85E806AF; Tue, 25 Nov 2014 08:52:52 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id E07F2ABC8; Tue, 25 Nov 2014 08:52:51 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 019031276; Tue, 25 Nov 2014 09:52:41 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mark R V Murray Subject: Re: svn commit: r274739 - head/sys/mips/conf References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> <86wq6k9okk.fsf@nine.des.no> Date: Tue, 25 Nov 2014 09:52:41 +0100 In-Reply-To: (Mark R. V. Murray's message of "Tue, 25 Nov 2014 07:53:51 +0000") Message-ID: <8661e3wtk6.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, Ian Lepore X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 08:52:52 -0000 Mark R V Murray writes: > How two consecutive calls to get_cyclecount() can repeatedly return > such massive numbers is an indication that something has gone badly > wrong. No, wait. I looked at the code. The most likely explanation is that it is falling through to this: binuptime(&bt); return ((uint64_t)bt.sec << 56 | bt.frac >> 8); so the top 8 bits are seconds (meaning that get_cyclecount wraps around every 256 seconds) and the bottom 64 are the base 2 fractional part. At first glance, Ian's number seem to be identical from one run to the next, but they're not - there seems to be a small amount of variation. But I'm still very suspicious of at91_st0, which is constant, and nexus0, at91_aic0 and at91_pmc0, which are constant *and* identical. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no