tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Speeding up autoconf on PCs

> 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?).

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

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

I'm wondering if the rnd issues are unrelated to the stack issues and
at least that is something else entirely.

Any ideas?


Attachment: pgpakDljRSFcf.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index