OS mit aktuellen Kerneltreibern für Phenoms/Opterons (FreeBSD???)

flybyray

Vice Admiral Special
Mitglied seit
06.06.2008
Beiträge
509
Renomée
9
Standort
München
Hi,

ich suche ein openos (UNIX/LINUX/SOLARIS ...) bei dem Treiber für "aktuelle" Hardware (für die es ausreichend Dokumentation gibt) auch aktiv entwickelt und verfügbar sind.

Speziell geht es mir um eine bessere HW P-States unterstützung.
Ich würde gerne unter Linux die selben Möglichkeiten haben, wie es sie mit Overdirve unter Windows gibt.
Ich möchte das System beispielsweise "undervolten" und "underclocken" und eben in Bereitschaft versetzen (bei minimalem Energieverbrauch).

Dazu gehören natürlich auch detailierte Ausgaben für Temperatur Lüfterdrehzahlen ... eben wie bei Overdrive.

Wenn ich nun im Internet ein bisschen herumsuche. Fällt mir auf das in den Quellen für FreeBSD einige amd_fam10h spezifische Dinge rumgeistern die ich im linux kernel nicht finde.
Hat jemand Erfahrungen mit FreeBSD und aktueller Hardware (SB600/790FX/K10)?

PS:
Ich weiß, dass ich mittels /sys/bus/pci/devices/XXXX:XX:XX.X/config auf einige dieser Werte mit den meisten Linux-Distributionen zugreifen kann. Jedoch würd ich das doch etwas bequemer haben und mir nicht irgendwelche Skripte basteln.
Die Hardware P-States könnte ich auch mit rdmsr und wrmsr lesen und verändern.
 
PS:
Ich weiß, dass ich mittels /sys/bus/pci/devices/XXXX:XX:XX.X/config auf einige dieser Werte mit den meisten Linux-Distributionen zugreifen kann. Jedoch würd ich das doch etwas bequemer haben und mir nicht irgendwelche Skripte basteln.
Die Hardware P-States könnte ich auch mit rdmsr und wrmsr lesen und verändern.

Die P-States lassen sich auch unter Linux vollständig nutzen. Was die Hardware anbietet, lässt sich via cpufreq nutzen. Interessant wird es erst, wenn es nicht offiziell von der Hardware offeriert wird. Dann sind wir beim undervolten.
 
Mein System siehst du ja links. Sollte dem entsprechen was du suchst.

Ich benutze ein Arch Linux mit dem aktuellen Stable Kernel.
P-States sind überhaupt kein Problem. Das funktioniert einwandfrei. Mit Cpufreq Tools lassen sich auch verschiedene Modis einstellen, die man glaube ich auch per GUI verwalten kann (mache ich allerdings nicht).
Die Modis wären hier:
Code:
#  ondemand, performance, powersave,
#  conservative, userspace
Man kann natürlich auch von Hand auf ein P-State schalten.

Das Undervolten habe ich noch nicht probiert. Ich hab leider auch keine Ahnung, ob das mit einem AMD geht. Für mein Pentium-M im Laptop gibt es ein angepasstes Modul, mit dem das sehr schön geht. Das ist allerdings nicht zu einem AMD kompatibel. Aber laut Homepage wird daran gearbeitet.

Dieses amd_fam10h kenne ich als Compilerflag. Damit lassen sie die selber kompilierten Programme auf deinen CPU-Typ optimieren.
amdfam10, barcelona
AMD Family 10h core based CPUs with x86-64 instruction set support. (This supersets MMX, SSE, SSE2, SSE3, SSE4A, 3dNOW!, enhanced 3dNOW!, ABM and
64-bit instruction set extensions.)
 
Was die Hardware anbietet, lässt sich via cpufreq nutzen. Interessant wird es erst, wenn es nicht offiziell von der Hardware offeriert wird. Dann sind wir beim undervolten.
Was die Hardware offiziell anbietet lässt sich mit cpufreq nutzen.
Aber nicht das inoffizielle!
Selbst mit dem AMD Overdrive kann ich den Phenom von 2200 auf 1000Mhz runtertakten.
Wenn man sich 31116-Public-GH-BKDG_3.20_2-4-09.pdf ansieht ist noch mehr möglich. Das wurde scheinbar sogar schon von so manchem untersucht und im Internet veröffentlicht.

Cpufreq ist zu dem sehr allgemein für verschiedene Prozessortypen sogar schon beinahe herstellerunabhängig entworfen. Das liegt halt einfach an "Torvalds and Friends" die wollen nichts spezialisiertes in ihrem Baum haben.
Andererseits sind spezielle Treiber nichts ungewöhnliches in anderen Bereichen.
Warum sollte es also nicht mal einen Treiber geben, der eben nur für AMD Phenom CPU's all das herausholt was laut der obigen Dokumentation möglich ist.
(Wie schon erwähnt habe ich da im FreeBSD umfeld nützliche Quellen gefunden. Und da frage ich mich eben ob ich vielleicht auch mal ein neues Lager bei BSD aufschlagen sollte.)

