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. -- [EMAIL PROTECTED] -- H�ufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
