T6x Anleitung: FSB 1066 CPUs inkl. Core 2 Quad in Thinkpad T61 benutzen + GPU undervolten

[el-sahef]

Hallo,

meine Tests von hier mit dem Core 2 Quad Q9000 haben nun doch noch Früchte getragen .

Die benötigten Schritte, um eine FSB-1066-CPU in einem T61 zu betreiben, sind ja schon seit langem hier im Forum und an anderer Stelle im Internet zu finden. Nun ist es mir gelungen, basierend darauf auch einen Q9000 in einem T61-Board zum Laufen zu bekommen und zwar mit allen vier Cores aktiv.

Hier nun der Versuch, das ganze in einer Anleitung zusammenzufassen.


Teil 1: Wahl eines Mod-BIOS / GPU undervolten

Auf 51nb.com gibt es modifizierte BIOS-Dateien, die die Microcodes für die FSB-1066-CPUs drin haben. Im originalen Lenovo-BIOS sind diese nicht enthalten, weswegen die CPUs mit FSB 1066 (z. B. die Pxxxx-Serie) im T61 ab Werk nicht laufen.

Ursprünglich war nur eine BIOS-Version von xiaofei290 verfügbar, die die Microcodes vom W700 anstatt vom T61 drin hatte. Mit dieser Version funktionierten zwar FSB-1066-CPUs (inklusive Core2 Quad), die vorher nicht unterstützt wurden, dafür haben aber viele CPUs, die vorher im T61 liefen (z. B. T7500), anschließend nicht mehr funktioniert, da die Microcodes für diese im Mod-BIOS fehlten. Zudem war es beim Einbau eines Core2 Quad mit diesem BIOS nötig, eine modifizierte APIC-Tabelle mit dem acpi-Kommando des Bootloaders Grub2 zu laden, damit alle vier CPU-Kerne aktiviert wurden (statt nur zwei). Diese ursprüngliche Methode ist als Referenz noch in einen Post weiter unten ausgelagert, heute jedoch nicht mehr zu empfehlen. Ich verlinke das alte Mod-BIOS hier noch, jedoch gibt es nun eine deutlich bessere Alternative.

Originalpost von xiaofei290 auf 51nb.com Download-Link

Mittlerweile ist eine ganze Fülle von Mod-BIOS-Versionen von highsun auf 51nb.com verfügbar, unter anderem auch welche extra für Core2 Quads, die die modifizierte APIC-Tabelle bereits enthalten, so dass außer dem BIOS-Flash softwareseitig keine weiteren Änderungen mehr erforderlich sind. Bei all diesen Mod-BIOS-Versionen sind so gut wie alle Microcodes der Core2-Prozessoren enthalten, so dass anders als beim ursprünglichen Mod-BIOS auch Merom-CPUs wie z. B. T7500 weiterhin damit funktionieren. Zudem schalten sie SATA 2 frei und die Whitelist sowie den Thermal Sensing Error ab.

Außerdem gibt es Versionen, die den Nvidia-Grafikchip undervolten (sofern vorhanden) und so Stromverbrauch und Temperaturen senken, wodurch vermutlich auch das Ausfallrisiko durch den Nvidia-Bug verringert wird. Mit dem Lenovo-BIOS wird der Grafikchip standardmäßig mit 1,20 V unter Last und 1,15V im idle beterieben. Die Mod-BIOS-Versionen betreiben den Grafikchip immer mit der gleichen Spannung.

Weitere Versionen aktivieren PCIe Active State Power Management oder übertakten den Nvidia-Grafikchip auf core 450 400 / shader 900 / video-ram 700.

Originalpost von highsun auf 51nb.com Achtung, die Bios-Dateien mit dem GPU-Undervolting im ersten Post dort hatten noch einen Fehler drin, die berichtigten Versionen sind dort in Post 76 und hier in der Tabelle verlinkt.

