From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 16:59:47 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 177DA7D6; Tue, 25 Nov 2014 16:59:47 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E8467A4; Tue, 25 Nov 2014 16:59:46 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id h11so9834135wiw.1 for ; Tue, 25 Nov 2014 08:59:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=+lUjGBvddbpc0VsbOstHFvdNlPJenTvdIzmG1cb43SI=; b=cGGOXGic5TTlvMzI6R4dsUdOgQ1P4WLw83+T2iooOOdJKBR4Pn9lMORWC4O92dTMHN LijC2qXWKWGUrBOqasDQVZysF2ZcolzFQCzXCvo7m1Am4L9uUHtpP2A0+636/2KJSfVn 8eW9YexT+4JlaFp+ktSLTs7gFLIE3hY2RoxwOV00UECMeOw3dpOekr2xTi8uDDXcRhUa 069siI0/tIlHcddMkDhhn3lTCuNzYJRBU9ejrUWRHo3auSqRmElTTFznA2+HLks3m5IY Q1ofdw3Hb3GwgyYsPEjWuUHyf58AeHFtT7Px9yUnXHEgvWWZ0HXvnu6wo5RrrHX9z4/s dezA== MIME-Version: 1.0 X-Received: by 10.180.92.169 with SMTP id cn9mr33450214wib.26.1416934784954; Tue, 25 Nov 2014 08:59:44 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Tue, 25 Nov 2014 08:59:44 -0800 (PST) In-Reply-To: <1416925387.1147.437.camel@revolution.hippie.lan> 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> Date: Tue, 25 Nov 2014 08:59:44 -0800 X-Google-Sender-Auth: OWK5AcbPcj8pL16ZsvYOhc98vnY Message-ID: Subject: Re: svn commit: r274739 - head/sys/mips/conf From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= , 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 16:59:47 -0000 On 25 November 2014 at 06:23, Ian Lepore wrote: > On Tue, 2014-11-25 at 13:15 +0100, Dag-Erling Sm=C3=B8rgrav 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, then >> reboot. You let it run for as long as you wish, then copy the log file >> to another machine and run the attachtimes utility (source code below) >> on the log file to extract the data and display either the raw numbers >> 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 instead >> of just the delta, but remember to modify the utility as well, or the >> 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 months > 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 reading > garbage in binuptime() because the clock driver isn't working yet. The > numbers first change with at91_st0, that's the clock driver. atmelarm0 > 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 understand > why you think a system like this would behave any differently each time > 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 measurable > variation at all. > > The repeatability of the boot sequence of hardware like this is nearly > perfect at the resolution we're measuring. While that may be bad for > gathering entropy, it's a wonderful thing when you're debugging, because > problems that would be almost impossible to nail down on modern complex > hardware are 100% reproducible by just hitting the reset button. That > reproducibility extends all the way into multiuser mode unless there is > a network connection where packet arrival times start adding > interrupt-based entropy. > Can you bring up the clock first? Or at least earlier? 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. -adrian