staging.inyokaproject.org

Vor gut einem Jahr hatte ich das erste Mal einen PC auf dem Tisch bei dem SpeedStep nicht funktioniert.

Inzwischen häufen sich diese Fälle und es sind immer Fertig PCs von bekannte Firmen betroffen. DELL fällt mir dabei besonders negativ auf.

Nachdem also immer häufiger dieses Verhalten da ist, habe ich mal etwas Zeit investiert und nach den Gründen gesucht. Ergebnis: Fehler in den ACPI Tables des BIOS. Diese werden beim PC Start ausgelesen. Im laufendem System findet man diese Einstellungen unter /sys/firmware/acpi/tables/DSDT

Die Tables liegen binär vor, lassen sich einfach decompilieren, danach wieder compilieren zeigt dann schon etwas von der "Qualität" der Programmierer. Beispiel an einem DELL Vostro:

ASL Input:     dsdt.dsl - 6853 lines, 196252 bytes, 2698 keywords
ASM Source:    dsdt.asm - 600063 bytes

Compilation complete. 16 Errors, 7 Warnings, 10 Remarks, 68 Optimizations

Wie gesagt, aus dem Orginal, ohne Änderungen..

Jetzt kann man hingehen und mit viel Mühe die einzelnen Fehlermeldungen per Google suchen und beheben bis das Compilieren null Fehler ausgibt. Das ist aber noch keine Garantie das damit auch das fehlerhafte Auslesen der CPU Features und Timings behoben sind. Bei DELL kann man davon ausgehen dass das nicht der Fall ist. Da werden diese Daten (mit Absicht?) so ausgegeben das nur Windows damit etwas anfangen kann. Es wäre also weitere zeitaufwändige Recherche notwendig um das zu ändern.

Ich gehe in diesem Fall den einfacheren Weg. DELL und Medion werden von mir nicht mehr umgerüstet auf Linux.

Besser wäre schlicht kein DELL und schon gar kein Medion zu kaufen. Es gibt genug Händler wo man Linux kaufen kann und wo man ebenfalls professionellen Support dazu bekommt. Ansonsten bleibt noch selbst bauen und Teile anpassen.

Tids schrieb:

Besser wäre schlicht kein DELL und schon gar kein Medion zu kaufen. Es gibt genug Händler wo man Linux kaufen kann und wo man ebenfalls professionellen Support dazu bekommt. Ansonsten bleibt noch selbst bauen und Teile anpassen.

bei mir rennst Du damit offene Türen ein. Leider lernen meine willigen Umsteiger immer erst aus eigener Erfahrung.

Seltsam. Ich hatte mit Dell-Rechnern noch nie Probleme. Hast du mal nachgeschaut, ob es für die Mainboards bzw. Notebooks BIOS-Updates gibt? Dell produziert für einige Notebooks auch Jahre nach Produktionsende BIOS-Updates.

Was die Fehler in den ACPI-Tabellen betrifft:

Nicht jeder Fehler in der DSDT führt automatisch zu einem Fehler unter Linux. Gerade die neueren Kernelversionen sind viel toleranter gegenüber Fehlern in den ACPI-Tabellen geworden.

Ansonsten kannst du mal die Anleitung unter dem folgenden Link ausprobieren:

Launchpad Bug: Allow custom DSDT overrides in grub per default

Vorher musst du natürlich die Bugs in der DSDT korrigieren.

glasenisback schrieb:

Seltsam. Ich hatte mit Dell-Rechnern noch nie Probleme. Hast du mal nachgeschaut, ob es für die Mainboards bzw. Notebooks BIOS-Updates gibt? Dell produziert für einige Notebooks auch Jahre nach Produktionsende BIOS-Updates.

Was die Fehler in den ACPI-Tabellen betrifft:

Nicht jeder Fehler in der DSDT führt automatisch zu einem Fehler unter Linux. Gerade die neueren Kernelversionen sind viel toleranter gegenüber Fehlern in den ACPI-Tabellen geworden.

Ansonsten kannst du mal die Anleitung unter dem folgenden Link ausprobieren:

Launchpad Bug: Allow custom DSDT overrides in grub per default

Vorher musst du natürlich die Bugs in der DSDT korrigieren.

Soweit war ich schon...

Dell kompiliert viele ihrer Rechner mit dem Windows iasl Compiler. Die Werte für die CPUs, Timings, Frequenzen u.s.w., werden dabei gar nicht erst erstellt, die bringt dann Windows direkt mit. Es wäre also also nicht nur notwendig die Fehler zu beheben sondern zusätzlich auch die notwendigen Werte dazu zu schreiben. Und diesen Aufwand werde ich sicher nicht machen. Dafür gibt es genug Hardware auf dem Markt die sich an die allgemein gültigen Standards halten.

Inzwischen wissen alle die ich betreue, das Medion und Dell von mir keinen Support mehr erhalten. Das Problem wird sich damit in kürzester Zeit von selbst erledigen.

Bleys schrieb:

Dell kompiliert viele ihrer Rechner mit dem Windows iasl Compiler. Die Werte für die CPUs, Timings, Frequenzen u.s.w., werden dabei gar nicht erst erstellt, die bringt dann Windows direkt mit.

Das ist Blödsinn. Windows kann sich solche Werte auch nicht aus den Fingern saugen. Und wenn es so wäre, könnte es auch Linux. Der MS-Compiler ist einfach nur toleranter gegenüber Fehlern. Dazu kommt halt, dass die Hersteller ihre Produkte zu 99,9% nur unter Windows testen.

Mich würde aber interessieren, welches spezielle Notebook zu Probleme macht. Ich hatte jahrelang nur Dell-Notebooks und nie irgendwelche Probleme mit diesen (Abgesehen vom berüchtigten 855GM-Bug, aber da konnte Dell nichts dafür).

glasenisback schrieb: Ich hatte jahrelang nur Dell-Notebooks und nie irgendwelche Probleme mit diesen.......

Dem kann ich mich nur anschliessen, zumindest was die Latitude-Serie anbetrifft.

Gruß

glasenisback schrieb:

Bleys schrieb:

Dell kompiliert viele ihrer Rechner mit dem Windows iasl Compiler. Die Werte für die CPUs, Timings, Frequenzen u.s.w., werden dabei gar nicht erst erstellt, die bringt dann Windows direkt mit.

Das ist Blödsinn. Windows kann sich solche Werte auch nicht aus den Fingern saugen. Und wenn es so wäre, könnte es auch Linux. Der MS-Compiler ist einfach nur toleranter gegenüber Fehlern. Dazu kommt halt, dass die Hersteller ihre Produkte zu 99,9% nur unter Windows testen.

Ja, das hab ich auch erst glauben können nach dem es mir nicht möglich war in der decompilierten dsdt.asm die Pakete zu Frequenzen der Orginal verbauten Intel CPU zu finden. Eine SSDT gibt es auch nicht.

Auszüge fwts eines DEll Vostro 230:

microcode: Test if system is using latest microcode.
--------------------------------------------------------------------------------
Test 1 of 1: Test for most recent microcode being loaded.
This test verifies if the firmware has put a recent revision of the microcode
into the processor at boot time. Recent microcode is important to have all the
required features and errata updates for the processor.
FAILED [MEDIUM] MicrocodeNotUpdated: Test 1, The kernel did not report that CPU
0 has had a microcode update. The current firmware is revision 0xa0b and
probably has not been updated.
FAILED [MEDIUM] MicrocodeNotUpdated: Test 1, The kernel did not report that CPU
1 has had a microcode update. The current firmware is revision 0xa0b and
probably has not been updated.

================================================================================
0 passed, 2 failed, 0 warning, 0 aborted, 0 skipped, 0 info only.
================================================================================

maxfreq: Test max CPU frequencies against max scaling frequency.
--------------------------------------------------------------------------------
Test 1 of 1: Maximum CPU frequency test.
This test checks the maximum CPU frequency as detected by the kernel for each
CPU against maxiumum frequency as specified by the BIOS frequency scaling
settings.
PASSED: Test 1, 2 CPUs passed the maximum frequency check.

