I'm not sure if this should be in the Slackware forum or not (because it may be an issue with the initialization in Slack), but here goes.

I have an IBM Thinkpad 380XD. Everything works fine, even the sound, but there's a trick to it. You see, when I put the module load command into /etc/rc.d/rc.modules, it doesn't actually work. I have to unload it and then reload it using the exact same command once I get to a root prompt. Then it works fine. It also works perfectly if I put it in /etc/rc.d/rc.local which (of course) is executed last. My problem is that I shouldn't have to do this. I should simply be able to set up the module arguments in etc/modules.conf and then uncomment the already existing line in the standard Slackware /etc/rc.d/rc.modules.

What's going on? I think it's some sort of dependancy that's not being loaded in the right order or something. Anyway, here's some relevant information:

The proper module is cs4232.o

/usr/src/linux*/Documentation/sound/CS4232 says that the dependancies (and order they must be executed in) are as follows:
modprobe sound
insmod as1848
insmod uart401
insmod cs4232 (inits blah blah)

However, a simple "modprobe cs4232" should do the trick, provided that modules.conf is good to go. [NOTE: I've tried simply using the above commands in that order in etc/rc.d/rc.modules and it STILL needs to be reloaded, so that strengthens the case that it's a boot-order issue]

My etc/modules.conf is as follows:
--start--
options cs4232 io=0x530 irq=5 dma=1
--end--

That's it, just one line.

The relevant line (which is already in the standard Slackware /etc/rc.d/rc.modules) is simply:
---
/sbin/modprobe/cs4232
---

Note that with this configuration as-is it does not work. When I get to a root prompt and execute:

$rmmod cs4232
$modprobe cs4232

however, it works perfectly.

One final bit of information that is interesting is what I see when I execute dmesg:
---
as1848/cs4248 codec driver Copyright (blah blah)
as1848: No ISAPnP cards found, trying standard ones...
---

This message does not appear when loading the module manually from a root prompt.

Does anyone know what's going on? Like I said, it works fine from etc/rc.d/rc.local, but I shouldn't have to resort to that and I'd like to know what I can do to fix this and any similar problems I might find in the future.

Thanks!

-Andy Walker

--------------UPDATE------------

I have tried using an alias for the sound card to perhaps fix some priorities, but it simply makes it such that I have to type:
$rmmod (alias)
$modprobe (alias)
instead. Also, $lsmod produces the following output:
---
Module Size Used by Not tainted
cs4232 3652 0 (unused)
uart401 6532 0 [cs4232]
ad1848 22092 0 [cs4232]
sound 57516 0 [cs4232 uart401 ad1848]
---

However, this is the same whether the sound card is working or not.

The load from rc.modules is probably ignoring the options passed in /etc/modules.conf, which is a little odd... You can just pass the options directly on the module load:

/sbin/modprobe cs4232 io=0x530 irq=5 dma=1

That should work... also, did you enable hotplugging? As far as I know that doesn't give arguments to the modules properly.

Cheers,

Finegan

Thanks, but actually I HAVE tried directly passing the arguments to it. Still doesn't work... Hotplugging is enabled, but why should that effect this particular device?

I'm not sure how Patrick reconciled the use of /etc/rc.d/rc.modules and hotplugging. I think whatever it is that does hotpluging may actually run prior to when the rc.modules script gets run and therefore doesn't take the arguments to the module load.

One way to make certain is to put the sound module on the /etc/hotplug/blacklist

Actually, I just took a look at where each one is, and rc.hotplug gets called by rc.M whereas rc.modules gets called by rc.S, which should mean that hotplugging gets started second, but who knows if its fouling things up anyway...

Cheers,

Finegan