Aber stimmt ich werd noch mal diese Untermodule "ondemand, performance, powersave, conservative, userspace" von cpufreq durchsuchen ob ich die vielleicht einfach nur anpassen kann.
 
Zuletzt bearbeitet:
Ich zitiere mal aus dem Arch-Wiki. Es gibt durchaus spezifische Module für verschiedene CPU-Typen:
Most modern notebooks and desktops can simply use the acpi-cpufreq driver, however other options include the p4-clockmod, powernow-k6, powernow-k7, powernow-k8, and speedstep-centrino drivers.

Und es ist ja auch nicht gesagt, dass innerhalb der Treiber nochmal unterschieden wird.

Für meinen Phenom II sieht es so aus:
cpufrequtils 005: cpufreq-info (C) Dominik Brodowski 2004-2006
Bitte melden Sie Fehler an cpufreq@vger.kernel.org.
analysiere CPU 0:
Treiber: powernow-k8
Folgende CPUs können nur gleichzeitig ihre Frequenz variieren: 0
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: ondemand, 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.
analysiere CPU 1:
Treiber: powernow-k8
Folgende CPUs können nur gleichzeitig ihre Frequenz variieren: 1
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: ondemand, 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.
analysiere CPU 2:
Treiber: powernow-k8
Folgende CPUs können nur gleichzeitig ihre Frequenz variieren: 2
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: ondemand, 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.
analysiere CPU 3:
Treiber: powernow-k8
Folgende CPUs können nur gleichzeitig ihre Frequenz variieren: 3
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: ondemand, 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.

von 3Ghz auf 800Mhz sollte doch reichen, oder?
 
Ich erinnere mich an ein Projekt im Meisterkühlerforum, was genau das gemacht hat. Es hat einen Userspace Modus für cpufreq bereitgestellt, der vollständig anpassbar war. Ging schon mit dem K8. Dort kann man die verschiedenen Performancelevel per Hand anpassen, inkl. der verwendeten Spannung. Ist irgendwo auch als Projekt bei Sourceforge gehostet, ich komme nur leider nicht mehr auf den Namen. :(

Man muss also nicht zum BSD gehen, nur weil es dort ein paar Anpassungen gibt, die hat Linux auch. Zu BSD geht man wegen anderen leckeren Eigenschaften. ;)

Edit: Google ist dein Freund. Habe es wiedergefunden: nennt sich cpupowerd. Sourceforgelink und Thread im Meisterkühler.
 
Zuletzt bearbeitet:
Ich erinnere mich an ein Projekt im Meisterkühlerforum, was genau das gemacht hat. Es hat einen Userspace Modus für cpufreq bereitgestellt, der vollständig anpassbar war. Ging schon mit dem K8. Dort kann man die verschiedenen Performancelevel per Hand anpassen, inkl. der verwendeten Spannung. Ist irgendwo auch als Projekt bei Sourceforge gehostet, ich komme nur leider nicht mehr auf den Namen. :(

Man muss also nicht zum BSD gehen, nur weil es dort ein paar Anpassungen gibt, die hat Linux auch. Zu BSD geht man wegen anderen leckeren Eigenschaften. ;)

Ich glaube nicht, dass das funktioniert. Die Checks, welche Einstellungen getroffen werden dürfen, übernimmt der Kerneltreiber. Zumindest war das so, als ich mich damit beschäftigt hatte. Der Treiber ließ da keine Einstellungen zu, die nicht schon von Haus aus vorgesehen waren. Undervolten war damit also nicht möglich.
 
Soweit ich weiß, bestimmt der Govener über die CPU Einstellungen. Und wenn cpufreq die Regelung an einen userspace Govener abgibt sollte das kein Problem sein. Der Entwickler da labert ja auch nich nur heiße Luft sondern hat die Erfolge ja auch per Energieverbrauchsmessung bestätigt. Ich glaube also schon, dass diese Methode funktioniert.

Ich glaube an einem Test werden wir nicht vorbei kommen. ;) Vll. komme ich ja dieses WE mal dazu...
 
Cool hier ist ja doch noch einiges nützliches zusammen gekommen.
Wenn man bei google nach "AMD Voltage Regulator Specification, #40182"
sucht findet man auch noch einiges für Spannungsregelungen.
Ich meine irgendwie müssen die das bei dem Overdrive ja auch hinbekommen haben. ;D
Vielleicht gibt es ja irgendwo so gar schon ein Opensource Projekt das AMD Overdirve für Linux nachbildet. Da wäre ich jedenfalls sofort dabei! ;D
 
