Re: [OT] Assertion failure in journal_revoke()
Martin Samesch schrieb:
> Feb 1 18:37:07 tutnix kernel: Assertion failure in journal_revoke()
> at revoke.c:329: "!(__builtin_constant_p(BH_Revoked) ?
> Wie kommen solche Beschädigungen im normal laufenden Betrieb
> zustande?
Kernel-Bug? Es gab vor kurzem schon mal so eine Meldung auf der LKML:
http://groups.google.de/groups?selm=20030117193019%24054c%40gated-at.bofh.it
Es gab bisher keine Antwort darauf. Hier sieht man nicht nur, was
fehlende Realnamen bewirken ;-)
Vielleicht hat Adrian die obige Mail noch in seiner Mailbox, sowie Zeit
und Lust, Dir bei der fachgerechten Aufbereitung einer Bug-Meldung
(besonders reproduzierbare Kernel-Version - s.u.), dem Anhängen an
obigen Thread und dem per CC: in's Boot holen der zuständigen
Kernel-Entwickler behilflich zu sein.
Oder um es in anderen Worten zu sagen: schon so eine billige
Bug-Meldung ist richtige Arbeit.
Ein Beispiel: ich hatte vor ein paar Monaten einen Bug in Netfilter,
den ich schnellstens weg haben musste. Auf der Netfilter-ML wurde das
Problem schon mal ein paar Wochen vorher beschrieben. Aber so vage und
unspezifisch, dass es vom Entwickler auch nur ein "könnte bla sein"
Kommentar gab. Auf meine spezifischere Meldung hatte ich innerhalb von
24h einen Patch bekommen. Nach ein paar Wochen, kam sogar noch ein
weiterer Bugfix über die Liste, der damit nichts unmittelbar zu tun
hatte, aber davon wohl initiert wurde.
Und nun rechnen wir mal durch: das Problem einem Netfilter-Bug
zuzuordnen, genau zu analysieren und entsprechend beschreiben zu
können, hat mich über 2 Std. Arbeit gekostet. Der Entwickler wird mit
dem Einzeiler-Fix vermutlich < 1 Std. beschäftig gewesen sein. Die
verantwortlichen zwei Peer-Reviewer und der Tree-Maintainer vermutlich
jeweils max. 5-10 Min. In 2.4.20 ist der Fix enthalten und als so banal
eingeordnet, dass er nicht mal im Changelog steht.
Das heisst, zeitlich gesehen hatten nicht die Entwickler, sondern der
Bug-Reporter den grössten Aufwand. Und so ist das eigentlich meistens.
Die Kugel schnell vom Tisch schieben, eben eine vage Mail mit ein paar
kopierten Logs rausschieben - das kann jeder. Ich denke, mindestens ein
Drittel des Aufwands zur Entwicklung eines Open-Source Produktes ist
solche "versteckte Arbeit", die kaum einer sieht und wahr nimmt, vieler
ungenannter fleissiger Heinzelmännchen. Vielleicht ist es auch schon
mehr als die Hälfte (wäre mal ein interessantes Forschungsthema...).
> Ich benutze 2.4.20 mit ALSA- und Preempt-Patch und woody
Welchen 2.4.20? Die originale 2.4.20-Version von kernel.org hat einen
ext3-Data-Corruption-Bug. ext3 sollte damit gar nicht verwendet werden.
Der wichtige Punkt:
Kannst Du das auch mit der 2.4.20 Debian-Version oder letzten .21-pre
*ohne* Deine sonstigen Patch-chen reproduzieren?
> Wegen des Prüfsummen-Problems habe ich das IDE-Kabel ausgetauscht,
> was aber nichts genützt hat.
Kann man meistens ausschliessen, da 99% der Leute einen UDMA-Modus
benutzen, der selbst eine Prüfsummen-Sicherung beinhaltet. Würde also
separat im Log auftauchen.
--
rainer@ellinger.de
Reply to: