Arch Linux

ACPI C3-State fehlt

fs4000

Hallo,

ich hab mir ja vor kurzem ein Laptop gekauft. Der Intel Pentium Dual-Core T2330 unterstützt eigentlich 3 C-States, mit einem aktuellen Kernel (Vanilla und mit Arch-Patches) zeigt er aber nur 2 an. Mit allen älteren Live-CDs, die bei mir so rumliegen, funktioniert der C3 aber.
Z.B. mit Gentoo, Kernel 2.6.18 (Sabayon)

Ich würde doch jetzt gerne mal testen, ob das wirklich am Linux-Kernel liegt. Deshalb möchte ich einen Vanilla-Kernel Version 2.6.18 kompilieren, nur hab ich da recht wenig Erfahrung, wie ich den Konfigurieren muss. Normal hab ich ja die Konfiguration von Arch, aber die wird auf sowas altes wohl nicht passen. Oder hat jemand noch eine andere Idee, wie ich diesem Phänomen auf die Spur kommen könnte? Kann es vll. an der Konfiguration selbst liegen?

Schon mal vielen Dank für jeden Tipp.

GerBra

Ohne mit den neuen CPUs/Cores sehr viel Erfahrung zu haben, aber sind da wirklich
nicht mehr C-States zu finden?

Wieviele und wie oft genutzt kannst du z.B. mit:
cat /proc/acpi/processor/CPU/power
rauskriegen (CPU ist bei dir dann wohl CPU0 und CPU1)
max_cstate: C8 sollte dir dann die Anzahl anzeigen.
Nützlich ist auch das Tool acpitool, was dann über:
acpitool -c
die Verteilung auf die einzelnen States anzeigt.

Werden diese C-States denn bei den Dual-Cores noch genutzt? Oder wird das alles evtl.
über die cpufreq-Module geregelt, wo ja noch wichtig ist das alle Cores berücksichtigt
werden?

fs4000

Ein Core 2 Duo hätte natürlich mindestens auch den C4, die ganz neuen sogar C6. Aber ich habe ja "nur" einen Pentium Dual-Core.
Also eigentlich passt ja alles, nur wird der C3 einfach nicht erkannt. Das beginnt schon in den Bootmeldungen: nur C1 und C2 werden aufgelistet.

Mit cpufreq hat das ganze, soweit ich weiß, nichts zu tun. Die CPUs können auch unabhängig voneinander die C-States wechseln.

acpitool sagt, dass beide CPUs 3 C-States haben, allerdings zählt das den C0 mit. Prozessor 0 ist 90% in C2, Prozessor 1 zu 50%.

Wenn Windows XP oder eben das alte Sabayon läuft, dann springt der Lüfter sogut wie nie an, während er bei Arch immer wieder mal kurz läuft. Der Energieverbrauch ist so auch 1 bis 2 Watt geringer.

Jetzt habe ich noch Ubuntu gestestet:
5.10 mit Kernel 2.6.12: C3 geht
7.10 mit Kernel 2.6.20: C3 geht nicht

Also liegt es doch relativ sicher am Kernel selbst. Aber was soll man da tun? Ich bin kein Kernel-Entwickler.

Eines ist mir noch aufgefallen: Die C2-Latency von den neuen Kerneln entspricht nicht dem der alten Kernel, sondern dem des C3. Aber dieser C2 ist nicht der C3! Also irgendwas scheint da total verdreht zu werden.

fs4000

Noch was interessantes:
Nach einem Suspend to RAM scheint der C3 genutzt zu werden, auch wenn das System weiterhin nur bis C2 anzeigt.
Wenn man dann noch einen Suspend to Disk macht, ist der Effekt wieder weg.

fs4000

So jetzt hab ich einige alte Vanilla-Kernel einfach mit der Default-Konfiguration durchgetestet:
2.6.18.8 (letzte der 2.6.18-Reihe)
2.6.19 bis 2.6.19.2 lassen sich seltsamerweise nicht fertigkompilieren.
2.6.19.3

Nach einem Suspend to RAM im Arch-Kernel läuft die CPU fast zu 100% im C2 und braucht ca soviel Strom wie unter Windows. Bei meinem 2.6.19.3 geht das irgendwie nicht, jedoch funktioniert die Konsole nach dem Suspend noch. (Bei dem Arch-Kernel ist die danach nur noch schwarz.)

Das ist doch definitiv ein Kernel-Bug oder?

Tribaltrouble

Hallo,
ich habe einen Core 2 Duo CPU T7500.
acpitool -c gibt bei mir unter Anderem folgendes aus (2.6.24-ARCH):

Freq. scaling driver : acpi-cpufreq
# of CPU's found : 2

Processor ID : 0
Usage of state C1 : 2824 (0.1 %)
Usage of state C2 : 182055 (3.7 %)
Usage of state C3 : 4677520 (96.2 %)

Processor ID : 1
Usage of state C1 : 11421 (0.1 %)
Usage of state C2 : 309340 (3.2 %)
Usage of state C3 : 4713909 (48.5 %)

fs4000

Ehrlichgesagt, so hab ichs vermutet. Der Core 2 Duo hat 4 C-States (ohne C0), also fehlt auch einer. Und ebenfalls dieses Phänomen, dass der 2. Core nur 50% im Energiesparmodus ist.
Ich hab den Kernel-Bugtracker schon mal grob durchsucht, aber keinen entsprechenden Eintrag gefunden. Ich denke man sollte diesen Bug melden. In alten Kernel-Versionen läufts ja schließlich auch und es verlängert die Akkulaufzeit doch nicht ganz unerheblich.

fs4000

@Tribaltrouble:
Könntest du auch mal die Ausgabe von

cat /proc/acpi/processor/*/power

posten? Und was sagt acpitool denn bei Active C-state?
Ausgabe bei mir mit Arch-Kernel 2.6.24:

  Active C-state         : C0
  C-states (incl. C0)    : 3
  Usage of state C1      : 4351 (1.6 %)
  Usage of state C2      : 268493 (98.4 %)

  Active C-state         : C0
  C-states (incl. C0)    : 3
  Usage of state C1      : 2277 (0.4 %)
  Usage of state C2      : 270667 (50.0 %)

und mit Kernel 2.6.18.8:

  Active C-state         : C3
  C-states (incl. C0)    : 3
  Usage of state C1      : 60 (0.2 %)
  Usage of state C2      : 39778 (99.8 %)

  Active C-state         : C3
  C-states (incl. C0)    : 3
  Usage of state C1      : 128 (0.2 %)
  Usage of state C2      : 75167 (99.8 %)

Hier erkennt acpitool nur C1 und C2. C3 ist aber aktiv und wird laut powertop fast ständig genutzt.

Tribaltrouble

Hallo seht interessant,

cat /proc/acpi/processor/*/power etwas gekürzt damit es übersichtilcher bleibt

active state: C0
max_cstate: C8
bus master activity: 00000000
maximum allowed latency: 6666 usec
states:
C1: type[C1] latency[001] usage[00000198] duration[00000000000000000000]
C2: type[C2] latency[001] usage[00014569] duration[00000000000009791617]
C3: type[C3] latency[057] usage[00196570] duration[00000000000891502110]
active state: C0
max_cstate: C8
bus master activity: 00000000
maximum allowed latency: 6666 usec
states:
C1: type[C1] latency[001] usage[00000389] duration[00000000000000000000]
C2: type[C2] latency[001] usage[00013791] duration[00000000000013208991]
C3: type[C3] latency[057] usage[00201254] duration[00000000000954976711]

acpitool -c

Active C-state : C0
C-states (incl. C0) : 4

fs4000

Noch zwei Fragen:
Du hast nicht rein zufällig auch den Intel GM965 oder PM965 Chipsatz? Der scheint mitunter ein Auslöser für das Problem zu sein.
Und bringt

dmesg | grep -i compal

eine Ausgabe? Dann könnte man evtl. auf eine defekte ACPI-Implementierung des BIOS schließen.
Ich werde mal einen Bugreport einreichen.

Tribaltrouble

Hallo,
ich hab zwar einen PM965 Chipsatz aber da Macbook ein Extensible Firmware Interface.
Eine Fehlermeldung bekomme ich nicht. Meine Akkulaufzeit ist unter
Linux am schlechtesten.

Grüße Tribaltrouble

fs4000

OK, dann ist es wohl der Chipsatz. Ich hoff mal, dass das in zukünftigen Kerneln dann auch behoben werden kann. C-States sind einfach sehr wichtig für geringen Stromverbrauch.

fs4000

So Bugreport ist eingetragen: http://bugzilla.kernel.org/show_bug.cgi?id=10807
Mal schauen, was passiert.

fs4000

Es ist doch ein BIOS-Bug, MONITOR/MWAIT ist defekt. Nun wird es auf diesen Systemen deaktiviert.

Tribaltrouble

Warum hab ich dann auch das Problem mit einem Macbook?
Ich kann das leider nicht ganz nachvollziehen unter http://bugzilla.kernel.org.

Wie kann ich schauen ob es bei mir auch am Mwait liegt ?

fs4000

Der Patch scheint auch einen neuen Kernel-Parameter einzuführen, mit dem man Mwait deaktivieren kann, einfach mal testen. Ansonsten gibts vll im Setup des Rechners, wie auch immer das bei EFI aussieht, eine Option für die tiefen C-States.
Teilweise wird der C4 aber auch mit dem C3 gemappt, dann entscheidet irgendwas anderes zwischen C3 und C4 (nicht das OS). Vll. hast du dann einfach zu viele Wakeups oder andere Hardware, die mit Linux mehr Strom braucht (v.a. Grafikchips). Da musst du mal schauen, wie man da die Energiespartechnik in Gang setzt.

Tribaltrouble

Kannst du mir kurz schreiben wie ich den Kernel Patche?
Ich kenn mich da nicht so gut aus unter Linux.
Woher kommt dann die ungleichmäßige Verteilung vom C3 state?

fs4000

Das ist durch den Patch auch weg. Scheinbar liegt es auch an MWAIT. Alles was immer noch nicht geht, ist die Angabe des aktuellen Zustands, das ist immer C0.
Ich habe bisher nur ein Kernel-Image gebaut, keine Module. Zum Testen des Patches hat es gereicht.
Dazu brauchst du erstmal die Kernel-Sources von http://www.kernel.org/
Das ganze dann entpacken, den Patch dazu reinkopieren, mit "patch -Np1 -i process_idle.patch" patchen und mit "make xconfig" die Konfiguration erstellen (am Besten den ondemand-governor und Tickless idle aktivieren). Dann kann man mit "make -j2 bzImage" ein Kernel-Image bauen (dauert etwa 5 Minuten). Zum Schluss steht dann in der Nähe von "bzimage ready" der Pfad zum Image, das packts du an einen einfach erreichbaren Ort. Um den Kernel jetzt zu starten, musst du in Grub die E-Taste drücken, einmal Cursor nach unten und nochmal E. Jetzt den Pfad zum Kernel anpassen, mit Return bestätigen und B drücken.
Das System wird zwar viele Fehler wegen fehlender Module anzeigen, das kann man aber erstmal ignorieren. Es fehlen nur die Treiber für Sound, Netzwerk usw.
Wenns Probleme gibt, frag einfach morgen nochmal nach.