Mit cpupowerd geht undervolten sämtlicher über das bios zur Verfügung gestellter P-States.
Code:
eblis1 ~ # cpupowerd -s
cpupowerd 0.2.1 written by Markus Strobl.
WARNING: This program could cause damage to your Hardware!
Vendor                      : AMD
Family                      : K8
Model                       : 6
  Mastercpuid               : 0
    Affected cpuids         : 0 1
    Current voltage (VID)   : 1.0750 V (19)
    Current frequency (FID) : 2100 MHz (13)
    Supported frequencies   : 1000 1800 2000 2100 MHz

Mit einer Konfigurationsdatei und im Daemon Mode läuft das Rauf- und Runtertakten mit individuellen Spannungen sehr gut.
Code:
eblis1 ~ # cat /etc/cpupowerd.conf
1000 0.8000
1800 1.0250
2000 1.0500
2100 1.0750
Testen konnte ich es aber bisher nur auf K8'en.

lg
__tom
 
Ja, aber du kommst nicht drunter, oder? Also wenn für 1000MHz 0.8V vorgegeben sind, kannst du nicht auf 0.75V gehen, um mal ein konkretes Beispiel zu nennen.

WARNING: This program could cause damage to your Hardware!

Dann schreib doch einfach 0.75V in die conf Datei rein. Letztendlich ist es die Aufgabe von dem Tool es nach Anleitung ("AMD Voltage Regulator Specification") die Spannungen zu setzen. Vermutlich sind dann in der Spezifikation Grenzen hinterlegt. Denn du musst die Werte vermutlich wieder in irgendwelche Ganzzahlen konvertieren und da wird es eben Grenzen geben.
 
Dann schreib doch einfach 0.75V in die conf Datei rein. Letztendlich ist es die Aufgabe von dem Tool es nach Anleitung ("AMD Voltage Regulator Specification") die Spannungen zu setzen. Vermutlich sind dann in der Spezifikation Grenzen hinterlegt. Denn du musst die Werte vermutlich wieder in irgendwelche Ganzzahlen konvertieren und da wird es eben Grenzen geben.

Soweit ich mich jetzt erinnere, lässt der Treiber eben nichts außerhalb der Grenzen zu, die die Hardware vorgibt. Man kann es zwar in die config schreiben, der Treiber weigert sich aber, das umzusetzen. Wenn man da was anderes will, muss man den Treiber manipulieren. Das ist zumindest mein letzter Kenntnisstand.
 
Man muss also nicht zum BSD gehen, nur weil es dort ein paar Anpassungen gibt, die hat Linux auch. Zu BSD geht man wegen anderen leckeren Eigenschaften. ;)
Das ist mir schon klar. Auf bestimmter ebene sind BSD und Linux eh ähnlich. Notfalls kann man sich auch den Code dort klauen und sich sein Modul unter Linux stricken.

Aber mich würde jetzt trotzdem mal interessieren welche leckeren Eigenschaften du meinst! ;D
.
EDIT :
.

Soweit ich mich jetzt erinnere, lässt der Treiber eben nichts außerhalb der Grenzen zu, die die Hardware vorgibt. Man kann es zwar in die config schreiben, der Treiber weigert sich aber, das umzusetzen. Wenn man da was anderes will, muss man den Treiber manipulieren. Das ist zumindest mein letzter Kenntnisstand.
Naja ich vermute aber doch mal dass die eben schon alles was möglich ist erlauben in dem Treiber. Ansonsten sollte das nicht so schwer sein dass dann zu ändern, so wie es diese Spezifikation vorgibt.
Leider habe ich dieses doofe Dokument immer noch nicht gefunden bei AMD.
Hab da jetzt mal im Developer Forum nachgefragt wo es das gibt.
 
Naja ich vermute aber doch mal dass die eben schon alles was möglich ist erlauben in dem Treiber. Ansonsten sollte das nicht so schwer sein dass dann zu ändern, so wie es diese Spezifikation vorgibt.

Die Spezifikation sagt 0.8V bei 1000MHz, um jetzt mal ein fiktives Beispiel zu nehmen. Und wenn das so von der Hardware vorgegeben ist, geht der Treiber da nicht drunter, selbst wenn das theoretisch möglich ist. Viele Chips kann man ja mit weniger Spannung betreiben, als vom Hersteller vorgegeben. Wenn man das macht, und die Kiste dadurch instabil wird, hat man halt Pech. Man betreibt die Komponenten ja explizit außerhalb der Specs. Die Linux-Treiber halten sich nur sehr genau an die Specs. Das ist z.B. für den Enterprise-Bereich absolut notwendig. Deshalb haben es die Patches, welche den Betrieb außerhalb der Spezifikationen ermöglichen, nie in den vanilla-kernel geschafft. Zumindest meines Wissens nach nicht.
 
