Eine Möglichkeit, solche Probleme in Zukunft zu vermeiden wären standardisierte Tests des Kernels und anderer "Kernkomponenten" wie XFree86.

Beim GCC laufen z.B. täglich Tests, die alles messen, von dem Speed des Codes (SPEC) bis zu möglichen Fehlern beim Übersetzen. Das gleiche für den Kernel würde schlechte VMs, Regressinen, Fehler die das Compilieren verhindern, Geschwindigkeits- und Stabilitätsunterschiede, filesystem corruptions und auch Prozessorbugs deutlich aufzeigen.

Wenn auf einem Athlon z.B. täglich der Viewperf Benchmark abstürzt, sobald ein Pentium-optimierter Kernel verwendet wird, wüßte man, daß man ein Problem hat, daß gelöst werden muß.

Daß Entwickler die Kernel bei sich zu Hause testen und dann nach gutdünken als stabile Version veröffentlichen, ist wohl nicht mehr zeitgemäß.
Daß Firmen wie Redhat, Mandrake und Suse je einen Rechner abstellen, der nichts anderes tut, als Kerneltesten, wäre das mindeste.

Prinzipiell ist die Qualitaetskontrolle natuerlich ein Good Thing [TM], in diesem Fall allerdings wohl wenig hilfreich gewesen:
o Das Problem tritt nur bei bestimmten Systemen mit den betreffenden CPUs auf, d.h. die Wahrscheinlichkeit, dass auf einem Testsystem der Fehler auffaellt, ist gering.
o Es handelt sich ja nicht um einen Kernelbug, sondern einen CPU-Bug, was dementsprechend schwieriger zu tracen ist.

Ciao,
Dubu

>...Qualitaetskontrolle natuerlich ein Good Thing [TM],
>in diesem Fall allerdings wohl wenig hilfreich gewesen:
Doch, hätte auch in diesem Fall was gebracht.

>o Das Problem tritt nur bei bestimmten Systemen mit den
>betreffenden CPUs auf, d.h. die Wahrscheinlichkeit,
>dass auf einem Testsystem der Fehler auffaellt, ist gering.

Die Wahrscheinlichkeit, daß ein aktuelles Testsystem mit Athlon-CPU ausgestattet ist, würde ich als 40% einschätzen.

>o Es handelt sich ja nicht um einen Kernelbug, sondern einen
>CPU-Bug, was dementsprechend schwieriger zu tracen ist.

Wenns nur den AMD-Testrechner jedesmal beim Viewperf "zerlegt", wenn Pentiumopt. eingeschalten ist, würden vermutlich zuerst die GCC-Leute Anfragen bekommen, dann die Kernelhacker. Wenn die dann sagen, daß bei ihnen alles stimmt, fragt man mal bei AMD nach.

So einfach ist das ;-)

MW

"Die Wahrscheinlichkeit, daß ein aktuelles Testsystem mit Athlon-CPU ausgestattet ist, würde ich als 40% einschätzen."

*Grmpf*
Ja, schon klar. Aber das Problem tritt ja nur bei ein <paar Athlon-Nutzern auf, laengst nicht in jedem Athlon-System! Die Wahrscheinlichkeit, genau die "richtige" Kombination aus CPU, GraKa (offensichtlich sind ja wohl die NVidia-Treiber mit schuld) und evtl. Chipsatz zu haben, so dass der Fehler auftritt, ist wohl ziemlich klein. Frag mal die Treiberentwickler fuer Windows, warum sie immer wieder Bugfixes herausgeben. Koennen die nur alle nicht testen, oder ist es nicht eher eine Frage der unzaehligen moeglichen Kombinationen von Hard- und Software auf x86-Systemen?

"Wenns nur den AMD-Testrechner jedesmal beim Viewperf "zerlegt", wenn Pentiumopt. eingeschalten ist, würden vermutlich zuerst die GCC-Leute Anfragen bekommen, dann die Kernelhacker."

Die meisten AMD- bzw. Athlon-Rechner "zerlegt" es ja nicht, sonst waere es schon laengst aufgefallen.

Ciao,
Dubu

Wie es mit den neueren Treiberversionen ist, weiss ich nicht, da ich jetzt die Finger von so proprietärem Kram lasse.

Es sind mehrere Fehler die zusammenspielen. Damals war wie gesagt der Treiber Mist (was nun behoben ist) und der "neue" Bug kommt jetzt von der CPU und steht in Verbindung mit dem Kernel-2.4

arni

Bis zu diesem Zeitpunkt bleibt der Rechner über Lan erreichbar.

Der Fehler dürfte noch meim Nivdatreiber liegen.

in /etc/X11/XF86Config

Section "Device"
BoardName "GeForce 2 MX"
BusID "PCI:1:5:0"
Driver "nvidia"
Identifier "Device[0]"
VendorName "nvidia"
Videoram 32768
Option "NvAGP" "3"
EndSection

