Kernel Traffic #97 For 11 Dec 2000

Thanks go out to the many folks who wrote in to report that the printer-friendly version broke last week. There was not one flame in the entire bunch :-)! Sorry for not replying personally to every email, but I did read them all. The problem, finally, was a disk space shortage on one of our CVS servers, and it took a little while to straighten out. Thanks for the reports, folks!

There were 369 different contributors. 158 posted more than once. 147 posted last week too.

Rik van Riel meinte zu Alan Cox, "Hier ist ein Fix für einen dummen Bug, den es in 2.2 seit langem gibt (und vor welchem ich Dich in den letzten 6 Monaten einige Male gewarnt habe und zu welchem ich sogar ein paar Patches geschickt habe)." Er erklärte, dass " dieser Patch das 2.2er VM ein wenig stabiler machen sollte und die Beschwerden anderer Leute über "VM: do_try_to_free_pages failed for process XXX" beheben sollte. " Ville bestätigte dieses Problem und erklärte, " 2.2.18pre19, läuft seit 8 Tagen, läuft stundenlang idle. Dann ganz plötzlich erscheint 30mal "VM: do_try_to_free_pages failed for kswapd...", dann 15mal "VM: do_try_to_free_pages failed for xmms...", dann "VM: killing process xmms" und das wiederholt sich bei 10 Prozessen einschliesslich X." Und zusätzlich fragte er, "Ich erkannte Andreas VM-global Patch für dieses Problem als Lösung, ich habe es auch schon einkompiliert (obwohl ich noch nicht damit gebootet habe). Soll ich jetzt Riks oder Andreas Patch nehmen?" Er wollte auch wissen, ob einer der beiden in 2.2.18 eingehen würde. Rik antwortete, "Welche Verbesserung auch immer in den nächsten 2.2er Kernel genommen wird, bemühe dich nicht mich zu fragen, da ich 2.2 nicht viel Aufmerksamkeit zolle." Es folgte einige technische Diskussion über Riks Patch und dessen Zusammenspiel mit ext3.

Mohammad A. Haque berichtete ext2 Fehler "Freeing blocks not in datazone" während normaler Nutzung auf 2.4.0-test11. Neil Brown antwortete, " Oh, gut. Es sind also nicht nur ich und Tigran. Im ersten Moment beschuldigte ich meinen raid5 Code dafür, aber wenn du das auch erhälst und Tigran (berichted auf http://boudicca.tux.org/hypermail/linux-kernel/2000week48/0257.html) dann liegt es wahrscheinlich nicht an mir." Er fügte hinzu, "Jetzt wenn wir es in einen sicheren Weg hätten, es zu reproduzieren, könnten wir eine binäre Suche nach dem schlechten Patch starten...aber ich kann es nur mit einem gepatchten Kernel nach stundemlangen Performance-Testen reproduzieren." Anries Brouwer meinte, "Es wäre gut, wenn es nur dich und Tigran treffen würde. Unglücklicherweise trifft es auch mich." Alexander Viro begann Patches zu posten, obgleich Mohammad und Tigran Aivazian Schwierigkeiten hatten, den Fehler mit dem Ausgangszustand zu reproduzieren. Dann bemerkte Neil, "Ich führte mein Test Skript aus, welches eine Vielzahl von raid5 Arrays erstellt mit unterschiedlichen Anzahlen der Laufwerke und Chunk-Grössen und führte mkfs/bonnie/dbench auf jedem Array aus und es ging durch ca. 8 Filesysteme, doch stockte beim neunten, indem es einen Haufen Blocks in der System Zone zu alloziieren versuchte (nach einer Laufzeit von ca. einer Stunde)." Alexander warf ein: " Höllisch interessant. Ich kann nichts aktuelles erkennen, was dieses Problem betrifft. Interessante Versionen zum Testen: 11-pre5 und 11-pre6. Riecht nach Buffer Cache Problemen, doch kann ich nichts Relevantes entdecken." Später fügte er hinzu, " Fehlermeldungen würden interessant sein...Bisher sind sowohl 2.95 als _auch_ 2.91 beteiligt, Raid und Nicht-Raid. Just fschking peachy..."

