HD4250: Monitor ausschalten => ca.50W weniger Verbrauch!

niethitwo

Fleet Captain Special
Mitglied seit
16.08.2009
Beiträge
266
Renomée
7
Hallo,

habe ein Gigabyte GA-880GMA-UD2H mit einer HD4250 onBoard.

Das ganze läuft mit dem freien radeon Treiber unter Gentoo Linux amd 64, kernel 2.6.36-r5, DRI fest reinkompiliert.

Zusammen mit einem Plextor IDE Brenner, einer WD Caviar Blue 1TB, 2x4GB 1.5V ADATA RAM 1333MHz und einem Athlon X4 640@3GHz,1.275V verbraucht der PC im Leerlauf ca. 90-105W, unter Last geht er auf ca. 115W hoch...selten höher.

Als Netzteil ist ein Enermax LibertyEcoII 400W verbaut.


Ehrlich gesagt hatte ich mit einem niedrigeren Idle-Verbrauch um die 70W gerechnet.
Was mich erst recht stutzig macht:


Sobald ich den Monitor ausschalt oder die Graka nach einiger Zeit den Monitorausgang abschaltet, verbraucht der PC nur noch 46W! :o

In meiner xorg.conf sind eingetragen:
Code:
section "Device"
        Identifier  "Videocard0"
        Driver      "radeon"
        VendorName  "ATI"
        BoardName   "Radenon HD4250"
        Option      "DynamicClocks" "on"
        #Option "AccelMethod" "EXA"
        Option "RenderAccel" "off
        Option "ClockGating" "on"
        Option "ForceLowPowerMode" "on"
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Videocard0"
        Monitor    "Monitor0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24
                Modes    "1920x1200"
        EndSubSection
EndSection

Section "DRI"
Group        0
Mode         0666
EndSection

Wenn ich auf dem Mainboard die Karte auf 200MHz fix runtertakte, passiert am Stromverbrauch rein gar nichts.

In der Log:
Code:
(WW) RADEON(0): Option "DynamicClocks" is not used


Jemand ne Idee, was hier schief läuft?

