Wie vermeintlichen Bug im Linuxkernel ausfindig machen?

[_anonymous0815_]

Guten Abend,

ich sitze seit mittlerweile gut zwei Monaten an einem Fehler, den ich jetzt diffus im Linux-Kernel bei den SCSI-Treibern vermute.

Jedoch beherrsche ich kein C und nur die Grundlagen von C++ und etwas Python, sodass ich große Schwierigkeiten habe, die Funktionsweise der einzelnen Files nachzuvollziehen und mit raten komme ich hier nicht weiter.

Ich möchte daher gern einen Bugreport aufgeben und das Problem möglichst genau schildern, am besten mit einen Verweis auf eine File.

Welche Methoden, um einen Fehler einzugrenzen, ohne die exakte Funktionsweise der darunterliegenden Programme zu verstehen, empfehlen sich?

Mein Problem ist folgendes:

Ich möchte über iSCSI ein(mittlerweile zwei) optische USB-Laufwerke (CD/DVD/(4K)-BR) per SCSI-Passthrough an Clients, bzw. Initiatoren verteilen. Die Discs können gelesen werden, aber mit einer maximalen Übertragungsrate von 2 MB/s. Es fängt mit ca. 6 MB/s an, bricht dann kurz auf <1 MB/s ein und steigt dann nur noch bis 2 MB/s.

dmesg wird währenddessen mit Kernel-Fehlermeldungen bombardiert.

Die Laufwerke funktionieren unter Windows sowohl per USB, als auch über den Microsoft iSCSI-Initiator problemlos.

Die Laufwerke funktionieren auch unter Linux per USB problemlos (Wobei das auch erst seit kurzem wieder so sein muss, da sich mehr als ein Dutzend Fehlermeldungen im Bezug auf optische Laufwerke, angeschlossen per USB, mit meinem Fehlerbild, im Zeitraum 2020 bis Mitte 2023 finden lassen.

U.a. bin ich auf diesem langen Bugreport bei RedHat gestoßen:
https://bugzilla.redhat.com/show_bug.cgi?id=1822948#c136

Dort wird für seinen Use-Case ein Workaround in udev erwähnt, der mein Problem leider nicht behoben hat.

Dieser Workaround mündete in einem Commit-Vorschlag auf GitHub:
https://github.com/systemd/systemd/pull/23127

Welchen Lennart Poettering mehr oder minder als Unfug bezeichnet und dabei auf ein mögliches Problem im Kernel hingewiesen hat.

Ich habe jetzt selbst versucht, das Problem Stück für Stück weiter einzugrenzen, um das mögliche Problem zu greifen, weiß aber jetzt nicht mehr weiter.

Wenn ich ein /dev/sdX Device per SCSI Passthrough durchreiche, kann ich mit voller Geschwindigkeit lesen und schreiben, ohne dass Fehler geworfen werden.
In meinen Augen ein Hinweis, dass der Fehler nicht beim open-iscsi-Initiator zu verorten ist.

Wenn ich das Drive per USB direktverbinde, tritt der oben genannte Fehler aus dem RedHat-Bugreport auch nicht mehr auf.
Für mich bedeutet das, dass es hier in ca. Ende 2022 bis Mitte 2023 einen Commit gegeben haben muss, der diesen Fehler per USB behoben hat.

Nur wieso funktioniert es dann mit iSCSI nicht, was das Device wohl erst mal korrekt durchzureichen scheint?

Wie geht Ihr an solche Dinge heran?

Mir wurde schon gesagt, dass ich vermutlich eine Ebene zu tief bin und lieber mit Programmparametern arbeiten soll, aber ich habe bereits extrem viele Eventualitäten in diesen zwei Monaten ausprobiert, absolut nichts hat diesen Fehler tangiert. Ich glaube, dass ich mit der Richtung schon richtig bin.

Vielen Dank für alle Vorschläge

 

[Alexander2]

Zur Überschrift
Man nennt das
Bisect

Man kann mit dem Verfahren dann irgendwann den Punkt finden ab dem ein Patch das Verhalten brachte.
Per internetsuche sollte zu finden sein, was das genau ist und auch wie man es macht.

 

[Redundanz]

wenn du genug anlass hast zu vermuten, dass es am kernel liegen könnte, wirst du mit schilderungen dieser art hier, also deines posts, schon weiterkommen. vielleicht erstmal per email an kernel-devs die für dieses modul zuständig sind etwas vorfühlen.

 

[Alexander2]

Hast du schon ältere Kernel Probiert und einen gefunden, bei dem es ggf. funktioniert?

 

[_anonymous0815_]

Hast du schon ältere Kernel Probiert

Bis jetzt nur die Flucht nach vorn und 6.7.4 kompiliert, aber der Schritt rückwärts ist natürlich auch eine Idee.

Ergänzung (10. Februar 2024)

Der Kernel 4.19.0-26-amd64 wirft ebenfalls diesen Fehler. Damit habe ich jetzt ehrlich gesagt nicht gerechnet.

 

[Alexander2]

Immerhin etwas, das du als Info mitgeben kannst. Ich weiß garnicht wie weit du noch zurückgehen könntest die 3er Reihe würde noch gehen mit nem Modernen System?

 

[_anonymous0815_]

4.19.0-17-amd64 von 2021 ebenso betroffen...

Berichte habe ich ab 2020 zu diesem Problem gefunden, also muss ich wohl doch nochmal selbst kompilieren.

 

[Alexander2]

die beiden erwähnten kernel dürften ja auch die selben sein, das nach dem strich sind doch "nur" Distropatches, ggf nur auf die paketierung oder was die vom kernel wie kompiliert haben. buildflags und so.

 

[_anonymous0815_]

Also es ist gar nicht mal so einfach, an alte Linux Isos zu gelangen... ein Kernel Downgrade habe ich noch nie versucht.

Habe eine VM mit Debian Stretch (Alphaversion) erstellt. ESXi kann es nicht wirklich handlen, aber open-iscsi habe ich installiert bekommen und der Fehler bei der Initialisierung tritt NICHT auf.

Ich werde jetzt mal mit rsync und dd schauen, was speedtechnisch möglich ist.

Meine Theorie eines Bugs wird demnach wahrscheinlicher, allerdings ist es schwierig einzugrenzen, da diese Debianversion Kernel 4.0.0 von 2015 nutzt.

Ergänzung (11. Februar 2024)

Zu früh gefreut, die Fehlermeldungen kommen dann erst beim Kopiervorgang in dmesg. Allerdings ist eine durchschnittliche Leserate von 10 MB/s möglich.

Ergänzung (11. Februar 2024)

Jedenfalls spricht das wohl gegen einen Kernelbug im vermuteten Zeitraum, denn ich glaube nicht, dass das CD/DVD Handling seit mindestens 2015 broken ist. Das wäre ja wohl mal aufgefallen.

Andererseits kann ich dabei nur nochmal betonen, dass die Laufwerke KEINEN Defekt haben, unter Windows fehlerfrei nutzbar sind und auch mit aktuellem Kernel der Weg über USB geht. Das zweite Laufwerk habe ich mir gestern gekauft, es ist brandneu, also einen Hardware-Defekt schließe ich kategorisch aus.

 

[Alexander2]

Ja, ist nur die Frage wo der Bug ist :-) ich kann dir da grad leider auch nicht helfen, so viel Ahnung hab ich davon nicht.

Ich mach nur Linux mit Bare Metal und zocke damit neben Multimedia etc.

 

[_anonymous0815_]

Ist jedenfalls erst mal gut, die ganzen Ansätze aus dem Kopf zu schreiben.

Mir fällt jedenfalls auf, dass der Fehler bei der Initialisierung vom Laufwerk nicht auftritt, sondern erst, wenn ich den Kopiervorgäng mit Rsync starte.

dd, welches ein 1:1 Abbild macht, lässt dmesg nicht fluten, da tritt kein Fehler auf und die Disc ist mit einigermaßen Fullspeed lesbar (gerade 15,2 MB/s) Das ist tatsächlich auch mit aktuellem System der Fall.

Das verstehe ich nämlich auch nicht, was genau soll rsync hier anders machen, außer, dass es eben nicht Bit für Bit klont, sondern auf Fileebene kopiert.

Der Fehler in dmesg spuckt zudem jedes Mal einen Sector mit aus. Der Sektor liegt allerdings nicht auf der Disc, sondern ist eigentlich out of Range.

Bei aktuell ~44 GiB Disc und einer Blocksize von 2048 Byte, gibt es ca. 23,1 Mio Sektoren auf der Disc. Er fängt mit Sektoren >=80.000 an und gibt dann auch Sektoren >=24.000.000, welche wie gesagt nicht auf der Disc liegen dürften.

 

[Alexander2]

Nur allgemein, das dd schneller als rsync ist bei auch gerade optischen Medien kann man sich schon alleine mit dem Unterschied zwischen random und sequential read erklären.

Ohne erstmal auf irgendwelche Fehlermeldungen einzugehen.

 

[_anonymous0815_]

Das stimmt, aber rsync wird ja auch bei den größeren Files auf der Disc nicht schneller als 2 MB/s.

 

[AGB-Leser]

Kann das sein, dass dir sync dazwischen grätscht? Das klingt so, als wenn der nach jeder Bewegung den Vorgang richtig abschließt, das kenne ich von Netzwerkfreigaben und Dateisystemen

 

[riversource]

dmesg wird währenddessen mit Kernel-Fehlermeldungen bombardiert.

Was sind denn das für Fehlermeldungen? Das würde es erheblich einfacher machen, die Situation einzuschätzen.

 

[_anonymous0815_]

Was sind denn das für Fehlermeldungen?

https://bugzilla.redhat.com/show_bug.cgi?id=1822948#c16

So ähnlich wie hier in diesem Comment,

[sr0] tag#0 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=30s
    166 Apr 14 12:15:07 kernel: sr 5:0:0:0: [sr0] tag#0 CDB: Read(10) 28 00 00 00 02 00 00 00 02 00
    167 Apr 14 12:15:07 kernel: blk_update_request: I/O error, dev sr0,

Nur dass bei mir noch "critical target error" davorsteht.

wenn ich am PC sitze, reiche ich nochmal spezifisch nach.

Ergänzung (11. Februar 2024)

Hier nochmal spezifisch für mein Problem:

dmesg -w # open-iscsi Initiator auf Client

[  251.151134] SCSI subsystem initialized
[  251.155872] Loading iSCSI transport class v2.0-870.
[  251.166304] iscsi: registered transport (tcp)
[  252.168650] scsi host0: iSCSI Initiator over TCP/IP
[  252.183242] scsi 0:0:0:0: RAID              IET      Controller       0001 PQ: 0 ANSI: 5
[  252.215067] scsi 0:0:0:1: CD-ROM            NECVMWar VMware SATA CD00 1.00 PQ: 0 ANSI: 5
[  252.227076] scsi 0:0:0:0: Attached scsi generic sg0 type 12
[  252.227157] scsi 0:0:0:1: Attached scsi generic sg1 type 5
[  252.288011] sr 0:0:0:1: [sr0] scsi-1 drive
[  252.288015] cdrom: Uniform CD-ROM driver Revision: 3.20
[  252.362712] sr 0:0:0:1: Attached scsi CD-ROM sr0
[  257.230127] sr 0:0:0:1: [sr0] tag#46 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
[  257.230136] sr 0:0:0:1: [sr0] tag#46 Sense Key : Hardware Error [current]
[  257.230139] sr 0:0:0:1: [sr0] tag#46 Add. Sense: Internal target failure
[  257.230143] sr 0:0:0:1: [sr0] tag#46 CDB: Read(10) 28 00 00 00 00 82 00 00 7e 00
[  257.230145] critical target error, dev sr0, sector 520 op 0x0:(READ) flags 0x80700 phys_seg 63 prio class 2
[  257.438268] sr 0:0:0:1: [sr0] tag#46 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s

journalctl -f -u tgt # iSCSI Target Server

Feb 11 12:17:21 brd-srv tgtd[63414]: tgtd: graceful_write(85) sg device 11 write failed, errno: 22
Feb 11 12:17:21 brd-srv tgtd[63414]: tgtd: bs_sg_cmd_submit(227) failed to start cmd 0x0x55e
b9efaf9c0

 

[Alexander2]

tag#46 Sense Key : Hardware Error [current]

Ist das denn irgendwie anders angeschlossen als i nanderen Verbindungsarten? nicht, das der sich nur dauernd wegen zu wenig Strom beschwert, aber das ist komplett geraten, nicht das statt Strom nur aktuell gemeint ist.

 

[_anonymous0815_]

Der Aufbau ist wie folgt:

Optisches Laufwerk ---USB3---> ESXI 8 Host ---Passthrough via SATA---> Debian 12 mit tgt iSCSI-Target ---SCSI Passthrough---> open-iscsi-Initiator ---Debian Stable/Testing-Client---> Programme

Ergänzung (11. Februar 2024)

nicht, das der sich nur dauernd wegen zu wenig Strom beschwert

Tatsächlich war das auch schon eine Überlegung meinerseits, da ich Fehlerberichte zu externen Festplatten mit ähnlicher Fehlermeldung gefunden habe, aber dann habe ich mein älteres Laufwerk letzte Woche aus dem Enclosure ausgebaut und in einen Laptop mit Mini-SATA eingebaut und diesen als Target verwendet, keine Änderung.

Des Weiteren muss man hier wieder im Hinterkopf behalten, dass Windows hier keine Probleme macht.

 

[riversource]

Wenn man die Fehlermeldung googelt, findet man sie auffallend oft in Zusammenhang mit Virtualisierung. Eigentlich nur, um ehrlich zu sein. Da würde ich ansetzen. Kannst du es ohne VmWare dazwischen testen?

 

[_anonymous0815_]

Enclosure ausgebaut und in einen Laptop mit Mini-SATA eingebaut und diesen als Target verwendet, keine Änderung.

Da würde ich ansetzen. Kannst du es ohne VmWare dazwischen testen?

Ergänzung (11. Februar 2024)

Hat leider nichts mit Virtualisierung zu tun, wie gesagt, auf der tgt VM geht es perfekt und über iSCSI an Windows gehts auch perfekt.

Ergänzung (11. Februar 2024)

Hab jetzt über ein Dutzend dieser Fehlermeldungen in meinen Lesezeichen und die allerwenigsten haben dabei virtualisiert. Den ältesten hat mir Google vorhin als erstes Suchergebnis eingespült, der ist vom 13.12.2016:
https://unix.stackexchange.com/questions/330200/how-can-i-find-out-what-the-entries-in-dmesg-means

Ergänzung (11. Februar 2024)

ich kompiliere mal auf dem Targetserver einen aktuellen Kernel, das ist der einzige Punkt in der Kette, den ich bisher nicht angetastet habe, da tgt im Userspace ausgeführt wird und mit dem Kernel an sich erst mal nicht so viel zu tun hat. Aber am SCSI-System wurde letztes Jahr tatsächlich einiges verändert, wobei ich jetzt nicht wirklich an die Lösung beim Target glaube.