[ltp] ibm_acpi and modprobe.conf

[FeRD]

honey@gneek.com wrote:

> Thanks for the reply, FeRD:
>
Hope I've been some help so far. I should be thanking you, actually -- I 
remember hitting this one myself, and I meant to post to the list about 
it, but it was one of those "out of sight, out of mind" issues where I 
worked around the problem and promptly forgot to follow up on it, so 
your post served as a perfect chance to revisit the problem. Fortunately 
there are people out there with more community spirit than myself. :)

>> 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.

Careful there -- are you sure about the "ignores settings" thing being 
true? If so, that would be weird, as all the other boot-loaded modules 
respect modprobe.conf. 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", so it could be 
possible that the old version of the module is being loaded, WITH the 
modprobe.conf flags, but the experimental sections are missing because 
they're not implemented.

> [...]  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 load it at bootup, it's autodetected. In the same way I don't 
load the ide, yenta, or serio drivers. Just hardware autodetection Doing 
The Right Thing(tm), in my mind. *shrug* More black magic, but certainly 
black magic with precedent. Like I said, there are plenty of hardware 
drivers I don't load by hand. (Like... all of them.)

>> 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.


I'd be VERY interested in the results of that test, because it would 
confirm that I'm right about the problem here being that the old version 
is still in place, and that rm'ing the old version does "solve" (*cough* 
for lazy versions of solve) the problem.

If you are indeed getting the old version loaded, the question comes 
back to WHY. If I were to speculate, I'd guess that perhaps ibm_acpi.ko 
itself isn't in the initrd, but perhaps a modules.dep _IS_ that the 
system is using for boot-time module loading. That would explain why 
only boot-time operation got hold of the wrong version. Worth checking? 
*shrug* I consider the point sort of moot anyway. (See below.)

Going back to the deletion issue -- hey, I agree with you, I don't like 
it either. But I also don't like having two versions of the module 
installed, especially since there's NO justifiable reason for that. 
(Meaning, it's NEVER the situation you WANT to arrive at.) It's not like 
you can EVER use both at once. That's why the kernel doesn't even really 
seem to HAVE a strong and universal concept of module "versioning". (I 
think that's part of the problem here, and why it's so hard to do things 
like check "whch version" of a module is loaded. Plenty of modules don't 
even DISPLAY a version via modinfo.) I don't even like having two 
versions of a shared library installed unless I have to, and there ARE 
situations where that's desirable/necessary. With kernel modules, it's 
ALWAYS got to be one or the other, in reality, so I'm especially 
reticent about the whole two-versions thing.

(WOW, I USED a lot of CAPITALS in THAT PARAGRAPH. Yow!)

Here's how I look at the options here:

1. The "right solution" to this is probably to roll your own kernel RPM 
including ibm_acpi version 0.11. That seems like overkill, and a 
nightmare to have to maintain. But if you wanna be a purist, the Don 
Quixote Institute for Purism recommends this solution vehemently and 
unwaveringly. :)

2. You could get ibm_acpi 0.11 into the official Fedora Core kernel RPM 
builds. This is of course the ultimate goal, but isn't so much solving 
the problem as avoiding it. The question isn't what to do UNTIL that 
happens.

3. In a section of your original message I cut out, you mentioned you're 
rolling your own initrd for swsusp2. So am I, but automagically using 
Matthias Hensler's <a href="http://mhensler.de/swsusp/">Fedora Core 3/4 
Swsusp2 RPMs</a> and the corresponding mkinitrd. I mention this in part 
to say a long-overdue public THANK YOU to cubbi for his work maintaining 
this "nightmare" (see above) ;) and also to propose we ask that he start 
rolling version 0.11 of ibm_acpi into his releases. That's likely  a 
quicker process than getting the official releases up to date, and there 
is some precedent there: Matthias' RPMs include the ntfs module, which 
isn't part of the FC4 official builds. (That's also been a lifesaver, 
since having NTFS disappear every time I did a kernel upgrade, until 
Axel Thimm got a new module RPM out the door AND I remembered to install 
it, was a pain in the ass. Points out more of the muddy problems 
underlying the whole module/kernel version-management issue, too.) ...Of 
course, that's if you use cubbi's RPMs. Or, if you decide to start! ;)

4. You can write long-winded, pointlessly expository emails about the 
problem flinging out lots of armchair theories and pointless ideas on 
the problem without contributing much to the actual SOLUTION. But then 
you'd be doing MY job, and what the hell would I do??? :)

>> '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?

Well, for the case at hand, my 0.11 version of ibm_acpi spits out its 
version number into the kernel output when it's loaded, so it's 
accessible via dmesg, and also displays the version number in 
/proc/acpi/ibm/driver. No visibility into the options passed in at load, 
it seems. You'd EXPECT that the options would be displayed in 
/sys/module/ibm_acpi/parameters/, but surprisingly that path doesn't 
exist on my current system with 0.11 loaded WITH the experimental=1 
flag, so apparently /sys/module/foo/parameters has to be implemented by 
the module? That seems really odd to me, but evidence points in that 
direction...

Actually, it may be that version 0.11 is somewhat screwy in how it 
implements some of its modprobe/info/etc. hooks, since modinfo ouput for 
my build of ibm_acpi 0.11 is:

filename:       /lib/modules/2.6.12-1.1390_FC4_cubbi4_swsusp2/acpi/ibm_acpi.ko

author:         Borislav Deianov

description:    IBM ThinkPad ACPI Extras

version:        0.11

license:        GPL

parmtype:       experimental:int

vermagic:       2.6.12-1.1390_FC4_cubbi4_swsusp2 686 REGPARM 4KSTACKS gcc-4.0

depends:

srcversion:     55F6D8E7A8690697515E228


You'll notice there's a parmtype entry for experimental, but no 
corresponding parm entry. And hotkeys isn't represented at all. That may 
explain why /sys/module/ibm_acpi/parameters isn't being created. (Hmmm. 
Could this have some effect on what parameters are allowed to be passed 
to the module when it's boot-loaded? ...Pure crackpot-theory there, as 
an alternative to my wrong-version-being-loaded crackpot-theory. I wish 
it wasn't such a pain to test most of these, or I'd be less lazy about 
it. But rebooting means killing off amule, and I just finally got into 
the double-digit queue ranks on a lot of files! ;) )

This all also means (going back to the first crackpot-theory) that if 
version 0.8 didn't publish the version number, you'll have to look for 
the ABSENCE of the "version 0.11" output to determine that 0.8 is 
loaded, which is much more annoying than actually being able to look for 
something that identifies the driver as version 0.8.

I'd be tempted to bitch about the imperfections/incompleteness in all of 
this, if I wasn't WELL aware how much better we have it than users of 
any other OS, when it comes to things like driver management. None of 
the systems are perfect, but at least the light is brightest at the end 
of OUR tunnel. :)

-FeRD