[TABLE="class: grid, width: 1000, align: left"]
[TR]
[TD]Mod-BIOS Download-Link
[/TD]
[TD]Quadcore-APIC-Tabelle
[/TD]
[TD]Spannung der Nvidia-GPU
[/TD]
[TD]ASPM aktiviert
[/TD]
[TD]NVidia-GPU übertaktet
[/TD]
[/TR]
[TR]
[TD]专门网论坛_T61-BIOS.rar
[/TD]
[TD]nein[/TD]
[TD]Standard (1,15 V - 1,20 V)[/TD]
[TD]nein[/TD]
[TD]nein[/TD]
[/TR]
[TR]
[TD]专门网论坛_T61Q_BIOS.rar
[/TD]
[TD]ja[/TD]
[TD]Standard (1,15 V - 1,20 V)[/TD]
[TD]nein[/TD]
[TD]nein[/TD]
[/TR]
[TR]
[TD]专门网论坛_T61-BIOS(1.05).rar
[/TD]
[TD]nein[/TD]
[TD]1,05 V[/TD]
[TD]nein[/TD]
[TD]nein[/TD]
[/TR]
[TR]
[TD]专门网论坛_T61-BIOS(1.05)_ASPM.rar
[/TD]
[TD]nein[/TD]
[TD]1,05 V[/TD]
[TD]ja[/TD]
[TD]nein[/TD]
[/TR]
[TR]
[TD]专门网论坛_T61Q_BIOS(1.05).rar
[/TD]
[TD]ja[/TD]
[TD]1,05 V[/TD]
[TD]nein[/TD]
[TD]nein[/TD]
[/TR]
[TR]
[TD]专门网论坛_T61Q_BIOS(1.05)_ASPM.rar
[/TD]
[TD]ja[/TD]
[TD]1,05 V[/TD]
[TD]ja[/TD]
[TD]nein[/TD]
[/TR]
[TR]
[TD]专门网论坛_T61-BIOS(1.0).rar
[/TD]
[TD]nein[/TD]
[TD]1,00 V[/TD]
[TD]nein[/TD]
[TD]nein[/TD]
[/TR]
[TR]
[TD]专门网论坛_T61-BIOS(1.0)_ASPM.rar
[/TD]
[TD]nein[/TD]
[TD]1,00 V[/TD]
[TD]ja[/TD]
[TD]nein[/TD]
[/TR]
[TR]
[TD]专门网论坛_T61-BIOS(1.0)_OC.rar
[/TD]
[TD]nein[/TD]
[TD]1,00 V[/TD]
[TD]nein[/TD]
[TD]ja[/TD]
[/TR]
[TR]
[TD]专门网论坛_T61-BIOS(1.0)_ASPM_OC.rar
[/TD]
[TD]nein[/TD]
[TD]1,00 V[/TD]
[TD]ja[/TD]
[TD]ja[/TD]
[/TR]
[TR]
[TD]专门网论坛_T61Q_BIOS(1.0).rar
[/TD]
[TD]ja[/TD]
[TD]1,00 V[/TD]
[TD]nein[/TD]
[TD]nein[/TD]
[/TR]
[TR]
[TD]专门网论坛_T61Q_BIOS(1.0)_ASPM.rar
[/TD]
[TD]ja[/TD]
[TD]1,00 V[/TD]
[TD]ja[/TD]
[TD]nein[/TD]
[/TR]
[TR]
[TD]专门网论坛_T61Q_BIOS(1.0)_OC.rar
[/TD]
[TD]ja[/TD]
[TD]1,00 V[/TD]
[TD]nein[/TD]
[TD]ja[/TD]
[/TR]
[TR]
[TD]专门网论坛_T61Q_BIOS(1.0)_ASPM_OC.rar
[/TD]
[TD]ja[/TD]
[TD]1,00 V[/TD]
[TD]ja[/TD]
[TD]ja[/TD]
[/TR]
[TR]
[TD]专门网论坛_T61-BIOS(0.95).rar
[/TD]
[TD]nein[/TD]
[TD]0,95 V[/TD]
[TD]nein[/TD]
[TD]nein[/TD]
[/TR]
[TR]
[TD]专门网论坛_T61-BIOS(0.95)_ASPM.rar
[/TD]
[TD]nein[/TD]
[TD]0,95 V[/TD]
[TD]ja[/TD]
[TD]nein[/TD]
[/TR]
[TR]
[TD]专门网论坛_T61Q_BIOS(0.95).rar
[/TD]
[TD]ja[/TD]
[TD]0,95 V[/TD]
[TD]nein[/TD]
[TD]nein[/TD]
[/TR]
[TR]
[TD]专门网论坛_T61Q_BIOS(0.95)_ASPM.rar
[/TD]
[TD]ja[/TD]
[TD]0,95 V[/TD]
[TD]ja[/TD]
[TD]nein[/TD]
[/TR]
[TR]
[TD]专门网论坛_T61-BIOS(0.9).rar
[/TD]
[TD]nein[/TD]
[TD]0,90V[/TD]
[TD]nein[/TD]
[TD]nein[/TD]
[/TR]
[TR]
[TD]专门网论坛_T61-BIOS(0.9)_ASPM.rar
[/TD]
[TD]nein[/TD]
[TD]0,90V[/TD]
[TD]ja[/TD]
[TD]nein[/TD]
[/TR]
[TR]
[TD]专门网论坛_T61Q_BIOS(0.9).rar
[/TD]
[TD]ja[/TD]
[TD]0,90V[/TD]
[TD]nein[/TD]
[TD]nein[/TD]
[/TR]
[TR]
[TD]专门网论坛_T61Q_BIOS(0.9)_ASPM_.rar
[/TD]
[TD]ja[/TD]
[TD]0,90V[/TD]
[TD]ja[/TD]
[TD]nein[/TD]
[/TR]
[/TABLE]

Zuerst überprüfen, ob man die neuste EC-Firmware 1.08 auf seinem T61 hat. Falls nicht, zunächst das neuste BIOS von Lenovo flashen, dabei wird auch die EC-Firmware aktualisiert. Danach das Mod-BIOS seiner Wahl sowie den Flasher herunterladen und die Archive entpacken, die BIOS-Datei von <DATEINAME>.ROM nach BIOS.ROM umbenennen. Anschließend einen bootbaren USB-Stick mit DOS erstellen und die Dateien go.bat, phlash16.exe und BIOS.ROM drauf kopieren.
Vom Stick booten und wenn ihr auf der Kommandozeile seid go.bat eingeben und Enter drücken. Danach kommt eine Fehlermeldung, dass irgendeine Checksumme falsch sei. Diese durch Drücken von z ignorieren, der Flash funktioniert trotzdem.

Alternativ kann man auf der Kommandozeile folgendes eingeben:

phlash16.exe BIOS.ROM /S /X /C /MODE=3 /BO=BACK.ROM

Dies speichert das alte BIOS in BACK.ROM und flasht anschließend das Mod-BIOS (BIOS.ROM). Ich habe es zwar nicht ausprobiert, gehe aber davon aus, dass ihr mit

phlash16.exe BACK.ROM /S /X /C /MODE=3

das alte BIOS wieder einspielen könnt, solltet ihr dies aus irgendwelchen Gründen wollen.

Teil 2: FSB-1066-CPUs im T61

Es gibt mehrere Gründe, warum FSB-1066-CPUs im T61 nicht laufen: Die Microcodes für diese CPUs sind nicht im originalen Lenovo-BIOS und der Chipsatz will 800 MHz FSB sehen, sonst startet das Gerät nicht (in anderen Notebooks gibt es auch die Variante, dass die CPU auf den niedrigsten Multiplikator 6x gelockt wird). Außerdem wird der RAM bei FSB-1066 übertaktet. Um dies zu unterbinden, muss das SPD eines DDR2-800-Riegels auf DDR2-667 oder sogar DDR2-533 geflasht und die Timings angepasst werden oder man besorgt sich RAM, der mit dem resultierenden Takt von 440 MHz mit den Timings für DDR2-667 stabil läuft.

1) SPD des RAMs flashen:

Jetzt am Anfang von Post #8 zu finden.

Da ich mittlerweile längst das blöde 20.000-Zeichen-Limit pro Post sprenge, muss ich Teile des ursprünglichen Posts dahin auslagern.


2) Mainboard modifizieren:

Zuerst schneidet man auf der Unterseite des Mainboards die gelb hinterlegte Leiterbahn durch. Die rot eingekreiste Stelle ist dafür wahrscheinlich noch am besten geeignet, woanders ist es noch enger. Hierbei muss man aufpassen, keine andere Leiterbahn in der Nähe in Mitleidenschaft zu ziehen. Ich habe ein sehr spitzes Skalpell benutzt.

Danach verbindet man die beiden rot eingekreisten Punkte mit einem Kabel.

Dadurch glaubt der Chipsatz, er würde mit FSB-800 bzw. 200 MHz betrieben, auch wenn der FSB tatsächlich 266 MHz beträgt. Macht man die Modifikation auf diese Weise, dann funktionieren sowohl FSB-667- und FSB-800-CPUs als auch FSB-1066-CPUs in dem Board automatisch mit ihrem nativen FSB.

Für 14,1-4:3-Boards und 15,4"-16:10-Boards:



Für 14,1-16:10-Boards ist die Stelle zum Durchritzen woanders:

Kabelverbindung für 14,1-16:10-Boards:

Teil 3: Core 2 Quad zum Laufen bringen:

1) CPU-Pins isolieren:

Damit ein Quadcore läuft, müssen die Pins D8, AA7, AA8, AC8 und AE8 isoliert werden. Ich habe hierfür die Isolierung von einem dünnen Kabel aus dem Modellbahn-Zubehör verwendet. Diese "Röhrchen" lassen sich dann mit einer Pinzette leicht auf die entsprechen Pins der CPU stecken.

Man kann stattdessen auch die entsprechenden Pins mit einem Seitenschneider abknipsen. Schmälert allerdings den Wiederverkaufswert des Core2 Quad .



2) Löcher im Sockel vergrößern:

Da die isolierten Pins jetzt dicker sind, müssen die entsprechenden Löcher im Sockel vergrößert werden, damit man die CPU noch reinstecken kann. Damit dabei keine Spähne in den Sockel kommen und die Kontakte nicht beschädigt werden habe ich zunächst das Oberteil mit den Löchern an den vier Schnapphaken seitlich ausgehängt und eine dünne Holzplatte zwischen den Sockel und das Oberteil mit den Löchern geschoben. Danach wurden die entsprechenden Löcher mit einem 1-mm-Bohrer per Hand aufgebohrt.

Auf keinen Fall versuchen, die Löcher aufzubohren, ohne das Oberteil auszuhängen, ansonsten schrottet man die Kontakte im Sockel! Dann noch lieber alle vier Haltenasen abschneiden.

Es gibt zwei verschiedene Sockel, einen schwarzen und einen weißen. Bilder, die zeigen, wie man das Oberteil am besten aushängt, befinden sich in Post #153.



T61-Mainboard Sockel nach der Änderung:


3) Mainboard modifizieren:

Zusätzlich zu den Modifikationen für FSB 1066 ist für den Betrieb eines Quad-Cores noch eine weitere Änderung am Mainboard nötig.

Es gibt ein Signal bzw. Pin GTLREF, an dem 0,63* VCC1R05B anliegen muss. Lenovo macht das über einen Spannungsteiler mit zwei Widerständen (2k und 1k). Bei Quad-Cores ist ein weiterer solcher Pin (D22) vorhanden, der bei den Dual-Cores Reserved ist. An den muss man auch die 0,63*VCC1R05B anlegen.

Für den entsprechenden Sockel-Kontakt ist eine Durchkontaktierung auf dem Mainboard, die man von der Unterseite anzapfen kann. T61-Mainboards der 14"-Widescreen-Modelle haben diese Durchkontaktierung nicht, nur bei den 14"-4:3-Boards und den 15,4"-Widescreen-Boards ist sie vorhanden.

Um den Pin D22 (GTLREF_2) auf 0,63*VCC1R05B zu setzen lötet man eine Kabelverbindung wie im Bild gezeigt von der Durchkontaktierung von GTLREF (Pin AD26) zur Durchkontaktierung von GTLREF_2 (Pin D22). Das Kabel sollte dabei möglichst kurz sein. Diese einfachere Variante stammt vom User FryPpy auf forum.thinkpads.com.

Die ursprünglich verwendete Variante war der Nachbau der Lenovo-Lösung vom W700-Mainboard mit zwei Extra-SMD-Widerständen für GTLREF_2, die aber wegen des erhöhten Aufwands gegenüber der Lösung mit der simplen Kabelverbindung nicht mehr zu empfehlen ist:



Jetzt kann man die Quad-Core-CPU im Sockel platzieren und damit booten.



Im BIOS sollte nun der C2Q richtig angezeigt werden. Hat man in Schritt 1 ein BIOS mit Quadcore-Support gewählt, so sollten im Betriebsystem auch alle vier Cores aktiviert sein.



Allerdings hat man noch das Problem, dass nur die ersten beiden Cores auch mit vollem Takt betrieben werden, die letzten beiden Cores laufen immer mit dem niedrigstem Takt. Siehe auch Post 130.
Um dieses Problem zu beheben, siehe Post 142, wo eine funktionierende Lösung für Windows und Linux beschrieben wird.

Stand der Dinge:

Ursprünglich gab es noch Stabilitätsprobleme, die jedoch auf falsche Timings bzw. Einstellungen beim Flashen des SPDs zurückgingen. Nach dem Umflashen des RAMs auf DDR2-667 mit den Timings vom DDR2-800-Profil sind diese verschwunden.
Die Kühlung des Q9000 ist nach dem Einbau eines Kühlers vom T500 mit ATI-Grafik kein Problem mehr und der Core2 Quad läuft absolut stabil. Ein Kühler vom T61 mit Nvidia-Grafik kühlt genauso gut, ist eventuell aber etwas lauter. Nicht zu empfehlen sind die Kühler vom T61 und T500 mit Intel-Grafik, da diese ca. 10°C schlechter kühlen als die zuvor genannten, sowie sämtliche T60-Kühler.

