Stromsparmodi aktivieren bei Radeon-Treiber auf Debian Squeeze

Dalai

Grand Admiral Special
Mitglied seit
14.06.2004
Beiträge
7.420
Renomée
262
Standort
Meiningen, Thüringen
Hallo Leute,

da mir Ubuntu immer mehr aufn Sack geht und mir die Entwicklungsrichtung schon seit einiger Zeit nicht mehr gefällt, installierte ich mir heute Debian Squeeze auf meinen ThinkPad T43.

Die Installation lief einwandfrei, auch wenn ich erstmal den Grub2 runterkratzen und durch Grub ersetzen musste, weil Grub2 zu doof ist, sich in eine Partition zu installieren :] - aber das isn anderes Thema.

Es läuft soweit einwandfrei, nur habe ich ein dickes Problem: es wird viel zu viel Strom verbraucht, ungefähr 10 Watt mehr als nötig. Daher habe ich versucht, die Stromsparmodi der Grafikkarte zu aktivieren, bislang leider ohne Erfolg.

Zuerst habe ich es mit Optionen in /etc/modprobe.d/radeon-kms.conf versucht:
Code:
options radeon modeset=1 dynclks=1 dynpm=1

Dann habe ich KMS abgeschaltet (modeset=0) und eine xorg.conf erstellt mit diesem Inhalt:
Code:
Section "Device"
	Identifier	"Radeon X300"
	Driver		"radeon"
	Option		"ClockGating"	"on"
	Option		"DynamicPM"	"on"
#	Option		"DynamicClocks"	"on"
EndSection

Section "Monitor"
	Identifier	"blub"
EndSection

Section "Screen"
	Identifier	"Screen"
	Monitor		"blub"
	Device		"Radeon X300"
EndSection
Das Paket fimware-linux-nonfree ist ebenfalls installiert. Die Xorg.0.log gibt auch keine Warnungen oder Fehler in der Richtung aus, im Gegenteil: er bestätigt die angegebenen Optionen. Aber die Kiste zieht immernoch zuviel Strom und die GPU ist eindeutig zu warm.

Was kann ich tun? Wo kann ich ansetzen?

MfG Dalai
 
kms anmachen und dann:
Code:
echo profile > /sys/class/drm/card0/device/power_method
echo auto >/sys/class/drm/card0/device/power_profile
Ob man das auch direkt an das modul übergeben kann weiß ich leider nicht ohne selbst zu suchen. Jedenfalls ist es das was du machen solltest.
Einen Wechsel des Zustands merkst du an einem kurzen Flackern.

Edit: Das ganze xorg.conf Zeugs ist mit KMS obsolet, afaik.
 
Zuletzt bearbeitet:
kms anmachen und dann:
Code:
echo profile > /sys/class/drm/card0/device/power_method
echo auto >/sys/class/drm/card0/device/power_profile
OK, hab KMS wieder eingeschaltet und neu gebootet, aber genannte Dateien gibt es nicht. Ich hab nur ein Verzeichnis /sys/class/drm/card0/device/power (mit einer Datei wakeup drin). Und wenn ich diese Befehle ausführe, meckert er, dass die Dateien fehlen.

Edit: Das ganze xorg.conf Zeugs ist mit KMS obsolet, afaik.
Ich weiß. Ich wusste das auch erst nicht und hab mich gewundert, warum die Anweisungen der xorg.conf nicht angenommen werden, wie dem Xorg.0.log entnommen werden konnte. Aber das konnte ich dank Googlelei rausfinden :).

MfG Dalai
 
Da gibt es dann mehrere Möglichkeiten:
1. Kernel zu alt (Ich glaube mind. 2.6.37)
2. KMS funktioniert nicht (dmesg? Xorg.0.log?)
3. Irgendwas an das ich jetzt nicht gedacht hab ;)

Zu 2: Ich weiß leider nicht, was man genau machen muss um KMS + radeon als Modul zum Laufen zu bringen. Könnte mir vorstellen, dass man es in die initrd integrieren muss, insofern du eine hast.
Zusätzlich muss berücksichtigt werden, dass KMS auf Chips >=r500 externe Firmware benötigt (z.B. R600_rlc.bin), die du im linux-firmware repo findest. Diese muss in den Kernel einkompiliert, bzw. hier vermutlich in die initrd integriert werden.
Genau kann ich dir das aber nicht sagen, da ich radeon nicht als Modul verwende.
 
Da gibt es dann mehrere Möglichkeiten:
1. Kernel zu alt (Ich glaube mind. 2.6.37)
Debian Squeeze verwendet 2.6.32, stabil eben ;D.

2. KMS funktioniert nicht (dmesg? Xorg.0.log?)
Doch, sonst würde er die Optionen der xorg.conf anwenden. Aber keine Sorge, die xorg.conf hab ich wieder umbenannt, so dass sie nicht stört.

