Arch Linux

[systemd] Autostart-Skripts läuft seit Update nicht mehr

Tersus

Guten Abend,

mein Skript funktioniert beim Starten nicht mehr. Die Datei "/usr/lib/systemd/system/acpi_cpufrequenz.service" ist unverändert und hat die richtigen Rechte, gleiches gilt für die Datei "/usr/lib/systemd/scripts/acpi_cpufrequenz", auf welche der Service verweist.

Wenn ich letztere Datei ausführe, wird auch alles korrekt abgearbeitet, nur eben beim Starten nicht mehr ... Woran kann das liegen?

Inhalt des Skripts:

#!/bin/bash

lsmod | grep -q '^acpi_cpufreq ' \
&& cpupower frequency-set -g $([ "$(acpi -a)" == "Adapter 0: on-line" ] && echo performance || echo powersave)

Tersus

Das Problem ist wohl, dass der Dienst "/usr/lib/systemd/system/acpi_cpufrequenz.service" vor dem Dienst "/usr/lib/systemd/system/cpupower.service" ausgeführt wird und daher die Ausgabe im Skript "lsmod | grep -q '^acpi_cpufreq ' \" falsch wird ...

Wie kann ich eine Abhängigkeit zwischen den Diensten herstellen? Ich habe den Inhalt von "/usr/lib/systemd/system/acpi_cpufrequenz.service" unter "[unit]" schon auf "Wants=cpupower.service" gesetzt, aber ohne Erfolg.

fs4000

Wozu überhaupt das Ganze? Powersave spart keine Energie und Performance macht den Rechner nicht schneller. Es hat schon seinen Grund, warum gerade Ondemand der Standard ist.

Creshal

Genau genommen sind alle drei sinnlos und es wird gerade ein gescheiter Treiber eingebaut.

fs4000

Ja, bei Intel CPUs seit Nehalem ist ondemand nicht mehr optimal, da die Frequenz im Idle-Zustand egal ist. Die CPU ist in diesem Zustand sowieso stromlos. Weil das früher aber nicht so war, weckt ondemand die Kerne unnötig auf. Außerdem ist ACPI ziemlich lahm, weshalb ein komplett neuer Treiber entwickelt wurde, der direkt in die CPU-Register schreibt. Das Ding ist fest im Kernel und übernimmt bei Ivy Bridge CPUs automatisch die Kontrolle. Ältere Generationen werden in der nächsten Version kommen.

https://plus.google.com/117091380454742934025/posts/2vEekAsG2QT

badboy

Hm, das würde einiges erklären, sofern es in 3.9 schon drin ist. "cpufreq" meint dort, meine CPU könnte bis 3 Ghz takten und "ondemand" kann nicht geladen werden (allerdings steigt auch der Stromverbrauch rasant an). Ich muss das ganze nochmal genauer verfolgen.

fs4000

Ja, für Ivy Bridge ist der neue Treiber seit 3.9 aktiv. Es gibt aber scheinbar auch ein Problem seit 3.9.2: https://bugzilla.kernel.org/show_bug.cgi?id=58801

Man sollte da aber auch etwas vorsichtig sein, nur weil der Takt hoch bleibt, heißt das ja noch nicht, dass die Energieaufnahme höher ist. Je weiter die Stromaufnahme der CPU im Leerlauf gesenkt wird, desto weniger macht es Sinn, den Takt zu senken, außer bei einem Cache-Miss, weil der Speicherzugriff durch einen höheren Takt nicht schneller wird. Vor allem Interrupt-Handler sind davon betroffen.

Tersus

Eingabe:

watch grep \"cpu MHz\" /proc/cpuinfo

Powersave
Ausgabe:

cpu MHz         : 1000.000
cpu MHz         : 1000.000
cpu MHz         : 1000.000
cpu MHz         : 1000.000

Performance
Ausgabe:

cpu MHz         : 1667.000
cpu MHz         : 1667.000
cpu MHz         : 1667.000
cpu MHz         : 1667.000

ZVE: Intel Atom N570

Auch wenn Du schriebst, dass Taktraten nichts über den reellen Verbrauch aussagen müssen, so sind die vom System berechneten theoretischen Laufzeiten abhängig von den Modi nicht unerheblich unterschiedlich.

Also bitte ich noch einmal um Hilfe für mein in den ersten zwei Beiträgen geschildertes Problem, ungeachtet von vermeintlich fragwürdiger Effizienz.

fs4000

Prüfe die Laufzeit mal mit Ondemand. Die sollte in etwa der von Powersave entsprechen bei voller Leistungsfähigkeit. Powersave macht keinen Sinn, solange du die CPU nicht total auslastest und trotzdem maximale Laufzeit willst.

Tersus

Der Unterschied zwischen Ondemand und Powersave liegt bei ca. 15min-20min.

Ich habe den Vergleich mittels eines im Hintergrund laufenden Videos gemacht.

Im Leerlauf sind es wenige Minuten.

Wenn ich mir mit "watch grep \"cpu MHz\" /proc/cpuinfo" die ZVE im Leerlauf unter Ondemand anschaue, dann ist die Anwendung die vier (Pseudo)Kerne ständig am Hoch- und Runtertakten ... . Ich weiß nicht, ob das sinnvoll ist.

