[gelöst] Wie lange dauert es bis Patches kommen?

[JuergenPB]

Ich habe ein Problem mit meiner Grafikkarte.
Soweit ich es sehe, scheint das Problem prinzipiell erkannt und vorerst gelöst zu sein.

Es geht darum:
http://anonscm.debian.org/cgit/pkg-xorg ... 3e08738d8a
Wenn ich es richtig verstehe ist dieser Patch seit 14. Januar fertig.

Es müßte sich um das Paket handeln:
https://packages.debian.org/de/source/jessie/mesa

Wie lange dauert es, bis der dann offiziell bei jessie erscheint?

[alteholz]

Genaues kann Dir nur der Maintainer sagen. Da es kein RC Bug ist, würde ich vermuten, dass der Bug nicht in Jessie, sondern erst in Jessie-Backports gefixt wird.

Thorsten

[hikaru]

Dieser Patch wird gar nicht in Jessie auftauchen, denn der zugehörige Bugreport 775264 hat nur die Schwere "important". Im Freeze (in dem sich Jessie gerade befindet) werden jedoch nur Bugs der Schwere "serious" und höher gefixt. [1]
Du könntest theoretisch versuchen die Schwere zu eskalieren, aber ich sehe dafür wenig Grundlage, da ja offenbar nur bestimmte Nutzer des Pakets betroffen sind.


[1] https://www.debian.org/Bugs/Developer#severities

[deberik]

Ich habe ein Problem mit meiner Grafikkarte.
Soweit ich es sehe, scheint das Problem prinzipiell erkannt und vorerst gelöst zu sein.

Es geht darum:
http://anonscm.debian.org/cgit/pkg-xorg ... 3e08738d8a
Wenn ich es richtig verstehe ist dieser Patch seit 14. Januar fertig.

Es müßte sich um das Paket handeln:
https://packages.debian.org/de/source/jessie/mesa

Wie lange dauert es, bis der dann offiziell bei jessie erscheint?

Streng nach den Regeln gar nicht mehr. Zur Erklärung:

Die gewollte Versionsnummer in dem verlinkten Patch und Changelog-Eintrag ist 10.3.2-2. Da in Sid mesa schon die Version 10.4.2-2 besitzt, kann es also von Timo Aaltonen nur als direkter Jessie-Fix gedacht sein. Allerdings: es gibt keine Unblock- oder Pre-Approved-Anfrage[1] und der Fehler ist "nur" als important markiert (775264). Daher ist der Fix laut Freeze Policy[2] nicht mehr erlaubt.

[1] https://bugs.debian.org/cgi-bin/pkgrepo ... debian.org
[2] https://release.debian.org/jessie/freeze_policy.html

Edit: Da war ich wohl zu langsam

[JuergenPB]

Danke für die Erklärung, auch wenn das sehr unbefriedigend ist,
da ich täglich meist mehrfach (3 oder 4mal) einen solchen Fehler habe

Das bedeutet also, sofern ich bei Jessie bliebe, daß ich für gut die nächsten 2 Jahre täglich mehrfach SysRq-RSEIUB bemühen müßte. Toll!

[hikaru]

Du konntest dir auch selbst gepatchte Pakete bauen.

[JuergenPB]

Vielleicht wäre es einfacher eine andere Grafikkarte einzubauen – Aber da hat man ja nur die Wahl zwischen Pest (nvidia) oder Cholera (ati/radeon).

[KP97]

Probiere doch mal das Paket aus Sid, evtl. behebt es ja das Problem schon.
Falls ja, kannst Du es pinnen.
Ich habe jetzt aber nicht geschaut, ob und welche Abhängigkeiten da sind, das mußt Du selbst tun.

[michaa7]

Vielleicht wäre es einfacher eine andere Grafikkarte einzubauen – Aber da hat man ja nur die Wahl zwischen Pest (nvidia) oder Cholera (ati/radeon).

Oder du ziehst temporär nach sid um. Das wird, wenn jessi stable wird die grundlage für das neue testing. Du must dann bei freigabe des neuen release nur sofort deine repos wieder von unstable auf testing umstellen.

Möglicherweise ist dir sogar schon geholfen, wenn du jetzt nach aktivierung des sid/unstable repos das entsprechende gefixte paket für deine graka installierst, ggf. mit notwendigen abhängigkeiten und das sid-repo danach sofort wieder deaktivierst.

[deberik]

Derzeit NICHT auf Sid umziehen. changelog[1] ansehen, laut dem ist der Fehler NICHT gefixt.

[1] http://metadata.ftp-master.debian.org/c ... _changelog

[JuergenPB]

Ja, in sid ist es auch (noch) nicht drin.

[catdog2]

Du konntest dir auch selbst gepatchte Pakete bauen.