Zu 2: Ich weiß leider nicht, was man genau machen muss um KMS + radeon als Modul zum Laufen zu bringen. Könnte mir vorstellen, dass man es in die initrd integrieren muss, insofern du eine hast.
Ist ne Standardinstallation von Debian Squeeze 6.0 mit Desktopumgebung. Ich gebe zu, dass ich die Firmware erst später nachinstalliert habe ich deshalb nicht weiß, ob das Modul im initrd enthalten ist oder nicht.

Zusätzlich muss berücksichtigt werden, dass KMS auf Chips >=r500 externe Firmware benötigt (z.B. R600_rlc.bin), die du im linux-firmware repo findest.
Ich weiß. Deswegen hab ich das Paket firmware-linux-nonfree installiert, wo eine R300_cp.bin enthalten ist, die er vorher als fehlend anmeckerte.

MfG Dalai
 
2.6.32 ist meines Wissens zu alt dafür.
.
EDIT :
.

Siehe hier:
http://en.gentoo-wiki.com/wiki/Radeon#Kernels_.3C.3D_2.6.32

Code:
kernel /boot/2.6.37 root=/dev/sda2 radeon.modeset=1 video=1024x768-32@60

bei mir ohne initrd.
Gentoo Wiki ist keine gute Quelle. Ein großer Teil der dort verlinkten Artikel enthält gravierende Fehler oder ist veraltet.

Wie gesagt, man braucht keine initrd, ich bin mir allerdings nicht sicher, ob man radeon als Modul mit KMS ohne initrd verwenden kann. Einen Versuch ist es sicher wert.
Wenn man es einkompiliert braucht man natürlich keine initrd, das ist klar.
 
2.6.32 ist meines Wissens zu alt dafür.
.
EDIT :
.


Gentoo Wiki ist keine gute Quelle. Ein großer Teil der dort verlinkten Artikel enthält gravierende Fehler oder ist veraltet.

Wie gesagt, man braucht keine initrd, ich bin mir allerdings nicht sicher, ob man radeon als Modul mit KMS ohne initrd verwenden kann. Einen Versuch ist es sicher wert.
Wenn man es einkompiliert braucht man natürlich keine initrd, das ist klar.


CONFIG_DRM=y
CONFIG_DRM_RADEON=m
:]
Du meintest beides.
;)

2.6.32 ist meines Wissens zu alt dafür.
Ist doch schon ewig dabei.
 
Meine Config sieht so aus:
Code:
CONFIG_DRM=m
CONFIG_DRM_RADEON=m
# CONFIG_DRM_RADEON_KMS is not set

Dennoch halte ich das für in Ordnung, denn KMS selbst funktioniert ja. Man sieht es ja auch, weil er während der Textausgabe im Bootvorgang schon die Auflösung hochdreht.

MfG Dalai
 
:]
Du meintest beides.
;)
Nun, mag schon sein. Ist ja auch egal. Wenn KMS funktioniert scheitert es zumindest schonmal nicht daran.
Ist doch schon ewig dabei.
KMS ja, die Stromsparfunktionen aber nicht. Die wurden erst vor einigen Kernelversionen hinzugefügt. Ich meine mich zu erinnern, dass das 2.6.35 oder 2.6.36 war, sicher bin ich mir aber nicht. Und ehrlich gesagt jetzt zu faul in git herumzuwühlen. ;)

Jedenfalls würde ich es einfach mit einem neueren Kernel probieren. Der ist ja zum Glück recht austauschbar.
.
EDIT :
.

Meine Config sieht so aus:
Code:
CONFIG_DRM=m
CONFIG_DRM_RADEON=m
# CONFIG_DRM_RADEON_KMS is not set

Dennoch halte ich das für in Ordnung, denn KMS selbst funktioniert ja. Man sieht es ja auch, weil er während der Textausgabe im Bootvorgang schon die Auflösung hochdreht.

MfG Dalai
Wenn ich das richtig in Erinnerung habe, dann war DRM_RADEON_KMS die Option, die es per default aktivierte. Der Effekt wäre dann eben nur, dass du den Parameter modeset nicht übergeben musst.
 
Welche Möglichkeiten habe ich nun, vorzugsweise ohne Kernelkompilierung? Ob freier oder proprietärer Treiber ist mir völlig egal, funktionieren muss es. 3D brauche ich auch nicht. Wenn ich mir die Infos zu fglrx in Debian Stable anschaue und ich das richtig interpretiere, komme ich damit aber auch nicht weiter. Schließlich habe ich keine R6xx/R7xx sondern eine X300 (Codename M22).

MfG Dalai
 
