Package Details: tp_smapi-dkms 0.44-1

Git Clone URL: https://aur.archlinux.org/tp_smapi-dkms.git (read-only, click to copy)
Package Base: tp_smapi-dkms
Description: DKMS controlled modules for ThinkPad's SMAPI functionality
Upstream URL: http://www.thinkwiki.org/wiki/Tp_smapi
Licenses: GPL
Conflicts: tp_smapi
Provides: tp_smapi
Submitter: TamCore
Maintainer: barbuk
Last Packager: barbuk
Votes: 63
Popularity: 0.078844
First Submitted: 2011-08-30 13:12 (UTC)
Last Updated: 2023-08-01 06:59 (UTC)

Dependencies (1)

Required by (8)

Sources (2)

Latest Comments

1 2 3 4 Next › Last »

MartinX3 commented on 2023-07-12 08:21 (UTC)

Please create a hotfix release with commit https://github.com/linux-thinkpad/tp_smapi/commit/0c3398b1acf2a2cabd9cee91dc3fe3d35805fa8b

MartinX3 commented on 2023-07-12 07:31 (UTC)

Broken on kernel 6.4

$ cat /var/lib/dkms/tp_smapi-dkms/0.43/build/make.log
DKMS make.log for tp_smapi-dkms-0.43 for kernel 6.4.3-zen1-1-zen (x86_64)
Mi 12. Jul 09:27:52 CEST 2023
make -C /usr/lib/modules/6.4.3-zen1-1-zen/build M=/var/lib/dkms/tp_smapi-dkms/0.43/build O=/usr/lib/modules/6.4.3-zen1-1-zen/build modules
make[1]: Verzeichnis „/usr/lib/modules/6.4.3-zen1-1-zen/build“ wird betreten
  CC [M]  /var/lib/dkms/tp_smapi-dkms/0.43/build/thinkpad_ec.o
  CC [M]  /var/lib/dkms/tp_smapi-dkms/0.43/build/tp_smapi.o
  CC [M]  /var/lib/dkms/tp_smapi-dkms/0.43/build/hdaps.o
/var/lib/dkms/tp_smapi-dkms/0.43/build/thinkpad_ec.c:94:42: Fehler: Makro »DEFINE_SEMAPHORE« erfordert 2 Argumente, aber nur 1 wurden angegeben
   94 | static DEFINE_SEMAPHORE(thinkpad_ec_mutex);
      |                                          ^
In Datei, eingebunden von /var/lib/dkms/tp_smapi-dkms/0.43/build/thinkpad_ec.c:45:
./include/linux/semaphore.h:34: Anmerkung: Makro »DEFINE_SEMAPHORE« wird hier definiert
   34 | #define DEFINE_SEMAPHORE(_name, _n)     \
      | 
/var/lib/dkms/tp_smapi-dkms/0.43/build/thinkpad_ec.c:94:8: Fehler: »int« ist Standardtyp in Deklaration von »DEFINE_SEMAPHORE« [-Werror=implicit-int]
   94 | static DEFINE_SEMAPHORE(thinkpad_ec_mutex);
      |        ^~~~~~~~~~~~~~~~
/var/lib/dkms/tp_smapi-dkms/0.43/build/thinkpad_ec.c: In Funktion »thinkpad_ec_lock«:
/var/lib/dkms/tp_smapi-dkms/0.43/build/thinkpad_ec.c:112:35: Fehler: »thinkpad_ec_mutex« nicht deklariert (erstmalige Verwendung in dieser Funktion); meinten Sie »thinkpad_ec_lock«?
  112 |         ret = down_interruptible(&thinkpad_ec_mutex);
      |                                   ^~~~~~~~~~~~~~~~~
      |                                   thinkpad_ec_lock
/var/lib/dkms/tp_smapi-dkms/0.43/build/thinkpad_ec.c:112:35: Anmerkung: jeder nicht deklarierte Bezeichner wird nur einmal für jede Funktion, in der er vorkommt, gemeldet
/var/lib/dkms/tp_smapi-dkms/0.43/build/thinkpad_ec.c: In Funktion »thinkpad_ec_try_lock«:
/var/lib/dkms/tp_smapi-dkms/0.43/build/thinkpad_ec.c:126:30: Fehler: »thinkpad_ec_mutex« nicht deklariert (erstmalige Verwendung in dieser Funktion); meinten Sie »thinkpad_ec_lock«?
  126 |         return down_trylock(&thinkpad_ec_mutex);
      |                              ^~~~~~~~~~~~~~~~~
      |                              thinkpad_ec_lock
/var/lib/dkms/tp_smapi-dkms/0.43/build/thinkpad_ec.c: In Funktion »thinkpad_ec_unlock«:
/var/lib/dkms/tp_smapi-dkms/0.43/build/thinkpad_ec.c:138:13: Fehler: »thinkpad_ec_mutex« nicht deklariert (erstmalige Verwendung in dieser Funktion); meinten Sie »thinkpad_ec_lock«?
  138 |         up(&thinkpad_ec_mutex);
      |             ^~~~~~~~~~~~~~~~~
      |             thinkpad_ec_lock
/var/lib/dkms/tp_smapi-dkms/0.43/build/thinkpad_ec.c: In Funktion »thinkpad_ec_try_lock«:
/var/lib/dkms/tp_smapi-dkms/0.43/build/thinkpad_ec.c:127:1: Fehler: Kontrollfluss erreicht Ende von Nicht-void-Funktion [-Werror=return-type]
  127 | }
      | ^
/var/lib/dkms/tp_smapi-dkms/0.43/build/thinkpad_ec.c: Auf höchster Ebene:
/var/lib/dkms/tp_smapi-dkms/0.43/build/thinkpad_ec.c:94:8: Warnung: »DEFINE_SEMAPHORE« definiert, aber nicht verwendet [-Wunused-variable]
   94 | static DEFINE_SEMAPHORE(thinkpad_ec_mutex);
      |        ^~~~~~~~~~~~~~~~
cc1: Einige Warnungen werden als Fehler behandelt
make[2]: *** [scripts/Makefile.build:252: /var/lib/dkms/tp_smapi-dkms/0.43/build/thinkpad_ec.o] Fehler 1
make[2]: *** Es wird auf noch nicht beendete Prozesse gewartet …
/var/lib/dkms/tp_smapi-dkms/0.43/build/tp_smapi.c:115:36: Fehler: Makro »DEFINE_SEMAPHORE« erfordert 2 Argumente, aber nur 1 wurden angegeben
  115 | static DEFINE_SEMAPHORE(smapi_mutex);
      |                                    ^
In Datei, eingebunden von ./include/linux/fs.h:25,
                 von ./include/linux/proc_fs.h:10,
                 von /var/lib/dkms/tp_smapi-dkms/0.43/build/tp_smapi.c:41:
./include/linux/semaphore.h:34: Anmerkung: Makro »DEFINE_SEMAPHORE« wird hier definiert
   34 | #define DEFINE_SEMAPHORE(_name, _n)     \
      | 
/var/lib/dkms/tp_smapi-dkms/0.43/build/tp_smapi.c:115:8: Fehler: »int« ist Standardtyp in Deklaration von »DEFINE_SEMAPHORE« [-Werror=implicit-int]
  115 | static DEFINE_SEMAPHORE(smapi_mutex);
      |        ^~~~~~~~~~~~~~~~
/var/lib/dkms/tp_smapi-dkms/0.43/build/tp_smapi.c: In Funktion »store_battery_start_charge_thresh«:
/var/lib/dkms/tp_smapi-dkms/0.43/build/tp_smapi.c:780:15: Fehler: »smapi_mutex« nicht deklariert (erste Verwendung in dieser Funktion)
  780 |         down(&smapi_mutex);
      |               ^~~~~~~~~~~
