When emerging tp_smapi (0.21) and you have the useflag hdaps it generates a hdaps kernel module which is compatible with tp_smapi. It is put in extra/hdaps.ko but the original kernel modul is left in kernel/drivers/hwmon/hdaps.ko. Shouldn't that be removed? In my case the old incompatible module is the one being used. Until i manualy remove it and run depmod -a. Then it all works as expected. BTW i am using kerne 2.6.17-gentoo-r4 and hdapsd is installed with patch applied.
Version 0.21 of tp_smapi should be made stable as version 0.20 (currently the stable x86 version, 2006-08-07) doesn't support USE="hdaps" together with the 2.6.17 kernel (which is now stable for a week or so). tp_smapi-0.20 + kernel 2.6.16 = OK, also with hdaps tp_smapi-0.20 (USE="hdaps") + kernel 2.6.17 = compilation of hdaps failes tp_smapi-0.20 (USE="-hdaps") + kernel 2.6.17 = OK, but hdaps doesn't work tp_smapi-0.21 + kernel 2.6.17 = OK, with hdaps working (with manual workaround) And: bug with hdaps confirmed.
Could you post the output of these commands please? uberlaptop tp_smapi # rmmod hdaps uberlaptop tp_smapi # modprobe hdaps uberlaptop tp_smapi # rm /lib/modules/`uname -r`/extra/hdaps.ko uberlaptop tp_smapi # rmmod hdaps uberlaptop tp_smapi # modprobe hdaps FATAL: Could not open '/lib/modules/2.6.17-gentoo-r4/extra/hdaps.ko': No such file or directory uberlaptop tp_smapi # ls /lib/modules/`uname -r`/kernel/drivers/hwmon hdaps.ko As you can see I have the kernel module installed too and it loads the correct version. CC'ing kernel team if they have any ideas on how to prefer a module
UPDATE: 1.) I can confirm that there are two versions of hdaps in the modules directory tree, one from the kernel, one from the tp_smapi ebuild. 2.) I have to revert my previous statement: although there are two versions of hdaps the correct version (the one from tp_smapi) is used on my system. Greetings, Andreas.
Marking this one invalid as the origonal report is.
*** Bug 158706 has been marked as a duplicate of this bug. ***
Guys, I have exact the same problem with kernels 2.6.18 and 2.6.19 and app-laptop/tp_smapi-0.30. Here is output as you requested (I have copied hdaps.ko from /extra to /hwmon): ant extra # rmmod hdaps ant extra # rm /lib/modules/`uname -r`/extra/hdaps.ko ant extra # modprobe hdaps ant extra # tail -f /var/log/messages Dec 21 16:56:21 ant hdaps: driver unloaded. Dec 21 16:57:02 ant hdaps: initial mode latch is 0x01 Dec 21 16:57:02 ant hdaps: setting ec_rate=250, filter_order=2 Dec 21 16:57:02 ant hdaps: fake_data_mode set to 0 Dec 21 16:57:02 ant hdaps: device successfully initialized. Dec 21 16:57:02 ant input: hdaps as /class/input/input5 Dec 21 16:57:02 ant hdaps: driver successfully loaded. Could you reopen the bug and double check?.. Cheers.
Here is a fix after fresh install: cd /usr/src/linux make modules_install emerge tp_smapi ant linux # ant linux # modprobe hdaps FATAL: Error inserting hdaps (/lib/modules/2.6.19-gentoo-r2/kernel/drivers/hwmon/hdaps.ko): No such device or address ant linux # ls -al /lib/modules/2.6.19-gentoo-r2/extra/hdaps.ko -rw-r--r-- 1 root root 14192 2006-12-21 17:05 /lib/modules/2.6.19-gentoo-r2/extra/hdaps.ko ant linux # ls -al /lib/modules/2.6.19-gentoo-r2/kernel/drivers/hwmon/hdaps.ko -rw-r--r-- 1 root root 12322 2006-12-21 17:04 /lib/modules/2.6.19-gentoo-r2/kernel/drivers/hwmon/hdaps.ko ant linux # cp /lib/modules/2.6.19-gentoo-r2/extra/hdaps.ko /lib/modules/2.6.19-gentoo-r2/kernel/drivers/hwmon/ ant linux # modprobe hdaps ant linux # tail -f /var/log/messages Dec 21 17:04:42 ant hdaps: setting ec_rate=0, filter_order=1 Dec 21 17:04:42 ant hdaps: driver unloaded. Dec 21 17:05:42 ant hdaps: IBM ThinkPad T42 detected. Dec 21 17:05:42 ant hdaps: driver init failed (ret=-6)! Dec 21 17:09:05 ant hdaps: initial mode latch is 0x01 Dec 21 17:09:05 ant hdaps: setting ec_rate=250, filter_order=2 Dec 21 17:09:05 ant hdaps: fake_data_mode set to 0 Dec 21 17:09:05 ant hdaps: device successfully initialized. Dec 21 17:09:05 ant input: hdaps as /class/input/input6 Dec 21 17:09:05 ant hdaps: driver successfully loaded.
With all modules unloaded, you should modprobe tp_smapi. That should load the correct hdaps module.
No, it doesn't. Just tried: ant linux # lsmod Module Size Used by radeon 108192 2 drm 62356 3 radeon michael_mic 2432 4 arc4 1920 4 ecb 2944 4 ieee80211_crypt_tkip 9856 2 aes 27968 1 ieee80211_crypt_ccmp 6272 1 snd_seq_oss 26752 0 snd_seq_midi_event 5760 1 snd_seq_oss snd_seq 40784 4 snd_seq_oss,snd_seq_midi_event snd_seq_device 6156 2 snd_seq_oss,snd_seq ibm_acpi 24320 0 ipw2200 121392 0 ieee80211 26184 1 ipw2200 ieee80211_crypt 4352 3 ieee80211_crypt_tkip,ieee80211_crypt_ccmp,ieee80211 firmware_class 7168 1 ipw2200 ehci_hcd 23048 0 uhci_hcd 18056 0 i2c_i801 6668 0 intel_agp 20764 1 agpgart 24112 2 drm,intel_agp evdev 7424 1 ant linux # modprobe tp_smapi ant linux # lsmod | grep hdaps ant linux # lsmod Module Size Used by tp_smapi 19856 0 thinkpad_ec 5648 1 tp_smapi radeon 108192 2 drm 62356 3 radeon michael_mic 2432 4 arc4 1920 4 ecb 2944 4 ieee80211_crypt_tkip 9856 2 aes 27968 1 ieee80211_crypt_ccmp 6272 1 snd_seq_oss 26752 0 snd_seq_midi_event 5760 1 snd_seq_oss snd_seq 40784 4 snd_seq_oss,snd_seq_midi_event snd_seq_device 6156 2 snd_seq_oss,snd_seq ibm_acpi 24320 0 ipw2200 121392 0 ieee80211 26184 1 ipw2200 ieee80211_crypt 4352 3 ieee80211_crypt_tkip,ieee80211_crypt_ccmp,ieee80211 firmware_class 7168 1 ipw2200 ehci_hcd 23048 0 uhci_hcd 18056 0 i2c_i801 6668 0 intel_agp 20764 1 agpgart 24112 2 drm,intel_agp evdev 7424 1 ant linux # modprobe hdaps FATAL: Error inserting hdaps (/lib/modules/2.6.19-gentoo-r2/kernel/drivers/hwmon/hdaps.ko): No such device or address ant linux # tail -f /var/log/messages Dec 21 17:43:42 ant hdaps: setting ec_rate=0, filter_order=1 Dec 21 17:43:42 ant hdaps: driver unloaded. Dec 21 17:43:44 ant tp_smapi unloaded. Dec 21 17:44:02 ant thinkpad_ec: unloaded. Dec 21 17:44:06 ant fuse exit Dec 21 17:45:08 ant thinkpad_ec: thinkpad_ec 0.30 loaded. Dec 21 17:45:08 ant tp_smapi 0.30 loading... Dec 21 17:45:08 ant tp_smapi successfully loaded (smapi_port=0xb2). Dec 21 17:45:47 ant hdaps: IBM ThinkPad T42 detected. Dec 21 17:45:47 ant hdaps: driver init failed (ret=-6)! Any ideas what i'm doing wrong?
Ok, how about running modules-update - does that help?
Nop, still the same problem: ant linux # lsmod Module Size Used by radeon 108192 2 drm 62356 3 radeon michael_mic 2432 4 arc4 1920 4 ecb 2944 4 ieee80211_crypt_tkip 9856 2 aes 27968 1 ieee80211_crypt_ccmp 6272 1 snd_seq_oss 26752 0 snd_seq_midi_event 5760 1 snd_seq_oss snd_seq 40784 4 snd_seq_oss,snd_seq_midi_event snd_seq_device 6156 2 snd_seq_oss,snd_seq ibm_acpi 24320 0 ipw2200 121392 0 ieee80211 26184 1 ipw2200 ieee80211_crypt 4352 3 ieee80211_crypt_tkip,ieee80211_crypt_ccmp,ieee80211 firmware_class 7168 1 ipw2200 ehci_hcd 23048 0 uhci_hcd 18056 0 i2c_i801 6668 0 intel_agp 20764 1 agpgart 24112 2 drm,intel_agp evdev 7424 1 ant linux # modprobe tp_smapi ant linux # lsmod | grep hdaps ant linux # modprobe hdaps FATAL: Error inserting hdaps (/lib/modules/2.6.19-gentoo-r2/kernel/drivers/hwmon/hdaps.ko): No such device or address ant linux #
ok, so I mentioned on IRC, it seems modprobe.c takes the list from modules.dep and uses the first matched path. In my case it was ant 2.6.19-gentoo-r2 # grep hdaps modules.dep /lib/modules/2.6.19-gentoo-r2/kernel/drivers/hwmon/hdaps.ko: /lib/modules/2.6.19-gentoo-r2/extra/hdaps.ko: /lib/modules/2.6.19-gentoo-r2/extra/thinkpad_ec.ko So I swapped the lines and modprobe found the right driver. Or another way is to add one more dependence to tp_smapi: - /lib/modules/2.6.19-gentoo-r2/extra/tp_smapi.ko: /lib/modules/2.6.19-gentoo-r2/extra/thinkpad_ec.ko + /lib/modules/2.6.19-gentoo-r2/extra/tp_smapi.ko: /lib/modules/2.6.19-gentoo-r2/extra/hdaps.ko /lib/modules/2.6.19-gentoo-r2/extra/thinkpad_ec.ko In that order. In this case 'modprobe tp_smapi' will load thinkpad_ec and hdaps from the right place.
*** Bug 159349 has been marked as a duplicate of this bug. ***
I don't know anything about this particular thing, but why not just check and bail out if the user is already using the in-kernel one?
(In reply to comment #14) > I don't know anything about this particular thing, but why not just check and > bail out if the user is already using the in-kernel one? Because the hdapsd ebuild requires the module or in-kernel option. The hdaps USE flag in question here is 100% optional and only causes this issue when used.
(In reply to comment #15) > Because the hdapsd ebuild requires the module or in-kernel option. The hdaps > USE flag in question here is 100% optional and only causes this issue when > used. What about patching hdapsd ebuild to accept tp_smapi built with USE=hdaps? Some users need the one from tp_smapi for two reasons: a) hdaps from kernel is incompatible with tp_smapi as in "we can't use both of them at the same time" b) hdaps from kernel doesn't support all laptops that tp_smapi supports
(In reply to comment #12) > ok, so I mentioned on IRC, it seems modprobe.c takes the list from modules.dep > and uses the first matched path. In my case it was > > ant 2.6.19-gentoo-r2 # grep hdaps modules.dep > /lib/modules/2.6.19-gentoo-r2/kernel/drivers/hwmon/hdaps.ko: > /lib/modules/2.6.19-gentoo-r2/extra/hdaps.ko: > /lib/modules/2.6.19-gentoo-r2/extra/thinkpad_ec.ko Weird, as e comes before k. What are your locale / LC_ settings?
Created attachment 105544 [details] new hdapsd init script OK, depmod has no actual module ordering apparently, so it's pure luck which comes first. In a sane world, this should not matter as kernel stuff expects only one module, which makes sense. To get around this, the hdapsd init script now tries to load the hdaps module in the extra dir first. If we don't have that, then we just modprobe and hope as we do now. If anyone is not satisfied by this, let me know otherwise I'll whack this init script into portage next week to solve this bug.
(In reply to comment #18) > OK, depmod has no actual module ordering apparently, so it's pure luck which > comes first. In a sane world, this should not matter as kernel stuff expects > only one module, which makes sense. Why not make it happy and bail out if the current kernel has the hdaps module and we're building with USE="hdaps" OR when such a module is available? (Simple `modprobe -l` won't be enough as we might be running under different kernel than the one we're building for. And I'm not sure if the module .ko file actually disappears from /lib/modules/... after being disabled and kernel being rebuilt...) > To get around this, the hdapsd init script now tries to load the hdaps module > in the extra dir first. If we don't have that, then we just modprobe and hope > as we do now. I'm not a kernel hacker but it seems logical to me that we shouldn't randomly use both insmod and modprobe. It's also extremely confusing as stuff like modules.autoload.d won't work.
I agree with #19. That's confusing with modules.autoload.d and it won't work from a command line either. Woudn't it be better to patch kernel's hdaps and ask to recompile it then user do 'USE="hdaps" emerge tp_smapi'?
Why not 'just' delete the kernel/drivers/hwmon/hdaps.ko after successfully copying extra/hdaps.ko and then run modules-update to get a correct modules.dep? That's the easy workaround and exactly what I'm now doing by hand to get around this annoying situation. BTW, I think that tp_smapi refuses to compile with USE="hdaps" when hdaps is disabled in the kernel... but I'm not sure of this. Ciao, Andreas.
Just playing with hdaps on tp X60 today and I solved this by removing hdaps module from kernel. app-laptop/tp_smapi-0.32 with hdaps USE emerged just fine and everything works as it should. # uname -a Linux sanaz 2.6.22-gentoo-r8 #5 SMP Fri Nov 16 22:23:54 CET 2007 x86_64 Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz GenuineIntel GNU/Linux
in my opinion tp_smapi ebuild should check if there is hardcoded or module for hdaps in built kernel tree and if yes get error to remove it from kernel and rebuild it. than should install its own hdaps.ko module til kernel one will be compatible with tp_smapi.
That's likely what I shall do - I am working on rewriting the ebuilds at the moment - if anyone has anything else to add, comment on this bug. I'm also thinking of adding a kernel with the necessary HDAPS patches - would you all prefer this to be gentoo-sources with the HDAPS patches or the tuxonice (suspend2) kernel with the HDAPS patches?
I must be retarded, but why on earth don't we just remove the USE flag that conflicts w/ kernel and duplicated built-in kernel stuff?
The in-kernel one is a POS
(In reply to comment #26) > The in-kernel one is a POS Well, then make this thing die when the in-kernel POS is enabled, or get merged this lesser POS into kernel?
please don't add a new kernel to portage without speaking to me first
@dsd: Don't think you'd like what I want to add so was thinking more of adding it to my developer overlay. (In fact, I already have a couple of kernels in there, I think).
I understand it's a good thing to fix the root of the problem, but just to let you all know: the problem seems has disappeared for me with the latest stable kernel tuxonice-sources-2.6.23-r6 (I'm also using app-laptop/tp_smapi-0.32). I'm not sure which module is loaded, but it doesn't fail anymore. Here is the log: Jan 3 07:16:51 ant hdaps: initial mode latch is 0x01 Jan 3 07:16:51 ant hdaps: setting ec_rate=250, filter_order=2 Jan 3 07:16:51 ant hdaps: fake_data_mode set to 0 Jan 3 07:16:51 ant hdaps: device successfully initialized. Jan 3 07:16:51 ant input: ThinkPad HDAPS joystick emulation as /devices/platform/hdaps/input/input24 Jan 3 07:16:51 ant input: ThinkPad HDAPS accelerometer data as /devices/platform/hdaps/input/input25 Jan 3 07:16:51 ant hdaps: driver successfully loaded.
I still have this problem with tuxonice-sources-2.6.23-r10; after each modules_install I need to remove the old module manually and run depmod -a.
Created attachment 146782 [details, diff] tp_smapi-0.33.ebuild.patch This patch changes tp_smapi's behaviour so that it refuses to build if USE=hdaps and there already is a module with that name. Perhaps you could add a note to ERROR_SENSORS_HDAPS asking users to remove the module .ko from filesystem...
*** Bug 214166 has been marked as a duplicate of this bug. ***
Created attachment 146792 [details, diff] hdapsd-20060409-r1.ebuild.patch Jakub apparently prefers to deal with two packages in one bug, ok. The hdapsd package doesn't care what provides the module, it just needs it. For some users, the one from tp_smapi works better (and in fact you can't use in-kernel hdapsd and any module from tp_smapi together).
(In reply to comment #34) > Jakub apparently prefers to deal with two packages in one bug, ok. No, I prefer to get either in-kernel or external module built, *not* both. Since it absolutely doesn't make any sense. The current ebuild should die when in-kernel support is detected, until then changing anything else is plain pointless.
I agree with Jan, these two patches should fix the problem. Peter, please review it.
So this is the little secret of this confusion - the original hdaps module needs to be disabled, while the ThinkWiki manual stated that it has to be enabled... OK, this works for me, so I changed the article. http://www.thinkwiki.org/wiki/Tp_smapi#Installation_in_Gentoo
Applied Jan's patches. Closing.
Peter, you submitted the tp_smapi patch with a typo. Please re-apply the original patch or here is the correction: --- tp_smapi-0.37.ebuild?rev=1.1 2008-03-31 07:22:12.000000000 +0800 +++ tp_smapi-0.37.ebuild 2008-03-31 07:38:59.000000000 +0800 @@ -40,7 +40,7 @@ CONFIG_CHECK="!SENSORS_HDAPS" ERROR_SENSORS_HDAPS="${P} with USE=hdaps conflicts with in-kernel HDAPS (CONFIG_SENSORS_HDAPS)" - linux_info-pkg-setup + linux-info_pkg_setup fi } Troels, please re-open the bug.
(In reply to comment #39) > you submitted the tp_smapi patch with a typo Nope, the tp_smapi ebuild which is in ithe tree is correct.
Just for the records, it has been fixed: http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-laptop/tp_smapi/tp_smapi-0.37.ebuild?r1=text&tr1=1.1&r2=text&tr2=1.2&diff_format=h Mon Mar 31 08:34:42 2008 UTC (2 days, 14 hours ago) by welp s/linux_info-pkg-setup/linux-info_pkg_setup/ (Portage version: 2.1.4.4) Sorry for the spam.