Welche Möglichkeiten habe ich nun, vorzugsweise ohne Kernelkompilierung? Ob freier oder proprietärer Treiber ist mir völlig egal, funktionieren muss es. 3D brauche ich auch nicht. Wenn ich mir die Infos zu fglrx in Debian Stable anschaue und ich das richtig interpretiere, komme ich damit aber auch nicht weiter. Schließlich habe ich keine R6xx/R7xx sondern eine X300 (Codename M22).

MfG Dalai
Da kann ich dir leider nicht wirklich weiterhelfen, da das Debian-spezifisch ist.
Ich könnte mir aber vorstellen, dass es irgendwo ein repo mit aktuelleren Kernelversionen gibt. Kernel selbst kompilieren geht natürlich auch, wenn du die Debian-config nimmst bzw. noch anpasst (musst du machen, da die neuern Kernel teilweise andere Optionen haben, also `make oldconfig`), sollte sich der Aufwand auch in Grenzen halten.
Aber wie gesagt, schau mal, ob es irgendwo neuere Kernel gibt.

Könnte auch sein, dass du die Patches für 2.6.32 findest, aber das beinhaltet ja wieder Kernel neukompilieren, in dem Fall allerdings ohne Neukonfiguration.
Andere Möglichkeiten fallen mir leider auch nicht ein. Von fglrx würde ich ehrlich gesagt die Finger lassen, radeon ist wesentlich schmerzfreier, solange man nicht 3D Spiele spielen will.

Edit: Ich hab mir gerade nochmal Linux in meinem git tree angeschaut. Power Management gab es bis zu einem gewissen Grad auch schon in 2.6.32, allerdings weiß ich nicht darüber Bescheid, ob es funktionierte und wenn ja, wie gut. Auch weiß ich nicht, wie man es aktivierte. Erste Teile waren jedenfalls vorhanden.
Der Patch den ich meinte ist dieser hier:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ce8f5370
Der hatte Einzug in Kernel 2.6.35 erhalten und stellte die oben genannten Möglichkeiten bereit. Nach meinen Erfahrungen auch recht zuverlässig.
 
Zuletzt bearbeitet:
Ich könnte mir aber vorstellen, dass es irgendwo ein repo mit aktuelleren Kernelversionen gibt.
Debian bietet zwar auch einen aktuelleren Kernel, allerdings in experimental und darauf hab ich ehrlich keinen Bock, zumal das wieder Abhängigkeiten nach sich zieht.

EDIT: Debian baut wohl grade das Repos um und schiebt experimental nach sid, deshalb Anpassung der URL.

Kernel selbst kompilieren geht natürlich auch, wenn du die Debian-config nimmst bzw. noch anpasst
Das Problem ist immer: woher weiß ich, ob ich dann wirklich den bisher laufenden Kernel plus die gewünschten Optionen habe und nicht irgendein Debian-Patch "vergessen" wurde?

Könnte auch sein, dass du die Patches für 2.6.32 findest, aber das beinhaltet ja wieder Kernel neukompilieren, in dem Fall allerdings ohne Neukonfiguration.
Das wäre eine Möglichkeit, aber so richtig gefallen tut sie mir auch nicht, weil es IMO schon zuviel Aufwand ist.

Von fglrx würde ich ehrlich gesagt die Finger lassen, radeon ist wesentlich schmerzfreier, solange man nicht 3D Spiele spielen will.
Ich hab ja nur gefragt, weil ich fglrx in Ubuntu 8.04 verwendete und der dort (nach ein bisschen Konfig) auch gut funktionierte.

Der Witz ist ja: in Ubuntu 10.04 - das ebenfalls Kernel 2.6.32 verwendet - funktionieren die Stromsparmodi IIRC einwandfrei. Vor allem frage ich mich langsam, wie alt die Hardware noch sein muss oder wie lange man warten muss, bis solche Selbstverständlichkeiten ohne viel Gefummel funktionieren - ich sehe das jedenfalls als eine solche.

----

Nun hab ich mir so viel Arbeit gemacht, tpfand zum Laufen zu bringen *buck*, da muss doch dieser Mist auch noch zum Funktionieren zu überreden sein, oder?

MfG Dalai
 
