X280 X280 mit neuem Mainboard taktet nicht über 400MHz

[bemymonkey]

Moin zusammen!

Ich habe dieses Wochenende ein komplett totes X280 mit einem neuen Mainboard wiederbelebt. Grundsätzlich alles soweit so gut, bis auf dass mir alles im Debian Installer super langsam vorkam - trotz 100% Erfolg bei der Lenovo Diagnostics App ausm Bootmenü... nun bin ich bis zum Desktop durchgestartet und sehe auch, wo das Problem liegt: Die CPU will nicht hochtakten.

Was habe ich alles schon gemacht?

1. BIOS Einstellungen auf Defaults zurück
2. FW Updates für alles - fwupdmgr zeigt jetzt alles aktuell, UEFI ist auf Stand Oktober 2024 (für mich plausibel)
   1. System/UEFI/EC
   2. AMT
   3. Thunderbolt
   4. Sogar die SSD hat was Neues gekriegt
3. Akku getauscht
   1. Der ursprüngliche Akku hat 22Wh Restkapazität und wurde während Debian Install problemlos auf 90+% geladen
   2. Der "neue" Akku hat laut TLP noch ~36Wh Restkapazität, war aber ziemlich teifenentladen - mal sehen ob der CPU Takt sich ändert, wenn die Ladung etwas fortgeschritten ist (also Richting 20-30% kommt). Bei mittlerweile 15% geladen tut sich leider noch nix.
4. TLP installiert
5. CPU Temperatur geprüft (36° mit Lüfter aus - sollte eigentlich OK sein und nicht zum Throttlen führen... wärmstes Teil im Rechner ist die SSD mit ~50°)

Letzteres, also TLP, zeigt auch was Interessantes - nämlich sind die Sachen in Platform Profile (unten links im Bild) alle "not available"... das kenne ich eigentlich von meinen anderen Debianpads nicht so. Stimmt da vlt. irgendwas nicht? Habe ich beim Mainboard-Einbau vielleicht etwas vergessen?



Hat jemand eine Idee, was ich unbedingt noch probieren sollte?

Vielen Dank vorab wie immer!

-edit- Akku scheint's wirklich nicht zu sein - auch mit 40% Ladung tut sich da nichts beim CPU Takt. Im Akkubetrieb auch keine Änderung.

BIOS Screenshots:

 

[linrunner]

die Ursache für die 400MHz Sperre ist offensichtlich BD PROCHOT.

Rein aus Neugier: kann ich dessen Status unter Linux irgendwo sehen?

 

[bemymonkey]

Bin gespannt....

Hast du übrigens mal das neue BIOS von der Lenovo-Seite aufgeflasht ?
Das funkt richtig gut, bilde mir ein, es optimiert das System auch Richtung Effizienz/Stromverbrauch.

Jau, neues BIOS ist bereits drauf und hat nichts an dem Phänomen geändert.

Gibt diesen Fred dazu:
https://thinkpad-forum.de/threads/thinkpad-t580-7-neue-treiber-einschließlich-bios-update-innerhalb-von-60-tagen-die-nicht-in-vantage-oder-tvsu-auftauchen.243518/post-2429235

Dann vielleicht alles resetten was geht.....volles Programm...reset hole..Bios auf factory...usw...

Auch alles schon geschehen.

Auch mal ein anderes Live-Linux testen....idk.

Ich glaube langsam, das ist nicht mehr zielführend. Irgendwas stimmt halt mit der Kiste nicht auf Hardwareebene - wenn's nicht der Akku ist dann wird vermutlich irgendeine andere Komponente ein Paniksignal geben, das zum BD PROCHOT Trigger führt. Die Frage ist nur Welche - das ist alles sehr schlecht dokumentiert bei Lenovo, bzw. nicht öffentlich.

Rein aus Neugier: kann ich dessen Status unter Linux irgendwo sehen?

Das habe ich bisher auch noch nicht rausfinden können, sorry. Meine einzige Infoquelle dafür ist ThrottleStop in Windows. Häkchen gesetzt -> CPU springt auf gewohnten Takt hoch.

 

[linrunner]

Man findet schon Anleitungen. Die verwenden das Kernelmodul msr und die msr-tools. Leider übergehen die meisten die entscheidenden Punkte: da muss ein Register ausgelesen, Bit 0 maskiert und der Wert zurück geschrieben werden. In den Skripten steht stattdessen einfach "value". Ausserdem muss es wahrscheinlich für jeden Core einzeln gemacht werden.

 

[Crisser67]

Ich glaube langsam, das ist nicht mehr zielführend. Irgendwas stimmt halt mit der Kiste nicht auf Hardwareebene - wenn's nicht der Akku ist dann wird vermutlich irgendeine andere Komponente ein Paniksignal geben, das zum BD PROCHOT Trigger führt

Ist das Mainboard nagelneu oder refurbed, direkt von Lenovo ?
Du hasttest doch zwei tote X280 und nun nur ein Mainboard für beide ?

Ich würde in dem Fall vlt. alles sukzessive zurück-/umbauen, dann in das andere X280.
Vlt. ohne SSD, Wlan-, WWAN-Karte, nur mit externem Monitor/Tastatur.....
Wenn das Mainboard ok ist, könnte die Peripherie einen Schuss haben oder nicht richtig verbunden sein.
Echt mysteriös.....

 

[linrunner]

Ich würde mal raten, dass das Board selbst einen Schaden hat.

 

[Corvus]

An BD PROCHOT hängt zusätzlich zur CPU Temperatur und Strom vom CPU VRM und nur bei Notebooks die eGPU falls vorhanden und am selben Kühler und evtl der EC-Controller und damit dann auch der Akku. Und bei dem könnte es um Spannung bzw Vorhandensein gehen.

 

[bemymonkey]

Man findet schon Anleitungen. Die verwenden das Kernelmodul msr und die msr-tools. Leider übergehen die meisten die entscheidenden Punkte: da muss ein Register ausgelesen, Bit 0 maskiert und der Wert zurück geschrieben werden. In den Skripten steht stattdessen einfach "value". Ausserdem muss es wahrscheinlich für jeden Core einzeln gemacht werden.

Diese Anleitung hatte ich auch gefunden aber vermutlich missverstanden - ich hatte das so interpretiert dass die zu setzende Bitmaske dazu führt, dass BD PROCHOT ignoriert wird - nicht etwa, dass das tatsächlich das BD PROCHOT Bit selbst ist. Muss ich wohl nochmal in Ruhe lesen, danke für den Hinweis. Zudem stand irgendwo in einem issue zu einem der Skripte, dass das Schreiben mit msr-tools wohl ab Kernel 5.9 eh nicht mehr ginge...

Ist das Mainboard nagelneu oder refurbed, direkt von Lenovo ?
Du hasttest doch zwei tote X280 und nun nur ein Mainboard für beide ?

Mainboard ist aus dem Lenovo Super-Sale gewesen und sah soweit neu aus. Kann natürlich sein, dass ich eine Gurke erwischt habe

Ich würde in dem Fall vlt. alles sukzessive zurück-/umbauen, dann in das andere X280.
Vlt. ohne SSD, Wlan-, WWAN-Karte, nur mit externem Monitor/Tastatur.....
Wenn das Mainboard ok ist, könnte die Peripherie einen Schuss haben oder nicht richtig verbunden sein.
Echt mysteriös.....

Ja, sieht fast danach aus... ich halte Euch auf dem Laufenden ob sich irgendwas ergibt.

Ich würde mal raten, dass das Board selbst einen Schaden hat.

Wäre auch eine Möglichkeit... die ich nicht für unwahrscheinlich halte

An BD PROCHOT hängt zusätzlich zur CPU Temperatur und Strom vom CPU VRM und nur bei Notebooks die eGPU falls vorhanden und am selben Kühler und evtl der EC-Controller und damit dann auch der Akku. Und bei dem könnte es um Spannung bzw Vorhandensein gehen.

Sieht soweit alles i.O. aus - zumindest das, was man so auslesen kann.



Ich bleibe die Tage weiter dran. Erst mal vielen Dank Euch allen für den Input und die vielen Anregungen! Ich habe viel gelernt

 

[Crisser67]

Ich hoffe, dass du dem Problem auf die Schliche kommst und wenigstens ein komplettes X280 zusammengeklöppelt bekommst. Wäre sonst echt schade für die Teile und den ganzen Terz.
Sollte es sich irgendwie ergeben, dass du ein defektes X280 loswerden willst, könntest du mir Bescheid geben.
Ich bin nämlich gerade aktiv auf Suche, weil ich auch noch ein Mainboard, Akku und Tastatur zur Hand habe.

 

[rumpumpel1]

Dem Signal PROCHOT liegt in aller Regel ein HW-Problem zugrunde.
Ursprünglich dazu gedacht anzuzeigen, dass es der CPU zu heiß ist, wird es aber auch für andere Fehler verwendet.
Das Signal kann von der CPU, dem EC, dem Battery-Charger und dem IMVP8 Controller erzeugt werden.
Entsprechend vielfältig kann der Grund dafür sein.
Man müsste herauskriegen, welcher Chip das Signal setzt. Nicht ganz einfach wenn die Signalleitungen von BGA zu BGA Chip verlaufen und kein Pull-Up Widerstand vorhanden ist.
Ich würde versuchen mit einfachen Methoden das Problem einzukreisen:
1. kommt das Problem vor bei 1. nur Akku-Betrieb, 2. Akku+Netzteil und 3. nur Netzteil Betrieb?
2. der X280 hat - so, wie die meisten ThinkPads - zwei Ketten von Bauelementen, die die Temperatur überwachen:
A: siehe Schaltplan S.66. 12 in Reihe geschaltete PTCs, die an strategisch wichtigen Stellen auf dem Mainboard verteilt sind. Da kann man z.B. mal den Gesamtwiderstand messen.
B: siehe Schaltplan S.56. 6 Dioden, die auch an strategisch wichtigen Stellen positioniert sind. Auch die, würde ich auf Funktion prüfen.
3. Der Battery Charge misst den Eingangsstrom vom Netzteil: liegen dann an den Pins ACN und ACP (Pin 2 und 3) auch wirklich nur wenige mV an, oder sind es deutlich mehr?

Ich habe einen X1 Carbon Gen 4 mit diesem 400 MHz Problem. Trotz tagelanger Suche ist es mir bisher nicht gelungen den Fehler zu beseitigen.

 

[bemymonkey]

Hi @rumpumpel1 , besten Dank für die Gedanken dazu!

1. Kommt in allen drei Fällen vor
2. Gute Idee. Schade, dass man den Status dieser Sensoren nicht per Software auslesen kann - ich hab gestern nochmal die gesamte Diagnosekette in Commercial Vantage durchlaufen lassen mit dem Ergebnis, dass alles tippi toppi wäre... Gucken wir mal wann ich die Tage dazu komme, das Board wieder auszubauen um das Ganze zu messen - ich gehe davon aus, dass die nicht alle einfach auf der "praktischen" seite des Boards liegen
3. Mmm vermutest Du einen Defekt des Shunt-Widerstands oder worauf willst Du hinaus? Das Problem ist in allen Betriebszuständen mit und ohne Akku vorhanden, und der Akku lädt auch mit der erwarteten Leistung (also 30-40W mit angeschlossenem 65W Netzteil).

Man müsste herauskriegen, welcher Chip das Signal setzt. Nicht ganz einfach wenn die Signalleitungen von BGA zu BGA Chip verlaufen und kein Pull-Up Widerstand vorhanden ist.

Zumindest beim X280 sehe ich Serienwiderstände an Vielen der PROCHOT Leitungen, z.B. am Charger IC. Geht's dabei wirklich nur um dieses eine PROCHOT Netz? Sprich, die gehen alle verodert auf den PROCHOT Eingang der CPU (??) und sagen Dieser damit, sie soll bitte langsam machen?

Dann könnte man ja einfach erst mal alle Serienwiderstände wegklappen die man findet (mindestens eine Schaltplanseite ohne Serienwiderstand hab ich leider schon gesehen) und dann mal gucken, ob's Problem schon weg ist...

 

[Crisser67]

Ich halte Euch auf dem Laufenden ob sich irgendwas ergibt.

 

[ConiKost]

Ich kenne das Problem vom X260 und dort hat nur ein Boardwechsel geholfen..

 

[bemymonkey]

Moin zusammen, danke für die weiteren Rückmeldungen und die vielen Tipps. Leider komme ich mangels Zeit nicht wirklich weiter. Ich hab's nun aufgegeben und gebe die Geräte ab. @DocMabuse @Crisser67 siehe PN.