svn commit: r274739 - head/sys/mips/conf

[Adrian Chadd]

On 25 November 2014 at 06:23, Ian Lepore <ian at freebsd.org> wrote:
> On Tue, 2014-11-25 at 13:15 +0100, Dag-Erling Smørgrav 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