Zuletzt bearbeitet:
Debian bietet zwar auch einen aktuelleren Kernel, allerdings in experimental und darauf hab ich ehrlich keinen Bock, zumal das wieder Abhängigkeiten nach sich zieht.
Da würde ich ehrlich gesagt einfach rigoros vorgehen. Der Kernel selbst hat nicht wirklich Abhängigkeiten (es gibt aber Ausnahmen!) und es sollte wirklich kein Problem sein, da einen aktuelleren Kernel einzubinden.
Wenn ich mir die von dir verlinkte Seite genauer anschaue, dann sollte es auch in diesem Fall nicht in einem Abhängigkeitenchaos enden, da die Abhängigkeiten minimal sind.
Falls doch würde ich so vorgehen, dass du das .deb Paket runterlädst, mit ar -x entpackst und dir den Kernel einfach selbst installierst.
(Also alles in /boot und /lib/modules, den Rest brauchst du vermutlich nicht.)
Im Falle des Kernels ist das auch nicht so evil wie im Falle eines normalen Programmes, welches du nach /usr installieren würdest.
Das Problem ist immer: woher weiß ich, ob ich dann wirklich den bisher laufenden Kernel plus die gewünschten Optionen habe und nicht irgendein Debian-Patch "vergessen" wurde?
Am besten würdest du natürlich den Sourcecode des Debiankernels verwenden.
Oft sind die Patches der Distributionen aber ohnehin mehr Ärgernis als nützlich. Besonders bei Ubuntu ist das häufig der Fall.
Der Witz ist ja: in Ubuntu 10.04 - das ebenfalls Kernel 2.6.32 verwendet - funktionieren die Stromsparmodi IIRC einwandfrei.
Nun, da kann ich natürlich so nichts dazu sagen, wäre aber bzgl. dieser Aussage eher skeptisch, da ich mir nicht vorstellen kann, dass Ubuntu oder Debian in Bezug auf diese Funktion irgendwelche Patches eingespielt haben. Die Ubuntu-Maintainer sind da zwar relativ schmerzbefreit, wenn es um Patches geht, aber ich glaub nicht, dass die sowas anfassen.
Vor allem frage ich mich langsam, wie alt die Hardware noch sein muss oder wie lange man warten muss, bis solche Selbstverständlichkeiten ohne viel Gefummel funktionieren - ich sehe das jedenfalls als eine solche.
Da hast du vermutlich einfach Pech. Bei mir funktioniert eigentlich so gut wie alles "ohne viel Gefummel". ;)
Und ich hab nicht mal wirklich alte Hardware. :o
 
Da würde ich ehrlich gesagt einfach rigoros vorgehen. Der Kernel selbst hat nicht wirklich Abhängigkeiten (es gibt aber Ausnahmen!) und es sollte wirklich kein Problem sein, da einen aktuelleren Kernel einzubinden.
Wenn ich mir die von dir verlinkte Seite genauer anschaue, dann sollte es auch in diesem Fall nicht in einem Abhängigkeitenchaos enden, da die Abhängigkeiten minimal sind.
Falls doch würde ich so vorgehen, dass du das .deb Paket runterlädst, mit ar -x entpackst und dir den Kernel einfach selbst installierst.
(Also alles in /boot und /lib/modules, den Rest brauchst du vermutlich nicht.)
Werd ich vielleicht mal ausprobieren.

Im Falle des Kernels ist das auch nicht so evil wie im Falle eines normalen Programmes, welches du nach /usr installieren würdest.
Das stimmt, es sind weniger Abhängigkeiten. Dafür sind es deutlich mehr Risiken, weil der Kernel das gesamte System beeinflusst und nicht nur ein Programm.

Nun, da kann ich natürlich so nichts dazu sagen, wäre aber bzgl. dieser Aussage eher skeptisch, da ich mir nicht vorstellen kann, dass Ubuntu oder Debian in Bezug auf diese Funktion irgendwelche Patches eingespielt haben. Die Ubuntu-Maintainer sind da zwar relativ schmerzbefreit, wenn es um Patches geht, aber ich glaub nicht, dass die sowas anfassen.
Ist aber Fakt. Unter Ubuntu erreicht die GPU eine Temp von ~48°C und das System verbraucht ~17 Watt, bei Debian zieht die Kiste hingegen ~23 Watt und die GPU ist nicht unter 52°C zu bekommen. Powertop liest unter Debian übrigens Müll aus, deshalb hab ich den Wert aus den Energiestatistiken genommen (durch Klick auf das Akkusymbol im "Tray").

Ergänzung: Ich sehe grade, dass ich unter Ubuntu die Optionen in der xorg.conf ebenfalls gesetzt habe, die Xorg.0.log sagt aber, dass sie ignoriert werden. Trotzdem verbraucht er weniger. Demzufolge muss irgendein Powermanagement aktiv sein.

Da hast du vermutlich einfach Pech. Bei mir funktioniert eigentlich so gut wie alles "ohne viel Gefummel". ;)
Ja, so wird das wohl sein. Mit meinem Desktop-PC hätte ich vermutlich keine Probleme (außer vielleicht mit dem nVidia-Treiber *buck*), aber dort geht's mir auch nicht ums Stromsparen :-/.

MfG Dalai
 