Wieso es beim T500 und W500 nicht geht:

Nun könnte man ja sagen: Das T500 und das R500 haben drei Phasen und nativen Support für FSB 1066, wieso nicht darauf testen? Nun, das habe ich ja zuerst getan, die Ergebnisse sind in diesem Thread in Post 18 und 23 zu finden. Hier musste ich aber, damit ich in ein Betriebssystem booten konnte, im BIOS "Core Multiprocessing" auf "disabled" stellen, so dass sogar nur ein Core aktiv war. Ein Test mit einem X61t, wo ich das auch deaktiviert hatte und dann über ne APIC-Tabelle den zweiten Core wieder aktivieren wollte schlug aber fehl. Demnach scheint es so zu sein, dass diese Option auf "enabled" stehen muss, damit man mittels eigener APIC-Tabelle zusätzliche Cores aktivieren kann. Das T61 bootet mit Quadcore und dieser Option auf "enabled" Betriebssysteme, das T500 nicht.
Nächster Punkt ist das Laden einer eigenen APIC-Tabelle mit GRUB2: Mit dem BIOS des T500 funktioniert dies nicht, bzw. nur mit der Option "-e", was dazu führt, dass nur GRUB2 die eigene APIC-Tabelle benutzt, nicht aber das Betriebssystem, was somit reichlich sinnlos ist.

Beim T500 und W500 bräuchte es also einen entsprechenden BIOS-Mod mit vollem Quad-Core-Support oder es müsste so umgeändert werden, dass man wie beim T61 mit "Core Multiprocessing" auf "enabled" booten und mit GRUB2 ne eigene APIC-Tabelle laden kann. Unwahrscheinlich, dass das jemand hinbekommt. Beim R500 fehlt die Durchkontaktierung am Sockel für den Mod des Mainboards und ob das BIOS sich wie das des T61 verhalten würde, habe ich nicht getestet. T400 und R400 kann ich mangels Hardware nicht testen.

 

[Thrakath]

Beim X9100 sollte ja eigentlich der Mulitplikator unlocked sein oder? Ist trotzdem bei 15 Schluss? Ich komme leider mit TS/IBM_ECW nicht höher.

 

[nightninja96]

Would I be able to use these bios on a Thinkpad with Intel graphics. Many thank

- - - Beitrag zusammengeführt - - -

Wäre ich in der Lage, diese Bios auf einem Thinkpad mit Intel-Grafik zu verwenden.Vielen Dank

 

[el-sahef]

Yes, you can use all the BIOS files from the first post on any T61 with Intel graphics. Any GPU undervolting for Nvidia graphics that might be included in that BIOS does not apply then.

 

[zsolt]

Hi !

Ich habe mich wegen dem thread hier angemeldet und möchte einen dankeschön dafür aussprechen.
Im Grunde war ich nur auf der suche nach einem Laptop mit rs-232...
Nach ein bisschen suche kam ich auf dem Entschluss das der t61 geeignet wäre , also ebay t61 15,4 Wide geschossen (das erst beste Angebot ) und den Ultrabay schacht rs232.

Nach ein bisschen google fand ich die Seite hier. Lange Rede kurzer Sinn , jetzt läuft ein q9100 in dem Ding und warte noch auf dem Backlight LED.
Bei der CPU stress komme ich um die 64 Grad Höchstwert und etwa 48 watt max. unter Manjaro mit tlp Einstellungen.

Auf jeden Fall, dank der Anleitung hat die Modifikation geklappt.
Was allerdings anders war als in der Beschreibung beschrieben ist, das der 0 Ohm Widerstand oder was das sein soll auf den Bildern um den FSB zu erhöhen, bei mir entfernt musste.
Zuerst habe ich den Kabel angelötet wie auf den Bilder zu sehen ist und es ging nichts. Nach mehreren versuchen zu starten habe ich den Kabel auf der andere Seite angelötet, also den Wiederstand ausgelassen und erst dann konnte ich booten.
Ich habe das Board mit der Nummer 41w6438 drinne, vielleicht hilft das jemanden der sich die mühe macht die 22 Seiten durchzulesen und das hier findet ,

Im nachhinein noch so viel, ich hätte mich besser für den x9100 entschieden, der q9100 lässt sich nicht so runtertakten und ich komme im besten Fall auf 16 watt .
Ich habe hier noch einen p8400 mit dem habe ich 9 watt geschafft!
Gruß

 

[fakeraol]

Zum Bootlogo:
* https://ittutorials.net/computer-repair/laptop/change-bios-boot-screen-logo-image-lenovo-laptops/
* https://thinkpad-forum.de/threads/1...Kinderleicht-(inkl-BIOS-Update-vom-USB-Stick)

Zu meiner Frage:
Da man für die GPU die Spannung mittels EC-Firmware-Patch absenken kann, müsste das doch auch für die CPU gehen? Das wäre doch mal eine Innovation, auch ohne Software-Tools gleich ab Boot kühler, länger, und leiser.
Dazu müsste man wissen, wie weit sich generell für alle Modelle, die von einer Bios-Version unterstützt werden, die Spannung pauschal absenken lässt, ohne daß dann einzelne Exemplare instabil werden. Evtl. kann man ja nach Tests per Software für sein individuelles Gerät dann noch eine weitere Absenkung vornehmen (alles über fertig gepatchte Bios-Dateien, so wie hier für die GPU).

Dazu bräuchte es jemanden, der sich mit der Modifikation dieser Dateien auskennt. el-sahef evtl.?
Oder geht sowas aus irgendwelchen Gründen garnicht per Firmware-Mod?

 

[Rimmsi]

Hi all, I have a question if something like that happened to someone. I flashed the Highsun BIOS 0,95 into my T61 with NVS 140m graphics card, operation was successful, the CPU P9700 works on the board, but graphics card is not undervolted, still running with factory voltage. I reflashed BIOS several times, without any change, voltage is still factory. Did anyone encounter a problem?Any idea what can be a problem? Thanks.

 

[el-sahef]

I also had this problem. No idea why it does not work in some boards. As far as I know the undervolting is active only when the driver is loaded so you have to check it when the operating system has booted up (Nvidia driver has to be installed) and not in the BIOS. There is also the possibility of a hardware mod: https://thinkpad-forum.de/threads/1...-undervolten?p=2093201&viewfull=1#post2093201

 

[Rimmsi]

Hardware mod is too complicated for me. I wonder if it is a difference in the board. I undervolted GPU using BIOS on many boards with FRU 44C3924, this board has FRU 42W7649.

 

[pentode]

I see other posts in English, hopefully nobody minds if I do!

I've done the quad core mod on a widescreen T61 and everything is working very well- except getting proper ACPI/voltage/multiplier settings working under linux. I'm hoping someone out there who has gotten things working under linux can point me in the right direction.

I'm running a Q9000 and I've modified the .aml files successfully as far as I can tell. They appear to be loaded by the kernel on boot, but I see differences between cores 0-1 and 2-3 from c2ctl, temperatures are higher than under windows with throttlestop, the multiplier changes on cores 0-1 under load but not on 2-3, and the voltage changes on 0-1 under load (which I think should remain steady?) while no changes occur on cores 2-3.

If anyone out there understands c2ctl and the specific needs of linux, I would dearly appreciate your insight. The machine runs great under Windows- but I don't

 

[el-sahef]

Did you do everything according to this post? Please post your SSDT6.

Normally, when the SSDT tables are loaded and Speedstep is activated with c2ctl on cores 2 and 3 frequency and voltage change should work on those too. So it seems that there is either a mistake in the SSDTs or they are not loaded properly.

 

[pentode]

Hi,
Thanks so much for helping.

edit: to be completely clear- yes, I did follow the instructions in that post.
I'm going to have to reboot into Linux to get the previous version of SSDT6 that I used, but I can tell you that the behavior was the same with this file as well as the earlier version where I made fewer edits. The first time, I only changed the few lines that you mentioned in your comments in a previous post. In this file I changed a few earlier values (in the SPSS section) to see if they had any effect. I have no experience with this acpi coding language.
edit: my instinct is that the code isn't being loaded properly. The kernel does report "loaded" though at 0.000 seconds in the log

 * Intel ACPI Component Architecture
 * AML Disassembler version 20130823-64
 * Copyright (c) 2000 - 2013 Intel Corporation
 * 
 * Disassembly of SSDT6.aml, Thu Jun  5 16:09:31 2014
 *
 * Original Table Header:
 *     Signature        "SSDT"
 *     Length           0x00000240 (576)
 *     Revision         0x01
 *     Checksum         0xA5
 *     OEM ID           "PmRef"
 *     OEM Table ID     "Cpu0Ist"
 *     OEM Revision     0x00000100 (256)
 *     Compiler ID      "INTL"
 *     Compiler Version 0x20050513 (537199891)
 */
DefinitionBlock ("SSDT6.aml", "SSDT", 1, "PmRef", "Cpu0Ist", 0x00000100)
{

    External (_PR_.CPU0, ProcessorObj)
    External (_SB_.PCI0.LPC_.EC__.HT10, FieldUnitObj)
    External (_SB_.PCI0.LPC_.EC__.LPMD, MethodObj)    // 0 Arguments
    External (CFGD, IntObj)
    External (DT00, FieldUnitObj)
    External (LWST, FieldUnitObj)
    External (NPSS, IntObj)
    External (PDC0, IntObj)

    Scope (\_PR.CPU0)
    {
        Method (_PPC, 0, NotSerialized)  // _PPC: Performance Present Capabilites
        {
            Store (0x00, Local0)
            Store (\_SB.PCI0.LPC.EC.LPMD (), Local0)
            If (LNot (Local0))
            {
                If (LOr (\DT00, \_SB.PCI0.LPC.EC.HT10))
                {
                    Store (\LWST, Local0)
                }
            }

            Return (Local0)
        }

        Method (_PCT, 0, NotSerialized)  // _PCT: Performance Control
        {
            If (LAnd (And (CFGD, 0x01), And (PDC0, 0x01)))
            {
                Return (Package (0x02)
                {
                    ResourceTemplate ()
                    {
                        Register (FFixedHW, 
                            0x00,               // Bit Width
                            0x00,               // Bit Offset
                            0x0000000000000000, // Address
                            ,)
                    }, 

                    ResourceTemplate ()
                    {
                        Register (FFixedHW, 
                            0x00,               // Bit Width
                            0x00,               // Bit Offset
                            0x0000000000000000, // Address
                            ,)
                    }
                })
            }

            Return (Package (0x02)
            {
                ResourceTemplate ()
                {
                    Register (SystemIO, 
                        0x10,               // Bit Width
                        0x00,               // Bit Offset
                        0x00000000000000B2, // Address
                        ,)
                }, 

                ResourceTemplate ()
                {
                    Register (SystemIO, 
                        0x08,               // Bit Width
                        0x00,               // Bit Offset
                        0x00000000000000B3, // Address
                        ,)
                }
            })
        }

        Method (XPSS, 0, NotSerialized)
        {
            If (And (PDC0, 0x01))
            {
                Return (NPSS)
            }

            Return (SPSS)
        }

        Name (SPSS, Package (0x03)
        {
            Package (0x06)
            {
                0x000007D0, 
                0x000088B8, 
                0x0000006E, 
                0x0000000A, 
                0x00000083, 
                0x00000000
            }, 

            Package (0x06)
            {
                0x00000640, 
                0x000088B8, 
                0x0000006E, 
                0x0000000A, 
                0x00000183, 
                0x00000001
            }, 

            Package (0x06)
            {
                0x000004B0, 
                0x00003E80, 
                0x0000006E, 
                0x0000000A, 
                0x00000283, 
                0x00000002
            }
        })
        Name (_PSS, Package (0x03)  // _PSS: Performance Supported States
        {
            Package (0x06)
            {
                0x000007D0, 
                0x000088B8, 
                0x0000000A, 
                0x0000000A, 
                0x0000471B, 
                0x0000471B
            }, 

            Package (0x06)
            {
                0x00000640, 
                0x000088B8, 
                0x0000000A, 
                0x0000000A, 
                0x0000461B, 
                0x0000461B
            }, 

            Package (0x06)
            {
                0x000004B0, 
                0x00003E80, 
                0x0000000A, 
                0x0000000A, 
                0x0000061B, 
                0x0000061B
            }
        })
        Method (_PSD, 0, NotSerialized)  // _PSD: Power State Dependencies
        {
            If (And (CFGD, 0x01000000))
            {
                If (And (PDC0, 0x0800))
                {
                    Return (Package (0x01)
                    {
                        Package (0x05)
                        {
                            0x05, 
                            0x00, 
                            0x00, 
                            0xFE, 
                            0x02
                        }
                    })
                }

                Return (Package (0x01)
                {
                    Package (0x05)
                    {
                        0x05, 
                        0x00, 
                        0x00, 
                        0xFC, 
                        0x02
                    }
                })
            }

            Return (Package (0x01)
            {
                Package (0x05)
                {
                    0x05, 
                    0x00, 
                    0x00, 
                    0xFC, 
                    0x01
                }
            })
        }
    }
}