Sollte so schlimm nicht sein den debian-jessie branch ausm git ziehen, apt-get build-dep mesa, dpkg-buildpackage -b -j#cpukerne, warten, freuen.

[NAB]

Das bedeutet also, sofern ich bei Jessie bliebe, daß ich für gut die nächsten 2 Jahre täglich mehrfach SysRq-RSEIUB bemühen müßte. Toll!

Wäre das nicht ein "macht das betreffende Paket unbrauchbar" (grave) oder gar "verursacht ernsthaften Datenverlust" (critical)? Letztendlich ist das gesamte System unbrauchbar ... wenn man mesa als zwingend erforderlich ansieht.

[hikaru]

(Ich glaube) um "grave" zu rechtfertigen müsste eine wie auch immer zu definierende Menge an Usern betroffen sein. Von diesem Bug sind allerdings nur einige wenige Nutzer einer ganz bestimmten Sorte von Grafikkarte betroffen.
Ob es Datenverlust verursacht ist vermutlich eine Frage dessen ob man nur im RAM (und nicht auf Platte) befindliche Daten überhaupt schon als vorhanden betrachtet.

Unabhängig davon lässt sich ja auch auf der problematischen Hardware ein Desktopsystem ohne Probleme betreiben. Man muss dan eben nur auf hardwarebeschleunigte Grafik verzichten.

Edit:
@JuergenPB:
Ich habe gestern Abend testweise Jessie/amd64-Pakete mit dem Patch gebaut, aber ohne passende Hardware kann ich natürlich nicht beurteilen ob sie funktionieren. Falls du sie haben willst melde dich per PN bei mir!

[catdog2]

Unabhängig davon lässt sich ja auch auf der problematischen Hardware ein Desktopsystem ohne Probleme betreiben. Man muss dan eben nur auf hardwarebeschleunigte Grafik verzichten.

Das ist völliger quatsch. Wir sind in 2015 und das lässt sich absolut nicht ohne Probleme betreiben sondern nur eingeschränkt. Außerdem wird bei den radeonsi Modellen meines Wissens GLAMOR zur 2D Beschleunigung unter X verwendet welches opengl verwendet und damit den mesa Treiber.

Ob es Datenverlust verursacht ist vermutlich eine Frage dessen ob man nur im RAM (und nicht auf Platte) befindliche Daten überhaupt schon als vorhanden betrachtet.

Wenn dein System plötzlich abraucht kann das zu Datenverlust führen, da besteht kein Zweifel.

(Ich glaube) um "grave" zu rechtfertigen müsste eine wie auch immer zu definierende Menge an Usern betroffen sein. Von diesem Bug sind allerdings nur einige wenige Nutzer einer ganz bestimmten Sorte von Grafikkarte betroffen.

Ist die Frage ob man diese gerne ignorieren möchte.

[JuergenPB]

Wenn ich es richtig verstehe, sitzt die Änderung in der Datei radeonsi.so
Diese wird vom Paket libgl1-mesa-dri geliefert.
Das Paket habe ich jetzt mal deinstalliert. Vielleicht reicht das ja schon.

Edit:
@JuergenPB:
Ich habe gestern Abend testweise Jessie/amd64-Pakete mit dem Patch gebaut, aber ohne passende Hardware kann ich natürlich nicht beurteilen ob sie funktionieren. Falls du sie haben willst melde dich per PN bei mir!

Danke für das Angebot.
Ich schaue jetzt erst einmal, was ohne dieses Paket passiert…

[NAB]

Wenn man sich den Patch mal genau anguckt, steht da:"While the root cause for
this might need to be fixed in the kernel, let's disable it for now." Langfristig könnte also ein neuer Kernel das Problem beseitigen, der Patch in Mesa ist nur ein Abschalten der fehlerhaften Funktion. Eventuell lässt sich die Korrektur im Kernel auch in den 3.16er Kernel reinpatchen.

RadeonSI scheint der generelle Treiber für Radeon HD 7000 und aufwärts zu sein:
http://www.phoronix.com/scan.php?page=search&q=RadeonSI
die Anzahl der Nutzer sollte also im weiteren Leben von Jessie ansteigen. Das könnte durchaus eine Hochstufung des Bugs rechtfertigen.

[hikaru]

Das ist völliger quatsch. Wir sind in 2015 und das lässt sich absolut nicht ohne Probleme betreiben sondern nur eingeschränkt. Außerdem wird bei den radeonsi Modellen meines Wissens GLAMOR zur 2D Beschleunigung unter X verwendet welches opengl verwendet und damit den mesa Treiber.

Und was hat die Jahreszahl nun mit dem verwendeten Grafiktreiber zu tun?
Ich sage voraus, dass sich auch 2020 noch eine Debian-Desktop mit xserver-xorg-video-vesa betreiben lassen wird, ganz ohne 2D- oder 3D-Beschleunigung.

Wenn dein System plötzlich abraucht kann das zu Datenverlust führen, da besteht kein Zweifel.

