> Yeah, it doesn't look like the MODULE_PARM mechanism is fully debugged
> in 2.1.22, or at least, several source files aren't yet using it
> correctly.
> And off the top of my head, it looks like the parameter is named "i",
> which is probably not a good idea...
The following patch resolves the issue for me:
(Sorry, it is posted from my aol windows program, so will need fromdos)
--- linux/drivers/cdrom/isp16.c~ Sun Jan 19 14:28:58 1997
+++ linux/drivers/cdrom/isp16.c Sun Jan 19 14:29:53 1997
@@ -62,12 +62,12 @@
static int isp16_cdrom_irq = ISP16_CDROM_IRQ;
static int isp16_cdrom_dma = ISP16_CDROM_DMA;
static char *isp16_cdrom_type = ISP16_CDROM_TYPE;
+
+#ifdef MODULE
MODULE_PARM(isp16_cdrom_base, "i");
MODULE_PARM(isp16_cdrom_irq, "i");
MODULE_PARM(isp16_cdrom_dma, "i");
MODULE_PARM(isp16_cdrom_type, "s");
-
-#ifdef MODULE
int init_module(void);
void cleanup_module(void);
#endif
--- linux/drivers/cdrom/sjcd.c~ Sat Jan 4 17:46:20 1997
+++ linux/drivers/cdrom/sjcd.c Sun Jan 19 14:27:43 1997
@@ -106,7 +106,10 @@
static struct sjcd_play_msf sjcd_playing;
static int sjcd_base = SJCD_BASE_ADDR;
+
+#ifdef MODULE
MODULE_PARM(sjcd_base, "i");
+#endif
static struct wait_queue *sjcd_waitq = NULL;
------------------------------- cut here ------------------------------------
Darrell A Escola
Clovis, Californea USA