[ltp] ibm_acpi and modprobe.conf

[linux-thinkpad@linux-thinkpad.org]

On Sun, 31 Jul 2005, honey@gneek.com wrote:

>> However, if my "multiple versions" hypothesis is correct, it may explain 
>> the problem... version 0.8 of the ibm_acpi module didn't do much of 
>> anything with "experimental=1",
>
> Yes indeed - I really actually need to do some proper rebooting and
> experimenting with both problems.  Lazy me, I'll try and do so in the
> next few days.

OK - after several reboots for this and the radeonfb mystery (which
I'll reply to in a separate post) here's my conclusion:

Renaming the ibm_acpi.ko module in /lib/modules/`uname
-r`/kernel/drivers/acpi/ makes no difference, whether you prefix
or suffix the name - it still gets loaded at boot time, as
/var/log/messages and /proc/acpi/ibm/ show.  You have to actually
*move* it - presumably it just looks inside any files, regardless
of name, for module symbols?  Kernel hackers here will have known
this I guess, but I didn't expect this.  Neither prefixing the name
"disable_ibm_acpi.ko" nor suffixing it "ibm_acpi.ko.disable" makes
any difference.  You have to actually *move* or *delete* to make sure
the 0.11 one in /acpi/ gets loaded - yuck.

But the hunch was right - having moved it, at system boot, the newer
0.11 gets loaded and works fine.  So module loading order is
different at system boot than during a modprobe.  Such
unpredictability seems to be a pretty awful "feature" to me - I'd
like to know why.

Once you've moved the 0.8 right out of the modules tree (and a depmod
-ae for good measure), /etc/modprobe.conf options are respected, and
it's loaded as experimental at boot time.  I have the following in 
modprobe.conf:
options ibm_acpi hotkey=enable,0100 experimental=1

Incidentally, sorry for losing that extra "t" in your name, Matthias,
if you're reading :)

Honey