1. With kernel 2.5.53 and module-init-tools-0.9.6, "modprobe tulip"
fails and goes into an infinite CPU-consuming loop. The problem
appears to be related to the dependency from tulip to crc32. If I
manually modprobe crc32 before modprobe tulip, it works. If crc32
isn't loaded, modprobe tulip first loads crc32 and then loops.
module-init-tools-0.9.5 did not have this problem.
2. The implementation of old-style MODULE_PARMs with type "1-16s"
is broken. Instead of splicing the parameter at the commas and
storing pointers to the substrings in consecutive array elements,
the whole string is stored in the array instead.
Consider parport_pc.c, which contains (simplified):
static const char *irq[16];
MODULE_PARM(irq, "1-16s");
"modprobe parport_pc irq=007" should store a pointer to "007" in
irq[0], but instead (unsigned int)irq[0] == 0x00373030, the ASCII
representation of "007" in little-endian. (Kernel 2.5.53 on x86,
with module-init-tools-0.9.[56].)
/Mikael
On Fri, Dec 27, 2002 at 05:16:35PM +0100, Mikael Pettersson wrote:
> 1. With kernel 2.5.53 and module-init-tools-0.9.6, "modprobe tulip"
> fails and goes into an infinite CPU-consuming loop. The problem
> appears to be related to the dependency from tulip to crc32. If I
> manually modprobe crc32 before modprobe tulip, it works. If crc32
> isn't loaded, modprobe tulip first loads crc32 and then loops.
>
> module-init-tools-0.9.5 did not have this problem.
Load modprobe with MALLOC_CHECK_=1. It will reveal that it tries to
free() some non-mallocated area.
Try patch below, insmod() can realloc/free its second argument, so
we can doublefree it, and glibc's malloc goes wild. It fixes problems
I had with modprobe ipx (which depends on psnap/p8022 which depends
on llc).
--- 0.9.6-1/modprobe.c.dist 2002-12-26 10:32:22.000000000 +0100
+++ 0.9.6-1/modprobe.c 2002-12-28 00:12:16.000000000 +0100
@@ -582,7 +582,7 @@
char *baseopts = NOFAIL(strdup(""));
insmod(list, baseopts, NULL, 0, dry_run, verbose, options,
commands, 0);
- free(baseopts);
+// free(baseopts);
}
/* Did config file override command or add options? */
Petr Vandrovec
[email protected]
In message <[email protected]> you write:
> 1. With kernel 2.5.53 and module-init-tools-0.9.6, "modprobe tulip"
> fails and goes into an infinite CPU-consuming loop. The problem
> appears to be related to the dependency from tulip to crc32. If I
> manually modprobe crc32 before modprobe tulip, it works. If crc32
> isn't loaded, modprobe tulip first loads crc32 and then loops.
>
> module-init-tools-0.9.5 did not have this problem.
This should be fixed in 0.9.6: a double free caused all kinds of wierd
behavior. Please tell me if this fixes it.
> 2. The implementation of old-style MODULE_PARMs with type "1-16s"
> is broken. Instead of splicing the parameter at the commas and
> storing pointers to the substrings in consecutive array elements,
> the whole string is stored in the array instead.
>
> Consider parport_pc.c, which contains (simplified):
>
> static const char *irq[16];
> MODULE_PARM(irq, "1-16s");
>
> "modprobe parport_pc irq=007" should store a pointer to "007" in
> irq[0], but instead (unsigned int)irq[0] == 0x00373030, the ASCII
> representation of "007" in little-endian. (Kernel 2.5.53 on x86,
> with module-init-tools-0.9.[56].)
Ew. I horribly misinterpreted "1-16s" to mean "a string 1-16 chars
long". The obvious fix (untested) is:
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.53/kernel/module.c working-2.5.53-sparam/kernel/module.c
--- linux-2.5.53/kernel/module.c 2002-12-26 15:41:06.000000000 +1100
+++ working-2.5.53-sparam/kernel/module.c 2002-12-28 21:32:34.000000000 +1100
@@ -604,7 +604,8 @@ extern int set_obsolete(const char *val,
return param_array(kp->name, val, min, max, obsparm->addr,
sizeof(long), param_set_long);
case 's':
- return param_string(kp->name, val, min, max, obsparm->addr);
+ return param_array(kp->name, val, min, max, obsparm->addr,
+ sizeof(char *), param_set_charp);
}
printk(KERN_ERR "Unknown obsolete parameter type %s\n", obsparm->type);
return -EINVAL;
I'll test this tomorrow...
Thanks for the bug report!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Not too long ago I had made a submission on SlashDot on something-or-other
(oh, right, "Rube-Goldberg Type Random Number Generators?"
http://ask.slashdot.org/article.pl?sid=02/07/26/1751228&tid=137) and I
stumbled across my submission to that article. After thinking about it, I
though it might be a reasonable thing to submit to this list as a possible
enhancement to the /dev/random driver if someone wants to try it. My
submission was thus:
"I've been vexed that the sound card plus CD-ROM drive combination always
shows signal at around -50 dBVU in CoolEdit. So, just for grins, I decided
to capture a few seconds of the noise and analyze the properties. I was
astonished to see that the resulting signal is a white-noise pattern with a
slight emphasis at the high end (when sampled at 44 kilosamples per
second). In short, it looks like diode noise with a 4 kilohertz square wave
thrown in.
"That suggests to me that this would make a fair source of random samples,
especially after you slot out the interfering signal.
"How many computers don't have cheap sound cards and CD-ROM drives?"
For what it's worth...
Satch
> I was astonished to see that the resulting signal is a white-noise
> pattern with a slight emphasis at the high end (when sampled at 44
> kilosamples per second). In short, it looks like diode noise with a
> 4 kilohertz square wave thrown in.
> "That suggests to me that this would make a fair source of random samples,
> especially after you slot out the interfering signal.
How can you guarantee that you are sampling noise, though, what if a
sound card was picking up 50 Hz mains hum, for example, that would
de-randomise the data quite a bit.
> "How many computers don't have cheap sound cards and CD-ROM drives?"
I have never understood how a 16-bit DAC or ADC can have noise above
96 dB. Surely _by definition_ a 16-bit DAC or ADC is one that does
not have noise above that level.
John.
* John Bradford ([email protected]) wrote:
>
> I have never understood how a 16-bit DAC or ADC can have noise above
> 96 dB. Surely _by definition_ a 16-bit DAC or ADC is one that does
> not have noise above that level.
Simple; the ADC might (ha - if you are lucky) have a nice low noise
figure; but its on a cheap sound card in a PC with god knows how much
other mush, with a cheap PSU with a piece of string connecting it to the
CDROM and loads of other crap.
Dave
---------------- Have a happy GNU millennium! ----------------------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
On Sat, Dec 28, 2002 at 04:00:25PM +0000, John Bradford wrote:
> I have never understood how a 16-bit DAC or ADC can have noise above
> 96 dB. Surely _by definition_ a 16-bit DAC or ADC is one that does
> not have noise above that level.
You're assuming that the ADC input is coupled to a noiseless source.
Most ADCs have a chunk of analogue circuitry just before them which
is a nice source of noise.
Not only will noise be picked up via disconnected inputs, but it will
also be picked up via the power supply and ground connections to that
analogue circuit. How much of that noise gets into the ADC input is
dependent on the quality, design and physical layout of the analogue
circuit.
(As a side note, it's interesting that (what used to be) Crystal
Semiconductor published a large chunk of information on the layout of
boards including the routing of power supplies for combined digital
and analogue circuits (and ADCs fall into that category.))
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
> > I have never understood how a 16-bit DAC or ADC can have noise above
> > 96 dB. Surely _by definition_ a 16-bit DAC or ADC is one that does
> > not have noise above that level.
>
> You're assuming that the ADC input is coupled to a noiseless source.
> Most ADCs have a chunk of analogue circuitry just before them which
> is a nice source of noise.
>
> Not only will noise be picked up via disconnected inputs, but it will
> also be picked up via the power supply and ground connections to that
> analogue circuit. How much of that noise gets into the ADC input is
> dependent on the quality, design and physical layout of the analogue
> circuit.
Right... So basically it can be claimed to be a 16-bit ADC as long as
it is noiseless above 96 dB, when all of the inputs to the ADC are
correctly terminated directly at the ADC inputs.
I just think it's funny that loads of "16-bit" soundcards are
effectively only 12-bit soundcards :-). Especially as that's about
the noise-floor of good quality vinyl :-).
> (As a side note, it's interesting that (what used to be) Crystal
> Semiconductor published a large chunk of information on the layout of
> boards including the routing of power supplies for combined digital
> and analogue circuits (and ADCs fall into that category.))
Good idea - I'd be grateful if more manufacturers would supply a
datasheet at all :-).
John.
> I was astonished to see that the resulting signal is a white-noise
> pattern with a slight emphasis at the high end (when sampled at 44
> kilosamples per second). In short, it looks like diode noise with a
> 4 kilohertz square wave thrown in.
> "That suggests to me that this would make a fair source of random samples,
> especially after you slot out the interfering signal.
JB> How can you guarantee that you are sampling noise, though, what if a
JB> sound card was picking up 50 Hz mains hum, for example, that would
JB> de-randomise the data quite a bit.
Well, the 50hz from the mains isn't a perfect 50hz; it has random (yes)
fluctuations.
Try this one: http://www.vanheusden.com/mirrors/audio-entropyd-0.0.5.tgz
(and if you have an unused video4linux-device, look here:
http://www.vanheusden.com/ved/ )
-----Oorspronkelijk bericht-----
Van: [email protected]
[mailto:[email protected]]Namens Stephen Satchell
Verzonden: zaterdag 28 december 2002 16:40
Aan: [email protected]
Onderwerp: Want a random entropy source?
Not too long ago I had made a submission on SlashDot on something-or-other
(oh, right, "Rube-Goldberg Type Random Number Generators?"
http://ask.slashdot.org/article.pl?sid=02/07/26/1751228&tid=137) and I
stumbled across my submission to that article. After thinking about it, I
though it might be a reasonable thing to submit to this list as a possible
enhancement to the /dev/random driver if someone wants to try it. My
submission was thus:
"I've been vexed that the sound card plus CD-ROM drive combination always
shows signal at around -50 dBVU in CoolEdit. So, just for grins, I decided
to capture a few seconds of the noise and analyze the properties. I was
astonished to see that the resulting signal is a white-noise pattern with a
slight emphasis at the high end (when sampled at 44 kilosamples per
second). In short, it looks like diode noise with a 4 kilohertz square wave
thrown in.
"That suggests to me that this would make a fair source of random samples,
especially after you slot out the interfering signal.
"How many computers don't have cheap sound cards and CD-ROM drives?"
For what it's worth...
Satch
> > I was astonished to see that the resulting signal is a white-noise
> > pattern with a slight emphasis at the high end (when sampled at 44
> > kilosamples per second). In short, it looks like diode noise with a
> > 4 kilohertz square wave thrown in.
> > "That suggests to me that this would make a fair source of random samples,
> > especially after you slot out the interfering signal.
> JB> How can you guarantee that you are sampling noise, though, what if a
> JB> sound card was picking up 50 Hz mains hum, for example, that would
> JB> de-randomise the data quite a bit.
>
> Well, the 50hz from the mains isn't a perfect 50hz; it has random (yes)
> fluctuations.
Yes, that's true.
More generally, though, is there any point in this going in to the
mainline kernel, if:
* Most users don't need faster entropy generation than we've got
and
* The entropy gathered from the soundcard is statistically inferior to
that gathered from the current sources of entropy.
I don't see how it's possible to guarantee that the data below a
certain dB level from the soundcard is noise.
John.
> Well, the 50hz from the mains isn't a perfect 50hz; it has random (yes)
> fluctuations.
JB> Yes, that's true.
JB> More generally, though, is there any point in this going in to the
JB> mainline kernel, if:
JB> * Most users don't need faster entropy generation than we've got
JB> and
JB> * The entropy gathered from the soundcard is statistically inferior to
JB> that gathered from the current sources of entropy.
Well, there isn't any :o) That's why there's a user-level implementation
for such a beast for those who do need it.
( http://www.vanheusden.com/mirrors/audio-entropyd-0.0.5.tgz )
JB> I don't see how it's possible to guarantee that the data below a
JB> certain dB level from the soundcard is noise.
Some guy contacted me about audio-entropyd and told me he'd done a lot
of analysis on all how this and gave me a few hints how to improve the
quality of what is produced with this tool. A quick fourier-
transformation doesn't really show any peaks.
At 09:28 PM 12/28/02 +0100, Folkert van Heusden wrote:
>JB> How can you guarantee that you are sampling noise, though, what if a
>JB> sound card was picking up 50 Hz mains hum, for example, that would
>JB> de-randomise the data quite a bit.
>
>Well, the 50hz from the mains isn't a perfect 50hz; it has random (yes)
>fluctuations.
As a start, I would slot out 50 Hz, 60 Hz (for people in the US and
US-engineered power systems in other countries), 4 kHz and
harmonics. Actually, if you are sampling at roughly random intervals you
would get about four to six bits per sample of somewhat random values, and
that would give you entropy as good as you get from mouse movement.
If someone were playing a CD at the time you were sampling the sound card,
you would get considerably more bits of entropy, but using the six bottom
bits would still be useful.
Hey, people, it's just a thought. Turning lemons into lemonade, if you will.
Satch
> Hey, people, it's just a thought. Turning lemons into lemonade, if you will.
Oh, I wasn't suggesting that it wasn't a useful idea, I was just
curious as to how random the entropy would be compared to other
sources such as disk and mouse activity.
John.
On Sat, 28 Dec 2002 21:37:22 +1100, Rusty Russell wrote:
>> 1. With kernel 2.5.53 and module-init-tools-0.9.6, "modprobe tulip"
>> fails and goes into an infinite CPU-consuming loop. The problem
>> appears to be related to the dependency from tulip to crc32. If I
>> manually modprobe crc32 before modprobe tulip, it works. If crc32
>> isn't loaded, modprobe tulip first loads crc32 and then loops.
>>
>> module-init-tools-0.9.5 did not have this problem.
>
>This should be fixed in 0.9.6: a double free caused all kinds of wierd
>behavior. Please tell me if this fixes it.
module-init-tools-0.9.7 fixed the problem.
>Ew. I horribly misinterpreted "1-16s" to mean "a string 1-16 chars
>long". The obvious fix (untested) is:
>
>diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.53/kernel/module.c working-2.5.53-sparam/kernel/module.c
>--- linux-2.5.53/kernel/module.c 2002-12-26 15:41:06.000000000 +1100
>+++ working-2.5.53-sparam/kernel/module.c 2002-12-28 21:32:34.000000000 +1100
>@@ -604,7 +604,8 @@ extern int set_obsolete(const char *val,
> return param_array(kp->name, val, min, max, obsparm->addr,
> sizeof(long), param_set_long);
> case 's':
>- return param_string(kp->name, val, min, max, obsparm->addr);
>+ return param_array(kp->name, val, min, max, obsparm->addr,
>+ sizeof(char *), param_set_charp);
> }
> printk(KERN_ERR "Unknown obsolete parameter type %s\n", obsparm->type);
> return -EINVAL;
Tested. This patch makes the parport_pc module work again. Thanks.
/Mikael
In message <[email protected]> you write:
> >long". The obvious fix (untested) is:
> >
> Tested. This patch makes the parport_pc module work again. Thanks.
Linus, please apply. Mikael, thanks for the excellent bug report!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Name: Fix MODULE_PARM for arrays of s.
Author: Rusty Russell
Status: Tested on 2.5.53 (by Mikael Pettersson)
D: I interpreted "1-10s" to mean a string of 1-10 chars. It actually
D: means 1-10 comma-separated strings.
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .748-linux-2.5-bk/kernel/module.c .748-linux-2.5-bk.updated/kernel/module.c
--- .748-linux-2.5-bk/kernel/module.c 2002-12-30 15:30:15.000000000 +1100
+++ .748-linux-2.5-bk.updated/kernel/module.c 2002-12-30 17:11:37.000000000 +1100
@@ -569,20 +569,6 @@ static int param_set_byte(const char *va
return 0;
}
-static int param_string(const char *name, const char *val,
- unsigned int min, unsigned int max,
- char *dest)
-{
- if (strlen(val) < min || strlen(val) > max) {
- printk(KERN_ERR
- "Parameter %s length must be %u-%u characters\n",
- name, min, max);
- return -EINVAL;
- }
- strcpy(dest, val);
- return 0;
-}
-
extern int set_obsolete(const char *val, struct kernel_param *kp)
{
unsigned int min, max;
@@ -618,7 +604,8 @@ extern int set_obsolete(const char *val,
return param_array(kp->name, val, min, max, obsparm->addr,
sizeof(long), param_set_long);
case 's':
- return param_string(kp->name, val, min, max, obsparm->addr);
+ return param_array(kp->name, val, min, max, obsparm->addr,
+ sizeof(char *), param_set_charp);
}
printk(KERN_ERR "Unknown obsolete parameter type %s\n", obsparm->type);
return -EINVAL;
> In message <[email protected]> you write:
> > >long". The obvious fix (untested) is:
> > >
> > Tested. This patch makes the parport_pc module work again. Thanks.
>
> Linus, please apply. Mikael, thanks for the excellent bug report!
>
> Rusty.
> --
> Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
>
> Name: Fix MODULE_PARM for arrays of s.
And this as well. We restore the ","s after parsing: if expect to
keep pointers to this stuff, we must not do that.
Linus, please apply.
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .5399-linux-2.5-bk/kernel/params.c .5399-linux-2.5-bk.updated/kernel/params.c
--- .5399-linux-2.5-bk/kernel/params.c 2002-12-26 15:41:06.000000000 +1100
+++ .5399-linux-2.5-bk.updated/kernel/params.c 2002-12-30 20:30:38.000000000 +1100
@@ -233,6 +233,7 @@ int param_array(const char *name,
int ret;
unsigned int count = 0;
struct kernel_param kp;
+ char save;
/* Get the name right for errors. */
kp.name = name;
@@ -247,7 +248,6 @@ int param_array(const char *name,
/* We expect a comma-separated list of values. */
do {
int len;
- char save;
if (count > max) {
printk(KERN_ERR "%s: can only take %i arguments\n",
@@ -256,18 +256,17 @@ int param_array(const char *name,
}
len = strcspn(val, ",");
- /* Temporarily nul-terminate and parse */
+ /* nul-terminate and parse */
save = val[len];
((char *)val)[len] = '\0';
ret = set(val, &kp);
- ((char *)val)[len] = save;
if (ret != 0)
return ret;
kp.arg += elemsize;
val += len+1;
count++;
- } while (val[-1] == ',');
+ } while (save == ',');
if (count < min) {
printk(KERN_ERR "%s: needs at least %i arguments\n",