so klappts zumindestens bei mir und ich sag trotzdem noch mal das abstürze auch mit der glibc 2.2.4 und dem emu10k1 (soundblaster) zutun haben könnten (war bei mir mit quakeIII so)
versuch mal ohne sound wenn dann immer noch (und natürlich emu10k1 && glibc 2.2.4) sag nochmal bescheidt

ich habe keine soundblaster, so dass dies bei mir nicht das problem sein kann, aber ich werde das mit dem agp mal probieren.

gestern hatte ich schon wieder einen dieser abstürze, schöne bunte streifen auf meinem bildschirm, ein STRG ALT BACKSPACE brachte nur den totalen absturz und nichts ging mehr.
manchmal sehe ich dann noch eine fehlermeldung in der console, die ich aber nur ungenau wiedergeben kann (kein informatiker) irgendwas mit "agp no texture availiable" oder ähnlich

Wer ist bitte Andrea?

Mit Depp meine ich nur den letzten Anonymous...

Nein, aber dafür kommunizieren sie Ihre Bugs vernünftig.

Das gleiche Prob bei mir.
Als ob Nvidia, VIA und AMD nicht reichen würden, kommt noch die SBLive hinzu: Traffic auf dem PCI Bus ohne was zu tun.

Nie wieder Creative Soundkarten (es gibt billigere und bessere)!
Nie wieder VIA-Chipsatz!

Und zu AMD: So lange die Preise von Intel nicht deutlich höher als die von AMD sin kauf ich mir vielleicht Intel. Sträube mich noch, weil wir wohl ohne AMD Wucherpreise für die P4 und kommenden bezahlen müssten.

Bleibt nur zu hoffen, das ATI bessere Treiber (support) rausbringt. Technisch ist es ja nicht mehr allzuweit Nvidia Paroli zu bieten.

ergo: vernünftige Hardware, dann klappt es auch mit AMD und Linux.

toi,toi,toi

MfG,

Hartmut

@Ano19:40: Klar ist ein stabiles System das wichtigste überhaupt. Nur würde mich interessieren, wieviel Leistung wirklich verlorengeht. Hat da schon jemand Messungen (auch subjektive) gemacht?

Arno

Weiss jemand mehr Details, wann der Linuxkernel tatsächlich auf 4MB zurückgreift. Soweit ich weiss haben x86 sowas schon ziemlich lange, aber noch wenig über deren extensiven Nutzen gehöhrt

Gruß
Marc

[ ] Anstand und Respekt ist deiner Wenigkeit fern

Ciao
Erich

Das ist ja HAARSTRÄUBEND!!!

Können denn die Kernelhacker nichts für deine Oma tun?!

Wie wärs mit einem offenen Brief?

Hast du evtl. eine Quelle wo Alan und Andrea gesagt haben, dass Linux von diesem Problem nicht betroffen ist,
sondern ausschliesslich Kernelmodule von Drittanbietern?

arni

Die Mail von Andrea Arcangeli:
http://www.uwsg.indiana.edu/hypermail/ linux/kernel/0201.2/1314.html

Die Mail von Alan Cox:
http://www.uwsg.indiana.edu/hypermail/ linux/kernel/0201.2/1352.html

(Links bitte wie ueblich wieder zusammensetzen; kann nicht mal jemand dieses Forums"feature" abstellen? *grummel*)

Beide sagen uebereinstimmend, dass der betreffende Aufruf im Kernel nicht vorkommt und dass es unwahrscheinlich ist, dass er im NVidia-Modul auftaucht.

Nichtsdestotrotz gibt es auf der Liste Meldungen von Leuten, die mysterioese Crashes durch die Kerneloption "mem=nopentium" abstellen konnten.

Ciao,
Dubu

"Beide sagen uebereinstimmend, dass der betreffende Aufruf im Kernel nicht vorkommt und dass es unwahrscheinlich ist, dass er im NVidia-Modul auftaucht."

diese aussage kann ich in den mails aber nicht entdecken...
gruß,
def

Sollte nicht oder ist nicht? So genau festlegen mag sich alan cox wohl auch noch nicht.

"diese aussage kann ich in den mails aber nicht entdecken..."

Ich habe nur die beiden relevantesten Mails zitiert. Im Verlauf des Threads ist auch die Aussage zum NVidia-Treiber zu lesen. Da dieser aber closed-source ist, kann wohl nur ein NVidia-Mitarbeiter endgueltige Aufklaerung liefern.

(Im Verlauf des Threads findet sich auch jemand, der behauptet, dass es einen solchen Aufruf im NVidia-Modul nicht gibt, er schreibt aber auch nicht, woher er das wissen will, deshalb erscheint mir das zu unglaubwuerdig.)

Ciao,
Dubu

append="mem=nopentium"

hinzufügen bzw. einen bereits existierenden append=-Eintrag um "mem=nopentium" ergänzen.

Jochen

Gruß Drizzt

Drizzt

Will auch Patch, oder ist der in SPs schon mit drin?