[gelöst?] phc-intel Bullseye: dkms-Build schlägt fehl

[hikaru]

Hallo,

ich betreibe noch ein altes Core2Duo-Notebook, auf dem ich die CPU zwecks Temperatur- und damit Lüfterreduzierung undervolte. Dazu nutze ich ein komatöses bis totes Projekt namens "phc-intel" [1], welches ein per dkms gebautes Kernelmodul bereitstellt.
Die laut [2] wohl aktuellste Version ist auf github zu finden [3] und wurde zuletzt 2020 für Kernel 5.7 angepasst. Offenbar hat sich seitdem eine Typdefinition in den Kernel-Headers geändert, denn beim Versuch, das dkms-Paket auf Bullseye mit Kernel 5.10 zu bauen bekomme ich diese Meldung:

Code: Alles auswählen

/var/lib/dkms/phc-intel/0.3.2/build/phc-intel.c:906:32: error: assignment to ‘int (*)(struct cpufreq_policy *, int)’ from incompatible pointer type ‘int (*)(int)’ [-Werror=incompatible-pointer-types]

vollständiges Log: 41450

Leider sind meine C-Kenntnisse inzwischen als nicht-existent zu bezeichnen. Kann mir jemand auf die Sprünge helfen, wie das zu fixen wäre?


[1] viewtopic.php?f=33&t=154693
[2] https://www.reddit.com/r/archlinux/comm ... ervolting/
[3] https://github.com/danielw86dev/phc-intel-dkms

[MSfree]

Code: Alles auswählen

/var/lib/dkms/phc-intel/0.3.2/build/phc-intel.c:906:32: error: assignment to ‘int (*)(struct cpufreq_policy *, int)’ from incompatible pointer type ‘int (*)(int)’ [-Werror=incompatible-pointer-types]

int (*) (struct cpufreq_policy *, int)
ist ein Zeiger auf eine Funktion, die int zurückliefert und zwei Parameter, nämlich einen Zeiger auf struct cpufreq_policy und ein int erwartet.

int (*) (int)
ist ein Zeiger auf eine Funktion, die int zurückliefert und nur einen Parameter, ein int erwartet.

Die beiden Funktionen unterscheiden sich also in der Parameterliste und sind nicht einfach austauschbar. Die Anpassung liegt also darin, die Funktion entsprechend anzupassen. Ich kenne mich aber im Kernel nicht aus, kann dir also nicht sagen, was diese struct cpufreq_policy beinhaltet und wie man die auffüllen muß, bevor man das entsprechend aufruft.

[hikaru]

Die beiden Funktionen unterscheiden sich also in der Parameterliste und sind nicht einfach austauschbar. Die Anpassung liegt also darin, die Funktion entsprechend anzupassen. Ich kenne mich aber im Kernel nicht aus, kann dir also nicht sagen, was diese struct cpufreq_policy beinhaltet und wie man die auffüllen muß, bevor man das entsprechend aufruft.

Vielen Dank für die ausführliche Wiedergabe meines Kenntnisstandes!

[JTH]

Du könntest das mal ganz naiv ausprobieren: Den neuen Parameter ergänzen, aber einfach ignorieren:

Code: Alles auswählen

diff -ruN phc-intel-pack-rev32/inc/5.7/acpi-cpufreq.c phc-intel-pack-rev32-patched/inc/5.7/acpi-cpufreq.c
--- phc-intel-pack-rev32/inc/5.7/acpi-cpufreq.c	2020-06-17 18:44:45.000000000 +0200
+++ phc-intel-pack-rev32-patched/inc/5.7/acpi-cpufreq.c	2021-08-22 16:22:21.014485657 +0200
@@ -126,7 +126,7 @@
 	boost_set_msr(enable);
 }
 
-static int set_boost(int val)
+static int set_boost(struct cpufreq_policy *policy, int val)
 {
 	get_online_cpus();
 	on_each_cpu(boost_set_msr_each, (void *)(long)val, 1);
@@ -162,7 +162,7 @@
 	if (ret || val > 1)
 		return -EINVAL;
 
-	set_boost(val);
+	set_boost(NULL, val);
 
 	return count;
 }