fs4000

Tersus schriebDer Unterschied zwischen Ondemand und Powersave liegt bei ca. 15min-20min.

Das ist jetzt doch irgendwie nicht ganz unerheblich. Wie lang ist denn die gesamte Laufzeit?

Wozu startest du cpupower.service überhaupt? Das brauchst du doch nicht.

Tersus

Weil ich nicht weiß, wie ich den ZVE-Takt ohne dieses Werkzeug ändere.

Wo kann ich nachsehen, ob meine ZVE bereits von der neuen automatischen ZVE-Taktänderung des Kernels 3.9 unterstützt wird?

EDIT:

Unter Windwos 7 habe ich 8 Stunden Laufzeit und während dessen arbeite ich! Unter Arch Linux sind es max. 5 Stunden ...

fs4000

Wahrscheinlich hast du cpupower.service nicht mal aktiviert, was ist denn der Status davon? Gestoppt ist richtig. Wenns nicht läuft, kanns auch nicht der Grund sein, dass es nicht mehr geht.

Ich denke, das eindeutigste Zeichen, gegen intel_pstate ist ein geladener acpi_cpufreq in lsmod. Es kann nur einer aktiv sein.

Wenn Windows 3 Stunden länger läuft, dann liegt das sicher nicht an Ondemand. Du hast wahrscheinlich falsche Einstellungen fürs S-ATA ALPM und PCIe ASPM. Soundkarte, Grafik und Festplatte sind womöglich auch nicht auf energiesparend gestellt. Powertop sagt dir, was alles falsch ist.

Tersus

Der Status von cpupower ist "active (exited)".

"acpi_cpufreq" läuft. Wie kann ich es abstellen und auf "intel_pstate" umstellen? Powertop zeigt mir eine Menge Hardware-Elemente an mit der Bemerkung "schlecht" und ich solle Energiesparmodis aktivieren ...

fs4000

Tersus schrieb"acpi_cpufreq" läuft. Wie kann ich es abstellen und auf "intel_pstate" umstellen?

Kann man nicht, der Treiber ist momentan nur für IvyBridge. Ich wage auch zu bezweifeln, dass der bei dem alten Atom etwas verbessern könnte.
Wegen weiteren Maßnahmen kannst du dich hier im Forum, im Wiki oder generell im Internet umsehen.

Tersus

Nach einigen Versuchen mit "powertop" bin ich zu dem Schluss gekommen, dass "powersave" nicht bedeutend viel bringt. Die Leistungsaufnahme nimmt sich in beiden Modi (powersave und ondemand) nicht sonderlich viel.

Dennoch interessiert mich das Problem, warum mein Boot-Skript nicht läuft, nach wie vor!

Ich habe das Skript mal beschnitten, um es einfach zu halten.

more /usr/lib/systemd/scripts/acpi_cpufrequenz

#!/bin/bash

echo "wird ausgeführt" > $HOME/a.txt

cpupower frequency-set -g powersave

Die Datei wird erfolgreich angelegt, aber der Befehl "cpupower frequency-set -g powersave" wird ignoriert.

more /usr/lib/systemd/system/acpi_cpufrequenz.service

[Unit]
Discription=Regelt die ZVE-Frequenz nach dem Booten

[Service]
Type=oneshot
ExecStart=/usr/lib/systemd/scripts/acpi_cpufrequenz

[Install]
WantedBy=multi-user.target

sudo systemctl status acpi_cpufrequenz.service

acpi_cpufrequenz.service
   Loaded: loaded (/usr/lib/systemd/system/acpi_cpufrequenz.service; enabled)
   Active: failed (Result: exit-code) since Di 2013-06-04 12:40:31 CEST; 8min ago
  Process: 154 ExecStart=/usr/lib/systemd/scripts/acpi_cpufrequenz (code=exited, status=237)

badboy

Weil vielleicht die entsprechenden Dateipfade zum Zeitpunkt der Ausführung noch nicht da sind? z.B. "/sys/devices/system/cpu/cpu0/cpufreq/"

nik

fs4000 schriebKann man nicht, der Treiber ist momentan nur für IvyBridge.

Sicher, dass die nicht auch mit SandyBridge laufen würden?

fs4000

Würden schon, aber AFAIK nicht mit Linux 3.9 sondern erst ab 3.10.

Und das ist dann wieder dieser Moment, in dem es schade ist, dass wir kein Repo mit Linux 3.10-rc4 haben.

nik

Wenn ich die Erklärungen unter https://plus.google.com/117091380454742934025/posts/2vEekAsG2QT richtig verstehe, funktioniert es zumindest mit der SandyBridge schon mit Kernel 3.9.

the 3.9/3.10-rc1 code right now only supports SNB cpus, but the CPU ID of IVB is about to added as well.

Hier steht es ja auch noch mal: https://wiki.archlinux.org/index.php/Cpupower#CPU_frequency_driver
Hätt ich lieber gleich mal ins Wiki geschaut -_-

Also spielt es eigentlich überhaupt keine Rolle, ob nun cpupower läuft oder nicht, solange der pstate-Treiber geladen wird, solange man den beim Booten nicht blacklistet?

Nächste Seite »