tp_smapi und akmod

E

endur

New member
Themenstarter
Registriert
20 Aug. 2008
Beiträge
26
Hallo,

am Wochenende habe ich ein akmod rpm für tp_smapi unter Fedora 14 erstellt. Das akmod rpm enthält einen Patch, welcher sicherstellt, dass tp_smapi auch gegen kernel 2.6.37 (zur Zeit in Rawhide) kompiliert.

Beide Pakete, auch das source rpm sowie das specfile sind in meinem Repo zu finden (nur für Fedora 14).
http://www.bennewitz.com/rpms/

Alternativ auch hier zum händischen Download:
http://endur.fedorapeople.org/downloads/

akmod-tp_smapi und
tp_smapi werden benötigt.

--
Endur
 
Code: 
Package: akmod-tp_smapi-0.40-3.fc14.x86_64 (/akmod-tp_smapi-0.40-3.fc14.x86_64)
           Requires: tp_smapi-kmod-common >= 0.40

sollte das Paket nicht auch gebaut werden?

Code: 
Wrote: /home/buddabrod/rpmbuild/RPMS/x86_64/akmod-tp_smapi-0.40-3.fc14.x86_64.rpm
Wrote: /home/buddabrod/rpmbuild/RPMS/x86_64/kmod-tp_smapi-0.40-3.fc14.x86_64.rpm
Wrote: /home/buddabrod/rpmbuild/RPMS/x86_64/kmod-tp_smapi-2.6.35.10-74.fc14.x86_64-0.40-3.fc14.x86_64.rpm
Wrote: /home/buddabrod/rpmbuild/RPMS/x86_64/tp_smapi-kmod-debuginfo-0.40-3.fc14.x86_64.rpm

bzw. was sollte der Inhalt sein?

Übrigens baut es nicht gegen den aktiven kernel, das ist nämlich 2.6.37. Ich schau auch gleich mal rein.
 
buddabrod' schrieb:
Package: akmod-tp_smapi-0.40-3.fc14.x86_64 (/akmod-tp_smapi-0.40-3.fc14.x86_64) Requires: tp_smapi-kmod-common >= 0.40
Zum Vergrößern anklicken....
Du brauchst nur akmod-tp_smapi-0.40-3.fc14.i686.rpm (bzw. Deinen x86_64 rebuild) und das noarch tp_smapi-0.40-1.fc14.noarch.rpm, dies stellt tp_smapi-kmod-common bereit (mit Readme ChangeLog usw)
 
buddabrod' schrieb:
Übrigens baut es nicht gegen den aktiven kernel, das ist nämlich 2.6.37. Ich schau auch gleich mal rein.
Zum Vergrößern anklicken....

updates = 2.6.35.10-74.fc14.
Rawhide = koji = 2.6.37-2.fc15
Für letzteren Kernel ist der hinzugefügte Patch.

--
Endur
 
Habe den -1 von koji. Es wird aber automatisch gegen den letzten fc14 kernel gebaut, auch akmod berücksichtigt nicht den aktiven 2.6.37er kernel von koji.

Liegt das daran, dass der "für" fc15 gebaut wurde?

Edit: das "baut nicht" heißt nicht, dass das Paket nicht kompiliert, sondern dass kein Modul für den aktuellen kernel gebaut wird. 2.6.37-1.fc15.x86_64
 
buddabrod' schrieb:
Habe den -1 von koji. Es wird aber automatisch gegen den letzten fc14 kernel gebaut, auch akmod berücksichtigt nicht den aktiven 2.6.37er kernel von koji.

Liegt das daran, dass der "für" fc15 gebaut wurde?
Zum Vergrößern anklicken....
Nein. Es müssen kernel-headers-2.6.37-2.fc15 und kernel-devel-2.6.37-2.fc15 (bzw -1) installiert sein.
 
Ist schon längst installiert, das brauche ich auch für andere Module

nur ein ausdrückliches
Code: 
rpmbuild -bb SPECS/tp_smapi-kmod.spec --define "kernels $(uname -r)" --target $(uname -m)
Baut das gebrauchte Modul ohne Probleme.
 
Ich revidiere: die Module werden gebaut von akmod und sind auch am richtigen Ort.

Was fehlt, ist ein depmod -a, sonst werden die Module nicht gefunden..
 
