tag:forum.selfhtml.org,2005:/self Debian: cpufreqd verweigert Kooperation mit Atom-CPU – SELFHTML-Forum 2013-04-02T20:02:53Z https://forum.selfhtml.org/self/2013/apr/2/debian-cpufreqd-verweigert-kooperation-mit-atom-cpu/1576305#m1576305 Der Martin self@kennst.net 2013-04-02T16:58:28Z 2013-04-02T16:58:28Z Debian: cpufreqd verweigert Kooperation mit Atom-CPU <p>n'Abend,</p> <p>nach einer längeren und leider erfolglosen Internet-Recherche frag ich jetzt einfach mal hier.</p> <p>Ich habe in den letzten Tagen ein System neu aufgesetzt, das meinen softwaremäßig schon recht betagten Home-Server demnächst ersetzen soll.<br> Hardware: Intel Atom 230, 1.60GHz; Intel ICH7 Chipset ; 1GB RAM; 160GB SATA HDD<br> Software: Debian Squeeze 6.0.7 Spar-Installation (ohne Desktop, ohne X, nur Konsole)</p> <p>Inzwischen laufen alle gewünschten Dienste (SSH, Samba, Dovecot, Apache) zu meiner Zufriendenheit, und bevor ich das System auf die endgültige Ziel-Hardware umsetze (gleiche CPU, gleiche Eckdaten), wollte ich der CPU noch einen Gefallen tun und cpufreqd installieren, damit das System selbständig von 1600 auf 800MHz runtertakten kann, wenn es sich langweilt, und so weniger Wärme produziert.</p> <p>Problem: cpufreqd weigert sich zu starten, die damit zusammenhängenden Meldungen an der Konsole lauten:</p> <pre><code class="block">Starting CPU Frequency Daemon: cpufreqd  failed! [...] Loading cpufreqd kernel modules...done (none) CPUFrequ Utilities: Setting ondemand CPUFreq governor...disabled, governor not available...done [...] startpar: service(s) returned failure: cpufreqd ... failed! </code></pre> <p>Überall wird beschrieben, dass cpufreqd völlig problemlos sei und eigentlich "out of the box" mit der Default-Config gut funktioniert. Aber was, wenn nicht?<br> Mich irritiert beispielsweise, dass die Failed-Meldung von cpufreqd schon kommt, bevor überhaupt die dafür nötigen Kernel-Module geladen werden, Und warum (none)? Ist cpufreqd mit den Atom-CPUs nicht kompatibel?</p> <p>Und cpufreq-info sagt mir nur:</p> <pre><code class="block">cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0:   no or unknown cpufreq driver is active on this CPU   maximum transition latency: 0.00 ms. analyzing CPU 1:   no or unknown cpufreq driver is active on this CPU   maximum transition latency: 0.00 ms. </code></pre> <p>Im <a href="http://wiki.debian.org/HowTo/CpuFrequencyScaling#Troubleshooting" rel="nofollow noopener noreferrer">Debian-Wiki</a> finde ich den lapidaren Hinweis, man könne mit [Befehlszeile] eine Liste der verfügbaren CPUFreq-Treiber abrufen. Da ist aber nichts dabei, was von der Bezeichnung her irgendwie auf eine Atom-CPU schließen lässt.</p> <p>Eigenartig finde ich auch, dass ich die oben zitierten Meldungen beim Systemstart nur an der Konsole erscheinen, aber weder in /var/log/messages, noch in /var/log/dmesg, noch in /var/log/syslog auftauchen.</p> <p>Tja, was den Startvorgang von Linux und dessen Debugging betrifft, bin ich leider noch recht unbeholfen. Kann mir jemand helfen? An welcher Stelle müsste ich ansetzen? Wo finde ich die nötigen Informationen?</p> <p>Ach ja, noch was finde ich eigenartig: Der Onboard-Netzwerkcontroller ist laut Auskunft von lspci ein "Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)". Das stimmt schon mal nicht ganz, es ist nur ein 100Mbit-Controller und kein Fast Ethernet. Linux hat allerdings den Treiber für den RTL8169-Chip ausgewählt. Das scheint tadellos zu funktionieren, anscheinend sind die kompatibel. Aber die vielen kleinen Unstimmigkeiten sind doch merkwürdig.</p> <p>So long,<br>  Martin</p> <div class="signature">-- <br> Elefant zum Kamel: "Sag mal, wieso hast du denn den Busen auf dem Rücken?"<br> Kamel:             "Ziemlich freche Frage für einen, der den Penis im Gesicht hat."<br> Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:( </div> https://forum.selfhtml.org/self/2013/apr/2/debian-cpufreqd-verweigert-kooperation-mit-atom-cpu/1576306#m1576306 Jens Holzkämper holzi@woodfighter.de 2013-04-02T17:35:33Z 2013-04-02T17:35:33Z Debian: cpufreqd verweigert Kooperation mit Atom-CPU <p>Tach,</p> <blockquote> <p>überhaupt die dafür nötigen Kernel-Module geladen werden, Und warum (none)? Ist cpufreqd mit den Atom-CPUs nicht kompatibel?</p> </blockquote> <p>ja, die <a href="http://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors#.22Diamondville.22_.2845_nm.29" rel="nofollow noopener noreferrer">CPU</a> unterstützt keine variable Taktfrequenz (SpeedStep).</p> <blockquote> <p>Das stimmt schon mal nicht ganz, es ist nur ein 100Mbit-Controller und kein Fast Ethernet.</p> </blockquote> <p>100MBit ist FastEthernet.</p> <blockquote> <p>Linux hat allerdings den Treiber für den RTL8169-Chip ausgewählt. Das scheint tadellos zu funktionieren, anscheinend sind die kompatibel.</p> </blockquote> <p>Es ist nicht ungewöhnlich, dass ein Treiber für diverse zu einer Familie gehörende Chips funktioniert, im <a href="http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/drivers/net/r8169.c" rel="nofollow noopener noreferrer">Code</a> heißt er inzwischen auch "RealTek 8169/8168/8101 ethernet driver" und wenn man reinschaut sieht man auch noch mehr unterstützte Karten.</p> <p>mfg<br> Woodfighter</p> https://forum.selfhtml.org/self/2013/apr/2/debian-cpufreqd-verweigert-kooperation-mit-atom-cpu/1576307#m1576307 Der Martin self@kennst.net 2013-04-02T18:00:00Z 2013-04-02T18:00:00Z Debian: cpufreqd verweigert Kooperation mit Atom-CPU <p>Hallo,</p> <blockquote> <blockquote> <p>Ist cpufreqd mit den Atom-CPUs nicht kompatibel?<br> ja, die <a href="http://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors#.22Diamondville.22_.2845_nm.29" rel="nofollow noopener noreferrer">CPU</a> unterstützt keine variable Taktfrequenz (SpeedStep).</p> </blockquote> </blockquote> <p>woraus genau leitest du das ab? Ich kann das an den angegebenen Informationen nämlich nicht erkennen. - Wenn das stimmt, kann ich die Suche natürlich einstellen und cpufreqd (mitsamt cpufreqtools) wieder rausnehmen.</p> <blockquote> <blockquote> <p>Das stimmt schon mal nicht ganz, es ist nur ein 100Mbit-Controller und kein Fast Ethernet.<br> 100MBit ist FastEthernet.</p> </blockquote> </blockquote> <p>Huh? Unter Fast Ethernet habe ich bisher Gigabit verstanden, das andere ist ja völlig normal und alles andere als "fast". Gut, ist natürlich Ansichtssache, und solche Prosa-Bezeichnungen sind immer heikel. Siehe USB: In USB 1.x unterschied man noch zwischen Low-Speed und Full-Speed, in USB2.0 kam High-Speed dazu und Full Speed war eben nicht mehr wirklich Full Speed.</p> <blockquote> <blockquote> <p>Linux hat allerdings den Treiber für den RTL8169-Chip ausgewählt. Das scheint tadellos zu funktionieren, anscheinend sind die kompatibel.<br> Es ist nicht ungewöhnlich, dass ein Treiber für diverse zu einer Familie gehörende Chips funktioniert</p> </blockquote> </blockquote> <p>Ja, ist mir klar. Nur hier war ich verblüfft, weil der 8169 gerade ein Gigabit-tauglicher Chip ist, der 8101 nicht.</p> <blockquote> <p>im <a href="http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/drivers/net/r8169.c" rel="nofollow noopener noreferrer">Code</a> heißt er inzwischen auch "RealTek 8169/8168/8101 ethernet driver" und wenn man reinschaut sieht man auch noch mehr unterstützte Karten.</p> </blockquote> <p>Okay, danke fürs Raussuchen. Nur mit dem 8168 ist er nicht wirklich kompatibel, obwohl er es behauptet. In einschlägigen Foren wimmelt es von Problemberichten mit dem 8169-Treiber, der für einen 8169-Chip automatisch ausgewählt wurde. Die Effekte reichen von "geht manchmal" über "sehr, sehr langsam" und "geht gar nicht" bis hin zu "System friert komplett ein". Und ich erinnere mich, dass ich "damals", als ich Gentoo auf der Büchse aufgesetzt habe, die jetzt auf Debian umsteigen soll, keinen generischen Kernel verwenden konnte, sondern einen RTL8168-Treiber direkt vom Hersteller besorgen und eincompilieren musste.</p> <p>Schönen Abend noch,<br>  Martin</p> <div class="signature">-- <br> Nicht jeder, der aus dem Rahmen fällt, war vorher im Bilde.<br> Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:( </div> https://forum.selfhtml.org/self/2013/apr/2/debian-cpufreqd-verweigert-kooperation-mit-atom-cpu/1576308#m1576308 Jens Holzkämper holzi@woodfighter.de 2013-04-02T20:02:53Z 2013-04-02T20:02:53Z Debian: cpufreqd verweigert Kooperation mit Atom-CPU <p>Tach,</p> <blockquote> <blockquote> <p>ja, die <a href="http://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors#.22Diamondville.22_.2845_nm.29" rel="nofollow noopener noreferrer">CPU</a> unterstützt keine variable Taktfrequenz (SpeedStep).</p> </blockquote> <p>woraus genau leitest du das ab? Ich kann das an den angegebenen Informationen nämlich nicht erkennen. - Wenn das stimmt, kann ich die Suche natürlich einstellen und cpufreqd (mitsamt cpufreqtools) wieder rausnehmen.</p> </blockquote> <p>daran dass bei den SpeedStep unterstützenden Prozessoren dran steht, dass sie es können; in der deutschen Wikipedia steht es auch explizit: <a href="http://de.wikipedia.org/wiki/Intel_Atom#Diamondville_.28Atom-.28N.29200-_und_300-Serie.29" rel="nofollow noopener noreferrer">http://de.wikipedia.org/wiki/Intel_Atom#Diamondville_.28Atom-.28N.29200-_und_300-Serie.29</a></p> <blockquote> <p>Huh? Unter Fast Ethernet habe ich bisher Gigabit verstanden, das andere ist ja völlig normal und alles andere als "fast".</p> </blockquote> <p>Als es eingeführt wurde, war es 10 mal schneller; Gigabit Ethernet heißt hilfreicherweise einfach Gigabit Ethernet.</p> <p>mfg<br> Woodfighter</p>