Kann doch nicht sein, dass ne IGP mit v.. 10-20W TDP ganze 50W frisst, selbst mit Zusatzmainboardbeschaltungen 8-(


Viele Grüße,
niethitwo
 
Zuletzt bearbeitet:
Hast Du die xorg.conf für diesen Post kopiert oder abgetippt? Sind nämlich zwei Vertipper drin, einmal steht da "Radenon" und außerdem fehlt ein Anführungszeichen hinter Option "RenderAccel" "off_
Keine Ahnung, ob das was ausmacht *noahnung*
 
Hast Du die xorg.conf für diesen Post kopiert oder abgetippt? Sind nämlich zwei Vertipper drin, einmal steht da "Radenon" und außerdem fehlt ein Anführungszeichen hinter Option "RenderAccel" "off_
Keine Ahnung, ob das was ausmacht *noahnung*

Das Radenon stört nicht, über das fehlende Anführungszeichen sollte er aber stolpern.

niethitwo:
Mach mal bitte ein "cat /sys/class/drm/card0/device/power_method" und ein "cat /sys/class/drm/card0/device/power_profile" in einer console (unter X),und zeig mal die Ausgabe.
 
bei /sys/class/drm/card0/device/
hoerts bei mir auf:
Code:
ls /sys/class/drm/card0/device/
insgesamt 0
-r--r--r-- 1 root root 4,0K 25. Jan 17:27 boot_vga
-rw-r--r-- 1 root root 4,0K 25. Jan 21:20 broken_parity_status
-r--r--r-- 1 root root 4,0K 25. Jan 17:27 class                                                          
-rw-r--r-- 1 root root  256 25. Jan 17:27 config                                                         
-r--r--r-- 1 root root 4,0K 25. Jan 21:20 consistent_dma_mask_bits                                       
-r--r--r-- 1 root root 4,0K 25. Jan 17:27 device                                                         
-r--r--r-- 1 root root 4,0K 25. Jan 21:20 dma_mask_bits                                                  
drwxr-xr-x 3 root root    0 25. Jan 17:27 drm                                                            
-rw------- 1 root root 4,0K 25. Jan 17:27 enable                                                         
-r--r--r-- 1 root root 4,0K 25. Jan 21:20 irq                                                            
-r--r--r-- 1 root root 4,0K 25. Jan 21:20 local_cpulist                                                  
-r--r--r-- 1 root root 4,0K 25. Jan 21:20 local_cpus                                                     
-r--r--r-- 1 root root 4,0K 25. Jan 21:20 modalias                                                       
-rw-r--r-- 1 root root 4,0K 25. Jan 21:20 msi_bus                                                        
-r--r--r-- 1 root root 4,0K 25. Jan 21:20 numa_node                                                      
drwxr-xr-x 2 root root    0 25. Jan 21:20 power                                                          
--w--w---- 1 root root 4,0K 25. Jan 21:20 remove                                                         
--w--w---- 1 root root 4,0K 25. Jan 21:20 rescan
--w------- 1 root root 4,0K 25. Jan 21:20 reset
-r--r--r-- 1 root root 4,0K 25. Jan 17:27 resource
-rw------- 1 root root 256M 25. Jan 21:20 resource0
-rw------- 1 root root 256M 25. Jan 17:27 resource0_wc
-rw------- 1 root root  256 25. Jan 21:20 resource1
-rw------- 1 root root  64K 25. Jan 17:27 resource2
-rw------- 1 root root 1,0M 25. Jan 21:20 resource5
-r-------- 1 root root 128K 25. Jan 21:20 rom
lrwxrwxrwx 1 root root    0 25. Jan 17:27 subsystem -> ../../../../bus/pci
-r--r--r-- 1 root root 4,0K 25. Jan 17:27 subsystem_device
-r--r--r-- 1 root root 4,0K 25. Jan 17:27 subsystem_vendor
-rw-r--r-- 1 root root 4,0K 25. Jan 21:20 uevent
-r--r--r-- 1 root root 4,0K 25. Jan 17:27 vendor

und unter Power:

Code:
ls /sys/class/drm/card0/device/power/
insgesamt 0
-rw-r--r-- 1 root root 4,0K 25. Jan 21:22 wakeup
-r--r--r-- 1 root root 4,0K 25. Jan 21:22 wakeup_count



Das gefixte Anfuehrungszeichen aendert leider nichts, er hat sich ja auch nicht beschwert.
 
Ok, dann hat der 2.6.36er Kernel die entsprechenden Updates fürs Power Management für r600 und danach noch nicht enthalten. Ich dachte zwar, dem wäre so. Aber offenbar irre ich mich hier. Da wundert es mich aber, dass der Stromverbrauch bei abgeschalteten Monitor runter geht. Du könntest den 2.6.37er Kernel probieren. Da müssen die genannten Einträge unter /sys vorhanden sein.
 
Die IGP nutzt doch den RAM? Dann verhindert sie wahrscheinlich, dass sich der Prozessor in den idle Modus schaltet, deswegen der große Unterschied beim off, da geht der Prozessor dann endlich mit schlafen.
 
Du hast nicht dummerweise doch das Meßgerät am PC und Monitor, also vor dem Verteiler?
Ich lache dich damit nicht aus, sowas passiert mir auch manchmal. ;)

Was ist für dich "Last"? Ist es z.B. Prime95 auf allen Kernen oder nur solala mal drauf geschaut?

@Desti
Man hat ständig irgendwelche Zugriffe auf den Ram. Wenn das so wäre, oder gar die Grafikeinheit, würde CnQ eine Totgeburt per Definition sein.

Grundsätzlich denke ich aber auch, dass der Prozessor sich nicht schlafen legt, als erster Schuß ins Blaue. (Bitte dazu die Frage zu prime95 beantworten)
Was sagen die Module zu cpufreq / powernowd-k8 bzw. ist der korrekte governor eingestellt?
(bei Debian und Arch wird das so eingestellt, Gentoo kenne ich nicht)

MfG Micha
.
EDIT :
.

Scheint auch mit powernowd-k8 und cpufrequtils zu laufen bei Gentoo
http://www.gentoo.org/doc/en/power-management-guide.xml

Im Bios ist auch alles auf Standard oder Auto, CnQ ist aktiviert und du hast nichts auf Manuell festgesetzt?
 
Ok, dann hat der 2.6.36er Kernel die entsprechenden Updates fürs Power Management für r600 und danach noch nicht enthalten. Ich dachte zwar, dem wäre so. Aber offenbar irre ich mich hier. Da wundert es mich aber, dass der Stromverbrauch bei abgeschalteten Monitor runter geht. Du könntest den 2.6.37er Kernel probieren. Da müssen die genannten Einträge unter /sys vorhanden sein.
Unter 2.6.37 sind sie auf jeden Fall vorhanden. Wenn mich git nicht täuscht, dann sollte das aber auch mit 2.6.36 gehen.

Man sollte allerdings noch erwähnen, dass man – zumindest soweit ich informiert bin – dafür KMS benötigt.
Das bedeutet, dass entweder die extra Firmware aus radeon-ucode (die glaube ich für jeden r600 oder später benötigt wird) entweder in den Kernel einkompiliert oder per initrd nachgeladen werden muss, sonst funktioniert KMS nicht.

Aus den bisherigen Angaben geht aber nicht hervor, ob KMS konfiguriert ist oder nicht.
Oder habe ich etwas übersehen?

Zum Einkompilieren benötigst du sowas:
Code:
CONFIG_EXTRA_FIRMWARE="radeon/RS780_pfp.bin radeon/RS780_me.bin radeon/R600_me.bin radeon/R600_pfp.bin radeon/R600_rlc.bin"
Hier ist R600_rlc.bin der Teil der Firmware, der nicht im Vanilla Kernel enthalten ist. Welche Teile du genau benötigst hängt aber von deiner Karte ab.
 
Zuletzt bearbeitet:
@Desti
Man hat ständig irgendwelche Zugriffe auf den Ram. Wenn das so wäre, oder gar die Grafikeinheit, würde CnQ eine Totgeburt per Definition sein.

Er hat damit aber Recht. Die Grafikkarte muss ständig auf den Speicher zugreifen, um den Scanout durchzuführen. Damit sind die Schlafphasen des Prozessors sehr verkürzt. Ich weiß zwar nicht genau wie das beim Athlon X4 so läuft, aber wenn dann jedes mal die Kerne mit aufwachen, wen die Northbridge geweckt wird, kommst du ganz schnell in diese Verbrauchsregionen.
 
Du hast nicht dummerweise doch das Meßgerät am PC und Monitor, also vor dem Verteiler?
Ich lache dich damit nicht aus, sowas passiert mir auch manchmal. ;)
Das kann ausgeschlossen werden, der hängt ganz wo anders...es ist wirklich nur das PC-Netzteil im Messgerät.


Was ist für dich "Last"? Ist es z.B. Prime95 auf allen Kernen oder nur solala mal drauf geschaut?
Last ist bei mir, wenn ich KDE o.ä. große Pakete kompiliere.
Aber es reichen auch schon kleinere...es laufen bei mir dann 6 kompilierende Prozesse, also CPU sollte immer gut zu tun haben.

Grundsätzlich denke ich aber auch, dass der Prozessor sich nicht schlafen legt, als erster Schuß ins Blaue. (Bitte dazu die Frage zu prime95 beantworten)
Was sagen die Module zu cpufreq / powernowd-k8 bzw. ist der korrekte governor eingestellt?

Im Bios ist auch alles auf Standard oder Auto, CnQ ist aktiviert und du hast nichts auf Manuell festgesetzt?

Code:
cpufreq-info 
cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Bitte melden Sie Fehler an cpufreq@vger.kernel.org.
analysiere CPU 0:
  Treiber: powernow-k8
  Folgende CPUs laufen mit der gleichen Hardware-Taktfrequenz: 0
  Die Taktfrequenz folgender CPUs werden per Software koordiniert: 0
  Maximale Dauer eines Taktfrequenzwechsels: 8.0 us.
  Hardwarebedingte Grenzen der Taktfrequenz: 800 MHz - 3.00 GHz
  mögliche Taktfrequenzen: 3.00 GHz, 2.30 GHz, 1.80 GHz, 800 MHz
  mögliche Regler: conservative, ondemand, powersave, userspace, performance
  momentane Taktik: die Frequenz soll innerhalb 800 MHz und 3.00 GHz.
                    liegen. Der Regler "ondemand" kann frei entscheiden,
                    welche Taktfrequenz innerhalb dieser Grenze verwendet wird.
  momentane Taktfrequenz ist 800 MHz  (verifiziert durch Nachfrage bei der Hardware).
analysiere CPU 1:
  Treiber: powernow-k8
  Folgende CPUs laufen mit der gleichen Hardware-Taktfrequenz: 1
  Die Taktfrequenz folgender CPUs werden per Software koordiniert: 1
  Maximale Dauer eines Taktfrequenzwechsels: 8.0 us.
  Hardwarebedingte Grenzen der Taktfrequenz: 800 MHz - 3.00 GHz
  mögliche Taktfrequenzen: 3.00 GHz, 2.30 GHz, 1.80 GHz, 800 MHz
  mögliche Regler: conservative, ondemand, powersave, userspace, performance
  momentane Taktik: die Frequenz soll innerhalb 800 MHz und 3.00 GHz.
                    liegen. Der Regler "ondemand" kann frei entscheiden,
                    welche Taktfrequenz innerhalb dieser Grenze verwendet wird.
  momentane Taktfrequenz ist 800 MHz  (verifiziert durch Nachfrage bei der Hardware).
analysiere CPU 2:
  Treiber: powernow-k8
  Folgende CPUs laufen mit der gleichen Hardware-Taktfrequenz: 2
  Die Taktfrequenz folgender CPUs werden per Software koordiniert: 2
  Maximale Dauer eines Taktfrequenzwechsels: 8.0 us.
  Hardwarebedingte Grenzen der Taktfrequenz: 800 MHz - 3.00 GHz
  mögliche Taktfrequenzen: 3.00 GHz, 2.30 GHz, 1.80 GHz, 800 MHz
  mögliche Regler: conservative, ondemand, powersave, userspace, performance
  momentane Taktik: die Frequenz soll innerhalb 800 MHz und 3.00 GHz.
                    liegen. Der Regler "ondemand" kann frei entscheiden,
                    welche Taktfrequenz innerhalb dieser Grenze verwendet wird.
  momentane Taktfrequenz ist 800 MHz  (verifiziert durch Nachfrage bei der Hardware).                    
analysiere CPU 3:                                                                                        
  Treiber: powernow-k8                                                                                   
  Folgende CPUs laufen mit der gleichen Hardware-Taktfrequenz: 3                                         
  Die Taktfrequenz folgender CPUs werden per Software koordiniert: 3                                     
  Maximale Dauer eines Taktfrequenzwechsels: 8.0 us.                                                     
  Hardwarebedingte Grenzen der Taktfrequenz: 800 MHz - 3.00 GHz                                          
  mögliche Taktfrequenzen: 3.00 GHz, 2.30 GHz, 1.80 GHz, 800 MHz                                         
  mögliche Regler: conservative, ondemand, powersave, userspace, performance                             
  momentane Taktik: die Frequenz soll innerhalb 800 MHz und 3.00 GHz.                                    
                    liegen. Der Regler "ondemand" kann frei entscheiden,                                 
                    welche Taktfrequenz innerhalb dieser Grenze verwendet wird.                          
  momentane Taktfrequenz ist 800 MHz  (verifiziert durch Nachfrage bei der Hardware).

CnQ ist im BIOS aktiviert, es ist eigtl alles auf Auto, außer die Spannung...die 1.4V die das MoBo anlegt waren mir dann doch auf Dauer etwas zu viel. hab im Moment 1.275V eingestellt.



Unter 2.6.37 sind sie auf jeden Fall vorhanden. Wenn mich git nicht täuscht, dann sollte das aber auch mit 2.6.36 gehen.
Ab 2.6.35 sagt die Treiberseite.
Man sollte allerdings noch erwähnen, dass man – zumindest soweit ich informiert bin – dafür KMS benötigt.
Das bedeutet, dass entweder die extra Firmware aus radeon-ucode (die glaube ich für jeden r600 oder später benötigt wird) entweder in den Kernel einkompiliert oder per initrd nachgeladen werden muss, sonst funktioniert KMS nicht.
radeon-ucode ist über portage installiert.

Aus den bisherigen Angaben geht aber nicht hervor, ob KMS konfiguriert ist oder nicht.
Oder habe ich etwas übersehen?
Zum Einkompilieren benötigst du sowas:
Code:
CONFIG_EXTRA_FIRMWARE="radeon/RS780_pfp.bin radeon/RS780_me.bin radeon/R600_me.bin radeon/R600_pfp.bin radeon/R600_rlc.bin"
Hier ist R600_rlc.bin der Teil der Firmware, der nicht im Vanilla Kernel enthalten ist. Welche Teile du genau benötigst hängt aber von deiner Karte ab.[/QUOTE]

Das wäre schon mal ein Anhaltspunkt,wieso es nicht tut:
Code:
cat .config | grep "CONFIG_EXTRA_FIRMWARE"
CONFIG_EXTRA_FIRMWARE=""

Code:
CONFIG_DRM=m
CONFIG_DRM_KMS_HELPER=m
CONFIG_DRM_TTM=m
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
CONFIG_DRM_RADEON=m
# CONFIG_DRM_RADEON_KMS is not set

Habs mal in der Kernelconfig aktiviert und die von dir gepostete Zeile in die CONFIG_EXTRA_FIRMWARE Variable gepackt...der Kernel kompiliert damit EDIT: nicht.
Danke schon mal dafür, das mit KMS hatte ich glatt überlesen :]

Jetzt muss ich nur noch ein anderes Problem lösen, weswegen gerade mein System mit neukompilierten Kerneln nicht mehr startet...iwie findet er die root Partition beim Initialisieren von udev nicht, aber das ist ne andere Geschichte...wohl zu viel aus dem Kernel geschmissen *lol*, dann kann ich euch berichten, ob es was geholfen hat :)


EDIT: okay, man sollte sich nochmal alles durchlesen, bevor man sagt, das etwas kompiliert wurde. Es kam zwar Status 0 in der Konsole zurück, aber diese Fehler war zu sehen:
Code:
make[1]: *** Keine Regel vorhanden, um das Target »firmware/radeon/R600_rlc.bin«, 
  benötigt von »firmware/radeon/R600_rlc.bin.gen.o«, zu erstellen.  Schluss.
make: *** [firmware] Fehler 2

EDIT2: der Pfad muss natürlich noch gesetzt werden zu /usr/lib(64)/firmware
danach hab ich nur die ...rlc.bin in die Variable geschrieben, und make firmware_install ausgeführt, was erfolgreich war.
jetzt kommt bei make && make modules_install:
Code:
ake[1]: *** Keine Regel vorhanden, um das Target »/usr/lib64/firmware/radeon/R600_rlc.bin«, 
  benötigt von »firmware/radeon/R600_rlc.bin.gen.o«, zu erstellen.  Schluss.
make: *** [firmware] Fehler 2

EDIT3: Pfad auf /lib64/firmware geändert...
jetzt kommt beim Kompilieren:
Code:
firmware/radeon/R600_me.bin.gen.S: Assembler messages:
firmware/radeon/R600_me.bin.gen.S:5: Error: file not found: /usr/lib64/firmware/radeon/R600_me.bin
make[1]: *** [firmware/radeon/R600_me.bin.gen.o] Fehler 1
make: *** [firmware] Fehler 2