buddabrod' schrieb:
Was fehlt, ist ein depmod -a, sonst werden die Module nicht gefunden..
Zum Vergrößern anklicken....
Gut, depmod -a wird mit jedem boot ausgeführt, ich schaue mal, ob es sinnvoll oder üblich ist, es inmerhalb %post auszuführen...
 
Bei mir wird es scheinbar nicht ausgeführt. Zumindest nicht, wenn man es braucht :D
 
buddabrod' schrieb:
Bei mir wird es scheinbar nicht ausgeführt. Zumindest nicht, wenn man es braucht
Zum Vergrößern anklicken....
Habe keine Idea, woran das liegt... depmod -a müsste beim automatischen Installieren des durch akmod (was das source rpm enthält) gebauten kernel-modul-rpm aufgerufen werden...
 
endur' schrieb:
buddabrod' schrieb:
Bei mir wird es scheinbar nicht ausgeführt. Zumindest nicht, wenn man es braucht
Zum Vergrößern anklicken....
Habe keine Idea, woran das liegt... depmod -a müsste beim automatischen Installieren des durch akmod (was das source rpm enthält) gebauten kernel-modul-rpm aufgerufen werden...
Zum Vergrößern anklicken....
Das passiert leider nicht. Ich nehme an, dass man irgendwie die verbosity hochschrauben kann und dann sieht, woran es liegt.

Da depmod sehr schnell läuft, wenn es einmal ausgeführt wurde, werde ich es eben bei jedem Start laufen lassen.
 
Hallo,

ich habe auf meinem R400 Fedora 15 mit Gnome3 installiert.
Es läuft auch soweit alles zufriedenstellend, bis auf das Problem, dass sich tp_smapi nicht kompilieren lässt und der Suspend nicht funktioniert.

Ich habe für das kompilieren von tp_smapi unter Fedora mal ein kleines Skript geschrieben:
Code: 
#!/bin/bash
#tp_smapi kompilieren
sudo yum install kernel-headers kernel-devel gcc make
cd ~/Linux/tp_smapi
tar xvzf tp_smapi-0.40.tgz
cd tp_smapi-0.40
sudo make install
sudo make clean
cd ~/Linux/tp_smapi
rm -r tp_smapi-0.40 
sudo modprobe tp_smapi
echo "Ready"
sleep 60
exit 0
Dabei liegt das Skript und das Archiv bei mir immer in dem Ordner "~/Linux/tp_smapi".
Unter Fedora 14 hat das alles Problemlos geklappt, seit Fedora 15 klappt das nicht.

