[ltp] ibm_acpi and modprobe.conf

linux-thinkpad@linux-thinkpad.org linux-thinkpad@linux-thinkpad.org
Tue, 26 Jul 2005 20:50:51 +0100 (BST)


Thanks for the reply, FeRD:

> You didn't mention how you're loading the module (properly) after boot -- 
> are you using modprobe? And if so, does a 'modprobe -v ibm_acpi' show the 
> options from your modprobe.conf being passed to insmod by modprobe?

Yes - after bootup I am, and it always works correctly with options
specified in modprobe.conf - and as you say modprobe -v confirms
this.  What's baffling me is if I don't load it manually anywhere
with modprobe, it's still loaded on bootup - I don't know where from
- and ignores settings in modprobe.conf.  If I reload it manually by
hand or in rc.local, it's fine.  But that's messy.

Thanks for the cat -vent - didn't think to check for whitespace, but
it confirms it's ok.  I'm using FC4 also.  Where do you load the
module at bootup?  I'm pretty sure I didn't manually modprobe
anywhere, and it loaded without options.  But I get hazy on where
bootup decides to load which modules - hardware detection of IBM-ish
stuff?  Highly technical guess there :)

> (I don't 
> believe ibm_acpi would be in your initrd unless you intentionally put it 
> there, but I'm not too familiar with the initrd structure. It's all black 
> magic to me.)

Yes, checked this - you can unpack the initrd with gzip and take a
look.  I make my own anyway with radeonfb included, and for swsusp2
- it *really* isn't in there, promise..!

> I do always take the precaution of rm'ing /lib/modules/`uname 
> -r`/kernel/drivers/acpi/ibm_acpi.ko when I build and install version 0.11, 
> since I don't install it in the same place as the distribution version. So 
> if you still have the old version installed, check that the system isn't 
> grabbing that one at boot.

I don't like deleting stuff that's included in an RPM, but that's me
being over-fastidious - having gone through some Red Hat/Fedora
lists, it seems there's no clearly defined order in which modules
are loaded - except by checking modules.dep, which depmod compiles,
I think - and which for me always puts the added one above the older
kernel one.  Maybe at bootup whatever's loading it *is* loading the
old one - I wish I understood why it's being loaded at all.  Maybe I
could rename the kernel one and reboot, yes.

> 'modinfo' also doesn't necessarily help you here, since it doesn't show the 
> version of the module that's already BEEN LOADED into the kernel. (Unless 
> there's a flag I missed.) That was part of what led to my confusion and 
> suspected/possible heisenbug, I think.

Thanks - didn't know that.  It seems weird to me that there appears
to be no way of knowing what version of module is *actually loaded*
and with what options.  Is there really no way?  Nothing in /proc or
/sys?

Honey