Kernel Traffic #98 For 18 Dec 2000

There were 368 different contributors. 156 posted more than once. 129 posted last week too.

James Lamanna berichtete gute Erfahrungen mit dem Promise Technologies Fasttrack 100 Treiber (mit Quellen und einer proprietären Objektdatei erhältlich). Er wollte wissen ob es möglich ist, das Modul direkt in den Kernel einzukompilieren, damit sein System die Karte automatisch erkennen würde. Und erklärte, "Das Makefile zu bearbeiten um das Modul einfach in die SCSI Library einzulinken scheint nicht zu klappen. Die Laufwerke werden beim Booten nicht erkannt wenn ich von Floppy Laufwerk und mit so einem Kernel boote." Aufstürmend antwortete Andre Hedrick:

NEIN!

Du VERLETZT so die vereinbarten Bedingungen, wenn du die BINARY Soft-Raid Engine und die GPL Vereinbarungen im Kernel benutzt.

Henning P. Schmiedehausen versuchte dies zu korrigieren, er sagte die einzige Vetragsverletzung läge vor, wenn James das Result verbreiten würde. Hinzufügend meinte er, "Man kann in seinen Kernel alles einkompilieren, solange man es nicht weitergibt."

Im Gegenzug sagte Andre, " zur Erinnerung ICH LEGTE die Bedingungen fest, dass das Modul erzeugt werden darf! Schau' den Wrapper an und du wirst sehen, dass es Teile des pdc202xx.c Codes sind der mir gehört. Dies berücksichtigt sind, um diesen GPL Code zu nutzen, die auferlegten Einschränkungen und Vereinbarungen Modul-exklusiv."

In Bezug auf die allgemeine GPL Fragen war Dr. Kelsey Hudson anderer Meinung als Henning und meinte, das wenn GPLte Quellen verändert werden der Anwender das Resultat verbreiten muss. Er sagte, "Man kann nicht Sachen hinzufügen und es dann nicht verteilen, das ist Vertragsverletzung." Alan Cox antwortete, "Nein ist es nicht. Manche glauben es wäre eine. Man muss nur die Änderungen bereitstellen, wenn man die betreffenden Binaries ausgibt. Manche Leute denken auch, dass die 'linking'-Klausel bedeute, dass sie einfach den Hersteller anweisen könnten den Link zu machen; auch das wäre falsch im haftungsbezogener Rechtsform - das Gesetz kümmert sich um den Inhalt. " Pavel Machek antwortete: "Genau das passiert momentan mit dem lucent Winmodem Treiber: es gibt eine modifizierte Version von serial.c und die Kunden werden aufgefordert, es zu kompilieren und (statisch) mit proprietären Code zu linken, um einen brauchbaren Treiber zu erhalten. Ist das ok oder nicht?" Alan dachte eher nicht doch er meinte, dies liegt bei Theodore Y. Ts'o, ob er es erzwingen würde oder nicht. Es folgte eine lange Diskussion über die Lizenzbedingungen der FSF es kam jedoch zu keiner echten technischen Diskussion mehr.

Fortführend von BROKEN KCREF, berichtete Andries Brouwer, " Ich testete noch einmal zwei grosse Trees. Es gab wieder Korruptionen und - nach genauerer Einsicht - waren die Dateiinhalte gleich; es ist nur interne Korruption." Linus Torvalds fragte nach einer groben Schätzung, wann Andries dieses Verhalten erstmals bemerkt hat und Andries meinte, " Ich berichtete beide Fälle. Das heisst, das erste Mal vor einigen Tagen." Linus antwortete:

Ich wollte damit nicht sagen, das du sie nicht ordentlich berichtet hast.

Es ist nur so, dass ich mit einer weit fortgeschrittenen Form von Altzheimer geboren wurde und ich habe Probleme Details für mehr als fünf Mintuten im Kopf zu halten.

Ich bin halb ernst, btw. Es ist nicht so, dass ich kein gutes Gedächtnis habe, aber ich neige dazu mir Sachen als Muster zu merken und wie sie arbeiten aber ich bin _wirklich_ schlecht in Detaildenken. Darum bin ich auch absolut abhängig von Leuten wie Alan Cox etc., die Problem-Listen verwalten und gut darin sind, Berichte zu erfassen, welche Systeme dies sehen usw. Ich bin hier echt schlecht darin. Wirklich.

Jedenfalls klingt das vorläufig wie eine Anforderungs-Korruption des neuen re-merge Codes. Es passt zu den Details, du hast IDE und alles. Ich merke, dass du es zumindest nicht mehr in pre3 reproduzieren kannst aber wenn es danach noch einmal vorkommen sollte, dann schrei. Laut.

Doch das löst nicht die SCSI Korruption, die nicht durch die Anforderung kommen kann. Was ist hier das Verhaltensmuster?

Dann berichtete Andries, "Ich probierte es gerade mit 2.4.0test12pre3, beinhaltet Jens Fix und habe keine Korruption mehr gesehen. Ich werde noch ein wenig testen, aber das war es wahrscheinlich. " Tigran Aivazian testete es auf seinem SCSI System, doch Jens Axboe erklärte, "Nein, dieser Fix wird nur auf einem IDE System einen Unterschied bedeuten. Daher kann er wahrscheinlich nicht für alle Korruptionsprobleme gelten, doch hoffe ich zumindest für ein paar... Der Fix wurde auf dem anderen Korruptions-Thread gepostet und er ist auch in test12-pre3."

Patrick van de Lageweg postete einen Patch der es einem UserSpace Dämon erlaubt, die Interna des seriellen Ports zu verwalten. Er sagte, "Er wurde für den Pele 833 RAS Server geschrieben, sollte aber auch für Device Drivers im UserSpace nützlich sein." Pavel Machek bemerkte, "Super, endlich hat das einer implementiert. Das wird obgligatorisch sein, wenn wir WinModems richtig unterstützen wollen; auch die ISDN Leute könnten interessiert sein [um die AT Emulation aus dem Kernel zu bekommen]." Und Jamie meinte, "Für WinModems kann man es ganz gut über ptys machen -- die pty und tty Seite greifen auf die selbe termios-Struktur zu. Der neue Treiber ist trotzdem mit der gleichen Funktionalität wesentlich sauberer."

Doch Tigran Aivazian führte an, dass der Patch aufgebläht ist, da die Variablen explizit auf null gesetzt sind, statt den Anfangswert des BSS Bereichs, den der Kernel ohnehin beim Bootvorgang auf null setzt, zu nutzen. Er erklärte, dass der Patch so wie er jetzt ist, "mindestens 4 * USSP_MAX_PORTS Bytes im Kernel Imgage vergeudet. Typischerweise um die 64 Bytes aber es könnten auch mehr sein. Für weitere Informationen siehe die dummen Flamewars auf der Liste." Rogier Wolff meinte, "Und ich dachte, das die Leute gewonnen haben, die sagten, "Dokumentation ist wichtiger als die paar Bytes"." Er argumentierte, dass wenn die Anfangswerte explizit auf null gesetzt werden, es den Code Maintaintern wichtige Informationen gebe. Dann sagte Russell King: "In welchem Fall können wir das besser als Dokumentations-Fix einsetzen als die Kompiler-Ausgabe?" Er empfahl einfach einen Kommentar einzufügen, dass die Variablen erwarten würden anfänglich auf null gesetzt zu werden. Mit dem kam Rogier nicht klar und sagte :

Ich kümmere mich mehr über die 4 Bytes Extra Source als um die 4 Bytes Extra Objekt.

Ich halte die 4 Bytes Extra Objektcode für einen Compiler-Bug und wenn wir das vernachlässigen, wird der Compilerbug niemals behoben werden.

Roberto Ragusa berichtete, dass bei aktuellen Entwicklungs-Kerneln (2.4.0-test10 und 2.4.0-test11) der SoftwareRAID Autodetect Code eine Kernel Panic verursacht. Er postete ein Haufen Systeminformation, Oops Ausgaben, etc. und Neil Brown antwortete unverzüglich, dass das in 2.4.0-test12pre3 behoben sei; Roberto berichtete nein, dass Problem bleibt auch in diesem Kernel bestehen. Neil sah sich das Ganze näher an und antwortete:

Meine Schuld. Es gab einen "oops in SoftwareRAID autodetect" mit test10 und test11, der in test12pre3 behoben wurde und ich nahm einfach an, dass deiner derselbe ist, schaute also nicht richtig nach.

Jetzt, wo ich es mir noch einmal anschaue ist dein Problem ein anderes und ziemlich seltsam.

Er fügte einen Einzeiler dazu und sagte, " Ich habe mir den Code noch einmal einige Zeit angesehen und denke, dass ich etwas gefunden habe. linear.c könnte einen kmalloced Puffer überschreiben, was genau das erzeugt was du bekommst. Der folgende Patch ist nicht *korrekt* aber wenn er bei dir einen Unterschied macht, wissen wir was das Problem ist.. Bitte gebe mir Bescheid."

Roberto antwortete glücklich, "Ja, es gibt einen Unterschied :-) . Der Bootvorgang klappt jetzt und alle RAID-Partitionen werden korrekt erkannt."

Oleg Drokin bemerkte, dass in 2.4.0-test11, aktiviertes hot-plugging eine Race Condition verursacht wenn die Anzahl der Netzwerk Interfaces geändert wird (in diesem Fall von ppp verursacht). Andrew Morton gab einen langen Patch und erklärte, "Jupp. Das ist weil der Kernel versucht von einem halb-toten Process zu fork()en/exec()en. Kannst du diesen Patch bitte testen? Er wurde Linus für test12-pre4 geschickt, aber..." Oleg antwortete, "Ja, so klappt es. Doch Code Pfade und Lesbarkeit sind furchterregend geworden, leider:(" Keine Antwort folgte.

hier mein letzter Versuch einen Weg zu finden das A20M# auf wirklich allen Systemen einzuschalten -- einschliesslich Olivettis, IBM Aptivas, exotischen Notebooks, yadda yadda.

Die exotischen Notebooks mit broken SMM Code sind es über die ich mich am meisten sorge... es könnte ziemlich gut KEINEN WEG geben diese zu untersützen da man keine Rückmeldungen bekommt, dass es mit diesen nicht funktioniert.

Falls jemand A20M# Probleme mit irgendeinem Kernel hatte - aktuell oder nicht - *bitte* probiert diesen Patch gegen 2.4.0-test12-pre5

Linus Torvalds hatte einige technische Punkte und sagte, "Apropos - kennen wir irgendein System, das wirklich dieses "and $0xfe" braucht? Dieses Register macht mich echt nervös." H. Peter Anvin sagte, " Gute Frage. Das Ganze macht mich hier irgendwie nervös... vielleicht sollten wir den BIOS INT 15h Interrupt nehmen, um in den Protected Mode zu kommen?" Alan Cox fiel grinsend ein, "Aus meiner Erfahrung mit BIOS Authoren werden nur die gleichen Sachen am Stackanfang und die gleichen Segment Register genommen, wenn Windows98 die gleichen Funktionen mit den gleichen Paramtern aufruft;)" Linus fuhr fort: " Ich stimme Peter zu - wenn jemand von BIOS Programmierung eine Ahnung hat und weiss, wie man "int 15" nutzt um den Protected Mode zu aktivieren, dann sollte das die leichteste Lösung sein. Der einzige Grund warum der Linux Setup Code dies manuell macht, ist dass das Original eben so geschrieben wurde - und es wurde so geschrieben, weil ich noch nie in meinem Leben das BIOS genutzt habe _und_ weil ich den i386 kennenlernen wollte. Weder das eine noch das andere ist ein guter Grund jetzt 10 Jahre später."

Der Protected Mode Schalter in INT 15 ist wahrscheinlich die am wenigesten getestete Funktion überhaupt. I würde ihr nicht trauen, denn darauf zu bauen würde zusätzliche Belastung für Embedded LinuxEntwickler bringen, viele von ihnen haben überhaupt kein BIOS. Es ist das 'am wenigsten getestete' weil es keinen Weg zurück in den Real Mode gibt. Dies deutet an, dass es einer einmal 'gestestet' hat, sichergestellt hat, dass einige 32-Bit Funktionen für ein paar Microsekunden liefen und verkündigte: "Es funzt!"

Viele neue Chipsätze schauen nach der Sequenz:

Write 0xd1 to port 0x64
Write 0xN1 to port 0x60

... Wo 'N' irgendwelche Bits sind und das LSB den A20 verbreitet

Die Schreibbefehle müssen in der richtigen Reihenfolge sein, also 0x60 muss zuerst gelesen werden OR in Bit 0. Schreibe 0xD1 in 0x64 und dann den neuerstellten Wert auf Port 0x60.

Es braucht zwischen ca.700 und 1500 Microsekunden das A<20> Propagation Bit zu setzen. Es benötigt nur wenige hundert Nanosekunden für dir virtuelle Sequenz - wie oben - das gleiche zu tun.

Auf allen Systemen, die ich mir angeschaut habe, einschliesslich diverser Laptops ist der 'schnelle' A<20> Enable Port R/W. Das heisst, man muss nicht das System abstürzen lassen, wenn man ein geheimes reserviertes Bit aktiviert. Einfach erst lesen, OR in dem A<20> Bit, dann schreiben.

Wenn man DOS (oder free-DOS) bootet, kann man damit experimentieren und mit DEBUG herumspielen. Wenn man in Real Mode DOS A<20> setzt wird nichts passieren. Man kann sogar nach wraps hinter FFFF:0000 mit DEBUG schauen um zu sehen, ob das Bit aktiviert ist.

I schlage vor, dass eine "universelle" Sequenz die D1/N1 Sequenz ist - wie oben angezeigt (das wird mit echten Keyboard Controllern funktionieren); man muss nicht auf das Beenden des letzten Kommandos warten solange man nur 2 Befehle hintereinander hat. Das ist deshalb so, da der Controller nicht weiss, ob man den Status liest, er wird das nächste Kommando ausführen sobald der Abschluss des vorhergehenden Befehls geschrieben wurde.

Der nächste Schritt in der "universellen" Sequenz - falls das vorhergendene nicht funktioniert - wäre das schnelle A<20> Bit (nur) auf Port 0x92 zu aktivieren.

Woanders berichtete Kai Germaschewski Fehler mit H. Peter's Anfangspatch und sagte, "Nur ein Hinweis. Der Patch behebt hier (Sony PCG-Z600NE) nicht das Problem. Immer noch ein spontaner Reboot genau dann, wenn ich meine Konsole erwarte wieder zu erscheinen." Linus Torvalds Gedanken machten einen Sprung und er antwortete:

Ich wette, ich weiss was passiert.

Möchte $5 USD darauf wetten, dass suspend/resume den Keyboard A20 Status speichert, aber NICHT die fast-A20 Gate Information?

Also wird alles, was A20 nur mit dem fast A20 Gate aktiviert, denken dass A20 bei Resume wieder deaktiviert wurde.

Was Linux _wirklich_ traurig machen würde, überflüssig zu sagen. Sofortiger Tod in Form eines Triple Faults (all der Kernel Code ist zwischen 1-2MB angesiedelt, was unsichtbar wäre), geht in einen sofortigem Reboot über.

Peter, wir müssen definitiv das Keyboard A20 machen auch wenn fast-A20 gut funktioniert.

Jupp. Es ist ein BIOS Bug, welch ein Schock...(so etwas passiert nie, richtig?)

Ich könnte es zusammenhacken, dass INT 15h für den Sprung in den Protected Mode genutzt wird, so hässlich wie es ist, doch ich werde keine Zeit haben vor meiner Reise. Es würde ein wenig Umstrukturierung in setup.S bedeuten und könnte LOADLIN breaken.

Einstweilen ist dies mein Zwischen-Patch (um test11 zu säubern). Das Wichtige ist, dass ich den Keyboard Controller Timeout verringert habe um einem Faktor von ca. 167, während ich das "delay" Bit ein wenig grösser gemacht habe.

Jetzt, wenn man keinen Keyboard Controller hat, sollte die Bootup Dauer ca. 1.2 Sekunden oder so dauern (es ruft empty_8042 3mal auf, jedes Mal mit ca. 0.4 Sekunden Timeout). Was in Ordnung ist. Vor allem da die System ohne Keyboard Controller und die nicht einmal eines emulieren, recht rar sind. Und es ist immer noch lang genug, dass wenn der Keyboard Controller innerhalb 0.4 Sekunden noch nicht geleert wurde etwas anderes ziemlich falsch ist.

Der kein-keyboard-controller Timeout war bisher um die 3 Minuten.. Was _ganz sicher_ extrem ist. Die meisten würden annehmen, dass ihr System sich aufgehängt hat.

Okay, hier noch ein A20 Patch (gegen test12-pre6); diesmal für alle, die ihn ausprobieren wollen. Der Patch hat die folgenden Alogrithmen, um A20 zu aktivieren:

Try the BIOS call. If it works, we're cool.
Try the KBC (using Linus' lowered timeouts.)
If the KBC doesn't work, or is very slow, flip port 92.

Nach 3 Mal sitzt er in der selben Endlosschleife, auf die Aktivierung des A20 wartend (notwenig für z.B. einige Toshiba Notebooks, die einen sehr langsame Antwort für den A20 haben).

Der Hauptunterschied zwischen diesem Patch und test12-pre6:

Zuallererst wird das BIOS probiert. Das sollte das Risiko, dass das BIOS während eines Supends durcheinanderkommt reduzieren. Dies gibt ausserdem eine nicht-geltende Entschuldigung für Nicht-Standard Sachen -- wenn das Standard KBC nicht implementiert ist *und* man auch keine BIOS Aufruf bereitstellt, hat man ein echtes Problem mit der Hardware.
Wenn das KBC schnell genug antwortet (innerhalb ca. 10000 Zyklen) werden wir das fast A20 Gate nicht anrühren. Das ist unterschiedlich zum vorhergehendem Code, wo das fast A20 Gate gleich nach dem KBC aufgerufen wurde, auch wenn das KBC sofort antwortete.
Ich musste den A20 Code etwas eher in setup.S einfügen, damit das BIOS trotzdem erreichbar ist.

Bitte probiert es aus und lasst mich es so bald wie möglich wissen.

Reto Baettig wollte wissen, " ob es irgendeinen standardisierten Weg gibt, I/O mit einem Block Device zu machen, welches 64Bit für die Block Nummer ausgelegt hat?" Er meinte noch, dass mit dem momentanen 32-Bit Schema, "Meint ihr nicht, dass wir auf Probleme stossen werden, wenn es bald Raid Systeme mit einigen Terrabytes Speicher vollgeladen mit MP3's gibt ;-)" Brian Pomerantz gab ein realistisches Beispiel dieses Problemes und sprach, "Ich werde im Februar ein Raid Systems mit 1.7 - 5.1 TB aufstellen. Es wird von Clients über ein Netzwerk Block Device als ein einziges Block Device gesehen (vielmehr werden es 16 Ciprico Rimfire 7000er verteilt auf 4 Knoten über einen Quadrics Switch sein). Also was ich momentan sehe, ist dass ich nicht in der Lage sein werde diese Speicherkapazitäten über ein einzelnes Block Device anzusprechen. Im Sommer 2001 wollen wir 10-15 TB (abhängig von Budget und Nutzen) Speicherkapazität für einen Produktions- Cluster zusammenstellen und es wäre schön, wenn unser paralleles Dateisystem den kompletten Platz auf einem Image haben könnte." Stephen C. Tweedie sagte, dass dies auf den "dringenden Fixes" für 2.5 stehen würde.

Die CyrixIII Chips von Via haben die Centaur Hersteller-ID, womit der identify_cpu Aufruf in arch/i386/kernel/setup.c fehlschlägt. Die Centaur ID zu haben ist wohl begündet damit, dass Via auch Centaur besitzt. Ich habe erst den centaur_model Aufruf mit dem des cyrix_model ersetzt, doch ich weiss ja, dass ich einen Cyrix Chip habe.

Vielleicht sollte ein Test in dem centaur_model Abschnitt eingefügt werden, um auf den cyrixIII zu testen.

Fehlermeldung ist ein general protection fault.

Er entschuldigte sich, falls das ein "alter Hut" sein sollte, doch Alan Cox antwortete, "Es ist ein ziemlich neuer Hut. der VIA cyrix III ist ein NextGeneration IDT Winchip (VIA kaufte sowohl die Winchip Sachen als auch die Cyrix Sachen). 2.2.18 sollte den Winchip korrekt behandeln " Dave Jones erläuterte, dass die stabilen und Entwickler Trees nun schon einige Zeit diesen Test beinhalteten und fragte Eric, "Meinst du, dass die letzten Versionen ihn immer noch nicht erkennen? " Doch es gab keine Antwort.

Carl Perry sah bei Slashdot, dass die Microsoft API sehr schlecht dokumentiert sei und er möchte nicht Linux denselben Weg gehen sehen. Er fragte, ob es ein Projekt gäbe, wo die Kernel Teilsysteme, Treiber, Kompatibilitätssachen, etc dokumentiert seien und bot an das Ganze zu koordinieren und den Aufwand in Kauf zu nehmen. Jeff V. Merkey antwortete, "Wer auch immer das auf Slashdot gepostet hat er wird irgendein Killerzeug geraucht haben oder was auch immer. Die Windows API ist ausserordentlich gut dokumentiert via Online Doku von MSDN -- besser als die meiste Software irgendwo auf der Welt. Wer so etwas behauptet war high oder ignorant oder hatte noch nie ein MSDN Einschreibung. Ich bekam 20-40 CDs monatlich von MS auf einer allgemeinen Einschreibung mit einer enormen Dokumentation." Auch Alan Cox antwortete Carl:

Für die Kernel Bereiche gibt es ein Projekt dort draussen, welches über Funktionen und was sie inline im Kernel machen, Dokumentation führt. Es geht nur langsam voran. Irgendetwas formell und strukturiert durchzuführen ist solange nicht produktiv, bis die Dokumentation wesentlich vollständiger ist.

Bei System Aufrufen: Andries Brouwer maintained eine man page Sammlung (und schreibt viele davon selbst). Er empfängt Vorlagen dafür.

Daniel Phillips postete einen Link zu Linux Cross Reference, und erinnnerte, "Ich weiss genau, wie es sich das erste Mal anfühlt, in die Kernel-Schnittstellen Internas einzutauchen - für mich war das kaum vor einem Jahr. Ich wollte zu jener Zeit alle Dokumentations-Probleme beheben, aber es wurde schnell zu einer Wahl zwischen guter Entwicklung zu machen oder nützliche Dokumentation zu schreiben. Schätze mal, für was ich mich entschieden habe. Ich hoffe inständig, dass sich andere für das Gegenteil entscheiden werden und die Linux Hacking Welt ein besserer Ort sein wird." Er gab auch einen Link zu Andries Brouwer's Linux Information Seiten und die Kernelnewbies Links Seite. Weiterhin sagte er, " Tigran Aivazian hat 'Linux Kernel Internals' geschrieben, was *sehr empfohlen* und 100% frei ist. Warum tust du dich nicht mit ihm und Gary Lawrence Murphy zusammen (siehe auch seinen monatlichen Kenrnel-Nag)?" und Tigran Aivazian antwortete in Bezug auf die 'Linux Kernel Internals':

falls er nicht weiss wo er es finden kann:

http://www.moses.uklinux.net/patches/lki.html

Interessanterweise scheint das Hauptproblem mit LKI zu sein, dass es _nicht_ die Aufgabe ist es up-to-date zu halten, sondern die fehlenden Stücke einzufügen, hervorzuheben den Buffer Cache und Page Cache. Bis jetzt verstehe ich mehr oder weniger den Linux Buffer Cache (nur nach fleissigem Vergleich mit UW7, AIX, OSR5 und vielen anderen kommerziellen UNIX Implementationen dessen Quellcode erhältlich ist) aber noch nicht den Page Cache (sogar nachdem ich alles darüber gelesen habe, einschliesslich aktuelle Linux Kernel Bücher von Bovet, womit ich gerade fertig wurde). Zum Beispiel kapiere ich nicht, dass Dinge schieflaufen, wenn jemand die gesamte readahead Logik des Page Caches entfernt.

Also, wenn einer ein Kapitel über Linux Page Cache und es den LKI Buch beisteuern könntet (und so zum Co-Autor werden würde :) überlegt nicht lange -- es wäre ein Beweis, dass jemand in der Welt es tatsächlich versteht -- momentan zweifle ich da sehr daran. Nehmt' es als Herausforderung :)


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

1.	24 Nov 2000 - 5 Dec 2000	(34 posts)	Licencing Discussion
2.	28 Nov 2000 - 4 Dec 2000	(56 posts)	Hunting Several Filsystem Corruption Bugs: The Saga Continues
3.	30 Nov 2000 - 7 Dec 2000	(9 posts)	User-Space Serial Port Driver
4.	1 Dec 2000 - 6 Dec 2000	(12 posts)	Kernel Panic In SoftwareRAID Autodection In Recent Development Kernels
5.	4 Dec 2000	(3 posts)	Race Condition with Hot-Plugging And Number Of Network Interfaces
6.	5 Dec 2000 - 8 Dec 2000	(21 posts)	Negotiating The A20 Address Gate
7.	6 Dec 2000 - 7 Dec 2000	(5 posts)	Status Of Large Filesystem Support
8.	7 Dec 2000	(3 posts)	Trouble Identifying Cyrix III Chips From Via
9.	7 Dec 2000 - 8 Dec 2000	(6 posts)	Kernel Documentation

Kernel Traffic #98 For 18 Dec 2000

By Zack Brown

Translated By: Florian Zimmermann