Dabei kommt folgende Fehlermeldung:
Code: 
Geladene Plugins: langpacks, presto, refresh-packagekit
Einrichten des Installationsprozess
Paket kernel-headers-2.6.38.6-27.fc15.i686 ist bereits in der neusten Version installiert.
Paket kernel-devel-2.6.38.6-27.fc15.i686 ist bereits in der neusten Version installiert.
Paket gcc-4.6.0-7.fc15.i686 ist bereits in der neusten Version installiert.
Paket 1:make-3.82-4.fc15.i686 ist bereits in der neusten Version installiert.
Nichts zu tun
tp_smapi-0.40/
tp_smapi-0.40/CHANGES
tp_smapi-0.40/Makefile
tp_smapi-0.40/README
tp_smapi-0.40/TODO
tp_smapi-0.40/diff/
tp_smapi-0.40/diff/Kconfig-thinkpad_ec.add
tp_smapi-0.40/diff/Kconfig-tp_smapi.add
tp_smapi-0.40/hdaps.c
tp_smapi-0.40/include/
tp_smapi-0.40/include/linux/
tp_smapi-0.40/include/linux/thinkpad_ec.h
tp_smapi-0.40/thinkpad_ec.c
tp_smapi-0.40/thinkpad_ec.h
tp_smapi-0.40/tp_smapi.c
make -C /lib/modules/2.6.38.6-27.fc15.i686/build M=~/Linux/tp_smapi/tp_smapi-0.40 O=/lib/modules/2.6.38.6-27.fc15.i686/build modules
make[1]: Entering directory `/usr/src/kernels/2.6.38.6-27.fc15.i686'
  CC [M]  ~/Linux/tp_smapi/tp_smapi-0.40/thinkpad_ec.o
~/Linux/tp_smapi/tp_smapi-0.40/thinkpad_ec.c:91:8: Warnung: »int« ist Standardtyp in Deklaration von »DECLARE_MUTEX« [-Wimplicit-int]
~/Linux/tp_smapi/tp_smapi-0.40/thinkpad_ec.c:91:1: Warnung: Parameternamen (ohne Typen) in Funktionsdeklaration [standardmäßig aktiviert]
~/Linux/tp_smapi/tp_smapi-0.40/thinkpad_ec.c: In Funktion »thinkpad_ec_lock«:
~/Linux/tp_smapi/tp_smapi-0.40/thinkpad_ec.c:108:28: Fehler: »thinkpad_ec_mutex« nicht deklariert (erste Benutzung in dieser Funktion)
~/Linux/tp_smapi/tp_smapi-0.40/thinkpad_ec.c:108:28: Anmerkung: jeder nicht deklarierte Bezeichner wird nur einmal für jede Funktion, in der er vorkommt, gemeldet
~/Linux/tp_smapi/tp_smapi-0.40/thinkpad_ec.c: In Funktion »thinkpad_ec_try_lock«:
~/Linux/tp_smapi/tp_smapi-0.40/thinkpad_ec.c:122:23: Fehler: »thinkpad_ec_mutex« nicht deklariert (erste Benutzung in dieser Funktion)
~/Linux/tp_smapi/tp_smapi-0.40/thinkpad_ec.c: In Funktion »thinkpad_ec_unlock«:
~/Linux/tp_smapi/tp_smapi-0.40/thinkpad_ec.c:134:6: Fehler: »thinkpad_ec_mutex« nicht deklariert (erste Benutzung in dieser Funktion)
~/Linux/tp_smapi/tp_smapi-0.40/thinkpad_ec.c: Auf höchster Ebene:
~/Linux/tp_smapi/tp_smapi-0.40/thinkpad_ec.c:91:8: Warnung: »DECLARE_MUTEX« als »static« deklariert, aber nirgendwo definiert [-Wunused-function]
~/Linux/tp_smapi/tp_smapi-0.40/thinkpad_ec.c: In Funktion »thinkpad_ec_try_lock«:
~/Linux/tp_smapi/tp_smapi-0.40/thinkpad_ec.c:123:1: Warnung: Kontrollfluss erreicht Ende von Nicht-void-Funktion [-Wreturn-type]
make[3]: *** [~/Linux/tp_smapi/tp_smapi-0.40/thinkpad_ec.o] Fehler 1
make[2]: *** [_module_~/Linux/tp_smapi/tp_smapi-0.40] Fehler 2
make[1]: *** [sub-make] Fehler 2
make[1]: Leaving directory `/usr/src/kernels/2.6.38.6-27.fc15.i686'
make: *** [modules] Fehler 2
rm -f tp_smapi.mod.* tp_smapi.o tp_smapi.ko .tp_smapi.*.cmd
rm -f thinkpad_ec.mod.* thinkpad_ec.o thinkpad_ec.ko .thinkpad_ec.*.cmd
rm -f hdaps.mod.* hdaps.o hdaps.ko .hdaps.*.cmd
rm -f *~ diff/*~ *.orig diff/*.orig *.rej diff/*.rej
rm -f tp_smapi-*-for-*.patch
rm -fr .tmp_versions Modules.symvers diff/hdaps.diff.tmp
FATAL: Module tp_smapi not found.
Ready
Hat irgendwer das gleiche Problem oder wie habt ihr das mit dem Modul tp_smapi gelöst.
Ist schon schade, wenn man die Akkuladeschwellen nicht einstellen kann.

Darüberhinaus kommt beim Versuch in den Standby zu wechseln (Suspend-to-RAM) nach kurzer Zeit der gesperrte Bildschirm, aber in den Standby wechselt das System nicht. Es blinkt ein paar mal die Standbyleuchte und dann bin ich auf dem gespeerten Bildschirm. Da habe ich überhaupt keine Idee.

Gruß
Bentallica
 
'declare_mutex' wurde in den neueren Kernels auf 'define_semaphore' umbenannt. Den source bearbeiten und entsprechend ersetzen.
 
Hallo,

ich habe die Änderung händisch integriert und nun klappt es, danke für die Hilfe.
Wie und wo muss ich diesen Patch einspielen? Bin da nicht so bewandert.

Bleibt noch das Problem mit dem Standby. Ich habe mittlerweile festgestellt, dass das Problem nur hin und wieder auftritt. Im Prinzip kann man sagen, so jedes 2-3x geht der Rechner in den Standby (habe das ein paar mal öfter jetzt probiert).
Ich habe in Erinnerung, dass es in Fedora 14 ein Problem mit den TPM-Modul und Standby gibt. Daraufhin habe ich es im BIOS deaktiviert und hatte nie ein Problem.
Von daher denke ich, der Fehler ist woanders zu suchen, bloß wo?

Gruß
Benny
 
Zuletzt bearbeitet:
Bentallica schrieb:
Hallo,
ich habe die Änderung händisch integriert und nun klappt es, danke für die Hilfe.
Wie und wo muss ich diesen Patch einspielen? Bin da nicht so bewandert.
Zum Vergrößern anklicken....

In etwa so:
Code: 
yum install patch gcc kernel-headers
tar -xf tp_smapi-0.40.tgz
cp tp_smapi-0.40-patch_for_2.6.37.patch tp_smapi-0.40
cd tp_smapi-0.40
patch -Np1 < tp_smapi-0.40-patch_for_2.6.37.patch
make load HDAPS=x
make install HDAPS=x
modprobe -v tp_smapi
 
Ich bin nicht so erfahren mit Fedora (benutze F15)

Wenn ich es wie oben mache bekomme ich:
Code: 
bash-4.2$ make load HDAPS=0
Makefile:31: Building tp_smapi requires Linux kernel 2.6.19 or newer, and matching kernel headers.
Makefile:32: You may need to override the following Make variables:
Makefile:33: .   KVER=2.6.38.6-26.rc1.fc15.x86_64
Makefile:34: .   KBUILD=/lib/modules/2.6.38.6-26.rc1.fc15.x86_64/build
Makefile:35: .   MOD_DIR=/lib/modules/2.6.38.6-26.rc1.fc15.x86_64/kernel
Makefile:36: For "make patch", you may also need the full kernel sources, and may need to override:
Makefile:37: .   KSRC=/lib/modules/2.6.38.6-26.rc1.fc15.x86_64/source
Makefile:38: *** Missing kernel headers.  Schluss.
bash-4.2$

kernel-headers hab ich aber installiert...:whistling:
Weiß jemand was da schief läuft?
 
Was zeigt:
rpm -qa|grep kernel
uname -r

Normal wird tp-smapi gegen den aktuell laufenden kernel kompiliert, scheinbar hast du aber die falschen headers bzw. das kernel-devel Paket nicht installiert oder etwas anderes geht schief.
 
Ich verstehe euch nicht wirklich, tp_smapi geht ohne Probleme (HDAPS habe ich nicht getestet). Folgendes geht bei mir problemlos:
Im Eingangsposting sind SRPMS von endur verlinkt. Da lädt man sich tp_smapi-0.40..src.rpm und tp_smapi-kmod..src.rpm. Mit
Code: 
su -c 'yum-builddep tp_smapi*src.rpm'
werden die zum bauen notwendigen Pakete nachinstalliert (yum-builddep ist Bestandteil von yum-utils). Wenn das fertig ist, kann man sich mittels
Code: 
rpmbuild --rebuild --define "kernels $(uname -r)" --target $(uname -m) tp_smapi-kmod-0.40-5.fc15.src.rpm 
rpmbuild --rebuild --define "kernels $(uname -r)" --target $(uname -m) tp_smapi-0.40-3.fc15.src.rpm
die für sein System und dem aktuell gebooteten Kernel passenden Pakete bauen (geht als normaler Nutzer). Diese werden dann wie folgt installiert:
Code: 
cd ~/rpmbuild/RPMS
su -c 'yum --nogpgcheck localinstall x86_64/kmod-tp_smapi-2.6.38.7-30.fc15.x86_64-0.40-5.fc15.x86_64.rpm noarch/tp_smapi-0.40-3.fc15.noarch.rpm'
installiert. Hier sind die Pfade und Paketenamen anzupassen. Meine Zeilen gelten für eine 64 Bit Plattform.

Auf die Art und Weise muss man nichts patchen oder sonst was. Bei mir hat es auch gegen Kernel 2.6.39 erfolgreich kompiliert.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben