SL510 Problem mit Standby

[Mang0]

Hallo!

Auch ich begebe mich nun also ins "Biotop der Bekloppten", wie es hier so schön heißt.

Mein Problem ist das folgende: Mein mittlerweile schon vier Jahre altes, aber erst ein Jahr intensiv genutztes Thinkpad SL510 (2847-7mg) hängt sich meistens, aber nicht immer auf, wenn ich es in den Standby schicke. Betriebssystem ist ArchLinux (stable, kein testing).
Wenn ich also suspend-to-ram ausführe, so scheint es zunächst so, als funktioniere alles ganz normal (Bildschirm geht aus etc.). Doch der Powerbutton hört nicht auf, schnell zu blinken, und nach einigen Sekunden fängt der Lüfter an, voll zu drehen, was ich darauf zurückführe, dass der Prozessor ausgelastet ist (hängt) und keinerlei Stromsparmechanismen (Runtertakten etc) mehr anschlagen. Es hilft nur noch der Hardreset durch fünf-sekündiges Drücken des Powerbuttons.
Nun habe ich schon Verschiedenstes ausprobiert, konnte aber noch keine Lösung finden. So habe ich schon einzelne Kernelmodule deaktiviert bzw. beim booten gar nicht erst geladen oder aber auch mit alten Kerneln (5 Jahre alte Knoppix live-CD) versucht in den Standby zu kommen. Ich konnte aber weder eine Lösung noch eine Regelmäßigkeit, wann es funktioniert und wann nicht, feststellen.

Darum nun meine Fragen: Hat irgend jemand ein ähnliches Problem schon einmal gehabt? Hat jemand eine Idee, was ich noch versuchen könnte? Gibt es eine Möglichkeit den Prozess zu debuggen (echte serielle Schnittstelle auf dem Mainboard)?
Über Tipps, Ideen, Hinweise, Lösungsvorschläge und so weiter wäre ich sehr dankbar!

Herzlichst
Mang0


Ps.: Ich war mir nicht sicher, ob dieses Thema zu Software/Linux oder zu Hardware/SL-Serie gehört. Sollte der Beitrag nun im falschen Unterforum gelandet sein, so bitte ich eine befähigte Person dies zu korrigieren. Danke.

 

[linrunner]

Hi,

willkommen im Forum!

Das BIOS ist aktuell?

Ich würde mal probieren pm-utils zu installieren und mit

pm-suspend

den Suspend einzuleiten. Hintergrund: in pm-utils ist eine Reihe von Workarounds ("Quirks") integriert.

 

[Mang0]

Danke!

pm-utils werde ich dann heute Nachmittag ausprobieren, sobald ich wieder zu Hause bin.
Laut wiki (https://wiki.archlinux.org/index.php/pm-utils#Standby.2Fsuspend_to_RAM) scheint es da ja durchaus öfters Probleme zu geben. allerdings hatte ich ja auch schon mit den Modulen herumprobiert. Naja, ich werde es ausprobieren und dann eventuell mich nochmal intensiver mit den Modulen beschäftigen.

Das BIOS müsste eigentlich aktuell sein, hatte ich vor nicht allzu langer Zeit mal aktualisiert. Bin mir aber nicht sicher; werde auch das nachschauen.

 

[pseudonym]

Hallo Mang0,

Kenne das von dir beschriebene Problem sehr gut. Leider finde ich nicht die Zeit mich intensiv damit zu beschäftigen. Das BIOS kann man bei der Fehlersuche ausklammern. Hab es seit Besitz des Laptops 3 Mal auf eine neuere Version gehievt. Der Effekt trat aber unter allen von mir genutzten BIOS-Versionen auf.
Ich vermute einen Zusammenhang mit dem Intel-Treiber. Wenn ich das OS hochfahre und nach dem Login den Deckel schließe geht er ohne Probleme in susend-to-ram. Starte und beende ich z.B. eine Video-Datei, dann geht wieder nix mehr.

Was ich aber sagen kann ist, dass suspend-to-ram bei meinem SL510 unter Kernel 3.14.20-1 einwandfrei funktioniert. Vor 2 Tagen habe ich 3.17.0-1 getestet. Ergebnis - funzt mal wieder nicht . Hab mich mittlerweile dran gewöhnt , dass ich Kernel-Hopping betreiben muss, wenn ich suspend-to-ram mit diesem Gerät fehlerfrei nutzen will.

Gruß
pseudonym

 

[Mang0]

Also pm-suspend hat keinerlei Veränderung gezeigt; das Verhalten war das selbe. Trotzdem danke linrunner!

Hallo pseudonym,
so traurig das klingt, aber ich freue mich, dass ich nicht der einzige mit diesem Problem bin. Ich denke, du beziehst dich mit deiner Aussage ja auch auf dein SL510. Dies zeigt dann zumindest, das es kein Defekt in einem Hardwareteil ist.
Intel-Treiber läge natürlich durchaus im Bereich des Möglichen, schließlich macht der ja andauernd nur Ärger und ist meines Wissens nach auch nicht mehr gepflegt für die alten GraKa-Chips. Erst vor Kurzem konnte ich Videos gar nur abspielen, wenn ich den Player gezwungen habe, den Prozessor zu nutzen, die Intel GraKa also faktisch umgangen habe.
Dennoch konnte ich das von dir beschriebene Verhalten, dass es direkt nach dem Booten noch funktioniert, noch nicht nachvollziehen. Ich meinte, das hätte ich schon ausprobiert. Wird aber nochmal versucht

Kernel habe ich im Moment 3.16.4-1. Kann mich aber ehrlich gesagt nicht daran erinnern, dass es schon jemals funktioniert hätte. Aber ich werde auch das ausprobieren. Wenn ich aber dann immer mit einem veralteten Kernel arbeiten muss, nur damit suspend funktioniert, find ich aber auch nicht wirklich lustig....

Naja, ich werde das alles ausprobieren und dann sieht man weiter. Auf jeden Fall schonmal Danke!

Gruß
Mang0

 

[pseudonym]

Wir haben das gleiche Gerät. Meins ist auch ein 2847-7MG.

Hab viele Distributionen getestet auf dem SL510. Alles was suspend-to-ram nicht out-of-the-box hinbekam hab ich irgendwann direkt wieder entsorgt. Die besten Erfahrungen habe ich dabei mit Arch und den beiden Abkömmlingen Chakra und Manjaro gemacht.

Die Probleme mit der Hardwarebeschleunigung kenn ich natürlich auch. Kann manchmal schon bissl nervig sein mit dem Teil. Das ist im 3.17er Kernel wohl behoben. Hatte ihn 1 Tag drauf, aber wegen suspend-to-ram wieder downgegraded. Ich nutze es mehrmals pro Tag und mag trotz den flotten Bootzeiten einer SSD nicht drauf verzichten.

Wenn ich aber dann immer mit einem veralteten Kernel arbeiten muss, nur damit suspend funktioniert, find ich aber auch nicht wirklich lustig...

Das ist eben der Preis ein freies Betriebssystem zu nutzen und ein SL510 sein Eigen nennen zu dürfen

Gruß
pseudonym

 

[haarp]

Das kann viele Gründe haben, aber gerade beim SL510 habe ich festgestellt, dass SATA ALPM die Ursache ist. Wird es auch nur einmal kurz aktiviert, ist die Chance hoch, dass der nächste Suspend einfriert. Meist wird es durch pm-tools oder TLP oder so gemanaged, dort muss es ausgeschaltet werden.

Meine Erfahrungen waren damals mit Kernel 3.5.7. Welchen Kernel hat denn Arch zurzeit? Wenn das Problem bei dir auch ALPM ist, dann mach doch bitte einen Bugreport auf http://bugzilla.kernel.org auf.

 

[Mang0]

Hallo zusammen,

hier mal ein kleines Update:
Ich habe alle eure Vorschläge ausprobiert, leider bis jetzt ohne Erfolg.
Sowohl LTS-Kernel 3.14.20-1 als auch 3.14.21-1 haben zunächst vielversprechend ausgesehen, beim dritten bis vierten mal in den Standby schicken haben aber auch diese sich aufgehängt. Insofern meine Frage an dich, pseudonym: Wie lange und ausführlich hast du das schon ausprobiert? Wie oft führst du suspend aus, bevor du rebootest?
Anschließend habe ich dann jegliche(!) Stromsparmechanismen der einzelnen Geräte ausgeschaltet, leider hat auch dies keine Wirkung gezeigt. Interessant aber auch hier, dass das Problem erneut erst beim dritten bis fünten Mal suspend aufgetreten ist. Insofern wäre die Frage, ob es irgend etwas mit der Betreibszeit (uptime) zu tun haben könnte.

Das kann viele Gründe haben...

Kannst du da vielleicht noch einige Möglichkeiten angeben, dass ich wenn ich Lust und Zeit habe noch das eine oder andere ausprobieren kann?

Welchen Kernel hat denn Arch zurzeit?

Aktuell ist gerade 3.16.4-1

Im Moment bin ich gerade dabei etwas auszuprobieren, dass bis jetzt sehr vielversprechend aussieht. Ich werde mich diesbezüglich wieder melden. Das Problem ist immer, dass man so schwierig sagen kann, ob es funktioniert oder nicht, da es ja anscheindend nur manchmal und zufällig auftritt. Sicherheit kann also nur ein Langzeitversuch geben; das wiederum dauert aber wie der Name bereits suggeriert eingige Zeit...

Gruß
Mang0

 

[haarp]

Das hört sich wirklich sehr stark nach dem Problem an, dass ich damals hatte.

Wenn es SATA ALPM ist, dann bringt es nichts, es manuell nach dem Start wieder auszuschalten. Für den Bug reicht es, wenn ALPM auch nur kurz eingschaltet war.

Kannst du da vielleicht noch einige Möglichkeiten angeben, dass ich wenn ich Lust und Zeit habe noch das eine oder andere ausprobieren kann?

Puh, das ist eine Weile her. Es gibt einen Haufen sogenannter "Quirks" die Probleme mit dem Suspend umgehen sollen. Dann häufiger Treiberprobleme, ACPI-Probleme, irgendwas mit USB und viel mehr. Ich hab damals unter anderem einen großen Thread im (englischen) Arch-Forum gefunden und dort mal alles durchprobiert, was aber nicht half. auf ALPM bin ich durch Selbstdiagnose gestoßen.

Was du auch probieren kannst, ist ältere Kernels zu installieren. Ich denke, unter Arch sollte das nicht allzu schwierig sein. Wenn in irgendeiner Version das Problem nicht mehr auftritt, können wir es weiter eingrenzen und so evtl. den Commit finden, der den Bug eingeführt hat.

Wenn die Ursache feststeht, ob nun Kernel oder was anderes, bitte auf jeden Fall an entsprechender Stelle einen Bug melden, damit sie großflächig ausgemerzt werden kann!

 

[linrunner]

Hinweis: um SATA-ALPM in TLP komplett auszuschalten, kommentiert man in der Konfiguration die beiden Einstellungen SATA_LINKPWR_ON_AC und SATA_LINKPWR_ON_BAT aus. Soweit ich weiss, fasst auch ein naturbelassenes Arch SATA-ALPM nicht an.

 

[Mang0]

Hallo zurück,

es gab lange kein Update meinerseits, ich wollte aber meine Ergebnisse erst ein paar Tage ausprobieren, bevor ich hier vergeblich Hoffnung verbreite.

Folgendes habe ich jetzt einige Tage zunächst mit Kernel 3.14.20-1-lts und nun mit dem aktuellen 3.17.1-1 getestet; bisher mit Erfolg!
Und zwar wurde das parallele "schlafenlegen" von Modulen und Geräten ausgeschaltet, sodass nun eins nach dem anderen geschieht.
Warum das allerdings funktioniert, ist mir ein Rätsel. Sollte die Liste der Abhängigkeiten zwischen den Geräten falsch sein, so dürfte es auch bei "eins-nach-dem-anderen" nicht funktionieren; ist sie richtig, so sollte es auch bei parallelem suspend gehen... Ich weiß nicht.
Darum würde ich euch bitten, das auch bei euch zu versuchen (Feldversuch). Sollte es auch bei euch postive Ergebnisse zeigen, so kann man sich auf tiefere Fehlersuche begeben und dann eventuell auch einen Bugreport erstellen.

Folgendes ist zu tun bzw. habe ich gemacht:

cd /sys/power/
cat pm_async          #gibt momentanen Status; 1 = parallel, 0 = aus (eins nach dem anderen)
echo 0 > pm_async

Dies hat bei mir zu dem Ergebnis geführt, dass ich bis jetzt noch keinen Absturz mehr bei suspend-to-ram gehabt habe. Und das jetzt immerhin über 2 Wochen.
Den obigen Code müsst ihr nach jedem reboot erneut ausführen, alternativ könnt ihr es auch in euren Autostart schreiben, vergleicht dazu diese Webpage [1].

Ich würde mich freuen, wenn ihr das auch versucht und es bei euch auch funktioniert! Um Rückmeldung wäre ich dann sehr dankbar.
Herzlichst
Mang0


[1] https://thomas-leister.de/allgemein/arch-linux-rc-local-ausfuehren-mit-systemd/

 

[pseudonym]

Hi Mang0 und sorry für die späte Rückmeldung.

Insofern meine Frage an dich, pseudonym: Wie lange und ausführlich hast du das schon ausprobiert? Wie oft führst du suspend aus, bevor du rebootest?

Aktuell nutze ich Manjaro mit Kernel 3.14.1-1. Habe bisher über mehrere Wochen kein suspend-Problem damit gehabt. Wie oft ich das ohne Reboot durchgeführt hab ist schwer zu sagen. Es kommt durchaus vor, dass das Gerät nur alle 4-5 Tage mal neu gebootet wird. In dieser Zeit komme ich dann sicher auf 20-40 suspends.

Mit Kernel 3.17.1-1 funzt es bei mir unter Manjaro definitiv nicht. Werd nun aber mal an deinem Feldversuch teilnehmen und das testen.


EDIT: Vielen Dank für den Tipp. Die von dir beschriebene Methode scheint zu funktionieren. Hab ihn jetzt mit Kernel 3.17.1-1 mehrere Male erfolgreich in suspend schicken können. Ich lass ihn jetzt mal mit diesem Kernel weiterlaufen und werde weiter hier im Thread berichten.

 

[linrunner]

Das beschleunigte Resume kam mit 3.15 [1], aber das Problem ist ja beim Suspend.

[1] http://www.heise.de/open/artikel/Die-Neuerungen-von-Linux-3-15-2196231.html

 

[Mang0]

Hallo pseudonym,

danke für deine Rückmeldung. Bei 20-40 suspend-Vorgängen würde ich es als funktionierend bezeichnen. Kernel 3.14.1-1 habe ich aber auch nicht ausprobiert, sondern nur 3.14.20-1, 3.14.21-1 sowie die aktuellen. Insofern danke für die Info, werde wenn ich mal Zeit und Lust habe 3.14.1 ausprobieren; vielleicht könnte man so schon die Fehlerquelle näher identifizieren.
Danke auch für deine Teilnahme und die Rückmeldung. Freut mich, dass es funktioniert!

...werde weiter hier im Thread berichten.

:thumbup:


Hallo linrunner!

Das beschleunigte Resume kam mit 3.15 [1], aber das Problem ist ja beim Suspend.

Ja, genau so ist es, aber wie du schon sagst stürzt er ja schon beim suspend ab. Abgesehen davon hatte ich das ganze ja auch mit Jahre alten Knoppix Live-CDs getestet und es hat auch nicht funktioniert. Umso erstaunlicher, dass zumindest bei pseudonym kernel 3.14.1 auch funktioniert. Das werde ich auf jeden Fall auch mal noch versuchen.
Trotz allem war meiner Meinung nach dieses Linux-Update bzw. diese neue Funktion das beste bzw. die beste seit Langem.

Mang0