Re: [gelöst] Re: Jagd nach dem ?Hänger-Problem: erste konkrete Spuren

Marc Santhoff <> wrote:
> Am Freitag, den 29.07.2011, 21:45 +0200 schrieb Oliver Fromme:
> > > Wirklich interessant ist aber, daß sie tatsächlich nur dann auftreten,
> > > wenn der Rechner wenig oder fast nichts zu tun hat. Sobald ein Compiler
> > > im Hintergrund läuft, oder ich die "glxgears" als optische Kontrolle
> > > laufen lasse, passiert nichts mehr, soll heißen die vermeintlichen
> > > Hänger sind verschwunden.
> >
> > Hast Du powerd(8) laufen? Falls ja, setze mal den sysctl
> > debug.cpufreq.lowest auf einen nicht allzu niedrigen Wert
> > (500 oder so), und/oder gib dem powerd die Option -m 500
> > mit auf den Weg.
>
> Stimmt genau, den hatte ich schon fast vergessen. Und es hilft, der
> Effekt ist weg. :)

Der entscheidende Hinweis war, dass die Hänger auftreten,
wenn der Prozessor gerade nichts zu tun hat.

Es gibt durchaus einige Prozessor-Mainboard-Kombinationen,
bei denen es zu Instabilitäten kommt, wenn der Prozessor zu
stark heruntergetaktet wird (100 MHz oder weniger; Fälle
mit mehr als 100 MHz sind mir nicht bekannt, was aber nicht
heißen muss, dass das nicht auch vorkommen kann). Die
genaue Ursache kenne ich nicht. Möglicherweise gibt es
dann Timing-Probleme mit dem Bus. Mainboards und Chipsätze
sind ja eher darauf ausgelegt, mit möglichst hohen Takt-
frequenzen zu arbeiten, was heutzutage bei 3 bis 4 GHZ eine
ziemlich knifflige Angelegenheit ist. Frequenzen, die
dagegen nach heutigen Maßstäben "extrem niedrig" sind,
werden vielleicht beim Design nicht so sehr berücksichtigt,
insbesondere bei Consumer-PCs (Server, Embedded, Net- und
Notebooks sind wieder eine andere Geschichte).

Von diesem Problem habe ich in den englischsprachigen
Mailinglisten schon mehrere Male gehört. Die Lösung war
jedesmal, den powerd(8) zu veranlassen, den Prozessor nicht
bis auf die unterste Stufe herunterzutakten. Wenn ich mich
richtig erinnere, genügte es in der Regel, die Untergrenze
von 50 auf 100 oder maximal 200 MHz anzuheben; vermutlich
genügt das auch in Deinem Fall. Ich hatte nur erstmal 500
empfohlen, um festzustellen, ob dies überhaupt die Ursache
sein kann.

Übrigens:
   sysctl dev.cpu.0.freq
zeigt die die aktuelle Frequenz an, und
   sysctl dev.cpu.0.freq_levels
listet alle Stufen auf, die Hardware und die zugehörigen
Treiber unterstützen. Die Zahl vor dem Schrägstrich gibt
die Taktfrequenz an, die Zahl dahinter steht für den
relativen Energieverbrauch (dies ist aber nur eine grobe,
theoretische Näherung).

Bei mir hier (AMD Phenom II X6 2,8 GHz mit ASUS-Mainboard)
sieht's gerade so aus:

dev.cpu.0.freq: 100
dev.cpu.0.freq_levels: 2800/19875 2450/17390 2200/15080 1925/13195
1650/11310 1500/10837 1312/9482 1125/8127 937/6773 800/6737
700/5894 600/5052 500/4210 400/3368 300/2526 200/1684 100/842

D.h. 100 MHz ist die unterste Stufe (die auch oft erreicht
wird), die zumindest in dieser Kombination bisher auch
stabil läuft. Dank dessen wird der Prozessor auch nicht
allzu heiß:

dev.cpu.0.temperature: 28.0C

Und das trotz leisem Lüfter ("Katana 3" von Scythe -- das
soll keine Werbung sein, ich habe mit der Firma nichts
weiter zu tun, außer dass ich zufriedener Kunde bin).

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
"Life is short (You need Python)"
        -- Bruce Eckel, ANSI C++ Comitee member, author
           of "Thinking in C++" and "Thinking in Java"
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message