================================================================================
1 passed, 0 failed, 0 warning, 0 aborted, 0 skipped, 0 info only.
================================================================================

Das BIOS liefert ausschließlich die maxfreq der CPU. Trotzdem taktet Windows die CPU korrekt durch alle möglichen Frequenzen der CPU. Wenn also "MS-Compiler ist einfach nur toleranter gegenüber Fehlern" heißt, dass Windows die nicht gelieferten Taktstufen irgendwie doch aus den Tables holt und nicht aus anderen Quellen, dann ist meine Aussage natürlich Blödsinn....

[Nachtrag]

Bill Gates überlegte 1999, ob er ACPI so gestalten sollte, dass andere Betriebssysteme Probleme mit der Implementierung dessen haben:^[4]

“One thing I find myself wondering about is whether we shouldn’t try and make the “ACPI” extensions somehow Windows specific. It seems unfortunate if we do this work and get our partners to do the work and the result is that Linux works great without having to do the work. Maybe there is no way to avoid this problem but it does bother me. Maybe we could define the APIs so that they work well with NT and not the others even if they are open. Or maybe we could patent something related to this.”

Quelle

Was willst du den jetzt mit dem Microcode-Test? Das hat nichts mit den ACPI-Tabellen zu tun, sondern nur mit der CPU. Hast du mal das Paket "intel-microcode" installiert? Dann gibt es nämlich keine Fehlermeldung bei diesem Test.

Was für eine Aussage der maxfreq-Test haben soll, erschließt sich mir auch nicht. Dort steht nur, dass der Rechner die maximale Frequenz korrekt auslesen kann. Es steht aber nirgends, dass der Test die Skaling-Funktionen testet.

In den ACPI-Tabellen stehen die Frequenzen übrigens nicht direkt drin. Diese sind in der CPU enthalten. ACPI definiert nur eine Schnittstelle zum Auslesen und Setzen der Frequenzen.

Was das Bill Gates-Zitat betrifft:

Das war vor 15 Jahren. In der Zwischenzeit unterstützt Linux ACPI sehr gut. Probleme gibt es immer nur dann, wenn ein Hersteller 100% auf Windows fixiert ist und Bugs in den ACPI-Tabellen keine Auswirkung auf Windows, aber auf Linux haben.

P.S.:

Hast du die aktuellste BIOS-Version bei dem Vostro installiert?

glasenisback schrieb:

Was willst du den jetzt mit dem Microcode-Test? Das hat nichts mit den ACPI-Tabellen zu tun, sondern nur mit der CPU. Hast du mal das Paket "intel-microcode" installiert? Dann gibt es nämlich keine Fehlermeldung bei diesem Test.

fwts hat ausschließlich etwas mit dem BIOS/ACPI zu tun.

Was für eine Aussage der maxfreq-Test haben soll, erschließt sich mir auch nicht. Dort steht nur, dass der Rechner die maximale Frequenz korrekt auslesen kann. Es steht aber nirgends, dass der Test die Skaling-Funktionen testet.

fwts testet die Firmware (BIOS) und nicht wie das Hostsystem damit umgeht. Und diese Tests stellen schlicht fest das es keine Informationen über Spannungen und Taktstufen zur CPU in der Firmware gibt.

In den ACPI-Tabellen stehen die Frequenzen übrigens nicht direkt drin. Diese sind in der CPU enthalten. ACPI definiert nur eine Schnittstelle zum Auslesen und Setzen der Frequenzen.

Auch das ist falsch, diese Informationen stehen in den Tables. Oder besser, sollten drin stehen: ACPI

Hast du die aktuellste BIOS-Version bei dem Vostro installiert?

Natürlich, war die erste Aktion.

[Nachtrag]

Hier mal ein Auszug einer CPU eines DSDT Beispiel wo es korrekt vorhanden ist und funktioniert:

Scope (_PR)
    {
  Name (PPC, 0x00)
    
  Name (PCT, Package (0x02){ 
            ResourceTemplate (){Register (FFixedHW, 0x4, 0x00, 0x199, ,)
            }, 

            ResourceTemplate (){Register (FFixedHW, 0x4, 0x00, 0x199, ,)
            }
        })
  Name (PSS, Package (0x06){ 
    
                        Package (0x06){3600,,0x0A,0x0A,0x2400,0x2400}, // p-state 0
                        Package (0x06){3100,,0x0A,0x0A,0x1f00,0x1f00}, // p-state 1
                        Package (0x06){2600,,0x0A,0x0A,0x1a00,0x1a00}, // p-state 2
                        Package (0x06){1600,,0x0A,0x0A,0x1000,0x1000}, // p-state 3
                        Package (0x06){1200,,0x0A,0x0A,0x0c00,0x0c00}, // p-state 4
                        Package (0x06){ 800,,0x0A,0x0A,0x0800,0x0800}, // p-state 5
                })

Und ja, der erste Wert in den geschweiften Klammern sind die Frequenzen die per SpeedStep unterstützt werden. Der komplette Block fehlt im BIOS des Vostro.

Bleys schrieb:

fwts hat ausschließlich etwas mit dem BOIS/ACPI zu tun.

Aber nicht der zitierte Test. Der betrifft den CPU-Microcode. Um diesen auf den, für diese spezielle CPU, aktuellsten Stand zu bringen, musst du das Paket "intel-microcode" installieren.

fwts testet die Firmware (BIOS) und nicht wie das Hostsystem damit umgeht. Und diese Tests stellen schlicht fest das es keine Informationen über Spannungen und Taktstufen zur CPU in der Firmware gibt.

Aber eben nicht dieser spezielle Test:

https://wiki.ubuntu.com/Kernel/Reference/fwts/maxfreq

Auch das ist falsch, diese Informationen stehen in den Tables. Oder besser, sollten drin stehen: ACPI

Nein stehen sie nicht. Zumindest stehen dort keine Frequenzen, sondern nur die einzelnen "Performance States" bzw. "P-States". Siehe auch Kapitel 8.1 der verlinkten PDF-Datei.

Natürlich, war die erste Aktion.

War nur eine Frage.

Edit:

Die Einträge tauchen bei meinem Rechner auch nicht auf und trotzdem funktioniert die Frequenzanpassung problemlos. Und wenn sie unter Windows problemlos funktioniert, ist die Tabelle auch nicht zwingend notwendig.

Für alle die das gerne mal selbst testen möchten. Ist allerdings etwas an Ersatz Hardware notwendig:

• Ein BIOS kastrierte Rechner. Dell oder Medion bieten sich an. Im Beispiel: Dell Vostro 230

• Eine zum Rechner passende CPU die nicht per default verbaut ist. Ich habe dafür einen C2D E8400

• Windows 7 pro installiert und Speedstep funktionierend mit dem ab Werk verbauten C2D E7500. Zum Testen: CPU-Z

• Windows Update ausgeschaltet!

Rechner runter fahren, CPU wechseln. Von E7500 zu E8400. Rechner wieder hochfahren:

Speedstep funktioniert auch unter Windows nicht! Zur Sicherheit mehrfach neu gestartet, länger genutzt.

Windows Update wieder einschalten und updaten lassen. Nach einem Neustart funktioniert Speedstep wieder...

Nochmals:

Hast du unter Ubuntu das Paket "intel-microcode" installiert?

Wahrscheinlich liefert Windows 7 nur ein passendes Microcode-Update nach und aktiviert dadurch Speedstep bei dieser CPU. Denn wenn es unter Windows erst nicht und nach einem installieren Update funktioniert, dann müsste das auch unter Linux möglich sein. Windows kann bei einem "defekten" BIOS auch nicht zaubern.

Hilfreich wäre es halt, wenn du wissen würdest, was unter Windows genau nachinstalliert wurde (KB-Nummer des Updates).