Kernel Traffic #99 For 25 Dec 2000

There were 453 different contributors. 197 posted more than once. 152 posted last week too.

Eckhard Jokisch hatte Probleme ein Onstream Laufwerk zum Laufen zu bringen. Rogier Wolff meinte im Laufe der Diskussion:

Mein Rat heutzutage: Lass von Onstream die Finger.

Seit dem achten Juli versuchen wir das dumme Teil zum Laufen zu bringen, auch der Technische Support bei Onstream war sehr hilfreich und sagte uns, was zu tun ist und so. Es ist wie wenn man auf eine Kernelversion zurückgreifen soll, von der man weiss, dass sie Remote-Sicherheitslücken hat. Trotzdem löst das nicht die Probleme, die wir damit haben. Nach vielem hin und her haben sie uns versprochen, dass sie das Problem für die Leute in den Staaten "eskalieren" lassen wollen. Das führt nicht zu den Ergebnissen, die wir ihnen in dem Monat als Vorgabe gegeben haben.

Kurz gesagt: Im einfachsten Fall, wenn einfach nur ein Stream von Bytes auf das Laufwerk geschrieben wird, geht es. Doch das Laufwerk hat nicht annähernd die "raw error rate" die es haben sollte.

Wenn man ein Backup-Programm hat, dass ein paar Mal vor- und zurückspulen muss verliert das Laufwerk die Information, auf welcher Spur es steht und kann diese Situation nicht korrigieren.

Ich habe meines dem Hersteller zurückgeschickt und hoffe, dass Onstream letztlich diese Meldung macht: Sie unterstützen NICHT Linux.

Doch Kurt Garloff widersprach, "Ich arbeitete mit den USB und SCSI Versionen des OnStream Laufwerkes und das ohne Probleme! Wenn du einen wirklichen guten Rat suchst: Nimm den osst Treiber in Verbindung mit ide-scsi. Berichte Probleme auf der osst Mailingliste. Ich kann mich an keinen erinnern, dem bisher nicht geholfen wurde. http://linux1.onstream.nl/test/" Eckhard antwortete, " Das war echt hilfreich :-) Es geht jetzt. Wäre es nicht gut, einen kleinen Link darauf irgendwo in der Kernel-Doku unterzubringen?" Ende des Threads.

Georg Nikodym berichtete, dass sich sysklogd 1.3-31 nicht mehr mit den Headern von 2.4.0-test11 kompilieren lässt, da sich linux/module.h inkompatibel geändert hat. Er meinte, " Streng genommen ist dies kein Kernel Bug" [...] " Ich verstehe nicht ganz klar, von wem der Code so geändert werden muss, dass ich sowohl linux-kernel als auch denjenigen, die das Pech haben in der sysklogd Man-Page zu stehen, Bescheid geben muss." Keith Owens antwortete:

Als der modutils Maintainer und derjenige, der list.h in module.h eingefügt hat, sage ich sysklogd sollte *nicht* in linux/module.h eingebunden werden darf. Linus hat gesprochen; es ist ein Fehler in UserSpace-Programmen die Kernel Header einzubinden. Sogar modutils beinhaltet nicht linux/module.h, stattdessen hat es eine portable (2.0 bis 2.4) lokale Definition der Struktur module.

ksym_mod.c ist nur vorhanden, um Oops Berichte in klogd zu entziffern. klogd behandelt nur einige Plattformen, es erhält oft den dekodierten Oops-Bericht falsch und zerstört die Log-Informationen die von anderen Oops Dekodern benötigt wird. IMNSHO (in my not so humble opinion) ist ksymoops beim Dekodieren der Oops'es wesentlich besser doch ich maintaine ksymoops, also bin ich vielleicht ein wenig voreingenommen;)

Ich wünsche mir, dass Oops-decoding komplett aus klogd entfernt wird. Die einzige Rechtfertigung dass klogd die Oops'es selbst dekodiert, ist dass es den User davor abhält manuell mit ksymoops zu arbeiten. Mir würde es nichts ausmachen, wenn klogd den Oops Text erhält, ausforkt um ksymoops zu starten um dann die ksymoops-Ausgabe zu loggen. Nur solange der Originaltext gelassen wird und die ksymoops-Ausgabe logischerweise von den echten Kernelausgaben unterscheiden muss.

Georg implementierte diesen Vorschlag und postete einen Patch, doch Keith sagte, " Du hast nur das Modulsymbol Handling entfernt. Das Problem ist aber, dass das komplette klogd Oops Handling veraltet und broken ist. Ich schlage vor alle Oops Abläufe von klogd zu entfernen, dass heisst klogd braucht weder irgendwelche Symbole noch die System.map." Georg meinte, er würde sich das einmal anschauen und meinte, " Da wir schon einmal eine grosse Operation tätigen, wozu überhaupt klogd? Bei jedem anderen Unix werden Kernel Messages via syslog geschickt. Welches Problem hat klogd gelöst und existiert es heute noch?" Er sagte, dass Keith's Angebot funktionell das Equivalent zu 'cat < /proc/kmsg > /dev/log &' sein würde. Keith erläuterte, " klogd bildet die Kernel Messages von <n>Text auf Syslog Levels ab und fummelt ein wenig an den Kernel Log-Levels während des Hochfahrens herum. Es muss mehr als ein simpler 'cat' sein. Als zu klogd Symobl-Handling hinzukam war ksymoops im Kernel drin und ziemlich unzuverlässlich. Seitdem ist das ksymoops Paket in ein abgetrenntes Paket verschoben worden und läuft jetzt sicher. Leider hat das Oops-Handling in sysklogd nicht Schritt gehalten und ist jetzt das Problem." Dann führte Georg eine Operation durch und entfernte alle Symbolabläufe aus sysklogd und schlug dann vor noch diverse Dateien aus diesem Paket herauszunehmen. Doch jetzt reklamierte Keith, " Schaut ganz gut aus, aber du musst die Optionen Flags für Abwärtskompatibilität beibehalten. Es gibt *sehr* viele Skripte aussen, die klogd mit verschiedenen Optionen ausführen und diese werden mit deiner Änderung fehlschlagen. Es wäre ok, wenn man einen Warnungshinweis einbaut "klogd options -[iIpkx] are no longer supported" solange klogd korrekt läuft. Sonst wird man viele irritierte Anwender haben, die sich beschweren, dass klogd beim Booten nicht funktioniert." George postete einen neuen Patch, der verschiedene Kommandozeilenparamter als überholt auflistet und der Thread glitt davon.

Mike A. Harris wollte wissen, welches Ethernet Modul er mit seiner D-LINK DFE-530-TX Karte verwenden soll. Peter Horton antwortete, " Wenn die PCI device ID 3065 ist, dann is es via-rhine, was aber vom Kernel nicht unterstützt wird. Hol' dir das aktuelle via-rhine von Donald Becker's Seite http://www.scyld.com/network." Doch Jeff Garzik führte an, " 2.4.x-test hat einige Fixes für via-rhine, die es scheinbar noch nicht in Beckers Treiber gibt..."

Simon Huggins fragte, ob eines der genannten in den Haupt 2.2er via-rhine eingehen würden und Jeff meinte, " Becker hat mir noch nie auf einen Patch oder so geantwortet, keine Ahnung also. Frag Becker... " Auch Alan Cox sagte, er würde einen Patch in 2.2.19pre einfügen, wenn ihn einer schreiben würde. Von Urban Widmark gab es einen grossen Patch und er erklärte:

Anbei ein Patch der den 2.2 via-rhine Treiber von Becker's 1.08b updatet, bis auf das PCI probing was so geblieben ist, Kompatibilitäts Macros und Code, der in 2.2 nicht benötigt wird ist entfernt (das ifdef CARDBUS von 1.08b wurde entfernt) und die "clear_tally_counters" von 2.4.

Wäre schön, wenn Leute mit 2.2 und diesen Karten diesen Patch testen könnten.

Der Patch enthält:

new VT6102 pci id & supporting non-aligned data buffers for that chip
completely untested (by me, that is) big<->little endian stuff
free allocated memory on driver unload
no more writel to 0x7c.
2 16bit values accessed as one 32bit (why? not sure, pci optimization?)
change transmit ring size

und ein paar andere mehr oder weniger kleine Änderungen/Cleanups.

Es ist hauptsächlich eine copy&paste Sache. Wenn ihr lieber einen kleineren Patch nur für das VT6102 braucht, wäre das ganz einfach.

Trotzdem ist das hier dem 2.4 Treiber sehr ähnlich (ausser bei locking) also hoffe ich, das es in Ordnung ist. Und wenn ich nicht einen Grossteil des 1.08b Treibers einbinden würde, wüsste ich ja nicht welchen Versions- Namen ich geben soll ... :)

Jeff V. Merkey erklärte, dass er bereits tausende seiner NTFS repair tools verschickt habe zu den Leuten, die ihm von den korrupten Dateisystemen verursacht von dem nicht-funktionierenden NTFS Dateisystem Support in Linux berichtet haben. Er fügte hinzu, " Ich werde diesen Support weiterhin machen, doch ich behandle nur die Symptome der Krankheit und heile also nicht den Patienten selbst. Basierend auf der Verseuchung von TRG mit Microsoft IP wurde mir geraten, das wenn ich einen NTFS Austausch vor dem 18.Monat der Lehre dass "window" unvermeidlich Vergangenheit ist, bereitstelle, uns Microsoft sicherlich verklagen wird - und gewinnen wird." Er empfahl die Anwender zu alarmieren, dass das Feature gefährlich und instabil ist und sie es nicht nutzen sollten. Peter Samuelson anwortete:

Hier ist eine Idee: machen wir r/w Unterstützung als eigenständige CONFIG Option und betiteln es als "DANGEROUS".

Oh Moment, das haben wir schon.

Vielleicht sollten wir die Anwender warnen, sie sollen ihre NTFS Partitionen sichern, wenn sie diese Option probieren. Diese Warnung soll in den Hilfetext für CONFIG_NTFS_RW stehen.

Oh Moment, das haben wir auch schon.

Wie blöd muss einer sein, eine Option - als "DANGEROUS" bezeichnet - zu aktivieren, und das in einem nicht-expermintellen System?

Auch Michael H. Warfield fügte später hinzu, " Es kann nicht einmal aktiviert werden, solange die experimental code options deaktiviert sind. Dann ist es standardmässig deaktiviert und man muss explizit die R/O NTFS einschalten. Und dann muss diese Option explizit ausgewählt werden, um den R/W Zugriff, der augenscheinlich "DANGEROUS" markiert ist, zu setzen. Das Ganze ist nicht einfach durch einen Akt der Unterlassung gefährlich. Es lebt und lässt sich nur durch 3 Bestätigungs-Schritte aktivieren. Alles was noch übrig bleibt, ausser es vom Kernel ganz wegzunehmen, ist die Option zu verstecken, so wie manche Debugging Optionen, die erfordern die Header-Dateien zu bearbeiten oder ein Makefile, um es zu aktivieren." Weiterhin meinte Peter, " Kommentiere die CONFIG_NTFS_RW Zeile ganz aus. Tatsäclich *wäre* das eine gute Idee. Jeder der geschäftlich mit NTFS_RW zu tun hat, ist mit Sicherheit in der Lage Config.in zu editieren." Jeff Garzik stimmte überein: " Meiner Meinung sollten Dateisysteme mit bekannter nicht-funktioneller Unterstützung von CONFIG_BROKEN abhängen (was standardmässig immer auf 'n' definiert sein soll)."

Anderswo fuhr Jeff V. M. fort, "Ich habe sogar noch schlechtere Nachrichten -- da es in Linux ist, ändert Microsoft bereits wieder die on-disk Strukturen; also wird der R/O Modus wenn Whistler herauskommt wieder broken sein." Als Antwort auf die Idee, dass keine zusätzlichen Warnungen oder Vorschritte nötig sind, damit Leute ihre Dateisysteme schiessen, sagte er auch, " Ihr sagt es wirklich. Ich werde hier sein wenn 100+ Nachrichten, die dann auf der Linux-Kernel Liste erscheinen mit "Linux destroyes my data" und ich werde sie behandeln. Ich möchte euch nur alarmieren, dass die Leute, die dieses Feature brauchen, steigt, was ein Indiz dafür ist, dass immer mehr Leute Linux nutzen, um den Umstieg von NT auf Linux durchzuziehen und umgekehrt, und dadurch auf Probleme stossen. Wir müssen eine längerfristige Lösung für dieses Problem erarbeiten. Ich schätze, dass wenn diese Tools auf unserem FTP Server für freien Download stehen, wird MS ganz schnell mit Rechtsanwälten daherkommen. Normalerweise würde ich es so tun, doch diese Tools sind via Zugriff auf die MS IP erstellt worden und solange ich als "Beratungs"-Stelle MS Kunden helfe Daten zu retten, bezweifle ich, dass sie einschreiten werden, auch weil jedesmal wenn das passiert Linux sich in ein grosses schwarzes Auge auf die betroffenen Kunden verwandelt. Aber schon sehr bald (nachdem 2.4 ausgeliefert wird) wird die Zahl der Leute, die das brauchen, so ansteigen, dass ich nicht mehr fähig bin sie sofort zu unterstützen, ohne dass diese Tools in die allgemeinen Distributionen eingehen -- denn dann wird die Scheisse den Ventilator von MS treffen."

Eric W. Biederman meinte, dass wenn Microsoft absichtlich die Zusammenarbeit zwischen Linux und Windows NT verhindert, sollte Jeff V. M. die Anti-Trust Rechtsanwälte kontaktieren. Doch Jeff V. M. antwortete:

Ich meine das die Anti-Trust Sachen ein Streitgesräch sind -- die hatten schon ihr Fett mit Microsoft. Sie wurden von der allgemeinen Öffentlichkeit als verletzt und verkrüppelt allein gelassen. Gross-Kunden scheinen das nicht zu schlucken .NET.

Anderswo rollte Ren Haddock das ganze Problem noch einmal anders auf, er sagte, " Ich denke, dass ein Teil des Problemes ist, dass andere Sachen als DANGEROUS markiert sind, die tatsächlich sehr zuverlässig laufen (spontan z.B. die IDE config Sachen..). Vielleicht sollte man explizit sagen 'Das funktioniert nicht und wird garantiert Daten zerstören. Lass die Finger davon.' Der 'DANGEROUS' Bezeichner scheint zu sagen, dass es Daten zerstören -könnte-, was zu der 'mir passiert das nicht'-Mentalität führt." Andre Hedrick antwortete geschichtstreu:

DANGEROUS == GO_FOR_IT_DUMB_ARSE_SCREW_YOURSELF_WILDLY

Das war die Absicht als ich die DANGEROUS Sache startete. Wegen der instabilen Natur des extremen Alpha Codes am Anfang. Doch mit der Zeit glaubten die Leute nicht mehr an eine echte Bedeutung, die ich aber am Anfang als solche definierte.

Wenn das hier alles geschäftlich wäre und wir würden bewusst Software vertreiben, die gefärlich ist, würden wir vielleicht legale Probleme befürchten müssen.

Warum vertreiben wir solche eindeutig nicht-funktionsfähige Software? Mann wir haben Unwilligkeit bei reiserfs gesehen, ein ziemlich hoch- qualitatives, gut unterstütztes Dateisystem. Und wir fahren weiterhin fort diesen !@#$% zu vertreiben... Es muss wohl irgendwo eine seltsame Zielrichtung geben, den Gebrauch von Linux einzuschränken.

Doch Horst von Brand antwortete, dass es nicht legal sein würde, da markante Warnungen angezeigt werden. Er sagte, " Es ist nur weil NTFS seit langem im Kernel existiert und faulte. Keiner nahm sich die Zeit, um es zu entfernen (das würde wesentlich schneller gehen, als die Zeit, die hier wegen diesem Problem verdiskutiert wurde...). "

Steven Cole nutzte die Kompilierung des Kernels als Benchmark und folgerte, dass auf Ein-Prozessorsystemen 2.2.18pre26 das Kernel-Kompilieren 3% schneller war als auf 2.4.0-test12-pre7. Er meinte mit entschuldigendem Ton, " Dennoch ist der Zugewinn so gering, das ein Bericht fällig wäre." Er sagte ausserdem, dass er für diesen Test den gcc 2.91.66 (kgcc) für den 2.2.18er Kernel genommen habe und den gcc 2.95.3 für den 2.4.0er Kernel. Einige kamen dazwischen und sagten, dass kgcc einen schnelleren Kernel liefert und dass wenn gleiche Testresultate erzielt werden wollen, auch beide Kernel gleich übersetzt werden sollten. Steven antwortete mit einigen Ergebnissen, in welchen kgcc wirklich leicht schnellere Kernel macht als gcc. Doch eine Wiederholung seiner Tests zeigten nur ein paar Sekunden Verbesserung gegenüber der alten Version auf. Er sagte, " aber ich denke wir stehen nur vor einem unbedeutender Lücke jetzt." Also war sein anfänglicher Bericht wieder Hauptpunkt und es gabe ein kurze Diskussion warum 2.2.18 schneller als 2.4.0 sein könnte. Alan Cox meinte dann, " Eine interessante Demo, dass 2.4 ein paar Geschwindigkeits- problem hat, da 2.2 langsamer ist als 2.0, auch wenn heutzutage nicht mehr bedeutend."

Später führte Steven einen ähnlichen Test von Benchmarks auf SMP-Systemen durch und berichtete, dass bei ihm 2.4.0 2% schneller als 2.2.18 ist. Linus Torvalds antwortete:

Nehmt in Kenntniss, dass Kernel-Kompilieren ein nicht wirklich geeignetes Benchmark ist, da Differenzen in dieser Grössenordnung einfach nur ein Nebeneffekt sein können: Sachen wie Treiber-Versions Unterschiede die aufkommen, doch Systeme unterschiedlich betreffen (z.B. ein Treiber ist für manche System besser und schlechter auf anderen. Solche Sachen).

Die Einstellung die du beschreibst ist zu CPU-lastig ohne Fähigkeiten für echt interessante Unterschiede.

Steven bemerkte dass in er dem SMP Test, " X und KDE 2.0 laufen liess um eine bessere Auslastung für die getesteten Kernel zu schaffen." Linus meinte:

Du solltest das gleiche im Bereich zwischen 32 und 64MB des RAMs versuchen. Und bewege deine Maus immer ein bisschen herum, um KDE/X daran zu hindern auszupagen, wo es dann wieder uninteressant wird. Ich habe keine Ahnung, wie man so etwas wiederholt machen kann, aber was ich ab und an mache, ist, dass ich meine Email lese (was nicht besonders CPU-lastig ist aber es hält den Desktop aktiv und gibt mir auch ein Gefühl für das interaktives Verhalten).

Dann sollte es in den Zahlen vielleicht mehr Unterschiede geben (und die Streuung wird wohl wesentlich grösser sein).

Steven probierte den selben Test nocht einmal mit einem 'make -j3', die Maus herumbewegend und den Desktop wechselnd und berichtete, " Das Ergebnis ist sogar näher dran. Die Unterschiede sind so gering, dass sie statistisch nicht entscheidend ist. Hmmm, vielleicht ist keine Nachricht hier gute Nachricht." Linus empfahl:

Mach das ganze lieber mit:

make -j3 'MAKE=make -j3' bzImage

