Some modules aren't loading and when I edit rc.modules it doesn't help. To be more specific, sata_promise, ahci, libata and coretemp are not loading. I've removed them from blacklist. I'm sure they aren't the only ones that aren't loading either, I've just not noticed.

I was going to add a file to /etc/modprobe.d/, but then I noticed a bunch of pnp:PNP0543whatevers in there and didn't know what to make of them. I'll try that, but I'm not counting on it working.

Back before modprobe.conf became deprecated I could just generate-modprobe.conf and everything was nice. Anyway, adding modprobe this and modprobe that to rc.modules doesn't work and was wondering if anyone could point me in the right direction.

OH, when I manually do modprobe ahci libata sata_promise etc, it works fine, then drive mounts and is working correctly.

You should be placing the `modprobe` commands in /etc/rc.d/rc.modules-$(uname -r), which is /etc/rc.d/rc.modules-2.6.24.5-smp in a default 12.1 setup or /etc/rc.d/rc.modules-2.6.21.5-smp in a default 12.0 setup. /etc/rc.d/rc.modules is usually a symlink to one of the above files, but if you modified things (ie you use a different kernel, like your signature suggests, or if through an upgrading error from 12.0 to 12.1 that symlink is still pointing to rc.modules-2.6.21.5-smp -- though this shouldn't matter, if you look below), it'll be incorrect.

/etc/rc.d/rc.S loads the first rc.modules file it finds, looking in the following order:
rc.modules.local
rc.modules-$(uname -r)
rc.modules

You could just create an rc.modules.local file that you could keep consistent across kernel compiles (assuming you don't change any kernel options that affect the extra modules you're trying to load), or you could create (or modify) /etc/rc.d/rc.modules-$(uname -r).

More information would be nice, such as which Slackware version and kernel version you're using, whether it's a default kernel (if so which one) or if you compiled your own. Your signature suggests 12.0 with a custom-compiled 2.6.25.1, but that could be old for all I know. I would *guess* that a /etc/rc.d/rc.modules-$(uname -r) file exists, and that rc.modules isn't pointing to it, and so editing rc.modules isn't loading the appropriate modules. I could be wrong -- are there any errors during bootup (they may not be present in the logs -- check the screen as it boots)? As a last-resort hack, you could add the modprobe commands to rc.local, but that is NOT the best idea. You should also make sure that in rc.modules* you're using the absolute path of /sbin/modprobe, because the $PATH variable for root may not be filled yet.

Hmm... I don't have a rc.modules.local file. I do have an rc.local file.

My rc.modules is a simlink to rc.modules-2.6.21.5-smp. So, if I open rc.modules it opens that file instead. Looking through the file, I'm thinking I could just change the name and relink it and that would be enough as it seems pretty generic. Of course, I'm no scripting wiz.

Though, I did have to create the simlink as it would seem it wasn't there before? Then it ran it on boot up, when I'm fairly certain it didn't before, but this did not solve my problem.

Well, I'm having similar problems with both my laptop and the computer in my sig. The laptop has a pretty much default slackware 12.1 with the 2.6.25.1 kernel and my sig is up to date, except I added a Promise SATA TX4 controller. I must say I had some issues with that kernel version, but that's besides the point. My laptop doesn't want to load coretemp, but I'm pretty sure that whatever I'm doing wrong with sata_promise modules I'm doing wrong with coretemp, so I'd rather just concentrate on the computer in my sig as I'm guessing I can apply the fix to my laptop as well.

The errors and oddities I'm seeing in dmesg are:

ACPI: Handling Garbled _PRT entry
iomem 0xf0000-0xfbfff could not be reserved
Driver 'sd' needs updating - please use bus_type methods

The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

I really think by adding it to rc.modules that I'm forcing it and that won't work because lspci sees it fine and it seems to give me something that look like normal output about sata and it's my only sata device of any kind in my system. It says:

ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)

and other things like that. Though it's supposed to be a 3.0 Gbps controller but I can't complain until the thing at least loads properly.. lol... Besides I think there's another reason it says that anyway.

One more thing, it sometimes loads as /dev/sda1 and other times as /dev/sdb1, even though it's my only sata or scsi device.

I hope I didn't ramble too much for anyone and thanks for your reply.