From: Dave H. <da...@jo...> - 2005-11-18 07:27:30
|
Hi, I think this is a single problem, but might be wrong. I have built kernel and tools, including miniperl, with revision 649 of buildroot, and have installed them on my 200MHz Gumstix Basix (with waysmall board only). Around 50% of the time I run the perl binary it dies immediately with the following message: Your random numbers are not that random I can only stop this happening by running export PERL_HASH_SEED=xxx beforehand (where xxx is some non-zero integer). Guessing that the cause might be the gumstix's limited stores of entropy I ran: cat /dev/random which gave absolutely nothing - ever. I then checked the values in /proc/sys/kernel/random/ which are: boot_id:de136bd0-2606-4239-90a8-a4408c4d75cb entropy_avail:0 poolsize:512 read_wakeup_threshold:64 uuid:94d3bf6e-66c0-4b81-8359-ae6b7d4b8011 write_wakeup_threshold:128 The entropy level never rises. (I would have thought the USB port I'm using should be able to provide at least a little.) I tried fudging things by making /dev/random psuedo-random with mknod /dev/random c 1 9 but perl still complained. Having not seen any forum traffic about this sort of behaviour, I'm getting worried I'm missing something obvious. What I'd like to know is: 1/ Have I broken something or shouldn't we expect anything from /dev/random? 2/ Is the perl failure a separate issue? (library related perhaps?) and possibly: 3/ How can I pump more entropy into the kernel? (assuming I can scratch some up from peripherals) Thanks Dave http://www.awma.au.com |
From: Chris D. <cg...@co...> - 2005-11-18 12:39:35
|
On 11/18/05, Dave Hawthorne <da...@jo...> wrote: > 3/ How can I pump more entropy into the kernel? (assuming I can scratch > some up from peripherals) Dave, Although I'm not sure about answers to your other questions, I know this one. Writing to either /dev/random or /dev/urandom is handled by adding the data to the kernel's entropy pool. -chris |
From: John P. <pa...@be...> - 2005-11-18 13:15:35
|
I see the perl "Your random numbers are not that random" issue also. -----Original Message----- From: gum...@li... [mailto:gum...@li...] On Behalf Of Dave Hawthorne Sent: Friday, November 18, 2005 2:27 AM To: gum...@li... Subject: [Gumstix-users] problem: /dev/random is empty, perl can't get hash seed Hi, I think this is a single problem, but might be wrong. I have built kernel and tools, including miniperl, with revision 649 of buildroot, and have installed them on my 200MHz Gumstix Basix (with waysmall board only). Around 50% of the time I run the perl binary it dies immediately with the following message: Your random numbers are not that random I can only stop this happening by running export PERL_HASH_SEED=xxx beforehand (where xxx is some non-zero integer). Guessing that the cause might be the gumstix's limited stores of entropy I ran: cat /dev/random which gave absolutely nothing - ever. I then checked the values in /proc/sys/kernel/random/ which are: boot_id:de136bd0-2606-4239-90a8-a4408c4d75cb entropy_avail:0 poolsize:512 read_wakeup_threshold:64 uuid:94d3bf6e-66c0-4b81-8359-ae6b7d4b8011 write_wakeup_threshold:128 The entropy level never rises. (I would have thought the USB port I'm using should be able to provide at least a little.) I tried fudging things by making /dev/random psuedo-random with mknod /dev/random c 1 9 but perl still complained. Having not seen any forum traffic about this sort of behaviour, I'm getting worried I'm missing something obvious. What I'd like to know is: 1/ Have I broken something or shouldn't we expect anything from /dev/random? 2/ Is the perl failure a separate issue? (library related perhaps?) and possibly: 3/ How can I pump more entropy into the kernel? (assuming I can scratch some up from peripherals) Thanks Dave http://www.awma.au.com ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Craig H. <cr...@gu...> - 2005-11-18 18:22:15
|
On Nov 17, 2005, at 11:26 PM, Dave Hawthorne wrote: > I think this is a single problem, but might be wrong. > > I have built kernel and tools, including miniperl, with revision > 649 of buildroot, and have installed them on my 200MHz Gumstix > Basix (with waysmall board only). Around 50% of the time I run the > perl binary it dies immediately with the following message: > Your random numbers are not that random > > I can only stop this happening by running > export PERL_HASH_SEED=xxx > beforehand (where xxx is some non-zero integer). > > Guessing that the cause might be the gumstix's limited stores of > entropy I ran: > cat /dev/random > which gave absolutely nothing - ever. I then checked the values > in /proc/sys/kernel/random/ which are: > > boot_id:de136bd0-2606-4239-90a8-a4408c4d75cb > entropy_avail:0 > poolsize:512 > read_wakeup_threshold:64 > uuid:94d3bf6e-66c0-4b81-8359-ae6b7d4b8011 > write_wakeup_threshold:128 > > The entropy level never rises. (I would have thought the USB port > I'm using should be able to provide at least a little.) Hmmm -- I'd have thought the USB fed the entropy pool too, as well as things like interrupts firing. Maybe that was a bad assumption on my part, and I need to hack that in myself -- the linux arm mailing list might be a good place to ask this. > I tried fudging things by making /dev/random psuedo-random with > mknod /dev/random c 1 9 > but perl still complained. > > Having not seen any forum traffic about this sort of behaviour, I'm > getting worried I'm missing something obvious. What I'd like to > know is: > 1/ Have I broken something or shouldn't we expect anything from / > dev/random? Well, I more or less assumed the kernel would take care of feeding some entropy to the pool from things like interrupt timings, usb, etc. but I guess it's not doing so. > 2/ Is the perl failure a separate issue? (library related perhaps?) Well, I'm a little surprised that perl is trying to eat from /dev/ random and not /dev/urandom > and possibly: > 3/ How can I pump more entropy into the kernel? (assuming I can > scratch some up from peripherals) How about dd if=/dev/urandom of=/dev/random bs=1k count=x for some value of x. Try that, then try running perl. If that fixes things temporarily, you could just start a background process at boot which does while true;do dd if=/dev/urandom of=/dev/random bs=1k count=x;sleep 60;done C |
From: Dave H. <da...@jo...> - 2005-11-24 04:22:45
|
I wrote: > Hi, > > I think this is a single problem, but might be wrong. ... and I was wrong. At least on my revision 649 build, perl produces the 'Your random numbers are not that random' message because it is using a broken library function (drand48()) to get floating-point PRNs. In my gumstix build uClibc's drand48() seems to use the wrong floating point format, the first and second 32 bit halves were reversed. This has something to do with the value of the flag __FLOAT_WORD_ORDER. This fault also rendered perl's rand() function useless. It could be replicated with the following code cross-compiled for the GS: #include <stdio.h> #include <stdlib.h> int main(void) { for( i = 0; i < 10; i++ ) { printf("%f\n",drand48()); } return 0; } I tried to change the setting in the uClibc build to fix my drand48() problem but got terribly tangled up. My shameful, quick work-around is to modify perl/config.sh as follows: doublesize='8' -drand01='drand48()' +drand01='((double)lrand48())/2147483648.0' drand48_r_proto='0' dynamic_ext='' And then rerun make in the perl buildroot directory. This fixes both my startup problem and rand() problem. The lack of output from /dev/random doesn't seem to upset perl at all. John P, I hope this helps with your issues too. Dave |