Date: Mon, 24 Nov 2014 08:01:08 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Mark R V Murray <mark@grondar.org> Cc: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= <des@des.no>, arch@freebsd.org Subject: Re: svn commit: r274739 - head/sys/mips/conf Message-ID: <1416841268.1147.386.camel@revolution.hippie.lan> In-Reply-To: <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> 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>
index | next in thread | previous in thread | raw e-mail
On Mon, 2014-11-24 at 07:53 +0000, Mark R V Murray wrote:
> > On 24 Nov 2014, at 05:28, Ian Lepore <ian@FreeBSD.org> wrote:
> >
> > But I got some logging that maybe will be useful to you, attached. This
> > is the boot logging from hitting the reset button 4 times in a row. I
> > had RANDOM_DEBUG and FORTUNA options on.
>
> Thanks.
>
> > In the random debugging printf for device attach I added a display of
> > the actual bits being fed in as well as the count. That data in tabular
> > form (from 3 of the 4 runs so it fits email width) is interesting:
> >
> > nexus0: 0x00000010c6f7a0b6 0x00000010c6f7a0b6 0x00000010c6f7a0b6
> > at91_aic0: 0x00000010c6f7a0b6 0x00000010c6f7a0b6 0x00000010c6f7a0b6
> > at91_pmc0: 0x00000010c6f7a0b6 0x00000010c6f7a0b6 0x00000010c6f7a0b6
> > at91_st0: 0x0000003254e6e222 0x0000003254e6e222 0x0000003254e6e222
> > mmc0: 0x0000000000000000 0x0000000000000000 0x0000020000000000
> > at91_mci0: 0x0004480000000000 0x0004480000000000 0x00044e0000000000
> > ukphy0: 0x0001980000000000 0x00019a0000000000 0x0001960000000000
> > miibus0: 0x00060a0000000000 0x00060c0000000000 0x00060a0000000000
> > ate0: 0x000d260000000000 0x000d280000000000 0x000d2a0000000000
> > uart0: 0x0001400000000000 0x0001400000000000 0x0001400000000000
> > atmelarm0: 0x00231cc9539b8887 0x00231ec9539b8887 0x002328c9539b8887
> > mmcsd0: 0x0002620000000000 0x0002620000000000 0x0002620000000000
>
> Those numbers look weird; please send a diff of your change.
>
> The number of devices probed is also low. When you get the booting
> problem sorted, there are some constants that we could change that
> may help.
>
> > This nicely illustrates one of the main points I've been trying to make
> > for a long time: This kind of system boots nearly identically every
> > time you power on or reset. On every boot, all that "entropy" that's
> > getting fed in is about the same as last time it booted. In addition to
> > the low quantity of data available, when you consider its similarity
> > from one reboot to the next it's hard to even grace it with the name
> > "entropy.¡
>
> Iÿm well aware of that; Iÿve been saying something similar since at
> least 2000.
>
> M
The logging change was pretty simple:
Index: kern/subr_bus.c
===================================================================
--- kern/subr_bus.c (revision 274946)
+++ kern/subr_bus.c (working copy)
@@ -2851,8 +2851,8 @@ device_attach(device_t dev)
* need to be adjusted on other platforms.
*/
#ifdef RANDOM_DEBUG
- printf("random: %s(): feeding %d bit(s) of entropy from %s%d\n",
- __func__, 4, dev->driver->name, dev->unit);
+ printf("random: %s(): feeding %d bit(s) of entropy from %s%d: 0x%016llx\n",
+ __func__, 4, dev->driver->name, dev->unit, attachtime);
#endif
random_harvest(&attachtime, sizeof(attachtime), 4, RANDOM_ATTACH);
device_sysctl_update(dev);
The low number of devices is pretty typical. Sometimes there'll be
another uart. Sometimes an i2c eeprom.
I have no idea what's up with the first 3 unchanging numbers, but I
suspect a big part of the explanation for the other numbers is the 32KHz
clock it's getting the numbers from. There used to be a clock running
at about 2.8MHz, but the source code for that driver seems to have
disappeared from FreeBSD at some point between 8.x and -current.
-- Ian
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1416841268.1147.386.camel>