Zuletzt bearbeitet:
Das stimmt, es sind weniger Abhängigkeiten. Dafür sind es deutlich mehr Risiken, weil der Kernel das gesamte System beeinflusst und nicht nur ein Programm.
Der Kernel selbst hat eigentlich keine Abhängigkeiten in dem Sinne (ok, das ist so jetzt nicht richtig, aber auf das Paketmanagement bezogen).
Wenn du dir das anschaust, dann sind das im wesentlichen nur die Programme, die die Installation des Kernels handhaben, als mkinitrd und ähnliches.
Im Grund ändert sich bei diesen Tools eigentlich nichts, deshalb sollte es da kein Problem geben.
Versionsspezifische Abhängigkeiten sind in Bezug auf den Kernel eher selten, kommen aber vor. Meistens allerdings in die andere Richtung. So kann z.B. udev-X mind. Kernel-Y benötigen um zu funktionieren. Umgekehrt gibt es das so gut wie nie, ein neuerer Kernel sollte in den meisten Fällen ohne Probleme funktionieren.
Probleme treten im Normalfall nur dann auf, wenn irgendwelche Kernelfunktionen nicht mehr bereitgestellt werden, auf die eine Distribution aufbaut. Da solche Funktionen aber typischerweise jahrlang als deprecated markiert werden ist die Zeitspanne dann sehr groß.
 
Man kann gehörig mit Sachen, wie dkms kollidieren.
Außerdem mögen z.B. die berühmten propietären Grafiktreiber nicht alle Kernel/Distributions Kombinationen.
Dann hast Du bei neueren Kerneln prinzipiell das Problem, das die Konfiguration wiederum von der zugrundeliegenden Distri abhängig ist. Man fährt glaube ich besser, alle nicht benötigten Module raus zu nehmen.
Letztendlich ist es immer am besten, man hält den Mund und nimmt den Kernel, und die (unfreien) Treiber, die angeboten werden.
Die Alternative ist, seinen eigenen Kernel zu 'pflegen', dazu gehört aber auch zu wissen, was er braucht, und das ist natürlich Aufwand. Wenn man im Netz fragt, wie man seinen eigen Kernel machen soll, wird man heutzutage doch meist abgewiesen, typischerweise mit der Frage nach dem Zweck eines Selbstkompilats und dem Hinweis, dass die ausgelieferten Kernel doch ausreichend seien.
Möchte man dann alle Sicherheitspatches kommst Du ums zyklische neu bauen nicht mehr herum. Das kann ohne störrische Tools wie dkms zur richtigen Arbeit werden, je nach Programmlage.

Meine Meinung, einfach jemandem empfehlen das Teil selbst zu bauen kann heikel sein. :) Ich z.B. bin auch froh in der Hinsicht innerhalb einer Installation nicht Hand anlegen zu müssen. Bei gentoo z.B. kann das ja richtig Spaß machen, aber bei den "fetten" Distris neige ich höchstens zu Paketen und Sources aus den Backports. Ubuntu, Debian, Mandriva, Centos machen keine Lust bei sowas.

Edit:
Tschuldigung @Dalai&Topic ;)
 
Man kann gehörig mit Sachen, wie dkms kollidieren.
Außerdem mögen z.B. die berühmten propietären Grafiktreiber nicht alle Kernel/Distributions Kombinationen.
Verwendet denn Debian dkms? Zudem braucht man das ja nur bei externen Modulen, wie z.B. virtualbox, ist also gar kein Muss, je nach verwendeter Software.
Und natürlich sind proprietäre Grafiktreiber ein Problem, aber die würde ich ja auch nicht nutzen, zumindest nicht in diesem Fall wo ja 3D kein entscheidendes Kriterium zu sein scheint.
Möchte man dann alle Sicherheitspatches kommst Du ums zyklische neu bauen nicht mehr herum.
Das ist schon richtig, allerdings ist der Aufwand auch nicht so groß, da eine bestehende Kernelkonfiguration ja mit recht geringem Aufwand aktuell gehalten werden kann.
Das eigentliche Kompilieren des Kernels bzw. dessen Installation ist ja keine große Sache und auf einem modernen System in 10-15min erledigt (max. 5 min Eigenaufwand).
Meine Meinung, einfach jemandem empfehlen das Teil selbst zu bauen kann heikel sein.
Wenn du dir das nochmals genau durchliest, dann wirst du feststellen, dass ich das keineswegs empfohlen habe. Es war nur eine der Möglichkeiten, die ich ansprach, falls die anderen Optionen wegfallen.
Die von mir empfohlene Option war, den neueren Debiankernel aus experimental zu verwenden (oder zumindest zu versuchen, diesen zu verwenden) und diesen entweder mit apt, oder eben manuell zu installieren. Beides erfordert keine Neukompilation.
Bei gentoo z.B. kann das ja richtig Spaß machen
Gerade Gentoo ist in der Hinsicht eher nervig. :P
Aber ok, wenn du an Gentoo Spaß hast, dann will ich dir den sicher nicht nehmen. ;)

Abgesehen davon, wenn eine Distribution "fett" ist, dann trifft das mit Sicherheit auf Gentoo am ehesten zu, auch wenn es natürlich nicht so wirkt, da man ein schlankes System bauen kann (was du wahrscheinlich meintest).
 
Im Moment baut Debian wohl grad die Repos um, deswegen gibt's im Moment nur das Metapaket des Kernels und ich werde warten müssen, bis das echte Paket verfügbar ist. Da es nicht eilt, ist das nicht so schlimm. Ich werde dranbleiben.

MfG Dalai
 
Seit heute ist nun endlich nicht nur das Metapaket sondern auch der darin befindliche Kernel verfügbar. Ich zieh ihn grade und werde ihn dann installieren und berichten.

MfG Dalai
.
EDIT :
.

Installieren ließ sich der Kernel (brauchte noch linux-base und firmware-linux-free), aber geändert hat das am Problem nichts. Im Gegenteil: ACPI funktioniert nun nicht mehr richtig, weil einige Dateien & Verzeichnisse in /proc/acpi fehlen und powertop schmiert mit einem Speicherzugriffsfehler weg (syslog weist auf segfault in libc-2.11.2.so hin).

Auch wenn ich keine Verbrauchswerte habe, anhand der Temperatur der GPU kann ich erkennen, dass der Verbrauch nicht geringer ist. dmesg weist aber aus, dass Powermanagement im Vergleich zum alten Kernel aktiviert sein soll. KMS läuft auch, aber wie gesagt: sparen tut er nicht.

Was kann ich tun?

MfG Dalai
.
EDIT :
.

OK, nachdem ich die Befehle hier ausführte, geht die Temperatur zurück.
Code:
echo profile > /sys/class/drm/card0/device/power_method
echo auto >/sys/class/drm/card0/device/power_profile
Allerdings war der Kernel davon nicht gerade begeistert und meldete:
Code:
Feb 18 11:59:34 idefix kernel: [  138.165910] Uhhuh. NMI received for unknown reason b0 on CPU 0.
Feb 18 11:59:34 idefix kernel: [  138.168005] You have some hardware problem, likely on the PCI bus.
Feb 18 11:59:34 idefix kernel: [  138.168005] Dazed and confused, but trying to continue

Kann man gegen diese Meldung etwas tun? Wenn ja, was? Kann man das Profil auch sofort beim Start anwenden, vorzugsweise als Parameter übergeben oder so, denn in der rc.local wird's dann wohl auch zu einer solchen Meldung führen...

Kann ich den fehlenden ACPI-Kram noch irgendwie zum Laufen überreden? Hier mal der die Listings des Verzeichnisses /proc/acpi beider Kernel.

2.6.32:
Code:
/proc/acpi/
/proc/acpi/button
/proc/acpi/button/lid
/proc/acpi/button/lid/LID
/proc/acpi/button/lid/LID/info
/proc/acpi/button/lid/LID/state
/proc/acpi/button/power
/proc/acpi/button/power/PWRF
/proc/acpi/button/power/PWRF/info
/proc/acpi/button/sleep
/proc/acpi/button/sleep/SLPB
/proc/acpi/button/sleep/SLPB/info
/proc/acpi/dsdt
/proc/acpi/embedded_controller
/proc/acpi/embedded_controller/EC
/proc/acpi/embedded_controller/EC/info
/proc/acpi/fadt
/proc/acpi/ibm
/proc/acpi/ibm/beep
/proc/acpi/ibm/bluetooth
/proc/acpi/ibm/brightness
/proc/acpi/ibm/cmos
/proc/acpi/ibm/driver
/proc/acpi/ibm/ecdump
/proc/acpi/ibm/fan
/proc/acpi/ibm/hotkey
/proc/acpi/ibm/led
/proc/acpi/ibm/light
/proc/acpi/ibm/thermal
/proc/acpi/ibm/video
/proc/acpi/ibm/volume
/proc/acpi/info
/proc/acpi/power_resource
/proc/acpi/power_resource/PUBS
/proc/acpi/power_resource/PUBS/state
/proc/acpi/processor
/proc/acpi/processor/CPU0
/proc/acpi/processor/CPU0/info
/proc/acpi/processor/CPU0/limit
/proc/acpi/processor/CPU0/power
/proc/acpi/processor/CPU0/throttling
/proc/acpi/sleep
/proc/acpi/thermal_zone
/proc/acpi/thermal_zone/THM0
/proc/acpi/thermal_zone/THM0/cooling_mode
/proc/acpi/thermal_zone/THM0/polling_frequency
/proc/acpi/thermal_zone/THM0/state
/proc/acpi/thermal_zone/THM0/temperature
/proc/acpi/thermal_zone/THM0/trip_points
/proc/acpi/video
/proc/acpi/video/VID
/proc/acpi/video/VID/CRT0
/proc/acpi/video/VID/CRT0/brightness
/proc/acpi/video/VID/CRT0/EDID
/proc/acpi/video/VID/CRT0/info
/proc/acpi/video/VID/CRT0/state
/proc/acpi/video/VID/DOS
/proc/acpi/video/VID/DVI0
/proc/acpi/video/VID/DVI0/brightness
/proc/acpi/video/VID/DVI0/EDID
/proc/acpi/video/VID/DVI0/info
/proc/acpi/video/VID/DVI0/state
/proc/acpi/video/VID/info
/proc/acpi/video/VID/LCD0
/proc/acpi/video/VID/LCD0/brightness
/proc/acpi/video/VID/LCD0/EDID
/proc/acpi/video/VID/LCD0/info
/proc/acpi/video/VID/LCD0/state
/proc/acpi/video/VID/POST
/proc/acpi/video/VID/POST_info
/proc/acpi/video/VID/ROM
/proc/acpi/video/VID/TV0
/proc/acpi/video/VID/TV0/brightness
/proc/acpi/video/VID/TV0/EDID
/proc/acpi/video/VID/TV0/info
/proc/acpi/video/VID/TV0/state
/proc/acpi/wakeup

2.6.37:
Code:
/proc/acpi/
/proc/acpi/button
/proc/acpi/button/lid
/proc/acpi/button/lid/LID
/proc/acpi/button/lid/LID/info
/proc/acpi/button/lid/LID/state
/proc/acpi/button/power
/proc/acpi/button/power/PWRF
/proc/acpi/button/power/PWRF/info
/proc/acpi/button/sleep
/proc/acpi/button/sleep/SLPB
/proc/acpi/button/sleep/SLPB/info
/proc/acpi/ibm
/proc/acpi/ibm/beep
/proc/acpi/ibm/bluetooth
/proc/acpi/ibm/brightness
/proc/acpi/ibm/cmos
/proc/acpi/ibm/driver
/proc/acpi/ibm/fan
/proc/acpi/ibm/hotkey
/proc/acpi/ibm/led
/proc/acpi/ibm/light
/proc/acpi/ibm/thermal
/proc/acpi/ibm/video
/proc/acpi/ibm/volume
/proc/acpi/wakeup

Wie man sieht, fehlt dort ne ganze Menge. Keine Ahnung, ob dadurch Nachteile entstehen, aber ich kann mir vorstellen, dass die Meldung beim Ändern des Powerprofile damit zusammenhängt.

MfG Dalai
 
Installieren ließ sich der Kernel (brauchte noch linux-base und firmware-linux-free), aber geändert hat das am Problem nichts. Im Gegenteil: ACPI funktioniert nun nicht mehr richtig, weil einige Dateien & Verzeichnisse in /proc/acpi fehlen und powertop schmiert mit einem Speicherzugriffsfehler weg (syslog weist auf segfault in libc-2.11.2.so hin).
Das ist nicht so gut. Wobei powertop sowieso nicht wirklich notwendig ist. Um den Verbrauch zu bestimmen ist es sinnvoller hinter dem Netzteil zu messen.

OK, nachdem ich die Befehle hier ausführte, geht die Temperatur zurück.
Code:
echo profile > /sys/class/drm/card0/device/power_method
echo auto >/sys/class/drm/card0/device/power_profile
Allerdings war der Kernel davon nicht gerade begeistert und meldete:
Code:
Feb 18 11:59:34 idefix kernel: [  138.165910] Uhhuh. NMI received for unknown reason b0 on CPU 0.
Feb 18 11:59:34 idefix kernel: [  138.168005] You have some hardware problem, likely on the PCI bus.
Feb 18 11:59:34 idefix kernel: [  138.168005] Dazed and confused, but trying to continue
Das ist wirklich strange, sollte eigentlich nicht passieren. ist das reproduzierbar?
Kann man gegen diese Meldung etwas tun? Wenn ja, was? Kann man das Profil auch sofort beim Start anwenden, vorzugsweise als Parameter übergeben oder so, denn in der rc.local wird's dann wohl auch zu einer solchen Meldung führen...
Ich bezweifle ehrlich gesagt, dass das was bringen wird, aber im Prinzip sollte man das auch dem Kernel direkt übergeben können. Leider weiß ich nicht, welcher Parameter das dann ist. Spontan würde ich mal auf sowas tippen:
Code:
options radeon power_method=profile power_profile=auto
Sicher bin ich mir da aber nicht.
Kann ich den fehlenden ACPI-Kram noch irgendwie zum Laufen überreden?
Ohne Neukompilation leider nein. Wenn Debian CONFIG_ACPI_PROCFS nicht aktiviert hat, dann sind die Dateien nicht mehr vorhanden.
Wie man sieht, fehlt dort ne ganze Menge. Keine Ahnung, ob dadurch Nachteile entstehen, aber ich kann mir vorstellen, dass die Meldung beim Ändern des Powerprofile damit zusammenhängt.
Das bezweifle ich.
Code:
  ? CONFIG_ACPI_PROCFS:                                                                                                                                                                                                     ?   
  ?                                                                                                                                                                                                                         ?   
  ? For backwards compatibility, this option allows                                                                                                                                                                         ?   
  ? deprecated /proc/acpi/ files to exist, even when                                                                                                                                                                        ?   
  ? they have been replaced by functions in /sys.                                                                                                                                                                           ?   
  ? The deprecated files (and their replacements) include:                                                                                                                                                                  ?   
  ?                                                                                                                                                                                                                         ?   
  ? /proc/acpi/processor/*/throttling (/sys/class/thermal/                                                                                                                                                                  ?   
  ?       cooling_device*/*)                                                                                                                                                                                                ?   
  ? /proc/acpi/video/*/brightness (/sys/class/backlight/)                                                                                                                                                                   ?   
  ? /proc/acpi/thermal_zone/*/* (/sys/class/thermal/)                                                                                                                                                                       ?   
  ? This option has no effect on /proc/acpi/ files                                                                                                                                                                          ?   
  ? and functions which do not yet exist in /sys.                                                                                                                                                                           ?   
  ?                                                                                                                                                                                                                         ?   
  ? Say N to delete /proc/acpi/ files that have moved to /sys/
 
Ich kann sysfsutils vorschlagen:
http://wiki.ubuntuusers.de/Prozessortaktung#Einstellung-bei-Systemstart-festlegen
gibt es auch für Debian. Hab aber noch nie Gebrauch von gemacht.
Funktioniert wohl, denn er flackert kurz beim Systemstart und es steht auch in fraglichen Dateien drin.

Bezüglich des acpi, könnte es sein, da in der Kernel Hilfe etwas von 'deprecated' steht, dass Du einmal unter /sys/bus/acpi/drivers nachschaust.
Was soll ich in dem Verzeichnis sehen? Ich hab da ne Menge Dateien und Verzeichnisse drin.

In der Doku des Kernels (Dokument thinkpad-acpi) steht bei ein paar Sachen "deprecated", aber bei weitem nicht bei allen fehlenden. Nun kann man vermuten, dass in den vorhergehenden Kernels noch die anderen wegfielen.

Aber auf der anderen Seite funktioniert es nicht richtig. Ich weiß nicht, wie ich es erklären soll. Wichtigste Funktion: Anzeige des aktuellen Verbrauchs funktioniert nicht (powertop tut ja gar nicht im neuen Kernel und die Energiestatistik im Gnome gibt nur 0 zurück). Darauf basierend klappt natürlich die Errechnung der Akku-Restlaufzeit nicht, und das ist für mich ebenfalls wichtig.

Ich kenn mich leider zu wenig mit solchem systemnahen Zeug aus, als dass ich wüsste, wo ich ansetzen könnte und welche Informationen ich euch liefern müsste, damit ihr wisst, wie mir zu helfen wäre :-/.

Berniyh schrieb:
Das ist wirklich strange, sollte eigentlich nicht passieren. ist das reproduzierbar?
Ja, ist es oder besser gesagt: es war es. Im Moment passiert es nicht mehr, keine Ahnung, warum.

Spontan würde ich mal auf sowas tippen
Leider tut das nicht. Er sagt: Unknown parameter: power_method. Aber die Methode über sysfsutils genügt mir.

Wenn Debian CONFIG_ACPI_PROCFS nicht aktiviert hat, dann sind die Dateien nicht mehr vorhanden.
Die Konfig des Kernels sagt "CONFIG_ACPI_PROCFS is not set", im Gegensatz zum alten Kernel.

Gut, wenn es Deprecated ist, dann soll das so sein. Nur: wie bekomme ich meine Verbrauchswerte?

MfG Dalai
 
Nur: wie bekomme ich meine Verbrauchswerte?
Gerät kaufen, das zwischen PC und Steckdose stecken und messen lassen.
Ist ohnehin die einzige wirklich brauchbare Methode (insofern das Gerät natürlich keinen Mist misst). Das was ACPI ausgibt ist nur eine Schätzung, hab da so meine Zweifel, dass man darauf vertrauen kann.
 
Gerät kaufen, das zwischen PC und Steckdose stecken und messen lassen.
Bei nem Laptop auf Akkubetrieb :]. Die Werte von ACPI auf dem Gerät passen schon, sofern es denn mal funktioniert - in der derzeitigen Konfig eben nicht. Klar ist es nur eine Schätzung, genau wie die Angabe der Restlaufzeit, aber haben will ich sie! Unter Windows geht sie, unter Ubuntu, mit dem alten Debian-Kernel ebenfalls, also muss das lösbar sein. Um das noch etwas klarer zu machen: ich will mich nicht an die Verbrauchswerte festnageln, aber die sind die Voraussetzung für irgendeine Akkurestlaufzeit.

MfG Dalai
 
Zurück
Oben Unten