> 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 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? -- Dan.
Attachment:
pgpakDljRSFcf.pgp
Description: PGP signature