Zu einem Zeitpunkt erkannte Neil, dass sein Bericht irrelevant zu dem der anderen ist, indem er Alexander sagte, "Es scheint, dass meine Berichte falscher Alarm sind. Es war ein Bug in meinem raid5 Code - und kein aktueller ausserdem - der die Filesystem Inkonsistenz verursachte. Wenn also deine früheren Patches für alle Anderen passen, dann sollten das der richtige Weg sein. Ich habe meinen fatalen Fehler behoben und kann nun das Problem nicht mehr nachvollziehen. Der Patch ging zu Alan."

Auch andere berichteten Fehler, doch schaffte es keiner während des Threads diese einzugrenzen. Mehr über Filesystem Probleme gibt es hier: BROKEN KCREF

Jeff V. Merkey postete einen Patch für modutils, um das 'depmod' Programm mit Red Hat's Skripten und Programmen wie Anaconda kompatibel zu machen. Im Laufe der Diskussion meinte er, dass dieser Patch sehr wenig verändere, doch die Alternative wäre, alle Skripte die damit zu tun haben, abzuändern. David Ford sagte, "Es ist trotzdem ein schlechtes Beispiel. Anaconda hätte gleich korrekt geschrieben werden sollen." Mohammad A. Haque meinte auch, "Mir wäre ein anderes Anaconda auch lieber als speziell-verschachtelte Standard Utilities, die auf die Distributionen entfallen. " Jeff argumentierte in Bezug auf Red Hat's "alternate command line switch handling" in depmod, "wenn Red Hat diese Switches standardisiert hat, warum werden dann keine Alias-Kommandos daraus gemacht? Wäre ein trivialer Patch." David Ford kam dazwischen, "Dann lasse RedHat ihre eigene Version von modutils maintainen. Weder ist RedHat der Standard noch sollte RedHat Programmautoren Vorschriften machen noch sollten andere Distributionen von RedHat's Methoden beeinflusst werden. Wenn dir das nicht gefällt, ersetze depmod mit einem Skript, dass dieses Flag entfernt, bevor es das Original-depmod aufruft."

Anderswo sagte Keith Owens (modutils Maintainer), "Ich habe ein grosses Problem mit RedHat. Die machen imkompatible Änderungen an Utilities, geben keine Patches zum Maintainer zurück und erwarten, dass die restliche Welt ihrer Führung folgt. Die -i und -m Flags bei modutils sind nicht die einzigen Beispiele, ich fand erst neulich heraus, dass sie IA64- und Sparc Patches zu modutils hinzugefügt haben und keine Anstalten machen, es mir bekannt zu geben. Andere Distributionen senden mir Patches, speziell Debian und SuSe machen es richtig." Er fügte hinzu: "Der "-m -i" Patch ist überflüssig. Betrachtet dies als meinen Protest gegen die Unarten von Distributionen, die haben den Mist durch fehlende Kommunkation geschaffen und jetzt sollten sie ihn auch wieder beheben." Jes Sorensen antwortete:

Ich meine du sprichst hier ein sehr stichhaltiges Problem an. Das gleiche Problem exisitiert mit dem Kernel; Ich sehe es so oft, dass jemand sich entschliesst einen Treiber zu hacken und den Patch Linus zu senden, ohne den Author des Treibers einen CC zu geben. Manchmal ist das 'nur' um mit den letzten Entwicklungs-Kernels kompatibel zu bleiben - aber dem Maintainer zu CCen ist nicht viel was man hier erwarten kann.

Mir würde es auch gefallen, Leute zu ermutigen den Maintainer Bescheid zu geben, wenn sie umfangreiche Änderungen an einem Code - der einem anderen Maintainer gehört - durchführen. Es wäre nichts Besonderes, wenn der Maintainer schon eine Idee hat, wie Manches laufen könnte und könnte sogar mit daran arbeiten. Es ist Verschwendung, wenn Leute an zwei widersprüchigen Entwicklungen arbeiten wie hier.

Linus Torvalds veröffentlichte 2.4.0-test12-pre2 und sagte, "Durch die Geburt meiner dritten Tochter letzte Woche (yes, I got /.'ed), wenn ihr mir Patches sendet, die nicht in pre2 vorkommen, könntet ihr ziemlich sicher sein, dass sie verloren gehen." Ein Haufen Leute gratulierten und Neil Brown meinte Kernel-erfahren, " Was passiert mit den Sachen, die in 2.4.0test11-ac{1,2,3,4} eingegangen sind? Wirst du mit Alan "synchronisieren" oder sollen wir dir die Stückchen direkt schicken? " Alan Cox antwortete:

When Linus pre3 herausgibt, werde ich ihm Sachen aus meinem Tree senden, die sich als durchführbar bewiesen haben. Sachen, die fehlerverdächtig aussehen und an denen noch gearbeitet werden muss werde ich im -ac Tree behalten und es weiterhin gegen Linus Code veröffentlichen.

Es verschafft mir keine Probleme, wenn ihr Linus eine Kopie schickt, ich werde es nur von meinen Patches abziehen, sobald es in seinem Tree erscheint.

Alan sendet mir seine Patches ohnehin in kleinen Brocken und schafft es hervorragend Sachen aufzuteilen. Wenn mir direkt zurückgesendet wird heisst das, das Alan jenen Teil des Patches fallen lassen würde - oder dass ich den Patch zweimal erhalte. Beides ist in Ordnung, solange es der _selbe_ Patch ist.

Wenn ihr Änderungen gemacht habt und dies Alan schickt, solltet ihr mit Alan synchronisieren - um sicher zu gehen, dass ich nicht endlos die alten Sachen durch Alan verwende.

Kurt Garloff berichtete von einer Endlosschleife in modutils-2.3.21, wo sich PPP über Ethernet endlos in der build_stack() Funktion aufruft. Er legte die 'modules.dep' Datei bei, um das Verhalten aufzuzeigen und meinte, "Es gibt eine wiederkehrende Abhängigkeit von pppoe auf pppox auf pppoe auf....In modprobe exisitiert Code, der das in build_stack() erkennt, doch scheint er nicht zu funktionieren. Die alte Abhängigkeit wird verworfen und die neue genommen. Und wieder auf Abhängigkeiten gecheckt :-("

Keith Owens (der modutils Maintainer) antwortete, "Der Kernel Code ist broken. Wiederkehrende Abhängigkeiten sind sinnlos, der pppoe Maintainer pflichtet mir hier bei und ich dachte der Bug wäre behoben." Rod Stewart sagte, " Es ist in test10/11 behoben." Bezugnehmend auf den modutils Code, fügte Keith im gleichen Zug hinzu:

Wiederkehrende Abhängigkeiten werden weder unterstützt noch erkannt. Der exisitierende Code, der die Inter-Modul-Abhängigkeiten prüft, einschliesslich Abhängigkeiten, Aliases, Probes, Probealls vor und nach den Feststellungen ist ein Kuddelmuddel. Es wuchs mit den Jahren mit Spezial-Fällen die hinzugefügt worden sind und ist nicht stabil.

In modutils 2.5 wird der gesamte Code ausrangiert und durch einen "standard graph walking algorithm" mit Schleifenerkennung und Back-Tracking statt Spezial-Fall-Code ersetzt werden. Dies könnte das modutils Verhalten in einigen seltenen Fällten verändern, daher möchte ich diese Änderungen nicht umstellen, bevor 2.4 freigegeben ist. Ich habe eine Liste, von den Änderungen, die Ruckwärtskompatibilität brechen würde, dies ist nur eins davon.

Kurt meinte, er freut sich auf modutils 2.5, doch er meint das schon vor dieser Release, "das momentane Verhalten ist nicht annehmbar, da es das Sytem einfach zum Stillstand bringen kann, wenn es von kmod aufgerufen wird. Ich werde versuchen mir den Code zusammenzureimen und sicherstellen, dass modprobe nicht verrückt spielt durch Schleifenerkennung (wenn ich das in einer Weise machen kann, in der der Code auch weiterhin läuft) oder indem ich die Rekusrionstiefe eingrenze. Ich schicke Euch einen Patch." Am nächsten Nachmittag postete er einen Patch und sagte, "Da für mich die Abhängigkeiten tatsächlich recht schwerfällig aussahen, habe ich sie nicht wirklich verändert. Ich habe nur die Rekursionsgrenze implemententiert, um den modprobe Prozess daran zu hindern, den ganzen Speicher aufzubrauchen."

Tigran Aivazian berichtete fröhlich, " Nur zur Info, 2.4.0-test12-pre3 verhält sich wesentlich besser als frühere Versionen auf meiner 6GB RAM Maschine. Nicht nur /proc/mtrr zeigt alle 6GB ge-cached für write-back, ich musste auch nicht mehr eines der eepro100 Karten neu starten, um es zum Laufen zu bringen -- Das war etwas, was mit jeder früheren Version der Fall war (ohne david-mtrr.patch)" Boszormenyi Zoltan antwortete:

Excellent! :-))))

