For a while I had a similar problem where IRQ 14? would
trigger and attempt to add_timer_randomness before the
random driver's _init section had been run so it would go
into one of the infinite segfault loops on a un-initialized
variable, I just added a check on the pointer being
set, and returned if it was not. This only seems to happen
on faster machines 1G PIII or 1.4G Athlon my 200MHz
Pentium MMXes at home don't show this effect.
I am normally paranoid about un-initialized vars for just
these sort of reasons, it was a pain to track down, but
I had plenty of time on a new years day cross country
flight to hunt for it.
I just fixed it for my use by a simple extra check, not calling it
would of course be better but I did not care where the fast path
was, slow but working is much better than fast and wedged.
I think the base problem is that yet another assumption is being
broken by UML or the random device
or the magic init order is wrong again :(
likely the patch is mangled but here it is.
--- linux-2.6.0/drivers/char/random.c 2003-11-26 12:42:56.000000000 -0800
+++ G-03-2.6.0/drivers/char/random.c 2004-01-01 14:18:52.000000000 -0800
@@ -790,6 +760,8 @@
__s32 delta, delta2, delta3;
int entropy = 0;
+if (!random_state) return;
/* if over the trickle threshold, use only 1 in 4096 samples */
if ( random_state->entropy_count > trickle_thresh &&
(__get_cpu_var(trickle_count)__ & 0xfff))
Get latest updates about Open Source Projects, Conferences and News.