make firmware_install sagt: nichts zu tun für den target. ARGH.

Hab das ganze mal mit einem ln -s gelöst...jetzt scheint er es zu packen!
 
Zuletzt bearbeitet:
Er hat damit aber Recht. Die Grafikkarte muss ständig auf den Speicher zugreifen, um den Scanout durchzuführen. Damit sind die Schlafphasen des Prozessors sehr verkürzt. Ich weiß zwar nicht genau wie das beim Athlon X4 so läuft, aber wenn dann jedes mal die Kerne mit aufwachen, wen die Northbridge geweckt wird, kommst du ganz schnell in diese Verbrauchsregionen.
Ich baue in letzter Zeit fast nur Office-Kisten, wennich was mache, und das mit ähnlicher Grafik. Genau das Board habe ich mit X2 240, Enermax ECO350 und sonst ähnlicher Konfikuration auf unter 40W trimmen können. Sagt nicht, dass es der X4 50W im Idle saugt...

Hintergründe:
- Speicherzugriffe gehen möglichst an den Kernen vorbei, vom HT direkt zum Controller
- selbst wenn der wach ist, erst einmal bei minimalem Step des Powermanagements
- das Board hat seperaten Grafikspeicher, erst zusätzlich nimmt der vom Hauptram

MfG Micha
 
mhhh, verwechsel ich das jetzt?
Das habe ich nur aus dem Gedächtnis, ich meine ich wollte das für dieses Systm haben. Die Verbrauchswerte sind aber aufgeschrieben, die passen zu dem System.

Die anderen beiden Punkte sind seit Ewigkeiten bei den A64 so, da bin ich mir schon sicher.
 
Unter 2.6.37 sind sie auf jeden Fall vorhanden. Wenn mich git nicht täuscht, dann sollte das aber auch mit 2.6.36 gehen.

Man sollte allerdings noch erwähnen, dass man – zumindest soweit ich informiert bin – dafür KMS benötigt.
Das bedeutet, dass entweder die extra Firmware aus radeon-ucode (die glaube ich für jeden r600 oder später benötigt wird) entweder in den Kernel einkompiliert oder per initrd nachgeladen werden muss, sonst funktioniert KMS nicht.

Aus den bisherigen Angaben geht aber nicht hervor, ob KMS konfiguriert ist oder nicht.
Oder habe ich etwas übersehen?

Zum Einkompilieren benötigst du sowas:
Code:
CONFIG_EXTRA_FIRMWARE="radeon/RS780_pfp.bin radeon/RS780_me.bin radeon/R600_me.bin radeon/R600_pfp.bin radeon/R600_rlc.bin"
Hier ist R600_rlc.bin der Teil der Firmware, der nicht im Vanilla Kernel enthalten ist. Welche Teile du genau benötigst hängt aber von deiner Karte ab.

Wat!? Seit wann braucht der freie Radeon Treiber eine Firmware die nicht im Vanilla Kernel drin ist??


Edit:

Stimmt. .... hätt ich jetzt nicht erwartet.
 
Zuletzt bearbeitet:
Wat!? Seit wann braucht der freie Radeon Treiber eine Firmware die nicht im Vanilla Kernel drin ist??


Edit:

Stimmt. .... hätt ich jetzt nicht erwartet.
Ja ich auch nicht...dafür hat diese Aktion nun endlich mal wieder meine aktuelle Kernel-Config zum booten gebracht 8)

Code:
 cat /sys/class/drm/card0/device/power_method 
profile
cat /sys/class/drm/card0/device/power_profile
default
echo "low" >  /sys/class/drm/card0/device/power_profile
cat /sys/class/drm/card0/device/power_profile
low