Eine ganz gute Beschreibung findet sich im ersten Post des Threads im Meisterkühler. Da ist auch die Erklärung dafür drin, warum bei einigen Prozessoren Spannungen unter 0,8V nicht möglich sind.

Zu BSD: Allein schon die Lizens ist ein Grund sich bei bestimmten Einsatzszenarien für ein BSD zu entscheiden. Bei Veränderungen des Quellcodes, welche man nicht veröffentlichen will, weil Beispielsweise ein finazielles Interesse dahinter steht ist die BSD Lizens viel besser geeignet.
 
Aber es ist OpenSource, also wird sich mit ein wenig Quellcodeleserei und ein bisschen probieren doch bestimmt was für den K10 Stricken lassen...
Im Grunde geht es doch nur um eine einzelne Regelung für jeden Kern. So wie du dich im Programmierunterforum beteiligst, bist du doch auch nicht auf den Kopf gefallen, was das anbetrifft.

Ich würde bei so einem Projekt auch gern helfen, habe aber keinen eigenen K10 und bin zur Zeit im Abistress. :( Wenn ich irgendwo helfen kann, bin ich auch fast immer zu erreichen.
 
Hm jetzt hat da einer von AMD im Developer Forum auf meine Frage wo ich diese "AMD Voltage Regulator Specification, #40182" finde geantwortet.
AMD Voltage Regulator Specification, #40182
Scheint also irgendwelche besondere Verschlusssache zu sein. :]
Gut scheinbar braucht man das doch nicht. Ich habe den BIOS and Kernel Developer's Guide (BKDG) For AMD Family 10h Processors noch einmal genauer studiert.
Auf Seite 37 und folgende sind sogar die Möglichen Spannungen für Fam 10h Prozessoren beschrieben.
Es gibt 2 unterschiedliche Übertragungsarten an die Spannungsregulatoren. Die VID Werte können aber alle über MSR Register gesteuert werden. Hier die möglichen Spannungswerte des Prozessors (werden für alle Kerne immer für den Kern im höchsten P-State gesetzt).
  1. Boot VID Encodings
    VDD: 1.1 - 0.8 V
  2. Parallel VID Interface (PVI) Encodings
    VDD: 1.55 - 0.375 V
  3. Serial VID (SVI) Encodings
    VDD: 1.55 - 0.000 V
Boot VID Encodings sind für den Bootvorgang gedacht. Es wird erwartet dass das BIOS diese unterstützt.
Die beiden Moduse PVI/SVI werden je nach Platform unterstützt.
Ob <PVIMode> unterstütz wird kann man über das F3xA0 Power Control Miscellaneous Register auslesen.
.
EDIT :
.

Aber es ist OpenSource, also wird sich mit ein wenig Quellcodeleserei und ein bisschen probieren doch bestimmt was für den K10 Stricken lassen...
Im Grunde geht es doch nur um eine einzelne Regelung für jeden Kern. So wie du dich im Programmierunterforum beteiligst, bist du doch auch nicht auf den Kopf gefallen, was das anbetrifft.

Ich würde bei so einem Projekt auch gern helfen, habe aber keinen eigenen K10 und bin zur Zeit im Abistress. :( Wenn ich irgendwo helfen kann, bin ich auch fast immer zu erreichen.
Ja daran bin ich auch interessiert, bin aber auch ein im Stress! Es gibt eigentlich immer nur Stress. ;D
Ich habe mir den Code auch schon angesehen. Aber ich bezweifel es ob es mit "einfachem" Umbauen von cpupowerd geht.
Ich persönlich würde dann doch eher Anhand des BIOS and Kernel Developer Guids arbeiten wollen. Insbesondere würde ich dann die Punkte
2.4.1.8.1 Software-Initiated NB Voltage
2.4.1.8.2 Software-Initiated CPU Voltage Transitions
wie vorgegeben abarbeiten lassen.
Dazu muss ich mir aber auch noch mal BIOS and Kernel Developer's
Guide for AMD NPT Family 0Fh Processors ansehen und parallelen finden.
Im übrigen ist der K8 Guide mit wesentlich mehr Beispielen und Grafiken gespickt. Scheinbar hatte AMD beim Phenom für so etwas keine Zeit. ;D

Wäre aber auch noch wichtig mal vorher zu recherchieren, ob es nicht doch noch wo anderes ähnliche Projekte für den K10 gibt. Evtl. sogar gibt es ja schon irgendwo in den Themen bei Meisterkühler ein solches Verlangen nach Unterstützung für Phenoms / Phenom II.
 
Zurück
Oben Unten