Leserreporter: Wer schöne Verschwörungslinks für mich hat: ab an felix-bloginput (at) fefe.de!
[zurück][ältere Posting][neuere Posting] Mittwoch, 26 Juli 2017 | Blog: 9 | No: 38980
Ich hatte ja vor einer Weile geschrieben, dass ich ein Schenker-Notebook habe, mit dem ich auch soweit zufrieden war. Bin ich auch größtenteils immer noch, aber es gibt doch einen Fehler, den ich hier mal zu Protokoll geben will, weil es sich, wenn man nach dem Symptomen googelt, um einen Serienfehler zu handeln scheint.
Schenker-Notebooks sind, wie auch diverse andere Notebooks auch, ursprünglich Barebones von Clevo. Die Symptome sind spontane Bluescreens unter Windows in SynTP.sys mit Fehler DRIVER_IRQL_NOT_LESS_OR_EQUAL (gelegentlich auch ein anderer Fehler aber auch in SynTP.sys).
Das passiert im Allgemeinen während hoher Systembelastung, beispielsweise während Videospielen.
Das Internet ist voll von Fehlerbeschreibungen dieser Art, einige wenige (gefühlt die Ausnahme, aber das kann auch an meinem Sample liegen) auch bei anderen Herstellern als Clevo. Lösungen scheint es keine zu geben. Viele Foren schlagen dann so die üblichen hilflosen Verdächtigen vor, GPU-Treiber updaten, Antivirus deinstallieren, Patches einspielen, blablah, das ist alles Bullshit. Also bis auf Antivirus wegmachen jetzt :-)
Das kann man auch nicht auf ein Hardwareproblem schieben, weil das ein völlig eindeutiger Programmierfehler im Treiber ist. Wer sich mit Treiberprogrammierung unter Windows ein bisschen auskennt: Das passiert, wenn ein Treiber in einem kritischen Pfad auf Speicher zugreift, der aus dem Speicherpool mit Paging kommt statt aus dem Non-Paged Pool. Speicher aus dem Paging-Pool kann vom Kernel rausgeswappt werden, und der Zugriff darauf führt dann dazu, dass die Speicherseite nachgeladen werden muss. Unter Linux ist von Kerneltreibern allozierter Speicher grundsätzlich nicht swapbar, unter Windows aus historischen Gründen doch. Nun ist das nicht generell verboten, im Windows-Kernel auf page-baren Speicher zuzugreifen, aber es gibt eben Situationen, in denen es nicht geht. Zum Beispiel wenn man gerade einen Interrupt bearbeitet, oder von jemanden aufgerufen wird, der einen Interrupt bearbeitet. Weil während dieser Operation ein zentraler Mutex im Kernel gehalten wird, würde das Auslösen von Paging zu einem Deadlock führen. Wenn der Kernel das also feststellt, gibt es sofort einen Bluescreen.
Dieser Bug kann auch auftreten, wenn ein Treiber in einer Interrupt-Routine auf völlig ungemappten Speicher zugreift, also einem wilden Zeiger hinterherrennt oder so.
Es gibt, kurz gesagt, keine Entschuldigung für dieses Verhalten. Nein, da ist nicht "das Mainboard zu warm geworden" oder "die Hardware hat ne Macke". Das ist ein Programmierfehler im Treiber. Gut, außer das Mainboard ist so doll zu warm geworden, dass der RAM Mist zurückliefert, aber dann ist auch alles andere zu spät und das würde nicht reproduzierbar im SynTP.sys auftreten.
Weil dieses Problem bei diversen Laptops seit vielen Jahren auftritt, und Synaptics offensichtlich nicht in der Lage ist, einen Treiber ohne diesen Fehler auszuliefern, werde ich in Zukunft vom Erwerb von Laptops mit Synaptics-Touchpad absehen.
Unter Linux ist übrigens alles in Ordnung mit dem Touchpad. Es ist nur der Windows-Treiber von Symaptics, der hier braun ist.
Kann es sein, dass ein Hardware-Problem zu dem speziellen Timing führt, das diesen Bug erst triggert? Ja, theoretisch. Aber ob das jetzt in der Praxis auftritt oder nicht — das ist ein Programmierfehler im Symaptics-Treiber. Schenker kann dafür nichts (außer dass sie Synaptics-Produkte ausliefern). Das einzige, was ich daher an dieser Stelle von Schenker erwarten würde, ist dass sie ab jetzt an ihre Produkte klar ranschreiben, ob da Synaptics-Produkte verbaut wurden oder nicht.
Das Touchpad im Gerätemanager zu deaktivieren hilft übrigens nicht.
Den Treiber manuell zu deinstallieren hilft auch nicht, weil Windows den sofort aus dem Windows Update Repository neu nachinstalliert. Das selbe passiert, wenn man den offiziellen Treiber von der Webseite von Synaptics lädt und zu installieren versucht.
[zurück]
[ältere Posting][neuere Posting]
[zurück][ältere Posting][neuere Posting] Mittwoch, 26 Juli 2017 | Blog: 9 | No: 38980
dass ein Hardware-Problem zu dem speziellen Timing führt, das diesen Bug erst triggert?
Dass das möglicherweise von einem Filtertreiber ausgelöst wird
Schenker-Notebooks sind, wie auch diverse andere Notebooks auch, ursprünglich Barebones von Clevo. Die Symptome sind spontane Bluescreens unter Windows in SynTP.sys mit Fehler DRIVER_IRQL_NOT_LESS_OR_EQUAL (gelegentlich auch ein anderer Fehler aber auch in SynTP.sys).
Das passiert im Allgemeinen während hoher Systembelastung, beispielsweise während Videospielen.
Das Internet ist voll von Fehlerbeschreibungen dieser Art, einige wenige (gefühlt die Ausnahme, aber das kann auch an meinem Sample liegen) auch bei anderen Herstellern als Clevo. Lösungen scheint es keine zu geben. Viele Foren schlagen dann so die üblichen hilflosen Verdächtigen vor, GPU-Treiber updaten, Antivirus deinstallieren, Patches einspielen, blablah, das ist alles Bullshit. Also bis auf Antivirus wegmachen jetzt :-)
Das kann man auch nicht auf ein Hardwareproblem schieben, weil das ein völlig eindeutiger Programmierfehler im Treiber ist. Wer sich mit Treiberprogrammierung unter Windows ein bisschen auskennt: Das passiert, wenn ein Treiber in einem kritischen Pfad auf Speicher zugreift, der aus dem Speicherpool mit Paging kommt statt aus dem Non-Paged Pool. Speicher aus dem Paging-Pool kann vom Kernel rausgeswappt werden, und der Zugriff darauf führt dann dazu, dass die Speicherseite nachgeladen werden muss. Unter Linux ist von Kerneltreibern allozierter Speicher grundsätzlich nicht swapbar, unter Windows aus historischen Gründen doch. Nun ist das nicht generell verboten, im Windows-Kernel auf page-baren Speicher zuzugreifen, aber es gibt eben Situationen, in denen es nicht geht. Zum Beispiel wenn man gerade einen Interrupt bearbeitet, oder von jemanden aufgerufen wird, der einen Interrupt bearbeitet. Weil während dieser Operation ein zentraler Mutex im Kernel gehalten wird, würde das Auslösen von Paging zu einem Deadlock führen. Wenn der Kernel das also feststellt, gibt es sofort einen Bluescreen.
Dieser Bug kann auch auftreten, wenn ein Treiber in einer Interrupt-Routine auf völlig ungemappten Speicher zugreift, also einem wilden Zeiger hinterherrennt oder so.
Es gibt, kurz gesagt, keine Entschuldigung für dieses Verhalten. Nein, da ist nicht "das Mainboard zu warm geworden" oder "die Hardware hat ne Macke". Das ist ein Programmierfehler im Treiber. Gut, außer das Mainboard ist so doll zu warm geworden, dass der RAM Mist zurückliefert, aber dann ist auch alles andere zu spät und das würde nicht reproduzierbar im SynTP.sys auftreten.
Weil dieses Problem bei diversen Laptops seit vielen Jahren auftritt, und Synaptics offensichtlich nicht in der Lage ist, einen Treiber ohne diesen Fehler auszuliefern, werde ich in Zukunft vom Erwerb von Laptops mit Synaptics-Touchpad absehen.
Unter Linux ist übrigens alles in Ordnung mit dem Touchpad. Es ist nur der Windows-Treiber von Symaptics, der hier braun ist.
Kann es sein, dass ein Hardware-Problem zu dem speziellen Timing führt, das diesen Bug erst triggert? Ja, theoretisch. Aber ob das jetzt in der Praxis auftritt oder nicht — das ist ein Programmierfehler im Symaptics-Treiber. Schenker kann dafür nichts (außer dass sie Synaptics-Produkte ausliefern). Das einzige, was ich daher an dieser Stelle von Schenker erwarten würde, ist dass sie ab jetzt an ihre Produkte klar ranschreiben, ob da Synaptics-Produkte verbaut wurden oder nicht.
Das Touchpad im Gerätemanager zu deaktivieren hilft übrigens nicht.
Den Treiber manuell zu deinstallieren hilft auch nicht, weil Windows den sofort aus dem Windows Update Repository neu nachinstalliert. Das selbe passiert, wenn man den offiziellen Treiber von der Webseite von Synaptics lädt und zu installieren versucht.
Update: Ein hilfreicher Hinweis kam noch rein: Dass das möglicherweise von einem Filtertreiber ausgelöst wird. Ein Filtertreiber ist ein Treiber, der sich sozusagen zwischen einen anderen Treiber und den Kernel hängt, das kennt man hauptsächlich bei Filesystemen. Bei Clevo-Laptops gibt es aber einen Filtertreiber für Hotkey-Handling. Das ist denkbar, dass der sich vor den Synaptics-Treiber hängt und den kaputtmacht. Zwischen Kernel-Komponenten gibt es keinen Speicherschutz wie zwischen verschiedenen Programmen im Userspace. Wenn der Schuld ist, trifft Synaptics natürlich keine Schuld und ich ziehe meine Kritik zurück. Ich probiere das mal aus, diese Filtertreiber nicht zu laden.
Twiter-Ticker
Fefes Latest Youtube Video Links
Der Betrieb der KraftZeitung kostet Geld. Da wir auch weiterhin unabhängig, überparteilich und ohne kommerzieller Werbung für Sie da sein wollen, sind wir auf Ihre Spende angewiesen. Vielen Dank.
