two 2.5 modules bugs

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

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

@@ -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:

This should be fixed in 0.9.6: a double free caused all kinds of wierd behavior. Please tell me if this fixes it.

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
@@ -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

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.

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.

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   |_______/

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

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

Good idea - I'd be grateful if more manufacturers would supply a datasheet at all :-).

John.

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.

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.

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

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.

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/