- - - Beitrag zusammengeführt - - -

Just a couple follow-up questions...

In the speedstep-on.service, the startup command for c2ctl is:

ExecStart=/usr/sbin/c2ctl 3 -e

Should that in fact be ExecStart=/usr/sbin/c2ctl 2-3 -e or ExecStart=/usr/sbin/c2ctl 0-3 -e in order to activate speedstep on the last 2 cores? It seems to me that the command as-is will only start it on core 3. At any rate, I've tried to enable it manually and nothing changes on cores 2-3. The documentation for c2ctl seems to want binary values on the command line, but there's no mention of how to generate those values. In my case, what I've been able to determine is that in the lowest performance state, that appears to be "6" (which seems to correspond to the hex value of a multiplier of 6), medium is "7" (not what I specified in my SSDT6, but also seems to correspond to a multiplier of 7) and highest performance level is "71" which I assume is some kind of binary representation of the hex 47 from the file, which represents a 7.5 multiplier. Why 71? I'm sure none of this is relevant or related to my issue. I still suspect that due to some mistake I've made, the SSDT files either aren't being loaded or aren't being used.

Here is the output from c2ctl:

CPU0
      Current  Target    Min.    Max.
FID:       71      72       6      71
VID:       37      44      27      37
ESIT_ENABLE = TRUE    ESIT_LOCK = TRUE

CPU1
      Current  Target    Min.    Max.
FID:       71       6       6      71
VID:       37      27      27      37
ESIT_ENABLE = TRUE    ESIT_LOCK = TRUE

CPU2
      Current  Target    Min.    Max.
FID:        6       6       6      71
VID:       27      27      27      37
ESIT_ENABLE = TRUE    ESIT_LOCK = FALSE

CPU3
      Current  Target    Min.    Max.
FID:        6       6       6      71
VID:       27      27      27      37
ESIT_ENABLE = TRUE    ESIT_LOCK = FALSE

If I issue a "sudo c2ctl 0-3 6 27" from the command line, I get this output from c2ctl:

CPU0
      Current  Target    Min.    Max.
FID:        6       6       6      71
VID:       27      27      27      37
ESIT_ENABLE = TRUE    ESIT_LOCK = TRUE

CPU1
      Current  Target    Min.    Max.
FID:        6      71       6      71
VID:       37      37      27      37
ESIT_ENABLE = TRUE    ESIT_LOCK = TRUE

CPU2
      Current  Target    Min.    Max.
FID:        6       6       6      71
VID:       27      27      27      37
ESIT_ENABLE = TRUE    ESIT_LOCK = FALSE

CPU3
      Current  Target    Min.    Max.
FID:        6       6       6      71
VID:       27      27      27      37
ESIT_ENABLE = TRUE    ESIT_LOCK = FALSE

So, it appears that c2ctl is functioning to some extent.
In the current readme for c2ctl, in his DSDT example, he shows binary values for frequency and "power consumption" rather than hex. Does that indicate a change in newer versions of c2ctl? Are these values even relevant? Or are the only relevant values the FID/VID values?

I'm going to go back and try to verify that my dsl file for SSDT6 actually compiled properly. I know that it gave no errors and there are no error messages "loading" it at boot (I'm not sure if it's actually being loaded) but perhaps it compiled in such a way that the kernel can't use it and so it just ignores it?

edit: It appears that the .aml file is properly compiled... here is the output:

~/Documents/t61$ iasl -tc SSDT6uv.dsl

Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20180105
Copyright (c) 2000 - 2018 Intel Corporation

SSDT6uv.dsl     96:         Method (XPSS, 0, NotSerialized)
Warning  4089 -                       ^ Object is not referenced

ASL Input:     SSDT6uv.dsl - 218 lines, 5871 bytes, 32 keywords
AML Output:    SSDT6.aml - 581 bytes, 7 named objects, 25 executable opcodes
Hex Dump:      SSDT6uv.hex - 5809 bytes

 

[el-sahef]

I think it should be like this for a Q9000:

Name (SPSS, Package (0x03)
        {
            Package (0x06)
            {
                0x000007D1, 
                0x000088B8, 
                0x0000006E, 
                0x0000000A, 
                0x00000083, 
                0x00000000
            }, 

            Package (0x06)
            {
                0x000007D0, 
                0x000088B8, 
                0x0000006E, 
                0x0000000A, 
                0x00000183, 
                0x00000001
            }, 

            Package (0x06)
            {
                0x00000640, 
                0x00003E80, 
                0x0000006E, 
                0x0000000A, 
                0x00000283, 
                0x00000002
            }
        })
        Name (_PSS, Package (0x03)  // _PSS: Performance Supported States
        {
            Package (0x06)
            {
                0x000007D1, 
                0x000088B8, 
                0x0000000A, 
                0x0000000A, 
                0x0000481B, 
                0x0000481B
            }, 

            Package (0x06)
            {
                0x000007D0, 
                0x000088B8, 
                0x0000000A, 
                0x0000000A, 
                0x0000471B, 
                0x0000471B
            }, 

            Package (0x06)
            {
                0x00000640, 
                0x00003E80, 
                0x0000000A, 
                0x0000000A, 
                0x0000061B, 
                0x0000061B
            }
        })

You have to specify the minimum (6x for Q9000), maximum (7.5x for Q9000) and IDA state (8.5x for Q9000). The IDA state has 1 MHz higher frequency stated than the max state (don't know why, it's just how they do it in the tables that the BIOS provides) and a multiplier 1 higher than in maximum state.

ExecStart=/usr/sbin/c2ctl 3 -e is correct, those scripts worked for me when I had the T61 with the quadcore. There is no need to explicitly enable EIST on core 2 because it can only be enabled or disabled for a group of 2 cores (a core 2 quad is just two dual cores on the same package). There is nothing else that you need c2ctl for. The first two cores should have EIST enabled by the BIOS already. The Linux kernel handles the voltage and multiplicator changes when it gets the correct SSDT tables loaded by the bootloader and EIST is enabled for all cores.

If it does not work, there is either a mistake in the tables, they do not get loaded properly or EIST is not enabled with c2ctl on cores 2 and 3 (enabling it on core 3 will also enable it on core 2 and vice versa).

 

[pentode]

Thanks so much for the clarifications... it's very helpful as I feel like I'm mostly flying blind. I feel like I'm starting to develop enough of a sense of what's supposed to be going on that I can at least try to approach the problem scientifically.

So, I made the changes you suggested- and while the behavior _may_ have changed slightly (I'll explain that after) the key problems still persist. Cores 2-3 stay locked at a multiplier of 6 (or whatever I set them at) while cores 0-1 do change according to load, including the voltage - which is exactly what I don't want. I could live with the multipliers on 2-3 being stuck at 6, but as I know that my CPU will run at 1.05V (stress tested under prime95 for hours) I'd much prefer to keep the cores all running at minimum voltage, mainly for heat but also safety reasons. I say safety because, as you may have noticed, on my system, under load, the reported VIDs go up to 37, and occasionally appear to be trying to hit 44 (!) I have no idea how accurate these readings are, or if they're even accurate, but I certainly don't want the CPU running at 1.2-1.3V

I believe I have a few clues in the kernel log.

The kernel is at least attempting to load the aml files.

However, I'm wondering if this is an important clue:

[ 0.000000] ACPI: 6 ACPI AML tables successfully acquired and loaded

There are actually 7 .aml files in /boot/acpi. Does this mean that it's failing on one (maybe SSDT6.aml)? Or is this normal behavior?

My assumption, without fully understanding the code involved, is that we're setting the max and min values for both multiplier and core voltage (in 3 FID/VID pairs, high, medium, low) so if things were working properly, I would not only see EIST working on all 4 cores, but the actual/target/min/max voltage values reported by c2ctl should always be the same, in my case, 27. Is that right?

I feel like I'm very close, and yet I'm really worried about running the machine under linux at all until this is resolved as I don't want to kill the CPU with 1.3V!

 

[pentode]

edit: old post was unlocked, this became redundant.

 

[Mornsgrans]

Beitrag #433 freigeschaltet

 

[pentode]

I've been messing around with the ACPI tables trying to figure out what's going on, and it's almost 100% certain that my tables aren't being loaded. I dumped the ACPI tables on my machine and found that they're quite different from those in the archive linked in the instructions. I'm guessing that's perfectly normal as my BIOS might be different than that of the original machine. The power state settings in my ACPI tables are in ssdt9. I decided to edit that file and try to get it to load all on its own (not even sure this is possible) and in the process realized that my kernel log still says "6 ACPI tables found and loaded"... So, I'm guessing that they're being loaded from the firmware, not from my files. Why? I'm stumped. I tried moving the location of the acpi command around in grub - nothing has any effect.

Is it possible my kernel doesn't support dynamically loading ACPI tables? Is this something that needs to be enabled at compile-time?

This also raises another question: how many of these ACPI tables actually need to be edited in order to set the voltage and clock multipliers? Could I theoretically just edit the one SSDT file on my machine with those parameters and override the one in the firmware? Or do you need a certain set of files, all as one unit? Would there be any advantage (assuming I can ever get the files to load) to modifying my own ACPI tables (i.e. newer feature set or something?)

At any rate, I'm stuck with the files refusing to load for some reason. I'll try to look at the kernel. For the record, I'm doing all this on Lubuntu 18.04, so it's a current kernel (maybe too current??)

Thanks again for the help.

edit: status update


I have done some more experimentation and I think I've isolated the "problem", if it is in fact a problem. The issue I'm having seems to be related to grub. When I tried to load the acpi command the normal way, with /etc/default/grub and putting the command in GRUB_CMDLINE_LINUX_DEFAULT="" or GRUB_CMDLINE_LINUX="", the acpi command seemed to have no effect at all.

I decided to force the issue and put the acpi command directly into grub.cfg, and voila! It's definitely doing something different- in fact, it seems to be working as expected, other than that it's throwing lots of ACPI errors on boot such as:

[    0.000000] ACPI: Core revision 20170831
[    0.000000] ACPI Error: [_TPC] Namespace lookup failure, AE_ALREADY_EXISTS (20170831/dswload-378)
[    0.000000] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20170831/psobject-252)
[    0.000000] ACPI Exception: AE_ALREADY_EXISTS, (SSDT:TP-7V   ) while loading table (20170831/tbxfload-228)
[    0.000000] ACPI Error: [SSDT] Namespace lookup failure, AE_ALREADY_EXISTS (20170831/dswload-378)
[    0.000000] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20170831/psobject-252)
[    0.000000] ACPI Exception: AE_ALREADY_EXISTS, (SSDT:TP-7V   ) while loading table (20170831/tbxfload-228)
[    0.000000] ACPI Error: 2 table load failures, 10 successful (20170831/tbxfload-246)

