From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 17:08:19 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 7EBF3B51; Tue, 25 Nov 2014 17:08:19 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 314A58B6; Tue, 25 Nov 2014 17:08:18 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XtJb7-0009dW-CR; Tue, 25 Nov 2014 17:08:17 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sAPH8F40013732; Tue, 25 Nov 2014 10:08:15 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+xKkRlxR4pN1Cdv5BsDYaC X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: svn commit: r274739 - head/sys/mips/conf From: Ian Lepore To: Adrian Chadd In-Reply-To: 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> <8661e3wtk6.fsf@nine.des.no> <86oarvvaet.fsf@nine.des.no> <86egsrxypx.fsf@nine.des.no> <1416925387.1147.437.camel@revolution.hippie.lan> Content-Type: text/plain; charset="ISO-8859-1" Date: Tue, 25 Nov 2014 10:08:15 -0700 Message-ID: <1416935295.1147.457.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id sAPH8F40013732 Cc: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= , Mark R V Murray , "freebsd-arch@freebsd.org" 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 17:08:19 -0000 On Tue, 2014-11-25 at 08:59 -0800, Adrian Chadd wrote: > On 25 November 2014 at 06:23, Ian Lepore wrote: > > On Tue, 2014-11-25 at 13:15 +0100, Dag-Erling Sm=F8rgrav wrote: > >> Ian, please try the attached patch. > >> > >> The way this is intended to be used is that you set up a system with= an > >> /etc/rc that does nothing else than mount the root file system and > >> append the output from "sysctl -b hw.attachtimes" to a log file, the= n > >> reboot. You let it run for as long as you wish, then copy the log f= ile > >> to another machine and run the attachtimes utility (source code belo= w) > >> on the log file to extract the data and display either the raw numbe= rs > >> or a histogram showing the distribution. > >> > >> See freefall:~des/software/attachtimes.tgz for an example of how to = set > >> this up. All you need is the loader and kernel, a minimal /etc, and= the > >> tools required by /etc/rc (sh, fsck, mount, df, sysctl, halt, reboot= ). > >> The example contains quite a bit more than that because I wanted to = be > >> able to boot it in single-user mode for debugging. > >> > >> The patch can easily be modified to record the actual timestamps ins= tead > >> of just the delta, but remember to modify the utility as well, or th= e > >> output will be complete nonsense. > >> > >> DES > > > > Getting the results for this is going to take a while... I can't get = the > > system past mountroot right now. I have no idea why. It's been mont= hs > > since I last successfully booted -current on this old hardware. I'm > > also very busy with $work. > > > > For the 3 numbers that are identical at the start, I think we're read= ing > > garbage in binuptime() because the clock driver isn't working yet. T= he > > numbers first change with at91_st0, that's the clock driver. atmelar= m0 > > is the parent of everything listed between nexus and it, so the large > > number there is probably the subtraction of the post-init clock value > > from the pre-init clock garbage. > > > > In a more general sense, I'm going to repeat a couple things... > > > > The clock all this is being measured with runs at 32 KHz. That's 'K'. > > > > This output is evidence that the system behaves exactly as I've been > > saying it behaves for a long long while. You seem convinced, I don't > > understand why, that there must be some error here. I don't understa= nd > > why you think a system like this would behave any differently each ti= me > > it is powered on. The only actual entropy involved is whatever minor > > thermal transients may exist in the crystal oscillator. With 32KHz > > resolution (or even a few MHz) that amounts to not a lot of measurabl= e > > variation at all. > > > > The repeatability of the boot sequence of hardware like this is nearl= y > > perfect at the resolution we're measuring. While that may be bad for > > gathering entropy, it's a wonderful thing when you're debugging, beca= use > > problems that would be almost impossible to nail down on modern compl= ex > > hardware are 100% reproducible by just hitting the reset button. Tha= t > > reproducibility extends all the way into multiuser mode unless there = is > > a network connection where packet arrival times start adding > > interrupt-based entropy. > > >=20 > Can you bring up the clock first? Or at least earlier? >=20 First as in "before nexus"? That sounds tricky. Looking at the order of things now, it's nexus, the main SoC bus, the interrupt controller, power-management, clock driver. That seems reasonable to me, you need all that other stuff first to get the clock to the point where it can register as a timecounter and provide timestamps. > Should bintime() be returning garbage so early? I wonder if that'd > have an effect on any other driver startup paths that may use it. >=20 >=20 It seems odd that it returns garbage, but the alternative would be to return zero, and while that makes more sense to me, it isn't helpful in terms of providing useful data (other than as an indication that the clock isn't running yet). -- Ian