/var/lib/dkms/tp_smapi-dkms/0.43/build/tp_smapi.c:780:15: Anmerkung: jeder nicht deklarierte Bezeichner wird nur einmal für jede Funktion, in der er vorkommt, gemeldet
/var/lib/dkms/tp_smapi-dkms/0.43/build/tp_smapi.c: In Funktion »store_battery_stop_charge_thresh«:
/var/lib/dkms/tp_smapi-dkms/0.43/build/tp_smapi.c:822:15: Fehler: »smapi_mutex« nicht deklariert (erste Verwendung in dieser Funktion)
  822 |         down(&smapi_mutex);
      |               ^~~~~~~~~~~
/var/lib/dkms/tp_smapi-dkms/0.43/build/tp_smapi.c: Auf höchster Ebene:
/var/lib/dkms/tp_smapi-dkms/0.43/build/tp_smapi.c:115:8: Warnung: »DEFINE_SEMAPHORE« definiert, aber nicht verwendet [-Wunused-variable]
  115 | static DEFINE_SEMAPHORE(smapi_mutex);
      |        ^~~~~~~~~~~~~~~~
cc1: Einige Warnungen werden als Fehler behandelt
make[2]: *** [scripts/Makefile.build:252: /var/lib/dkms/tp_smapi-dkms/0.43/build/tp_smapi.o] Fehler 1
make[1]: *** [Makefile:2024: /var/lib/dkms/tp_smapi-dkms/0.43/build] Fehler 2
make[1]: Verzeichnis „/usr/lib/modules/6.4.3-zen1-1-zen/build“ wird verlassen
make: *** [Makefile:46: modules] Fehler 2

barbuk commented on 2023-05-04 07:23 (UTC)

Hdaps is owned by the kernel package:

$ pacman -Qo /usr/lib/modules/6.2.13-arch1-1.1/kernel/drivers/platform/x86/hdaps.ko.zst
/usr/lib/modules/6.2.13-arch1-1.1/kernel/drivers/platform/x86/hdaps.ko.zst is owned by linux 6.2.13.arch1-1.1

The installation still works for the thinkpad_ec and tp_smapi modules, but dkms status now show a warning:

tp_smapi-dkms/0.43, 6.2.13-arch1-1.1, x86_64: installed (WARNING! Diff between built and installed module!)

I don't know if it's an issue with a bad dkms tree, but removing the module and rebuilding it works fine:

sudo dkms remove tp_smapi-dkms/0.43 --all
sudo dkms add tp_smapi-dkms/0.43
sudo dkms autoinstall tp_smapi-dkms/0.43 -k $(uname -r)

Atomisirsi commented on 2023-03-13 18:15 (UTC) (edited on 2023-03-13 18:15 (UTC) by Atomisirsi)

I do not remember exactly when it started, but dkms had problems installing the tp_smapi modules due to already existing hdaps.ko.zst for some weeks.

I solved this by adding the following line to the pacman.conf:

NoExtract = usr/lib/modules/*/kernel/drivers/platform/x86/hdaps.ko.zst

nosada commented on 2021-05-30 07:43 (UTC)

@ryshglene Thank you so much for your detailed explanation and patch. It seems to work collectly. I updated this package to 0.43-4 to merge your patch.

If you've been using this package for a while, you should also have a bunch of leftover "restored" hdaps.ko.xz files under /lib/modules from older kernel versions (which there shouldn't be)

I confirmed there's a bunch of leftovers... Thanks for your advice.

ryshglene commented on 2021-05-28 17:48 (UTC) (edited on 2021-05-28 18:23 (UTC) by ryshglene)

I think I've found the issue.

TLDR: tp_smapi Makefile deletes the original hdaps module. DKMS backs it up, so it should be fine, but it doesn't know how to restore it correctly. So it restores it under /lib/modules/$(uname -r)/updates. This results in leftover files under /lib/module by DKMS when removing or upgrading the package. See patch below for fix.

Edit: wrong dir in TLDR

One of the commands DKMS will run during install is make install. Because we set HDAPS=1, one of the things that command will do is remove the original module from the source tree and install its own, as we can see from the Makefile here:

install: modules
        @( [ `id -u` == 0 ] || { echo "Must be root to install modules"; exit 1; } )
        rm -f $(MOD_DIR)/$(TP_DIR)/{thinkpad_ec,tp_smapi,tp_base}.ko
        rm -f $(MOD_DIR)/drivers/firmware/{thinkpad_ec,tp_smapi,tp_base}.ko
        rm -f $(MOD_DIR)/extra/{thinkpad_ec,tp_smapi,tp_base}.ko
ifeq ($(HDAPS),1)
        rm -f $(MOD_DIR)/drivers/platform/x86/hdaps.ko
        rm -f $(MOD_DIR)/extra/hdaps.ko
endif
        $(MAKE) -C $(KBUILD) M=$(PWD) O=$(KBUILD) modules_install
        depmod $(KERNELRELEASE)

Despite removing modules from the kernel package, that's actually all well and good, because DKMS will restore it later for us, when we do dkms remove on the package.

Now, the problem arises when we run dkms remove. As I've seen from your (and my) logs, it looks like, since DKMS installs the module under /lib/modules/$(uname -r)/updates, it also thinks when it has to restore later, it can restore the original module on that same location.

We know this isn't the case, because the kernel package installs its hdaps module under /lib/modules/$(uname -r)/drivers/platform/x86, whereas this package installs its patched hdaps under /lib/modules/$(uname -r)/updates via DKMS.

This disconnect in installation and restore location, causes the issue I've described earlier. And, surprisingly, it's already been observed years ago on this Fedora bug report I've found (albeit with a different module).

The solution I've found is simple. Since we want DKMS to restore under /lib/modules/$(uname -r)/drivers/platform/x86, we also tell DKMS to install on that same location. That way, we won't have to deal with DKMS not knowing how to put things back where it got them from.

Applying this patch solves the issue for me. Please update the package if you get the same results.

diff --git a/PKGBUILD b/PKGBUILD
index ee11257..bd4d05e 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -13,7 +13,7 @@ source=("https://github.com/linux-thinkpad/tp_smapi/releases/download/tp-smapi%2
         'dkms.conf'
         'kbase.patch')
 sha256sums=('bcef9cd045d52a74d719b2a67ac4f5324994a856f123c0fbc55f1d769d367110'
-            'ad75d30622f7d40ad00daa784776bb595c2ac4736fa58f492d7f0d6948e0a832'
+            '43aa280c078fc5ba0ee229b9c71238e215313315711f3d3caae7b9bd0ab24dbe'
             '4bcce516a9f3c486a934cfe6e3d3c92443833f4094ec008ce25264d1a5b66097')

 prepare() {
diff --git a/dkms.conf b/dkms.conf
index ae2ccd4..57d3175 100644
--- a/dkms.conf
+++ b/dkms.conf
@@ -5,7 +5,7 @@ CLEAN="make clean"
 AUTOINSTALL="yes"

 BUILT_MODULE_NAME[0]="hdaps"
-DEST_MODULE_LOCATION[0]="/updates"
+DEST_MODULE_LOCATION[0]="/kernel/drivers/platform/x86"

 BUILT_MODULE_NAME[1]="thinkpad_ec"
 DEST_MODULE_LOCATION[1]="/extra"

Edit2: I'm not sure if you've noticed, but your logs clearly shows DKMS moving back files where it shouldn't be:

hdaps.ko.xz:
 - Uninstallation
   - Deleting from: /usr/lib/modules/5.12.6-hardened1-1-hardened/updates/
 - Original module
   - Archived original module found in the DKMS tree
   - Moving it to: /usr/lib/modules/5.12.6-hardened1-1-hardened/updates/

If you've been using this package for a while, you should also have a bunch of leftover "restored" hdaps.ko.xz files under /lib/modules from older kernel versions (which there shouldn't be):

$ find /lib/modules -name hdaps.ko.xz

nosada commented on 2021-05-26 15:33 (UTC)

Ah, no, I'm misunderstanding. dkms will delete module on pre-transaction hook in pacman -R...

I manually call dkms remove --no-depmod -m tp_smapi-dkms and it shows hdaps.ko.xz is restored from DKMS tree; maybe it's not provided by this package.

sudo dkms remove --no-depmod -m tp_smapi-dkms -v 0.43 -k 5.12.6-hardened1-1-hardened

-------- Uninstall Beginning --------
Module:  tp_smapi-dkms
Version: 0.43
Kernel:  5.12.6-hardened1-1-hardened (x86_64)
-------------------------------------

Status: Before uninstall, this module version was ACTIVE on this kernel.

hdaps.ko.xz:
 - Uninstallation
   - Deleting from: /usr/lib/modules/5.12.6-hardened1-1-hardened/updates/
 - Original module
   - Archived original module found in the DKMS tree
   - Moving it to: /usr/lib/modules/5.12.6-hardened1-1-hardened/updates/

thinkpad_ec.ko.xz:
 - Uninstallation
   - Deleting from: /usr/lib/modules/5.12.6-hardened1-1-hardened/extra/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.


tp_smapi.ko.xz:
 - Uninstallation
   - Deleting from: /usr/lib/modules/5.12.6-hardened1-1-hardened/extra/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.

depmod...

Removing original_module from DKMS tree for kernel 5.12.6-hardened1-1-hardened (x86_64)

DKMS: uninstall completed.

(I'm using linux-hardened 5.12.6.hardened1-1)

nosada commented on 2021-05-26 15:13 (UTC) (edited on 2021-05-26 15:13 (UTC) by nosada)

hdaps.ko.xz is by dkms, not by this package itself. So I think it may correct that hdaps.ko.xz isn't deleted when uninstalling this package.

As far as I'm concerned, the followings will be deleted on removal by pacman -R tp_smapi-dkms:

$ pacman -Ql tp_smapi-dkms
tp_smapi-dkms /usr/
tp_smapi-dkms /usr/src/
tp_smapi-dkms /usr/src/tp_smapi-dkms-0.43/
tp_smapi-dkms /usr/src/tp_smapi-dkms-0.43/Makefile
tp_smapi-dkms /usr/src/tp_smapi-dkms-0.43/dkms.conf
tp_smapi-dkms /usr/src/tp_smapi-dkms-0.43/hdaps.c
tp_smapi-dkms /usr/src/tp_smapi-dkms-0.43/thinkpad_ec.c
tp_smapi-dkms /usr/src/tp_smapi-dkms-0.43/thinkpad_ec.h
tp_smapi-dkms /usr/src/tp_smapi-dkms-0.43/tp_smapi.c

ryshglene commented on 2021-05-24 02:27 (UTC)

This package has weird behavior.

It deletes the existing hdaps.ko.xz from the kernel package, and installs its own in under /lib/modules/$(uname -r)/updates/hdaps.ko.xz.

On removal, it doesn't remove the created /lib/modules/$(uname -r)/updates/hdaps.ko.xz, which dirties the /lib/modules/ directory with some unowned files.

I'm not sure how this could be fixed yet, but I think it needs some attention. I understand that the updates directory is for overriding the included hdaps.ko.xz in the repository kernel(s), but it shouldn't be deleting files from other packages.

guillaumedsde commented on 2020-02-24 22:50 (UTC)

@nosada this seems to be the issue indeed, I am using a Thinkpad T470. Your latest change "fixed" it :)

1 2 3 4 Next › Last »