and

[    0.068340] ACPI: Added _OSI(Module Device)
[    0.068340] ACPI: Added _OSI(Processor Device)
[    0.068340] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.068340] ACPI: Added _OSI(Processor Aggregator Device)
[    0.068340] ACPI: Added _OSI(Linux-Dell-Video)
[    0.068340] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
[    0.068340] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
[    0.068340] ACPI: EC: EC started
[    0.068340] ACPI: EC: interrupt blocked
[    0.069671] ACPI: \: Used as first EC
[    0.069674] ACPI: \: GPE=0x12, EC_CMD/EC_SC=0x66, EC_DATA=0x62
[    0.069676] ACPI: \: Used as boot ECDT EC to handle transactions
[    0.069830] ACPI: Executed 1 blocks of module-level executable AML code
[    0.076009] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
[    0.088943] ACPI: Dynamic OEM Table Load:
[    0.088953] ACPI: SSDT 0xFFFF94BDF66BE800 000240 (v01 PmRef  Cpu0Ist  00000100 INTL 20050513)
[    0.088969] ACPI Error: [_PPC] Namespace lookup failure, AE_ALREADY_EXISTS (20170831/dswload-378)
[    0.088978] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20170831/psobject-252)
[    0.089355] ACPI: Dynamic OEM Table Load:
[    0.089364] ACPI Exception: AE_NO_MEMORY, SSDT 0xFFFF94BDF66C1000 Table is duplicated (20170831/tbdata-562)
[    0.089375] No Local Variables are initialized for Method [GCAP]
[    0.089377] Initialized Arguments for Method [GCAP]:  (1 arguments defined for method invocation)
[    0.089378]   Arg0:           (ptrval) <Obj>           Buffer(8) 00 00 00 00 BF 0B 00 00
[    0.089392] ACPI Error: Method parse/execution failed \_PR.CPU0.GCAP, AE_ALREADY_EXISTS (20170831/psparse-550)
[    0.089420] ACPI Error: Method parse/execution failed \_PR.CPU0._PDC, AE_ALREADY_EXISTS (20170831/psparse-550)
[    0.089428] ACPI: Marking method _PDC as Serialized because of AE_ALREADY_EXISTS error
[    0.089886] ACPI: Dynamic OEM Table Load:
[    0.089894] ACPI: SSDT 0xFFFF94BDF6691F00 0000C8 (v01 PmRef  Cpu1Ist  00000100 INTL 20050513)
[    0.089908] ACPI Error: [_PPC] Namespace lookup failure, AE_ALREADY_EXISTS (20170831/dswload-378)
[    0.089915] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20170831/psobject-252)
[    0.090091] ACPI: Dynamic OEM Table Load:
[    0.090099] ACPI: SSDT 0xFFFF94BDF66AF240 000085 (v01 PmRef  Cpu1Cst  00000100 INTL 20050513)
[    0.090113] ACPI Error: [_CST] Namespace lookup failure, AE_ALREADY_EXISTS (20170831/dswload-378)
[    0.090119] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20170831/psobject-252)
[    0.091348] ACPI: Interpreter enabled
[    0.091374] ACPI: (supports S0 S3 S4 S5)
[    0.091376] ACPI: Using IOAPIC for interrupt routing

So, my very amateur interpretation of these errors is that there's some kind of conflict between my existing bios ACPI tables and the ones being loaded. In the interest of experimentation, I dumped my own ACPI tables and edited the file SSDT9 which contains the relevant code in my bios and loaded _only_ that file, thinking maybe it would simply overwrite that one file in memory. Interestingly, the system _still works_ as expected, i.e. the voltage seems to stay at minimum (27) regardless of load and all 4 cores do appear to function with EIST. (I need to do some scientific tests, but the values do change logically according to load).

However, I still have the same errors as posted above, so somehow the kernel isn't totally happy with this situation.

As always, any insight is most appreciated!

 

[DenkBlock]

Moin, zunächst mal vielen Dank für die Anleitung!

Habe das modifizierte Bios geflasht und den Hardwaremod gemäß der Anleitung durchgeführt. Bedauerlicherweise liegt der FSB immer noch bei 800 MHz. Woran kann das liegen?
Getestet wurde mit T9600 und P8700, Gerät ist ein T61 14,1" Widescreen mit Intel Grafik.

Gruß, Jonas

 

[pentode]

Habe das modifizierte Bios geflasht und den Hardwaremod gemäß der Anleitung durchgeführt. Bedauerlicherweise liegt der FSB immer noch bei 800 MHz. Woran kann das liegen?
Getestet wurde mit T9600 und P8700, Gerät ist ein T61 14,1" Widescreen mit Intel Grafik.
Gruß, Jonas

Hallo Jonas,
Haben Sie die Schaltung neben dem Widerstand durchgeschnitten?

 

[DenkBlock]

Hallo, danke für die rasche Antwort!
Ja, habe die Lane durchtrennt (denke ich). Wie tief muss man denn dafür schneiden? Bin so 2-3 mal mit einem Teppichmesser drübergegangen.

 

[pentode]

Hallo, danke für die rasche Antwort!
Ja, habe die Lane durchtrennt (denke ich). Wie tief muss man denn dafür schneiden? Bin so 2-3 mal mit einem Teppichmesser drübergegangen.

Gern geschehen. Entschuldigung für mein schreckliches Deutsch
Am besten prüfen Sie mit einem Multimeter die Durchgängigkeit zwischen dem Widerstand, an dem Sie den Draht angeschlossen haben, und dem Durchkontakt ("via") direkt daneben. Es sollte keine Kontinuität geben.