Ein einzelnes "-j3" wird nicht viel bringen. Es wird nur 3 Verzeichnisse gleichzeitig erstellen und man wird nie hohe Auslastung sehen. Aber wenn man es rekursiv macht, heisst das, dass man alle drei aus der Zeit, die durch die Verzeichnisse durchgegangen wird, macht und du solltest Auslastungen um 20+ sehen und auch wesentlich mehr Druck auf den Speicher.

Steven probierte das, und berichtete, dass 2.4.0 immer noch 1.3 Sekunden schneller fertig ist als 2.2.18 und auch die Systemauslastung auf niedrigerem Niveau bleibt. Ab hier gab es keine Diskussion mehr.

Im Laufe der Diskussion gab Alan Cox seine erwartete Zeiteinschätzung für 2.2.19. In Bezug auf mögliche Änderungen sagte er, " Dies wird nicht in 2.2 passieren bevor 2.2.19 veröffentlicht ist, was ungefähr in 6 Monaten ist." Horst van Brand forderte eine schnelle 2.2.19 um nur die speziellen Bug Fixes die diskutiert werden einzufügen, doch Alan Cox antwortete: " Soll ich eine 2.2 Release für jede Kleinigkeit machen? Ich glaube nicht. Es gibt bereits haufenweise Sachen, die in 2.2.19 eingefügt werden müssen."

Mark Symonds berichtete von hängenden Systemen mit vielen "VM: do_try_to_free_pages failed" Meldungen, die auf 2.2.18 herunterscrollen. Er sagte, " Was ich auch noch bemerkt habe, ist dass das Load Average üblicherweise bei 0.08 liegt; doch wenn ich es für ein paar Minuten idle lasse und drücke dann die SpaceTaste auf einem Terminal hört es für 10 Sekunden auf und die Load Average schnellt auf über 6 hinauf. Danach erholt sich das System manchmal wieder und reagiert normal weiter, oder es hängt sich auf." Alan Cox antwortete, " Anrea's VM-global Patch ist wohl wie eine Wunderheilung, für die die ihn probiert haben. Probier den mal aus und lass uns das Ergebnis wissen." Mark und ein anderer probierten den Patch und berichteten durchschlagenden Erfolg und Alan bemerkte, " Ich meine, Andrea hat gerade den offiziellen Gott-Status erreicht ;)" Jemand anderes fragte, ob Andrea's Patch in 2.2.19 eingefügt werden soll und Alan antwortete:

Die Frage ist nur 'in welcher Form'. Ich wollte sie logischerweise separat von den anderen grösseren Änderungen in 2.2.18 halten.

Andrea - können wir die core VM Änderungen haben, die du gemacht hast ohne die Änderungen in der Semaphore Semantik für das Dateisystem Locking, welches Maintaintern von anderen Dateisystemen Kopfschmerzen bereitet und auch nicht 2.4 Verhalten bereitstellt?

Andrea Arcangeli anwortete mit einigen technischen Beiträgen und er und Alan diskutierten für einige Zeit.


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

1.	30 Nov 2000 - 13 Dec 2000	(7 posts)	Problems With Drives From Onstream
2.	6 Dec 2000 - 11 Dec 2000	(11 posts)	sysklogd Cleanup; Using Kernel Headers In User-Space Programs
3.	6 Dec 2000 - 14 Dec 2000	(15 posts)	Ethernet Module Update For The D-LINK DFE-530-TX Card In 2.2
4.	7 Dec 2000 - 11 Dec 2000	(76 posts)	Read-Write NTFS Support Broken And Should Not Be Used
5.	10 Dec 2000 - 15 Dec 2000	(28 posts)	2.0 Faster Than 2.2 Which Is Faster Than 2.4 (Except For SMP)
6.	13 Dec 2000 - 14 Dec 2000	(11 posts)	Timeline For 2.2.19
7.	13 Dec 2000 - 17 Dec 2000	(17 posts)	VM Problems In 2.2.18

Kernel Traffic #99 For 25 Dec 2000

By Zack Brown

Translated By: Florian Zimmermann