Date: Tue, 25 Nov 2014 08:59:44 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Ian Lepore <ian@freebsd.org> Cc: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= <des@des.no>, Mark R V Murray <mark@grondar.org>, "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: svn commit: r274739 - head/sys/mips/conf Message-ID: <CAJ-Vmo=EPuDB0WsOoq0cjiZW-QxdNXL80h5wVDYgbWvHYuAL=Q@mail.gmail.com> In-Reply-To: <1416925387.1147.437.camel@revolution.hippie.lan> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <AE8F2D30-7F91-4C90-B79A-D99857D8AED8@grondar.org> <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> <F017033A-B761-4435-A7F8-264D2F4662A0@grondar.org> <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> <CC6B67E1-55A2-4952-AB43-5F6C787F629B@grondar.org> <86wq6k9okk.fsf@nine.des.no> <F60907B5-433F-4800-82B4-5D882AF0B3BB@grondar.org> <8661e3wtk6.fsf@nine.des.no> <D928DF64-2C5D-4D31-A7BE-62482A53A7EA@grondar.org> <86oarvvaet.fsf@nine.des.no> <86egsrxypx.fsf@nine.des.no> <1416925387.1147.437.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 25 November 2014 at 06:23, Ian Lepore <ian@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=EPuDB0WsOoq0cjiZW-QxdNXL80h5wVDYgbWvHYuAL=Q>