Große Dateioperationen: Totalabsturz

[Brauckes]

Tach auch!

Eigendlich gehörte dieses Problem in ein anderes Unterforum, aber keines erschien mir passend - ´tschuldigung!

Wenn ich große (>100 MB) Dateien kopieren, verschieben oder entpacken will, stürzt Debian vollkommen ab, der Bildschirm friert ein, die Uhr bleibt stehen und der Mauszeiger ist unbeweglich.
Dabei ist es egal, ob ich auf der Kommandozeile oder unter KDE versuche den jeweiligen Vorgang einzuleiten. Ebanfalls ist es vollkommen unterschiedlich wann der Absturz eintritt.

Gibt es irgendwelche Logs, die mir einen Hinweis geben können?

Kernel: 2.4.22 xfs
Dateisystem: ext3

Hat wohl nix mit SID zu tun, da das Problem schon seit der Erstinstallation autaucht.

Fragend,

Brauckes.

[zyta2k]

Passiert es aus der Konsole auch ?
Benutzt du einen Filemanager ? Nautilus ? konqui ?

[Brauckes]

Hallo Zyta!

Passiert es aus der Konsole auch ?
Benutzt du einen Filemanager ? Nautilus ? konqui ?

Ja, auf der Konsole passiert das auch, aber nach subjektivem Eindruck seltener/"später" also erst bei einigen hundert MB.
Filemanager in KDE ist der Konquerer, aber greift der nicht auch auf "Konsolenbefehle" zurück?

Brauckes.

[simca]

Moin,

hast Du evtl. ein Mainboard mit nforce2-Chipsatz?
Das hat bei mir nämlich genau solche Probleme produziert, bis ich das gesamte ACPI-Geraffel aus dem Kernel geworfen habe.
Jetzt läuft alles wunderbar.

Gruesse
Günther

[Brauckes]

Tach auch!

hast Du evtl. ein Mainboard mit nforce2-Chipsatz?
Das hat bei mir nämlich genau solche Probleme produziert, bis ich das gesamte ACPI-Geraffel aus dem Kernel geworfen habe.
Jetzt läuft alles wunderbar.

Ja habe ich! Muß ich dann neu kompilieren, oder wie geht man dann vor?

Brauckes

[pdreker]

Du brauchst "noapic nolapic acpi=off" als Kernelparameter. Das Ganze findet sich als "append" Zeile in der lilo.conf. Evtl. geht es auch ohne "acpi=off". Zusätzlich würde ich (falls möglich) den APIC Mode im BIOS abschalten.

Faustregel: APIC (nicht ACPI) sollte man bei Problemen mit NForce Chipsätzen so komplett wie möglich deaktivieren, das geht oft schief. Wenn Du selbst einen Kernel kompilieren solltest, solltest Du die IO-APIC und APIC on uni-processor Optionen in der Kernel Conf komplett deaktivieren.

Patrick (NForce2 APIC geschädigt)

[Dr. Eule]

hallo!

sorry, das ich dazwischenquatsche, aber ich muss diese Frage jetzt mal loswerden: ich habe schon von so einigen Problemen vom nforce2 unter Linux gehört (habe selber ein Board mit diesem Chipsatz), aber wo liegt eigentlich die Wurzel dieser Probleme? Auf der Software-Seite? auf der Hardware-Seite bzw. im BIOS, oder wo?
Gibt es Aussicht auf (irgendwann mal...) komplett funktionierendes APCI, APIC et. auf dem nforce2?

[pdreker]

Also ersteinmal: ACPI ist scheinbar nur ein "Kollateralschaden" und nicht unmittelbar an dem Problem beteiligt. Es ist halt so das ACPI und APIC Hand in Hand arbeiten, und wenn ACPI die IRQ Verteilung vornimmt, nimmt es halt gerne die APIC mit rein... Mein Board (Biostar iDeq200N Barebone) funktioniert z.B. *mit* ACPI...

Über die Wurzel des Problems wird noch ein wenig gerätselt, aber es existieren, soweit ich das überblicken kann, zwei Theorien, die auch beide zutreffen könnten:

1. Mit aktivierter APIC wird bei bestimmten Hardware Events der SMM (System Management Mode) des Chipsatzes aktiviert. Diese Events können z.B. Über- oder Unterschreitung bestimmter Lüfterdrehzahlen oder Temperaturbereiche sein. In diesem Mode sind alle Interrupts maskiert (sogar der eigentlich nicht maskierbare NMI). Aus irgendeinem Grund kommt das System aber nicht selbsttätig wieder aus diesem Zustand heraus, und steckt daher mit abgeschlateten Interrupts fest. Rien ne va plus...
2. Bei aktivierter APIC ist das PowerSaving System des Chipsatzes aktiviert, was im Linux Kernel Code zu häufigen Disconnects/Reconnects des FrontSideBus der CPU führt. Aus irgendeinem Grund hängt sich der Chipsatz dabei gelegentlich auf. Ende Gelände.

In beiden Fällen kann man schon sehen, dass auch ACPI (Power Management und Sensorkontrolle) im Spiel ist, was erklärt, dass bei einigen Boards ACPI geht, bei anderen nicht. In jedem Fall ist das Problem mindestens teilweise beim BIOS Programmierer zu suchen, der nur den "Funktioniert es unter Windows Test" gemacht hat. Auch die Tatsache, dass NVidia kein Stück der Dokumentation rausrückt macht das Debuggen des Problems nicht gerade einfacher.

Ich habe irgendwo im Netz 'mal einen "NForce Idle Patch" gefunden (Kernel 2.6), der die Frequenz der FSB Disc/Rec reduziert, und angeblich bei einigen Leuten das Problem behebt. Allerdings habe ich es noch nicht selbst getestet, da mein System halt ohne APIC absolut stabil läuft (tagelang ohne Probleme). Es könnte nämlich durchaus sein, dass der Patch die Häufigkeit der Crashes nur reduziert, das problem aber nicht komplett behebt.

Bei Interesse an dem Patch nochmal melden, ich könnte den dann posten oder mailen, aber nur absolut ohne Gewähr, und auf eigene Gefahr. Kernel 2.6 muss selbergebaut und gepatched werden, und da der Patch schon etwas älter ist, kann es gut sein, dass man den von Hand in einen neueren Kernel einbauen muss. Ich weiss auch nicht, ob der Patch zusäztliche Features erfordert, da er ursprünglich aus dem 2.6.3-mm1 Kernel stammt, der massiv gegenüber dem normalen 2.6 Kernel modifiziert ist.

Patrick