BTW was der test12-pre2/3 enthält ist David Wragg's Arbeit, zum HPA CPUID Code geupdatet, der in test11 ist. Linus hat mir fälschlicherweise den ganzen Patch in test12.log zugeschrieben.

John Fremlin berichtete, dass die Yamaha OPL3-SAx Sound Karte "für die Leute, deren BIOS genutzt wird das ISA Pnp zu aktivieren, zur Zeit nicht funktioniert." Er hat dem Maintainer vor einem Monat einen Patch gesandt - ohne Antwort. Er postete den Patch auf linux-kernel und erklärte, "Dieser Patch implementiert ISA Pnp probe und aktiviert/deaktiviert für den OPL3-SAx. Da ich keine Spezifikationen für diese Karte habe, kann ich nur sagen, dass es für mich geht; trotzdem sollte es keine Konfigurationen brechen, da der PnP probe nur eingreift, wenn keine Ressourcen als Parameter übergeben wurden." Scott Murray meinte, "Da ich der Maintainer hierfür bin, muss ich mich entschuldigen. Ich war nachlässig keinen Patch in 2.4 zu bekommen, da ich konzentriert darauf bin, einen neuen Job zu beginnen. Mein momentaner Plan ist am Freitag frei zu nehmen und all die verschiedenen Fixes, die mir zugeschickt wurden, in einen Patch zu integrieren. Ich muss trotzdem zugeben, dass ich 2.4.0-test Kernel seit einiger Zeit laufen habe und nie irgendwelche Probleme hatte meine OPL3-SA3 Karte zu aktivieren über den altmodischen Weg via isapnp." Er sah einige Probleme in Johns Patch und wiederholte, dass er versuche bald einen umfassenden Patch zu geben.

Richard Pries postete einen Patch, und erklärte, "Momentan, wird mmc_ioctl() in cdrom.c eine cdrom_msf Struktur übergeben wenn ioctl() mit CDROMREADRAW, CDROMREADMODE1 oder CDROMREADMODE2 als 2.Parameter aufgerufen wird. Diese Struktur bietet nicht den erforderlichen Puffer, um die Daten einzulesen und es entspricht nicht der Struktur, die cdrom.h meint mit diesen ioctl() Aufrufen benutzen zu müssen. Dieser Patch ersetzt die cdrom_msf Struktur mit einer cdrom_read Struktur (wie in cdrom.h angegeben). Einleitende Tests geben zu erkennen, dass dieser Patch für IDE und SCSI Geräte zugleich funktioniert." Doch Jens Axboe antwortete, " Ich könnte wetten, dass das funktioniert, aber du breakst alle Programme, die momentan jeden der oben genannten ioctls verwenden. Ich kenne das schon seit Jahren... Man kann das alles mit cdrom_msf machen, es bedeutet nur mehr Auseinandersetzung damit. In 2.5 werde ich neuere Varianten der oben genannten ioctls verwenden und sie aus Kompatibilitätsgründen so wie sie sind lassen, sie wegzuwerfen ist keine Lösung." Er fügte hinzu, " Ich werden einen Pactch machen, der den Kommentar durchgängig korrigiert." Woanders mit dem Betreff: [Patch] Correct cdrom.h comments., gab Richard einen Patch die irreführenden Kommentare in cdrom.h, die zu seinem Patch davor führten, auszubessern. Jens bedankte sich und fügte ihn ein.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	18 Nov 2000 - 30 Nov 2000	(12 posts)	Fix For Longtime 2.2 Virtual Memory Bug
2.	22 Nov 2000 - 29 Nov 2000	(42 posts)	More 2.4 Filesystem Corruption
3.	26 Nov 2000 - 27 Nov 2000	(18 posts)	Linux Distros Making Incompatible Changes To System Tools
4.	27 Nov 2000 - 3 Dec 2000	(13 posts)	Linus' Daughter
5.	28 Nov 2000	(5 posts)	'modprobe' Infinite Loop On Buggy Drivers
6.	29 Nov 2000	(2 posts)	Success Report For Big Memory Machines
7.	29 Nov 2000 - 30 Nov 2000	(2 posts)	Slow Maintenance Of Yamaha OPL3-SAx Sound Driver
8.	30 Nov 2000	(4 posts)	Longtime struct Weirdness And Doc Bug; True Fix Planned For 2.5

Kernel Traffic #97 For 11 Dec 2000

By Zack Brown

Translated By: Florian Zimmermann