Ich habe in dem Zusammenhang noch nichts von "abrauchenden Systemen" gelesen, nur von "GPU lockups".
D.h. das System sollte per ssh noch zugänglich sein und auch ein sauberer Shutdown via acpi sollte meines Wissens nach möglich sein. Ich sehe da keine Gefahr von Datenvelust (auf Massenspeichern). Weißt du mehr?

Ist die Frage ob man diese gerne ignorieren möchte.

Wenn die betroffenen User es nicht für nötig halten den Bugreport zu eskalieren indem sie darstellen warum ihr Nischenproblem für Debian rc sein sollte, sondern stattdessen lieber andere Hardware kaufen, warum sollte man sich dann im Freeze mit sowas rumschlagen?

[NAB]

hikaru:
https://bugs.debian.org/cgi-bin/bugrepo ... bug=774784
"Merged with 775264"
Da ist von "kernel crash" die Rede.

[hikaru]

Na dann los! Wegen Möglichkeit auf Datenverlust um Anhebung der Schwere auf "grave" bitten!

Der Knackpunkt:
Es muss sich wirklich jemand hinsetzen und die Mail schreiben.

[JuergenPB]

Wenn dein System plötzlich abraucht kann das zu Datenverlust führen, da besteht kein Zweifel.

Ich habe in dem Zusammenhang noch nichts von "abrauchenden Systemen" gelesen, nur von "GPU lockups".
D.h. das System sollte per ssh noch zugänglich sein und auch ein sauberer Shutdown via acpi sollte meines Wissens nach möglich sein. Ich sehe da keine Gefahr von Datenvelust (auf Massenspeichern). Weißt du mehr?

Es gibt laut Logdatei einen "GPU lockup".
Optisch ist es so, daß man auf dem Bildschirm "Schnee" hat. Die Maus läßt sich noch bewegen. Auf dem Bildschirm sieht man statt des Mauszeigers ein ebenso "verschneites" kleines Quadrat, das man bewegen kann.
Da man auch nicht mehr auf die Konsole kommt, bleibt nur SysRq-REISUB.
X zu killen nützt nichts, da der Bildschirm dann schwarz bleibt. Auch dann kommt man nicht auf die Konsole bzw. man sieht nur Schwarz.

Datenverlust hatte ich bisher keinen.
Allerdings ist es bisher auch nie passiert, wenn was "wichtiges" lief, wie ein Update oder so.


Wie gesagt: Ich habe jetzt erstmal libgl1-mesa-dri deinstalliert.
Das tat nicht weh, da nur irgendein Qt-Kram ebenfalls deinstalliert wurde.

Log started: 2015-02-01 14:28:31
Entfernen von qml-module-qtquick-controls:amd64 (5.3.2-2) ...
Entfernen von qml-module-qtgraphicaleffects:amd64 (5.3.2-2) ...
Entfernen von qml-module-qtquick2:amd64 (5.3.2-4) ...
Entfernen von libgl1-mesa-dri:amd64 (10.3.2-1) ...
Löschen der Konfigurationsdateien von libgl1-mesa-dri:amd64 (10.3.2-1) ...
Entfernen von qml-module-qtquick-layouts:amd64 (5.3.2-2) ...
Entfernen von qml-module-qtquick-window2:amd64 (5.3.2-4) ...
Log ended: 2015-02-01 14:28:35

Nachtrag 21:10
Bisher keinen Absturz mehr gehabt. Sieht gut aus…

[JuergenPB]

Ich habe das Thema auf "gelöst" gesetzt, weil mir diese Lösung reicht, auch wenn es prinzipiell noch nicht gelöst ist.

Das Deinstallieren hat dazu geführt, daß ich bisher keine Abbrüche mehr hatte. – Das reicht mir, wenn es so bleibt.
Mit den Nachteilen (fehlende DRI-Module) kann ich leben.

[JuergenPB]

Ich komme doch nochmal auf diesen Thread zurück.

Gerade stelle ich fest, daß nun blender nicht mehr funktioniert (initial window could not find the GLX extension, exit!)

Dann habe ich mal versuchsweise libgl1-mesa-swx11 installiert, was auch bewirkt, daß automatisch libgl1-mesa-glx deinstalliert wird.

Damit läuft Blender dann — ABER: Chromium nicht mehr.
Im Terminal gestartet meldet Chromium ständig wiederholend:

Code: Alles auswählen

[15493:15493:0212/140532:ERROR:gles2_cmd_decoder.cc(3823)] GLES2DecoderImpl: Context lost because context no longer current after resize callback.
[15493:15493:0212/140532:ERROR:gles2_cmd_decoder.cc(3952)] Error: 5 for Command kResizeCHROMIUM

Gut, Blender brauche ich eher sehr selten.
Unschön ist die Sache dennoch.