Re: Speeding up autoconf on PCs

[Andrew Doran <ad%netbsd.org@localhost>]

On Fri, Apr 04, 2008 at 07:12:34PM +1000, Daniel Carosone wrote:

> > On Sat, 29 Mar 2008, Andrew Doran wrote:
> > This patch uses kthreads to absorb delays during autoconf, speeding up the
> > boot process quite a bit.
> 
> A recent kernel since this was committed panics reliably during
> bootup, while probing and configuring usb.  The panic is detected as a
> stack overrun (maybe enabled by DIAGNOSTIC?).

SSP or the stack redzone? Have you got a backtrace from it?

> I guessed maybe too many threads were the problem, but dropping to 3
> rather than 8 still gives the same panic (just a few usb root devices
> earlier).
> 
> I don't have the dmesg handy, but the kernel also has:
>  options         RND_VERBOSE
>  options         RND_POOLWORDS=512
> 
> the RND_VERBOSE shows that there needs to be some locking in the rnd
> driver - the warning about insufficient entropy is printed several
> times over together with the usb probes.  Previously, I got a few of
> these, like so:
> 
> rnd: WARNING! initial entropy low (5).
> rnd: WARNING! initial entropy low (6).
> 
> the number increments each time it's called, because we mix in a
> current timestamp each time an extraction is called in a desperate
> attempt to get some early entropy and not seed with totally static
> values.  With the new kernel, I got lots more of these, and with lots
> of (0) and (1).  This seems to me like each has started into the rnd
> state earlier, and in parallel.
> 
> I'm wondering what in usb initialisation needs randomness and why, I'm
> wondering what to do about locking or serialisation in rnd (some kinds
> of overlap and races causing "pool corruption" might be fine, others
> not so - we don't want two concurrent threads producing the same
> output value).  I'm wondering if maybe the larger pool I'm using is
> also causng more stack to be used, and why it's a problem now and not
> earlier.
> 
> I'm wondering if the rnd issues are unrelated to the stack issues and
> at least that is something else entirely.
> 
> Any ideas?

The rnd code could definitley do with locking. I'll take a look.

Andrew