keine Änderung beim Stromverbrauch :(
Code:
echo "dynpm" > /sys/class/drm/card0/device/power_method
ebenfalls keine Änderung :(


Die CPU ist zu 92% bei 800MHz...

EDIT: das KMS scheint aber aktiv zu sein, denn:

cat /var/log/Xorg.0.log | grep WW
Code:
[    25.552] (WW) RADEON(0): Option "DynamicClocks" is not used
[    25.552] (WW) RADEON(0): Option "ClockGating" is not used
[    25.552] (WW) RADEON(0): Option "ForceLowPowerMode" is not used


dafür:
dmesg | grep drm
Code:
[    0.392371] [drm] Initialized drm 1.1.0 20060810
[    0.392507] [drm] radeon defaulting to kernel modesetting.
[    0.392550] [drm] radeon kernel modesetting enabled.
[    0.394448] [drm] initializing kernel modesetting (RS880 0x1002:0x9715).                                                         
[    0.394590] [drm] register mmio base: 0xFDEE0000
[    0.394630] [drm] register mmio size: 65536
[    0.395297] [drm] Detected VRAM RAM=512M, BAR=256M
[    0.395361] [drm] RAM width 32bits DDR
[    0.395624] [drm] radeon: 512M of VRAM memory ready
[    0.395662] [drm] radeon: 512M of GTT memory ready.
[    0.395740] [drm] radeon: irq initialized.
[    0.395779] [drm] GART: num cpu pages 131072, num gpu pages 131072
[    0.396994] [drm] Loading RS780 Microcode
[    0.430115] [drm] ring test succeeded in 1 usecs
[    0.430229] [drm] radeon: ib pool ready.
[    0.430321] [drm] ib test succeeded in 0 usecs
[    0.430361] [drm] Enabling audio support
[    0.430755] [drm] Radeon Display Connectors
[    0.430795] [drm] Connector 0:
[    0.430836] [drm]   VGA
[    0.430874] [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[    0.430926] [drm]   Encoders:
[    0.430963] [drm]     CRT1: INTERNAL_KLDSCP_DAC1
[    0.431001] [drm] Connector 1:
[    0.431038] [drm]   DVI-D
[    0.431074] [drm]   HPD1
[    0.431111] [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[    0.431164] [drm]   Encoders:
[    0.431201] [drm]     DFP1: INTERNAL_KLDSCP_LVTMA
[    0.484539] [drm] radeon: power management initialized
[    0.560119] [drm] fb mappable at 0xD0141000
[    0.560159] [drm] vram apper at 0xD0000000
[    0.560196] [drm] size 9216000
[    0.560233] [drm] fb depth is 24
[    0.560274] [drm]    pitch is 7680
[    0.581415] fb0: radeondrmfb frame buffer device
[    0.581436] [B][COLOR="Red"]drm: registered panic notifier[/COLOR][/B]
[    0.581458] [drm] Initialized radeon 2.6.0 20080528 for 0000:01:05.0 on minor 0


EDIT: wie kann ich denn bei nem AMD Prozessor auslesen, wie oft er in welchem C-State verweilt?
powertop zeigt mir das an meinem Notebook (core2duo) so weit ich weiß an...
 
Zuletzt bearbeitet:
Wahrscheinlich funktioniert das Powersaving dann bei deinem Chip einfach noch nicht.
 
hast du auch mal die neueste version von mesa, drm, radeon-video-xf86 und konsorten ausprobiert?
 
Wenn du debugfs konfiguriert und gemountet hast, dann sollte dir
Code:
cat /sys/kernel/debug/dri/0/radeon_pm_info
die aktuelle GPU Frequenz ausgeben.

Könnte mir z.B. vorstellen, dass die automatische Erkennung der Zustände aus irgendeinem Grund nicht funktioniert und er deshalb immer in default ist.
 
Wenn du debugfs konfiguriert und gemountet hast, dann sollte dir
Code:
cat /sys/kernel/debug/dri/0/radeon_pm_info
die aktuelle GPU Frequenz ausgeben.

Könnte mir z.B. vorstellen, dass die automatische Erkennung der Zustände aus irgendeinem Grund nicht funktioniert und er deshalb immer in default ist.
mit mkdir /debufs && mount -t debugfs debugfs /debugfs
liefert mir cat /debugfs/dri/o/radeon_pm_info:

Code:
default engine clock: 560000 kHz
current engine clock: 193320 kHz
default memory clock: 667000 kHz

Er scheint also runterzutakten. Liegt wohl doch an der CPU?

EDIT: positive Nebeneffekte von KMS:
-xserver stürzt nicht mehr mit segfault ab wenn KDE verwendet wird (war deshalb mit Fluxbox unterwegs)
-keine Grafikfehler mehr bei QIP 2005 unter wine
-sehr schnelles umschalten zu Konsole mit strg+alt+f1
 
Zuletzt bearbeitet:
EDIT: wie kann ich denn bei nem AMD Prozessor auslesen, wie oft er in welchem C-State verweilt?
powertop zeigt mir das an meinem Notebook (core2duo) so weit ich weiß an...
Also powertop sollte dir das auch für AMD-Prozessoren anzeigen. Und der hohe Verbrauch kann nicht am Powermanagement der GPU liegen. Du kriegst da vielleicht 20Watt raus, aber bestimmt keine 50.
 
Er scheint also runterzutakten. Liegt wohl doch an der CPU?
Bei 50W über die Grafikeinheite hätte wohl schon lange Rauchzeichen vom Mainboard gegeben. ;)

Wie ich oben schrieb, setze den Prozessor bewußt unter Vollast. Der Unterschied zwischen "fast nichts" und dem müßte mindestens gute 50W sein bei dem Prozessor. Sind es wie im ersten Post nur 20W, läuft bei den Prozessorkernen etwas schief.

Außerdem würde ich ein Bios-Update machen, alles auf default stellen und neu einstellen, dabei auch wirklich die Spannung nicht ändern. Ich hatte mal einen Fall bei 775, da wurde C1E deaktiviert, wenn man auf "manual" gestellt hat, egal ob zwei Zeilen darüber das auf "enable" stand.

Bei den P-States vergessen viele den Halt-Bfehl/C1(E). Wie effektiv der jedoch ist, bemerkt man schon bei P3 vorallem SockelA. ("Softwarecooling-Tools").


Dann auch mal die sache ohne X starten, den Fehler auf der Konsole ergründen oder ein LiveSystem starten. Letztere wie grml oder knoppix bringen auch schon alles mit, d.h. wenn die auch bei 100W heizen, würde ich eher beim Board suchen.
 
Das sieht bei mir so aus:


Code:
<Detaillierte C-Status Informationen sP-States (Frequenzen)
                                        3,00 GHz     7,7%
                                        2,31 GHz     0,4%
                                        1,80 GHz     0,9%
                                         800 MHz    91,0%

das sieht sehr nach "Detailierte C-Status Informationen sind nicht verfügbar"aus
*noahnung*

/proc/acpi/processor/CPU*

enthält nur "throttling".

In der Kernelconfig mal nach ACPI gesucht:

Code:
# Power management and ACPI options
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROCFS_POWER=y
# CONFIG_ACPI_POWER_METER is not set
CONFIG_ACPI_SYSFS_POWER=y
# CONFIG_ACPI_EC_DEBUGFS is not set
CONFIG_ACPI_PROC_EVENT=y
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
# CONFIG_ACPI_PROCESSOR_AGGREGATOR is not set
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_NUMA=y
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_ACPI_CONTAINER=y
# CONFIG_ACPI_SBS is not set
# CONFIG_ACPI_HED is not set
# CONFIG_ACPI_APEI is not set
# CONFIG_X86_ACPI_CPUFREQ is not set
# CONFIG_HOTPLUG_PCI_ACPI is not set
CONFIG_PNPACPI=y
CONFIG_ATA_ACPI=y


EDIT: mit gimps bekomme ich 139W.

Die CPU scheint also auch im idle zu schlafen. Mhh, was zieht hier dann so viel Strom :-/
 
Zuletzt bearbeitet:
Zurück
Oben Unten