Date: Tue, 25 Nov 2014 10:11:03 -0700 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@FreeBSD.org> Cc: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no>, Mark R V Murray <mark@grondar.org>, arch@freebsd.org Subject: Re: svn commit: r274739 - head/sys/mips/conf Message-ID: <18F34536-CA8B-4365-BDD9-C2D23E6067AA@bsdimp.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>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] > On Nov 25, 2014, at 7:23 AM, Ian Lepore <ian@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. I have similar hardware on my desk, and I might be able to find a little time to boot it. > 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. Yea, at best this bug is solved by initializing something to zero :) > 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’. Since these systems run at 200MHz or 400MHz, it makes a lot of sense that we’re seeing the same number. That’s like ~10k instructions between ticks. And since that is really 32,768Hz, it makes sense that the bottom 15 bits are zeros given how bintime encodes things. > 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. Yes, we’re 4 orders of magnitude above the ‘changes every instruction or so’ notion that Mark had sent out. > 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. Yea, every boot it is the same registers that are being read, in the same sequence, resulting in very similar cache patterns and performance profiles. I’d be surprised if anything apart from the ethernet chip’s state was different between boots. And even the ethernet’s stuff has a low variance until interrupts are turned on… Warner [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUdLgnAAoJEGwc0Sh9sBEAb7oP/Al2E4SXLa702GmiwHCllEQr PCl1vTy9XuBCQfgKNiT9M4MDFADg818/ZAL+kFxXVxCUvW1Lr4bUoy51bGTrdnpR +6/IGcSZ3UXm606wwuqj1FVorlgrVTxnXybCZNRQbiHZxsDUPnEIMWEyjUMAReBu RHkUUyYWSLRe2P/Mx30fMOygJUx1Q3NRAvhWn/gQk/viq6p9gIuR8dbwAL1tmAQX Ve1JBa6rkhp+d1/kWbSuImE3wSCIjYv8RF+/unxCZxJ1ocr2RQwXd/LavHOG7GAa e9VJb5jMRvTx/Gr5pby37UAeQGVQ4gIbiU75b9TNJXNMvi9z6f8GWbP+bn15U9tK 0cFe8ww6QZaP7L/XuWUtfOM4IjUMK4+2UVHf1XiePVACJ5WHt8sMlzMJWDVocenC VaN+QazmVJqpQxPEMQQyukDHJ9QwKbpHt/qMy8BK75d65s7rBXuwYiPBg0oYvIAk 2HBio3IkWgji0fsZzZMdIfMndie+Rd1YzUwv0ZAK9La0iIMgbrpw+8iDdvMQHtP+ y5AC+8UfFGz6VaZ+ZpYbqbx5GDtz8kwyI6cfjOFlcgf5OUgqZXsixbJJUI5Yz0d6 ODIwoK+sjPkqDAeODsbFXPzzdts2J+8STD7UlUasudcTHf5we9ekuMTJJuNED/BI xEoMYEJJONikyZjuXhkl =Ugyv -----END PGP SIGNATURE-----help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18F34536-CA8B-4365-BDD9-C2D23E6067AA>