Linux auf Akku

[sego]

So mal wieder ich, mal wieder Linux.

Diesmal aber kein Problem, sondern "nur" ne Frage. Hatte hier schonmal hinweisend gepostet, dass unter Linux dem Akku ne ganze Ecke schneller die Puste ausgeht.
Nun, zur Kontrolle hab ich mal KThinkBat installiert. Hat zwar nicht die Funktionalität vom Battery Maximizer, aber zumindest die schöne Anzeigeoptik mit der grünen Batterie und das Tool gibt den momentanen Stromverbrauch aus.
Sehr interessant: Im Idle nimmt sich mein T40 (Radeon 7500, 14" XGA Panel) laut dem Tool ganze 13 Watt. Dabei habe ich bereits phc installiert und die Voltages stark heruntergefahren. Momentane Werte sind "32 26 18 12 7 3". Die CPU-Temps sind dabei um fast 5° gefallen, scheint also zu funktionieren.
Da frage ich mich nur, welches Device sich so derbe den Saft schnorchelt? Ein solches T40 darf einfach keine 13 Watt nehmen. Im Windows komme ich im Schnitt auf 10-11 Watt.

Wie kann ich sowas überhaupt herausfinden. Habe z.B. in der xorg.conf den Parameter Option "DynamicClocks" "on" hinzugefügt, nur obs was gebraucht hat, keine Ahnung ...
Könnte auch die WLAN-Karte mit dem zusammengefrickelten Treiber sein. Nur wie kann ich verhindern, dass sie Strom zieht? Reicht es zu keinem WLAN verbunden zu sein? Muss man evtl mit rmmod das modul rausnehmen? Hab ich im Übrigen schon probiert, hat sich nix verändert ...

Der Hintergrund ist, dass ich ja momentan wegen fehlender CD und kaputtem Windows mein Debian häufiger nutze. Ich muss sagen, ich hab mich da echt dran gewöhnt. Das ist so der einzige Punkt, der mich noch ärgert. Habe mir zudem nen neuen Akku bestellt, bei höheren Kapazitäten machen die 20% laufzeittechnisch heftig was aus.

 

[onkel25]

Hast du dir folgende Thread mal angeschaut: Die Suche nach dem verlorenen Watt... ?

Aktuelle Distributionen haben neue Kernelfunktionalitäten, die da einiges ausrichten sollen. Verschwender kann man dann durch intel powertop (siehe thread) ausmachen.

Vielleicht ist das ja ein Ansatz. Werde mein TP bei Gelegenheit auch mal auf das neue Ubuntu Gutsy umstellen. Vor allem wegen dieser Aussicht.

Gruß, Mario

 

[sego]

PowerTOP version 1.7 (C) 2007 Intel Corporation

danke für den Tipp. Habe mir den Thread durchgelesen, so richtig weiter komme ich dadurch aber nicht. Erstmal hier mein Ergebnis vom powertop nachdem ich folgende Tipps von dem Proggi beherzigt habe:
#!/bin/bash
echo 1 > /sys/module/snd_ac97_codec/parameters/power_save
#mount -o remount,noatime /
echo 1500 > /proc/sys/vm/dirty_writeback_centisecs
echo 5 > /proc/sys/vm/laptop_mode
ps x | grep knotify | cut -c 2-5 | xargs kill -9
rovclock -c 170 -m 170
Beryl oder nicht Beryl macht lustiger Weise nix aus. Außer dass ich ohne Beryl noch weiter runter könnte mit dem Takt der Radeon, was aber auch nicht mehr viel bringt.

-------------------------------------------------------------------------------------------------------------
Cn Avg residency P-states (frequencies)
C0 (Prozessor läuft) ( 3,0%)
C1 0,0ms ( 0,0%) 1500 MHz ( 0,0%)
C2 4,4ms (97,0%) 1400 MHz ( 0,0%)
C3 0,0ms ( 0,0%) 1200 MHz ( 0,0%)
C4 0,0ms ( 0,0%) 600 MHz (100,0%)

Wakeups-from-idle per second : 222,4 interval: 5,0s
Stromverbrauch (nach ACPI): 11,6W (1,1 Std.)

Häufigste Ursachen für das Aufwachen:
31,1% ( 74,2) <interrupt> : uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3,
26,5% ( 63,4) <interrupt> : acpi DB-ICH4 Modem, Intel 82801DB-ICH4, ndis
17,9% ( 42,8) <interrupt> : i8042
6,2% ( 14,8) beryl : schedule_timeout (process_timeout)
4,8% ( 11,4) Xorg : do_setitimer (it_real_fn)
4,4% ( 10,4) alsamixergui : schedule_timeout (process_timeout)
----------------------------------------------------------------------------------------------------------------

Nun gut, 1,5 Watt hats schonmal gebracht, allerdings fehlen nochmal soviel zum Windows-Wert. Zudem fällt mir folgendes auf:
- Im Kernel von Lenny war USB_SUSPEND schon aktiviert. Trotzdem habe ich weiterhin viele Interrupts vom USB (siehe oben). Warum ? Es war nichtmal irgendein Device am USB dran ?(
- Was ist C3 und C4 genau bzw. warum geht mein Prozzi nicht in diese States im normalen Betrieb? Ist das evtl. deep sleep nur für Standby oder ist da wieder irgendwas wurstig konfiguriert ?
- Das Ravclock-Tool ist ganz nett und bringt neben knotify abschalten am meisten, nur manchmal verreckt mir das Betriebssystem ganz langsam, bzw. wird die Grafikausgabe immer langsamer. Zudem kann das Tool nicht den korrekten MHz-Betriebswert bestimmen wie es z.B. Ati TrayTool unter Win kann. Sprich: Man muss immer Werte erraten, bei denen die Grafikausgabe nicht krisselig wird. Gibt es evtl. bessere Proggis ? Oder hat jm. gute, niedrige Werte für die 7500 ? Also 100 und 170MHz für Core und Speicher gehen bei mir, bei 66MHz gehts z.B. nicht.
- Warum verursacht DRi (also das 3D-Zeugs) so viele Interrupts? Ohne Dri hab ich nochmal knapp 0,5W weniger, aber dann geht 3D-mäßig nicht mehr viel. Sogar 2D ist dann nicht immer flüssig. Ich mein, unter Windows geht das ja auch alles wunderbar sparsam MIT 3D.
- Was bedeuten die Zahlen eigentlich bei phc ? Meine Werte für den 1,5er Banias sind momentan 32 26 18 12 7 3. Und was heißt das dann ?

Danke Gruß
sego

 

[IronEagle]

Original von sego
Nun gut, 1,5 Watt hats schonmal gebracht, allerdings fehlen nochmal soviel zum Windows-Wert. Zudem fällt mir folgendes auf:
- Im Kernel von Lenny war USB_SUSPEND schon aktiviert. Trotzdem habe ich weiterhin viele Interrupts vom USB (siehe oben). Warum ? Es war nichtmal irgendein Device am USB dran ?(

Schau mal nach ob was auf dem gleichen Interrupt haengt. Powertop schneidet das gerne mal an der Seite ab. Einfach mal die USB Sachen nicht laden...

Original von sego
- Was ist C3 und C4 genau bzw. warum geht mein Prozzi nicht in diese States im normalen Betrieb? Ist das evtl. deep sleep nur für Standby oder ist da wieder irgendwas wurstig konfiguriert ?

Schau mal auf der Powertop Webseite bzw. da auf der Mailingliste. Das Thema wurde da schon x-mal durchgekaut.

Original von sego
- Das Ravclock-Tool ist ganz nett und bringt neben knotify abschalten am meisten, nur manchmal verreckt mir das Betriebssystem ganz langsam, bzw. wird die Grafikausgabe immer langsamer. Zudem kann das Tool nicht den korrekten MHz-Betriebswert bestimmen wie es z.B. Ati TrayTool unter Win kann. Sprich: Man muss immer Werte erraten, bei denen die Grafikausgabe nicht krisselig wird. Gibt es evtl. bessere Proggis ? Oder hat jm. gute, niedrige Werte für die 7500 ? Also 100 und 170MHz für Core und Speicher gehen bei mir, bei 66MHz gehts z.B. nicht.

Das ganze Powerplay-Zeugs funktioniert unter Linux leider eher suboptimal :-/

Original von sego
- Was bedeuten die Zahlen eigentlich bei phc ? Meine Werte für den 1,5er Banias sind momentan 32 26 18 12 7 3. Und was heißt das dann ?

RTFM?

The sysfs interface of linux-phc (version 0.3.0 or newer) requires you to specify VID (Voltage ID) numbers; see the documentation in the source package. For pre-Core Intel CPUs, VID is related to voltage (in mV) as follows: VID=(voltage-700)/16.

 

[onkel25]

Original von IronEagle

Original von sego
- Was bedeuten die Zahlen eigentlich bei phc ? Meine Werte für den 1,5er Banias sind momentan 32 26 18 12 7 3. Und was heißt das dann ?

RTFM?

Auf der phc-Seite gibts auch ein "phctool" - graphische Konfiguration ähnlich NHC unter Windows. Find ich ganz gut. Dann wird das auch klarer.

 

[sego]

hmm, naja, ich hab gestern nochmal ein wenig rumprobiert und es ist doch noch ein wenig heftiger als ich zunächst gedacht habe. Im absoluten Ruhezustand (also Display wie immer auf 5 von 7 - alles andere ist eh untauglich und am Desktop ohne Aktivität, WLAN aus) geht der im Windows bis auf 8 Watt (!!) runter. Das sind dann doch trotz Optimierungen noch saftige 3 Watt zu Linux.
Dass es in der Praxis nicht ganz so dramatisch ist, liegt daran, dass die 11,5Watt unter Linux recht stabil sind, im Windows gibt es immer mal wieder kurze Ausreißer in Richtg 11-12Watt.
Im Grunde ist das genau der Wert, den man von einem T40 mit der Ausstattung erwartet. Aber genau diese Verhaltensweise weckt eine Vermutung in mir.
Ich habe nämlich inzwischen sehr viel rumprobiert, alles mögliche im Kernel umgestellt. Dieses dynamic Ticks oder so mit dem anderen Zeugs ist eh schon im 2.6.21er Kernel drin. War auch schon aktiviert. Habe extra den 2.6.23.1 kompiliert und nochmal nachgeschaut. Es wird ja immer gesagt, da seinen neue ganz tolle Dinge zum Stromsparen drin. Also ich hab da nix gefunden außer dass ibm_acpi nun thinkpad_acpi heißt. Sonst ist da unter CPU und acpi Einstellung absolut nix Neues zu finden ! Entsprechend war auch das Ergebnis. 13-14 Watt im Idle, berücksichtigt, dass phc nicht ging und auch die anderen von powertop vorgeschlagenen Sachen nicht aktiviert waren, kommts auf dasselbe raus wie mit dem 21er Kernel.
Aus eigener Dummheit hab ich mir darauf hin mein Debian zersemmelt. Da ich hier nur ne FC7-CD mit habe, hab ich das vorhin mit irgendeinem 2.6.22-Kernel installiert. Auch hier dasselbe. 13-14Watt im Idle.
Werde morgen den Ubuntu "Affen" für zukünftige Linux-Einsätze installieren, aber auch da erwarte ich keine Überaschungen mehr.
Folgende Seite brachte mich auf die Idee: http://www.elsniwiki.de/index.php/Main/LarsiesKolumne
Da wird davon gesprochen, dass der 23er Kernel bei seinem Noti ACPI C3 ermöglicht und dieses im Schnitt 2 Watt spart. 2 Watt, die bei mir fehlen. Genau das denke ich, ist der Grund warum der mit Linux konstant mehr Saft schluckt. Zeigt ja auch powertop, dass bei c2 Ende ist. Zudem würde es erklären, warum die Spannung im Windows teilweise nach oben schießt und dann wieder fällt. c3 ist ja quasi "lebender Todzustand". Der Cache und große Teile der CPU sind aus. Dass dies auch im Idle kein Dauerzustand ist, versteht sich von selbst.
Komisch ist halt nur, dass ich im 23er Kernel nix von Acpi C3 gelesen habe. Weder bei CPU noch bei den Acpi-Einstellungen ...

 

[AndreasO]

Hallo,

ich hatte zuerst Feisty auf meinem T43, dann umgestellt auf Gusty.
Unter Feisty hatte ich 18,5 Watt im Idle, unter Gusty 19,5 Watt im idle.
Bis ich dann unter Gusty anstatt den 2.6.22-Kernel den 2.6.20 bootete.
Da war der Verbrauch dann nur noch auf 15 watt, (Windowsbetrieb 14,5 Watt). Ich hab das Linux aber wieder deinstalliert, da ich im Linuxbetrieb ein andauerndes Klacken der Festplatte hatte, was im Windowsbetrieb nicht vorkommt. Ich wäre schon fast umgestiegen auf Linux, denn es hat mitlerweile einen Stand erreicht, der sich sehen lassen kann. Doch leider ist es auf einem Notebook meistens nur eine Notlösung, da nur 90 % der Funktionen der Hardware verfügbar sind. Ausserdem hat sich das System des öfteren komplett aufgehängt, was ich unter XP prof noch nie geschafft habe.

Gruß Andi

 

[sego]

So, seit wenigen Stunden läuft nun Gutsy Gibbon auf meinem T40 und nunja, was soll ich sagen... Der neue Gnome-Desktop sieht schon sehr elegant-schick aus, ABER: weiterhin 13-14 Watt Verbrauch bei den o.g. Bedingungen. Also die üblichen, problematischen Werte. Ob Debian Lenny, Lenny@2.6.23.1, FC7 oder jetzt Ubuntu G.G. Zeigen allesamt dieselbe Problematik.
13 Watt sind satte 5 Watt über dem Windows-Idle-Wert. Selbst wenn ich alles wieder auf mein altes Debian-Niveau schraube mit phc, powertop und Konsorten, ists mit 11-12Watt immer noch miserabel! Bedeutet für mich erstmal, Hörsaal=WinXP.
Wenn jm. ne Idee hat, woran es liegen könnte, Vorschläge posten! Ich werde demnächst wenn alles wieder hergestellt ist, wie vorgeschlagen den 20er Kernel kompilieren, mal sehen. Wäre ja schon geil, wenns den Spar-Effekt auch bei mir geben würde.
Aber davor muss ich erstmal wie gesagt diverse andere Sachen wieder installieren.

So long ...
sego

 

[sego]

nachdem ich gestern gesehen habe, dass es für FanControl sogar ein deb-Paket für Gutsy Gibbon gibt, das zudem auch noch funzt wie geschmiert, hab ich Ubuntu lieb gewonnen
Was die USB-Wakeups angeht, muss ich das Modul usbcore mit autosuspend=1 aufrufen, dann klappts. Bringt aber auch nicht mehr viel. Zudem funzt dann mein Drucker nicht mehr. Also lass ichs... Es bleibt bei den 11,5W, die ich schon mit dem Debian-System hatte.
Das Hauptproblem ist halt leider, dass ich scheinbar von der "kein-C3-Problematik" betroffen bin. Es gibt einen Kernel-Patch, der das wohl beheben soll. Hat bei mir nicht geklappt.
Jetzt kompiliere ich den Kernel ohne dynTicks, soll angeblich bei Systemen mit dieser Problematik helfen.
Mal sehen. Ist halt öde, weil ich weiterhin Win nutzen muss. Hochgerechnete 45min Akkulaufzeit mit neuem Akku sind halt keine Kleinigkeit.

[Update]
nochmal ne kleine Frage von mir. Habe mir die hrt-Patches für den 22er Kernel gezogen. Dazu hab ich mal ein Paar Fragen. Typisch Linux nämlich mal wieder nicht so direkt auf den ersten Blick ersichtlich...
1: ... welches Paket von den unzähligen 2.6.22-Paketen ich brauche. Ich habe das einzige Paket ohne zusätzliches RC hinten dran gezogen.
2: ... welche Patches von den unzähligen Patches ich installieren muss. Sind insg. immerhin ganze 70 Stück in dem Paket enthalten! Dass ich die x86_64 Patches nicht in den Kernel prügel, ist klar. Brauch ich ja sowieso nicht. Aber von den anderen kann ich definitiv nicht alle anwenden. Wenn ich dies mache, lässt sich der Kernel nicht kompilieren, weil Fehler in der processor_idle.c oder in irgendeiner anderen gepatchten c-Datei auftauchen.
Hat da jm. den Überblick?
Hier ne Auflistung der Patch-Namen ausschließl. der 64Bit Patches:

acpi-move-timer-broadcast-and-pmtimer-access-before-c3-arbiter-shutdown.patch
acpi-remove-the-useless-ifdef-code.patch
clockevents-allow-build-without-runtime-use.patch
clockevents-fix-device-replacement.patch
clockevents-fix-resume-logic.patch
clockevents-fix-typo-in-acpi_pmc.patch
clockevents-remove-prototypes-of-removed-functions.patch
clockevents-remove-unused-code.patch
clockevents-remove-unused-inline-function.patch
cpuidle-complete.patch
highres-improve-debug-output-fix.patch
highres-improve-debug-output.patch
hpet-force-enable-on-ich34.patch
hpet-force-enable-on-vt8235-37-chipsets.patch
hrtimer-speedup-hrtimer_enqueue.patch
i386-hpet-add-x8664-hpet-bits.patch
i386-hpet-assumes-boot-cpu-is-0.patch
i386-hpet-check-if-the-counter-works.patch
i386-hpet-sharing-optimize.patch
i386-move-pit-function-declarations-and-constants-to-correct-header-file.patch
i386-pit-remove-the-useless-ifdefs.patch
i386-pit-stop-only-when-in-periodic-or-oneshot-mode.patch
i386-prepare-sharing-hpet-code.patch
i386-prepare-sharing-pit-code.patch
i386-remove-pit-interrupt-hook.patch
i386-remove-volatile-in-apicc.patch
ich-force-hpet-add-ich7_0-pciid-to-quirk-list.patch
ich-force-hpet-ich5-fix-a-bug-with-suspend-resume.patch
ich-force-hpet-ich5-quirk-to-force-detect-enable-fix.patch
ich-force-hpet-ich5-quirk-to-force-detect-enable.patch
ich-force-hpet-ich7-or-later-quirk-to-force-detect-enable-fix.patch
ich-force-hpet-ich7-or-later-quirk-to-force-detect-enable.patch
ich-force-hpet-late-initialization-of-hpet-after-quirk.patch
ich-force-hpet-make-generic-time-capable-of-switching-broadcast-timer.patch
ich-force-hpet-restructure-hpet-generic-clock-code.patch
jiffies-remove-unused-macros.patch
nohz-fix-nohz-x86-dyntick-idle-handling.patch
ntp-move-the-cmos-update-code-into-ntpc-fix-fix.patch
ntp-move-the-cmos-update-code-into-ntpc-fix.patch
ntp-move-the-cmos-update-code-into-ntpc.patch
pcspkr-use-the-global-pit-lock.patch
series
tick-management-spread-timer-interrupt.patch
timekeeping-fixup-shadow-variable-argument.patch
timerc-cleanup-recently-introduced-whitespace-damage.patch
version.patch

Ne ganz schön komplexe Sache diese Stromsparerei. Wenn man allein mal auf der Powertop-Seite schaut wieviele unzählige Patches es für diverse Programme gibt, ist es ja fast unglaublich wie einfach, zuverlässig und reibungslos das ganze unter WinXP funktioniert.

[Update]
Kleines Update nochmal. Habe auf der Powertop-Seite gelesen, dass mit angeschlossenen USB-Geräten kein C3 und C4 Sleep möglich ist. Also Windows gebootet und vergleichen. Ohne USB wie immer 8 Watt im Idle mit den kurzen Ausreißern nach oben, mit USB-Maus BÄM ... recht konstante 11,5 Watt, auf jeden Fall gehts nicht weiter runter. Damit isses wohl definitiv das fehlende C3, was Linux zum Säft-Junkie macht.
Die hrt-Patches kann man leider allesamt knicken. Gibt hunderte verschiedene Versionen, allein für den 22er Kernel 10 verschienene Packages, von denen KEIN EINZIGES auf dem 2.6.22.9 vom Guzzy Gibbon fehlerfrei anwendbar ist. Sprich: Der Kernel ist mit keinem dieser Patches kompilierbar. Tja ... noch nen anderen Kernel installiere ich jetzt nicht mehr. Am Ende funzt entweder WLAN oder Fancontrol oder phc oder sonstwas wieder nicht. Auf dem 23er Kernel geht z.B. das Fancontrol-Script nicht. Spuckt immer irgendeinen Fehler raus. Ich glaub ich muss mich einfach damit abfinden, dass Linux kein Win-Ersatz ist

 

[sego]

ICH HABS GESCHAFFT. ICH BIN GOTT. VERNEIGT EUCH VOR MIR
Da sei mir auch mal ein ganz pöhser Triple-Post gegönnt

Ich hab doch nochmal den 2.6.23.1 auf Ubuntu installiert und siehe da. Folgender Patch geht:
http://www.kernel.org/pub/linux/kernel/people/tglx/hrtimers/2.6.23/patch-2.6.23-hrt3.patch.gz
Auch der läuft zwar nicht ganz fehlerfrei durch, aber der Kernel lässt sich danach fehlerfrei kompilieren und das wichtigste - die C3 und C4 Modi funktionien danach.
Problematisch waren bei mir übrigens noch die Interrupts von der Radeon. Die waren komischer Weise in derselben Zeile angegeben wie die vom USB. Daher war das USB-Problem eigentlich gar keins... zumindest von den Interrupts her. Bei eingesteckten Geräten ists trotzdem aus mit C3 und C4. Nach wie vor hat sich da nix geändert. Also USB-Maus auf Akku ist BÖSE !
Mir als leidenschaftlicher "Pömpel-User" egal ...
Die Radeon-Interrupts sind nur zu beseitigen durch Abschalten von DRI. Also Option "NoDRI" in der xorg.conf... Gibt wohl keine Alternative.
Macht immerhin einen unterschied von 20% C4 zu 90% C4. Für Fancontrol nehm ich das deb-Paket von hier:
http://www.gambitchess.org/moin.py/ThinkPad_Fan_Control?action=show&redirect=tpfan
Das selbst kompilierte ging bei mir zumindest damals auf Debian Lenny mit 2.6.23.1 nicht. Zudem hat das Ubuntu-Paket schön viel Klicki-Bunti, mehr kann das Herz nicht verlangen.
Was phc angeht, bin ich mir nicht ganz sicher. Ich hab die 0.3.0-pre1 genommen und den Patch für den 22er Kernel von hier genommen: https://www.dedigentoo.org/bdz/linux-phc/
Der läuft im Gegensatz zur Anwendung auf dem 22er Kernel nicht fehlerfrei durch, das Modul konnte ich aber problemlos erstellen. Spuckt beim Aufruf auch keine Fehler aus. Dieses test-Tool - hab den Namen gerad vergessen - funzt bei mir nicht. Es meint, irgendwas im Kernel müsse umgestellt werden, aber ne. Nicht nochmal kompilieren, das reicht jetzt erstmal. Denn mein Ziel ist mehr als erreicht. Ich hab im Idle knapp unter 9 Watt auf Display 5/7 ohne WLAN im Idle (90% C4) und das konstant. also ohne Ausreißer nach oben. Der Firefox ist auch ganz lieb zur CPU, Acrobar Reader auch, mehr brauch ich auf Akku nicht. Audacity noch, aber das die CPU dort nicht pennen kann, ist wohl auch nicht zu verhindern.

http://mitglied.lycos.de/segoii/Bildschirmfoto.jpg

mission completed
sego

 

[pibach]

sego, auf C2D Prozessoren geht wohl der C4 sleep nicht so leicht. Ich krige zumindest keine auf meinem x61t. Hast du ne Idee warum? Oder gibt es sonst jemanden, der C4 sleeps auf einem C2D erhält?

 

[buddabrod]

iirc remapped das Bios im Akkubetrieb den C3 auf den C4. D.h. wenn dir Powertop C3 anzeigt, ist er in wirklichkeit im C4.

Mit meinem T61 mit Nvs 140m komme ich auf niedrigsten Einstellungen auf 10,5Watt. Muss aber den Ram tauschen, das Corsair Teil wird heiss wie nochwas und wird auch ordentlich Strom verbraten.

 

[sego]

so, ich hab aus ner Laune heraus gerade ein neues Ubuntu aufgesetzt und gleich den 2.6.24.1 Kernel kompiliert.
Positiv: Das Gefrickel mit den hrt-Patches hat ein Ende. C3 bzw. auf Akku C4 funktioniert out-of-the-box. Sehr schön.
Negativ: Ich meine mich an Stimmen zu erinnern, die meinten, dass die Interrupt-Problematik des open Radeon-Treibers nicht mehr vorhanden wäre. Nunja, bei mir hat sich da nix verändert. Mit DRI hab ich nur noch 20% C3 bzw. C4, der Rest verteilt sich auf C2 und CPU aktiv.

 

[sego]

so, da ich nix zu tun habe und nicht müde bin, hab ich mich mal wieder auf den langen Weg gemacht ein anständiges Linux auf die Beine zu stellen. Ubuntu ist zwar echt geil nur irgendwie gefiel mir Gnome nicht. KDE macht insg. einfach nen stimmigeren Eindruck. Der bessere Dateibrowser, schönere und kleinere Icons, mehr Einstellungsmöglichkeiten beim Design, etc. pp. Ist einfach besser.
Zudem weiß ich bei KDE schon wie ich mir ne kleine, minimale, individuelle Installation zusammenstelle.
Also wieder Debian Lenny drauf, diesmal mit Kernel 2.6.24.4.

Im Prinzip gilt noch alles, was ich schon bei Ubuntu gemacht habe, nur das tolle Klicki-Bunti Fancontrol musste ich wieder durch das hier ersetzen:
http://projekte.f4.fhtw-berlin.de/trac/s0332819-linuxtools/wiki/
Sieht nicht so schön aus, funzt aber auch.
Warum ich diesen Post schreibe hat allerdings einen anderen Grund. Nachdem mich schon die Umbenennung des i386-Ordners bei der Installation des phc-Patches Zeit gekostet hat (--> kleiner Tipp für User von linux-phc auf aktuellen Kerneln)
bin ich kurze Zeit später über einen anderes Problem gleicher Genialität gestoßen. Beim Radeon-Treiber hat sich ja trotz aller Gerüchte nix geändert. Mit DRI 11,5W, ohne DRI 8,5W Verbrauch. Hoher Interrupts sei dank. Nun war es ja bislang so, dass bei der xorg.conf in der Device-Section der Grafikkarte ein Option "NoDRI" ausreichte. Dem ist nicht mehr so. Es tut zwar keinen Abbruch - sprich: Der X-Server startet auch mit dem Befehl noch, allerdings weiterin mit DRI und serienmäßig höherem Stromverbrauch :evil:
Also eine weitere google-Orgie bis ich auf folgendes gestoßen bin:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=429495

Anstatt des o.g. Befehls ist nun ein Disable "dri" in der Module-Section notwendig um 3D den Gar auszumachen. Ich frag mich echt was sowas soll ?(
Son quatsch kostet den gewillten Linux-Nutzer nur unnötig Zeit. Was war an dem alten Befehl so schlecht? Naja, wer dasselbe Problem hat, hat ja jetzt die Lösung.

Gut Nacht.
Gruß
sego

[Edit]
auch hier mal zur Vervollständigung erwähnt:
gibt nen neuen OpenSource Radeon-Treiber, der das Interrupt-Problem beseitigt:
http://mitglied.lycos.de/segoii/xserver-xorg-video-ati_6.8.0+git29022008-0ubuntu1~ppa1_i386.deb