GentooForum.de

Hallo Gentoo Freunde,

ich hab wirklich ein etwas seltsames Phänomen:

Ich besitze einen HP 6715b. Dort ist ein AMD Turion 64 X2 mit einer ATI X1250 verbaut.
Als Kernel betreibe ich ein 64 bit 2.6.23 Kernel.
Der Rechner läuft sehr gut. Das einzige Problem ist, daß er meiner Meinung nach etwas viel Strom brauch (knapp 18 W mit Akku (gemessen mit Powertop), mit Stromversorgung 23 W(gemessen mit Strommessgerät)).
Wenn ich ihn jedoch aus einem Suspend to Ram aufwecke, dann sinkt der Stromverbrauch um 3 W. Das ist auch der Stromverbrauch, den ich erwartet habe.
Mache ich ein Suspend to Disk oder Neustart, ist er wieder bei 18 W.
Ich hab schon mit powertop und mit top versucht, den Stromverschwender ausfindig zu machen, doch sehe ich hier keinen Unterschied vor und nach einem Suspend.
Auch hab ich die Liste der geladenen Module verglichen, doch auch die ist identisch vor und nach einem suspend to ram.

Der geringer Stromverbrauch hat neben der längeren Akku Laufzeit (ca. 0,75 h mehr) auch den positiven Effekt, daß der Lüfter seltener anspringt.
Hat jemand ein ähnliches Problem bzw. eine Idee, wie ich den Stromverschwender ausfindig mache kann.

Danke für die schnelle Antwort.
Das ist wirklich eine gute Idee, aber auch eine ziemliche Sisyphusarbeit:
leider läßt sich /sys und /proc nicht vollständig mit cp kopieren. Einige Dateien, bspw. /proc/kcore wollen nicht kopiert werden (lassen sich nur mit less /proc/kcore > kcore.txt kopieren). Gibt es da noch einen Weg, /proc und /sys vollständig zu kopieren.
Eine andere Idee ist mir noch gekommen.
Ein möglicher Verdächtiger dieses Problems könnte der Grafikchip sein: dieser hängt bei HP Laptops mit der CPU an einer Heatsink, würde also bei hoher Last die CPU mit aufheizen und zu hohem Stromverbrauch und ständigem Anlaufen des Lüfters führen. Bei der miesen Implementierung des propritären Treibers von ATI würde mir solch seltsames Verhalten nicht wundern.
Ich werde mal auch in die Richtung forschen.

Hallo,

ja ich benutze den propritären ATI Treiber. Jetzt nachdem ATI die die Spezifikation offengelegt hat, hoffe ich, daß es blad einen freedesktop Treiber gibt.
Mit den Powerstates habe ich auch schon rumgespielt, bringen aber nichts (2 Mögliche Powerstates gibts bei der X1250).
Der Powerstate nach dem Aufwachen ist der gleiche wie vorher.
Hab jetzt auch noch verschiedene Module ge- und entladen, mit hdparm den Durchsatz der Festplatte getestet (vielleich Chipsatz runtergetakten) und den Kernel mit verschiedenen Einstellungen dir mir eingefallen sind gebaut. Ich hab nichts gefunden und werde warten, bis der 2.6.24 in den stable tree kommt
Zum Thema geschwafel über miese Implementierung:
wenn ATI sich schon herab läßt, Treiber für Linux zu bauen, dann bitte schön stabil:

ATI- Treiber 8.40.4 -> schwarzer Bildschirm nach aufwachen, keine Tastatureingabe mehr möglich
ATI-Treiber 8.443.1-r1 -> lief zur Abwechslung tadellos
ATI-Treiber 8.455.2-r1 -> fgl_fglxgears zeigt in der 64 bit Version nur Artefakte, wenn man Glück hat kann man es noch beenden, bevor der Rechner sich vollständig weghängt (soll man beheben können, indem man die virtuelle Bildschirmgröße auf eine durch 64 teilbare Größe einstellt, hat aber bei mir nicht geholfen)

Mein per reverse engineering von xorg nachgebauter ATI Treiber für meine Radeon 9000 läuft bspw. schon seit Jahren stabil.

Hallo,

ich hab jetzt den 2.6.24 ausprobiert, dort aber das gleiche Verhalten festgestellt.
Neben der Möglichkeit, daß es sich um ein Softwareproblem handelt, ziehe ich auch langsam die Möglichkeit eines Hardwareproblems in Betracht.
Ich hab zwar versucht, das BIOS zu flashen (ein update des Video BIOS war auch enthalten, ich habe den Eindruck, daß das Problem irgendwie mit dem ATI Chip zu tun hat). Aber das hat nicht funktioniert.
An der Stelle ein Hinweis für Besitzer eines HP 6715b: NICHT das auf der HP Seite zur Verfügung gestellte BIOS F.0B einspielen: euer Rechner ist danach quasi tot und läßt sich nur noch umständlich zum Leben erwecken.

Achja zum Thema ATI Treiber: der neue ATI Treiber (8.471.3) geht wieder prima.

Hallo,

zuerst nochmal Danke an alle, die sich an der Diskussion hier beteiligen. So hat man nicht das Gefühl allein mit seinem Problem zu sein.
Die Sache ist ja doch sehr speziell.

Den Vergleich hab ich gemacht und einige Unterschiede gefunden:
/sys/devices/system/node/node0/numastat -> hier sind numa_hit,interleave_hit und local_node unterschiedlich
/sys/kernel/uevent_seqnum
/sys/slab -> sehr viele Unterschiede
/proc/bus/pci/00/*

Doch das sind alles Dateien die sich meiner Meinung nach bei jedem Neustart ändern.

Ich hab den Vergleich manuell(sehr aufwendig und nicht vollständig sondern stichpunktartig), mit diff und mit dem mc gemacht. Bei diff und mc ist das Problem, daß diese im rekursiven Modus auch rekursive Schleifen (Unterverzeichnis mit Link auf übergeordneten Verzeichnis) als Unterschied melden.
Darum sind die oben ermittelten Unterschiede nicht vollständig.

Ich hab auch mal das neueste Knoppix mit 2.6.24 Kernel (32 bit) ausprobiert. Dort ist nach Start der gleiche (hohe) Stromverbrauch, wie unter Gentoo nach einem Neustart oder Suspend to disk.

Hallo,

danke das du dich gemeldet hast. Das dieses Phänomen mit einem anderen HP Notebook auftritt hilft mir schonmal weiter.
Die Grafik ist damit wirklich aus dem Rennen.
Ich hatte zuletzt nur noch die CPU bzw. das APIC, welches für die Steuerung der beiden Cores zuständig ist in Betracht gezogen. Starte ich den Rechner mit nolapic (ich schalte sozusagen den zweiten Kern ab) verbraucht er auch viel weniger (ca. 1 W weniger als nach einem S2Ram, was aber durch einen Kern weniger zu erklären wäre).
Da bei dir das gleiche Problem ist, kann es zwar immer noch am APIC liegen, nicht aber an der AMD CPU, die bei mir werkelt.
Das APIC Problem läßt sich meist auf das BIOS zurückführen.
Leider ist HP zu dämlich (anders kann man es leider nicht ausdrücken) ein funktionierendes neues BIOS für den 6715b rauszugeben, so daß ich hier noch keine neue BIOS Version probieren konnte (ja doch hab ich, BIOS F.0B, danach war mein Rechner tot, weil HP ein fehlerhaftes BIOS ausgeliefert hat, mittlerweile wieder diese Version aber zurückgezogen hat).
Halten wir also fest: das Problem ist wahrs. die APIC Implementation des BIOS, bzw. die Interpretation des APIC durch Linux bei Mehrkernprozessoren mancher HP Notebooks unabhängig von CPU und Chipsatz (intel oder AMD).