Wie vermeintlichen Bug im Linuxkernel ausfindig machen?

Naja... wie eigentlich erwartet, keine Änderung...

Ich muss meine Erkenntnisse jetzt irgendwie zusammenfassen und dann versuchen, einen Bugreport zu erstellen.
 
_anonymous0815_ schrieb:
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
Die Fehlermeldung hat absolut gar nichts mit deinem Fehler zu tun. Komplett anderer Driver State.

Du musst die Fehlermeldung inkl. Fehlergrund schon präzise lesen und suchen. Alles, was nicht DID_OK und DRIVER_OK beinhalten, kannst du von vornherein vergessen. Entsprechend passt auch der Redhat Bug oben nicht zu deinem Problem.

_anonymous0815_ schrieb:
Hat leider nichts mit Virtualisierung zu tun, wie gesagt, auf der tgt VM geht es perfekt und über iSCSI an Windows gehts auch perfekt.
Das schließt den Einfluss der Virtualisierung nicht aus. Die Probleme sind möglicherweise Timing-basiert, worauf der Linux Treiber ggf. empfindlicher reagiert, als der Windows Treiber. Lokal auf dem System kommt es nicht zum tragen, weil keine Netzwerkverbindung dazwischen ist.
 
Du hängst dich gerade an diesem State auf, ich debugge dieses Problem jetzt seit zwei Monaten, da ich sehr an einer Lösung interessiert bin. Allein der Bugreport im Eingangspost trifft sehrwohl auf mich zu, da er 1:1 das REALE VERHALTEN beschreibt, welches ich über iSCSI erlebe und das zählt. Ob da jetzt die nichtssagende Fehlermeldung mit #21 oder #22 ausgegeben wird, ist für mich, der den Code nicht als Ganzes interpretieren kann, relativ egal. Die Maintainer werden es schon eher einordnen können.

Und nochmal zur Virtualisierung. Ich hatte das Laufwerk in einem Laufwerksschacht eines Laptops eingebaut und dies per Mini-SATA verbunden, EXAKT GLEICHES Fehlerbild, der Laptop lief mit einem aktuellen Ubuntu und Kernel.

Ich werde den Report jetzt verfassen und einreichen, alles Weitere wird dann hoffentlich dort geklärt.
 
Du hast absolut keine Ahnung, was du da tust, oder?

_anonymous0815_ schrieb:
Ob da jetzt die nichtssagende Fehlermeldung mit #21 oder #22 ausgegeben wird, ist für mich, der den Code nicht als Ganzes interpretieren kann, relativ egal.
Sorry, aber das ist eine Katastrophe. Investiere deine Zeit woanders. Glaub mir, so bringt das nichts.

Beantworte dir nur eine Frage: Warum - glaubst du - loggen die Entwickler den Treiber Status? Wenn er denn für den Fehler unwichtig ist - deiner Aussage nach? Du merkst es selber, oder?
 
Nochmal... für MICH ist er uninteressant, WENN das Verhalten sich mit dem deckt, welches ich erlebe. Für den Entwickler ist es natürlich wichtig. Und wenn er Systeminformationen braucht, bekommt er die auch. Du hängst dich hier an einem erst mal nicht so wichtigen Nebenfakt auf. JEDES System ist anders, JEDES Laufwerk ist anders, JEDE Disc ist anders. Du wirst NIEMALS zwei Mal das exakte System vorfinden.

Ich muss hier Gemeinsamkeiten suchen, die habe ich gefunden und der Entwickler ENTSCHEIDET SELBST, welche Wertigkeit diese Querverweise haben, die ich mit einreichen werde.
riversource schrieb:
Investiere deine Zeit woanders. Glaub mir, so bringt das nichts.
Werfe ich jetzt einfach mal zurück, ich denke, dass ich mit dem Report auf dem richtigen Weg bin. Punkt.
 
_anonymous0815_ schrieb:
ich debugge dieses Problem jetzt seit zwei Monaten, da ich sehr an einer Lösung interessiert bin
Du machst da irgendwie zu viel Drama draus.
Schreib doch einfach erst mal einen (einfachen) Bug-Report und die Entwickler der entsprechenden Sub-Systeme bzw. Treiber sagen Dir dann schon, was sie noch als Info brauchen.
Sonst sitzt Du jetzt noch ein paar Wochen da und versuchst vorauseilend irgendwie Sachen abzuklappern, die dann vielleicht aber gar nicht benötigt werden.
Und die können die dann ggf, auch noch sagen, was Du anknipsen sollst, um detailliertere Infos loggen zu lassen.
 
  • Gefällt mir
Reaktionen: _anonymous0815_
ESXi macht man nicht. Werden die Devs auch nicht akzeptieren. Deine Beobachtungen, Rückschlüsse und Erwartungen sind irrelevant. Loglevel erhöhen und working/non-working vergleichen. Ich persönlich würde aber erst mal LIO, statt des alten tgt, testen.
 
  • Gefällt mir
Reaktionen: _anonymous0815_
_anonymous0815_ schrieb:
Nochmal... für MICH ist er uninteressant, WENN das Verhalten sich mit dem deckt, welches ich erlebe.
Nur weil die Symptome sich ähneln, heißt das nicht, dass die Ursache gleich ist. Mir wäre es nicht egal, wenn ich zwei Monate dem falschen Fehler nachjage.

Das mit dem Bug-Report ist wohl der beste Weg (hättest du früher machen sollen), aber ich denke auch, dass die Rahmenbedingungen im Moment zu exotisch sind, um den Fehler zu reproduzieren.
 
  • Gefällt mir
Reaktionen: _anonymous0815_
Uridium schrieb:
aber erst mal LIO, statt des alten tgt, testen.
Noch gar nicht erwähnt, aber auch schon aufgesetzt und ständig Timeouts und Hänger mit open-iscsi bekommen und wieder zurück zu tgt.

Das Drive war gar nicht funktional.

Uridium schrieb:
ESXi macht man nicht. Werden die Devs auch nicht akzeptieren.
Dann ist es gut, dass ich es auch gänzlich mit physischen Computern getestet habe und die Fehler exakt gleich waren.

Der Bugreport ist hoffentlich raus, hab das noch nie gemacht. Jedenfalls ist die Mail raus.
Ergänzung ()

riversource schrieb:
Das mit dem Bug-Report ist wohl der beste Weg (hättest du früher machen sollen
Hab mich ehrlich gesagt nicht getraut, die Mailinglisten sind ja schon eher raue Örtchen und ich wollte es möglichst eingrenzen, da ich es anfänglich nicht wirklich so tiefgreifend vermutet habe.
 
Zuletzt bearbeitet:
Ich glaube, dass ich Depp es falsch gemacht habe.

Ich habe die entsprechenden Maintainer aus der /linux/MAINTAINER rausgesucht und angeschrieben, jedoch keine Mailingliste hinzugefügt. In meinem Fall müsste ich die von Debian nehmen und die wollen das ganze Procedere auch in etwas anderer Reihenfolge.

Ich werde die Mail wohl nochmal umschreiben müssen.

Echt peinlich. >.<
 
Zurück
Oben