Ist nicht getestet, näher drin stecken tu ich da auch nicht. Mit ein bisschen Glück und Daumen drücken klappt das aber gerne mal.

Ich hab das Makefile beim Überfliegen so verstanden, dass es die neuest möglichen zum laufenden Kernel passenden Quellen nimmt, wenn keine exakt passenden vorhanden sind. Deshalb ein Patch in inc/5.7.

[hikaru]

Danke, das hat funktioniert!
Das Modul ließ sich bauen und laden und es funktioniert offenbar. Die Leistungsaufnahme des Notebooks unter synthetischer Last sinkt nach Setzen der Spannungswerte reproduzierbar von 123 auf 107W.

Das Fragezeichen im [gelöst?] lasse ich mal stehen, bis jemand bestätigt, dass das die saubere Lösung ist.

[MSfree]

Das Fragezeichen im [gelöst?] lasse ich mal stehen, bis jemand bestätigt, dass das die saubere Lösung ist.

Das sinnvollste dürfte sein, den Fix dem Entwickler über github vorzuschlagen.

[hikaru]

Das sinnvollste dürfte sein, den Fix dem Entwickler über github vorzuschlagen.

"Der Entwickler" ist ein User auf github.com, der seit über einem Jahr nicht mehr aktiv war und sich nur registriert hat um das drei Jahre alte Projekt eines anderen Users zu forken, welcher seinerzeit das Gleiche mit dem Originalcode von der Originalseite gemacht hat, die schon damals im Maintenance-Mode war und zwischendurch ganz weg war.

Ich schrieb ja, dass das Projekt komatös bis tot ist. Nun könnte ich meinerseits ein github-Projekt aufmachen, aber angesichts dessen, dass ich eindeutig nicht die Fähigkeiten habe den Code zu warten, würde ich nur eine weitere Iteration auf diese Zombie-Forkerei aufsetzen.

[JTH]

Ich hab nochmal eine zweiten Blick drauf geworfen: Die acpi-cpufreq.c in den inc/*.*-Ordnern sind anscheinend die ungepatchten Originale aus den Kernelquellen. Eigentlich relevant sind nur die ganzen Patche. Es wär also Quatsch, obige Anpassungen an irgendwen weiterzuleiten.

Wenn du also noch „sauberer“ für den 5.10er Kernel adaptieren willst:

Code: Alles auswählen

phc-intel-pack-rev32$ cp -r inc/5.7 inc/5.10
phc-intel-pack-rev32$ wget -O inc/5.10/acpi-cpufreq.c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/drivers/cpufreq/acpi-cpufreq.c?h=v5.10

Damit baut zumindest anschließend mit einem nackten make erfolgreich das .ko.

Das make dkms_install scheitert bei mir daran, sich den richtigen überhaupt einen Pfad in inc/ rauszusuchen – hast du daran bei dir etwas modifiziert, hikaru?

[hikaru]

Ich hab nochmal eine zweiten Blick drauf geworfen:

Danke!

Das make dkms_install scheitert bei mir daran, sich den richtigen überhaupt einen Pfad in inc/ rauszusuchen – hast du daran bei dir etwas modifiziert, hikaru?

Nein, ich habe abgesehen von dem was du explizit gepostet hast nichts geändert.
Das hier ist frisch aus einer Bullseye-VM: 41451

Wie sieht denn deine Fehlermeldung konkret aus?

[JTH]

Ah ja, das make dkms_mkdeb läuft hier in VM auch durch und das .deb lässt sich installieren. Ich hatte vorhin make dkms_install als Probe genommen, was das Ganze am Paketmanagement vorbei zu DKMS hinzufügt. Das scheiterte nach wenigen Zeilen mit:

Code: Alles auswählen

searching for patch directory... using ./inc/
copying files
cp: cannot stat './inc//acpi-cpufreq.c': No such file or directory

Das Makefile scheiterte dran, die passende Kernelversion rauszufinden, eine Variable blieb leer. Aber egal, ich wills ja nicht weiter benutzen. Gut, wenns bei dir funktioniert