scp: Hartes stehenbleiben meines Rechners!

newer
Re: Partionsgrößen nachträglich...

Martin Deppe

21 Sep 2008 21 Sep '08

16:44

Hi, mein PC läuft eigentlich sehr stabil, soweit! Leider bleibt er auch sehr stabil stehen, wenn ich per "scp" eine größere Datenmenge (mindestens 100 oder 200 MB) mit einer Datenrate von ca. 16 MB/s von ihm auf mein gateway kopiere. Dies ist reproduzierbar und tritt nicht auf, wenn ich die Daten z.B. per Samba mit einer Rate von etwa 2,5 MB/s kopiere. Ich beobachte dieses Phänomen schon länger und vermute einen Hardwaredefekt im Controller bzw. IO-System auf dem Mainboard. Hat jemand vielleicht eine Idee respektive Strategie, wie ich genauer rausfinden kann, was da abgeht? Das Problem ist nämlich außerdem, dass ich nichts mehr nachschauen kann, wenn es passiert. Vielen Dank Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Show replies by date

Thomas Schirrmacher

21 Sep 21 Sep

16:52

Hallo Martin, ist eigentlich nur eine Vermutung, aber es soll noch Rechner geben, wo die Leistung des Stromnetzteils für den gesamten PC nicht ausreicht und ausgewechselt werden sollte. Je nachdem wieviele Geräte man noch angestöpselt hat, verabschiedet sich der PC dann sang und klanglos. Das Problem hatte ich mal und Wochen recherchiert, bis ich mal auf das Netzteil kam. Gruß Thomas Am Sonntag 21 September 2008 18:44:53 schrieb Martin Deppe:

...

Hi,

mein PC läuft eigentlich sehr stabil, soweit! Leider bleibt er auch sehr stabil stehen, wenn ich per "scp" eine größere Datenmenge (mindestens 100 oder 200 MB) mit einer Datenrate von ca. 16 MB/s von ihm auf mein gateway kopiere. Dies ist reproduzierbar und tritt nicht auf, wenn ich die Daten z.B. per Samba mit einer Rate von etwa 2,5 MB/s kopiere.

Ich beobachte dieses Phänomen schon länger und vermute einen Hardwaredefekt im Controller bzw. IO-System auf dem Mainboard.

Hat jemand vielleicht eine Idee respektive Strategie, wie ich genauer rausfinden kann, was da abgeht? Das Problem ist nämlich außerdem, dass ich nichts mehr nachschauen kann, wenn es passiert.

Vielen Dank Martin

-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Martin Deppe

17:31

Hallo Thomas, ja, das Problem hatte ich auch lange Zeit mit dem PC, aber mittlerweile steckt ein 550W-Netzteil darin. Das sollte eigentlich ausreichen. Ich habe damit zumindest schon 5 Festplatten und 2 DVD-Laufwerke betrieben und es lief. Außerdem kühle ich das System heute besser als damals. Gruß Martin Thomas Schirrmacher schrieb:

...

Hallo Martin,

ist eigentlich nur eine Vermutung, aber es soll noch Rechner geben, wo die Leistung des Stromnetzteils für den gesamten PC nicht ausreicht und ausgewechselt werden sollte. Je nachdem wieviele Geräte man noch angestöpselt hat, verabschiedet sich der PC dann sang und klanglos. Das Problem hatte ich mal und Wochen recherchiert, bis ich mal auf das Netzteil kam.

Gruß

Thomas

Am Sonntag 21 September 2008 18:44:53 schrieb Martin Deppe:

...
Hi,

mein PC läuft eigentlich sehr stabil, soweit! Leider bleibt er auch sehr stabil stehen, wenn ich per "scp" eine größere Datenmenge (mindestens 100 oder 200 MB) mit einer Datenrate von ca. 16 MB/s von ihm auf mein gateway kopiere. Dies ist reproduzierbar und tritt nicht auf, wenn ich die Daten z.B. per Samba mit einer Rate von etwa 2,5 MB/s kopiere.

Ich beobachte dieses Phänomen schon länger und vermute einen Hardwaredefekt im Controller bzw. IO-System auf dem Mainboard.

Hat jemand vielleicht eine Idee respektive Strategie, wie ich genauer rausfinden kann, was da abgeht? Das Problem ist nämlich außerdem, dass ich nichts mehr nachschauen kann, wenn es passiert.

Vielen Dank Martin

Thomas Hertweck

17:49

Martin Deppe wrote:

...

mein PC läuft eigentlich sehr stabil, soweit! Leider bleibt er auch sehr stabil stehen, wenn ich per "scp" eine größere Datenmenge (mindestens 100 oder 200 MB) mit einer Datenrate von ca. 16 MB/s von ihm auf mein gateway kopiere. Dies ist reproduzierbar und tritt nicht auf, wenn ich die Daten z.B. per Samba mit einer Rate von etwa 2,5 MB/s kopiere.

Ich beobachte dieses Phänomen schon länger und vermute einen Hardwaredefekt im Controller bzw. IO-System auf dem Mainboard.

Hat jemand vielleicht eine Idee respektive Strategie, wie ich genauer rausfinden kann, was da abgeht? Das Problem ist nämlich außerdem, dass ich nichts mehr nachschauen kann, wenn es passiert.

Ich wuerde zunaechst mal den Speicher (RAM) mit memtest ueberpruefen. Ich hatte einmal ein aehnliches Phaenomen bei der Uebertragung groesserer Datenmengen ueber eth0 - da war es letztendlich der Speicher, der das Problem war (er wird ja fuer Buffer und Cache genutzt). Falls es nicht am Speicher liegt, wuerde ich mal eine andere Netzwerkkarte probieren. Teilt sich die Netzwerkkarte einen IRQ? Cheers, Th. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Martin Deppe

18:14

Thomas Hertweck schrieb:

...

Martin Deppe wrote:

...
mein PC läuft eigentlich sehr stabil, soweit! Leider bleibt er auch sehr stabil stehen, wenn ich per "scp" eine größere Datenmenge (mindestens 100 oder 200 MB) mit einer Datenrate von ca. 16 MB/s von ihm auf mein gateway kopiere. Dies ist reproduzierbar und tritt nicht auf, wenn ich die Daten z.B. per Samba mit einer Rate von etwa 2,5 MB/s kopiere.

Ich beobachte dieses Phänomen schon länger und vermute einen Hardwaredefekt im Controller bzw. IO-System auf dem Mainboard.

Hat jemand vielleicht eine Idee respektive Strategie, wie ich genauer rausfinden kann, was da abgeht? Das Problem ist nämlich außerdem, dass ich nichts mehr nachschauen kann, wenn es passiert.

Ich wuerde zunaechst mal den Speicher (RAM) mit memtest ueberpruefen. Ich hatte einmal ein aehnliches Phaenomen bei der Uebertragung groesserer Datenmengen ueber eth0 - da war es letztendlich der Speicher, der das Problem war (er wird ja fuer Buffer und Cache genutzt). Falls es nicht am Speicher liegt, wuerde ich mal eine andere Netzwerkkarte probieren. Teilt sich die Netzwerkkarte einen IRQ?

Cheers, Th.

Also, ich habe jetzt mal die 1.2 GB von der Festplatte am primären Kontroller (Master) auf die Festplatte am sekundären Kontroller (ebenfalls Master) kopiert. Interessanterweise funktioniert das problemlos. Noch dazu mit einer Transferrate von 20 MB/s. Dann habe ich das selbe Kommando wie vorher aber eben von der zweiten Festplatte aus ausgeführt ... und siehe da, es funktioniert ebenfalls problemlos. Könnt ihr mir zustimmen, wenn ich sage, es ist eben doch der Kontroller, aber nur der primäre IDE Kontroller und interessanterweise nur in Verbindung mit Netzwerkzugriffen? @Emil: andere Netzwerkkarten hatte ich auch schon mehrere in dem Rechner, zwar nie als konkreter Test, wie jetzt gerade eben, sondern weil irgendetwas wieder überhaupt nicht funktionierte, aber (wenn ich mich nicht irre) irgendwann trat dieser Fehler bei jeder Netzwerkkarte auf. Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Emil Stephan

17:57

Am Sunday 21 September 2008 18:44:53 schrieb Martin Deppe:

...

Hi,

mein PC läuft eigentlich sehr stabil, soweit! Leider bleibt er auch sehr stabil stehen, wenn ich per "scp" eine größere Datenmenge (mindestens 100 oder 200 MB) mit einer Datenrate von ca. 16 MB/s von ihm auf mein gateway kopiere. Dies ist reproduzierbar und tritt nicht auf, wenn ich die Daten z.B. per Samba mit einer Rate von etwa 2,5 MB/s kopiere.

Ich beobachte dieses Phänomen schon länger und vermute einen Hardwaredefekt im Controller bzw. IO-System auf dem Mainboard.

Hat jemand vielleicht eine Idee respektive Strategie, wie ich genauer rausfinden kann, was da abgeht? Das Problem ist nämlich außerdem, dass ich nichts mehr nachschauen kann, wenn es passiert.

Vielen Dank Martin

Hallo Martin, scp verschlüsselt die Daten und braucht dafür CPU-Leistung, während beim unverschlüsselten Kopieren per Samba eher die IO-Leistung im Vordergrund steht. Wie sieht es denn aus, wenn Du rcp verwendest? Das arbeitet ohne Verschlüsselung. Brauchst Du die Verschlüsselung? Tschö, Emil -- Registered Linux User since 19940320 -------------------------------------------------- Emil Stephan, Marktplatz 39, 53773 Hennef, Germany voice: +49-2242-84438 Accelerate Windows: 9.81 m/sec^2 would be adequate -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Martin Deppe

18:29

Emil Stephan schrieb:

...

Am Sunday 21 September 2008 18:44:53 schrieb Martin Deppe:

...
Hi,

mein PC läuft eigentlich sehr stabil, soweit! Leider bleibt er auch sehr stabil stehen, wenn ich per "scp" eine größere Datenmenge (mindestens 100 oder 200 MB) mit einer Datenrate von ca. 16 MB/s von ihm auf mein gateway kopiere. Dies ist reproduzierbar und tritt nicht auf, wenn ich die Daten z.B. per Samba mit einer Rate von etwa 2,5 MB/s kopiere.

Ich beobachte dieses Phänomen schon länger und vermute einen Hardwaredefekt im Controller bzw. IO-System auf dem Mainboard.

Hat jemand vielleicht eine Idee respektive Strategie, wie ich genauer rausfinden kann, was da abgeht? Das Problem ist nämlich außerdem, dass ich nichts mehr nachschauen kann, wenn es passiert.

Vielen Dank Martin

Hallo Martin,

scp verschlüsselt die Daten und braucht dafür CPU-Leistung, während beim unverschlüsselten Kopieren per Samba eher die IO-Leistung im Vordergrund steht. Wie sieht es denn aus, wenn Du rcp verwendest? Das arbeitet ohne Verschlüsselung. Brauchst Du die Verschlüsselung?

Tschö, Emil

Beim kopieren per Samba steht die IO-Leistung im Vordergrund? Wieso erhalte ich dann eine Transferrate von nur 2,5 MB/s rcp hatte ich gar nicht installiert und habe ich wieder gelöscht, da ich auch auf dem anderen Rechner nicht das Pendant dazu habe. ciao Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Emil Stephan

19:11

Am Sunday 21 September 2008 20:29:07 schrieb Martin Deppe:

...

Emil Stephan schrieb:

...
Am Sunday 21 September 2008 18:44:53 schrieb Martin Deppe:

...
Hi,

mein PC läuft eigentlich sehr stabil, soweit! Leider bleibt er auch sehr stabil stehen, wenn ich per "scp" eine größere Datenmenge (mindestens 100 oder 200 MB) mit einer Datenrate von ca. 16 MB/s von ihm auf mein gateway kopiere. Dies ist reproduzierbar und tritt nicht auf, wenn ich die Daten z.B. per Samba mit einer Rate von etwa 2,5 MB/s kopiere.

Ich beobachte dieses Phänomen schon länger und vermute einen Hardwaredefekt im Controller bzw. IO-System auf dem Mainboard.

Hat jemand vielleicht eine Idee respektive Strategie, wie ich genauer rausfinden kann, was da abgeht? Das Problem ist nämlich außerdem, dass ich nichts mehr nachschauen kann, wenn es passiert.

Vielen Dank Martin

Hallo Martin,

scp verschlüsselt die Daten und braucht dafür CPU-Leistung, während beim unverschlüsselten Kopieren per Samba eher die IO-Leistung im Vordergrund steht. Wie sieht es denn aus, wenn Du rcp verwendest? Das arbeitet ohne Verschlüsselung. Brauchst Du die Verschlüsselung?

Tschö, Emil

Beim kopieren per Samba steht die IO-Leistung im Vordergrund? Wieso erhalte ich dann eine Transferrate von nur 2,5 MB/s rcp hatte ich gar nicht installiert und habe ich wieder gelöscht, da ich auch auf dem anderen Rechner nicht das Pendant dazu habe.

ciao Martin

Hallo Martin, auch wenn die IO-Leistung im Vordergrund steht, heißt das noch nicht, dass sie gut ist. Samba kopiert da einfach nur, aber über Windows-Protokolle. rcp ist die unverschlüsselte Variante zu scp, ist Unix-basiert und somit der geeignete Vergleichskandidat. Mit scp wird aber sehr viel mehr CPU und Speicher gebraucht. Das sind die Unterschiede, über die Du Dir Gedanken machen musst. Deswegen verfolge mal die Idee von Thomas, einen memtest zu machen. Du musst aber zuerst memtest installieren. Der Test wird beim Booten ausgewählt und der Rechner steht für ein paar Stunden nicht zur Verfügung. Ich hatte in 2004 einen Rechner, bei dem waren ein paar Parameter zur Ansteuerung des Speichers im BIOS zu scharf eingestellt. Das habe ich dann über memtest isolieren können. Das hat aber ein paar Tage gedauert, weil ich die Parameter von den Safe Settings (ohne Performance) nach und nach hochgezogen habe. Tschö, Emil -- Registered Linux User since 19940320 -------------------------------------------------- Emil Stephan, Marktplatz 39, 53773 Hennef, Germany voice: +49-2242-84438 Accelerate Windows: 9.81 m/sec^2 would be adequate -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Martin Deppe

19:22

Emil Stephan schrieb:

...

Am Sunday 21 September 2008 20:29:07 schrieb Martin Deppe:

...
Emil Stephan schrieb:

...
Am Sunday 21 September 2008 18:44:53 schrieb Martin Deppe:

...
[...]

[...]

Beim kopieren per Samba steht die IO-Leistung im Vordergrund? Wieso erhalte ich dann eine Transferrate von nur 2,5 MB/s rcp hatte ich gar nicht installiert und habe ich wieder gelöscht, da ich auch auf dem anderen Rechner nicht das Pendant dazu habe.

ciao Martin

Hallo Martin, auch wenn die IO-Leistung im Vordergrund steht, heißt das noch nicht, dass sie gut ist. Samba kopiert da einfach nur, aber über Windows-Protokolle. rcp ist die unverschlüsselte Variante zu scp, ist Unix-basiert und somit der geeignete Vergleichskandidat. Mit scp wird aber sehr viel mehr CPU und Speicher gebraucht. Das sind die Unterschiede, über die Du Dir Gedanken machen musst. Deswegen verfolge mal die Idee von Thomas, einen memtest zu machen. Du musst aber zuerst memtest installieren. Der Test wird beim Booten ausgewählt und der Rechner steht für ein paar Stunden nicht zur Verfügung. Ich hatte in 2004 einen Rechner, bei dem waren ein paar Parameter zur Ansteuerung des Speichers im BIOS zu scharf eingestellt. Das habe ich dann über memtest isolieren können. Das hat aber ein paar Tage gedauert, weil ich die Parameter von den Safe Settings (ohne Performance) nach und nach hochgezogen habe.

Tschö, Emil

Hallo Emil, meinst Du nicht, wenn ein und derselbe Vorgang dann von einer anderen Festplatte respektive dem anderen IDE-Kanal erfolgreich verläuft, dass es recht unwahrscheinlich ist, dass es am Speicher liegt? ciao Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Tobias Crefeld

23:21

On Sun, 21 Sep 2008 Martin Deppe wrote:

...

meinst Du nicht, wenn ein und derselbe Vorgang dann von einer anderen Festplatte respektive dem anderen IDE-Kanal erfolgreich verläuft, dass es recht unwahrscheinlich ist, dass es am Speicher liegt?

Meinst Du nicht, dass diese Information nicht ganz unbedeutend ist und bislang fehlte?! Nicht ganz auszuschließen ist in solchen Fällen ein IRQ-Konflikt. Dabei kann letztlich ein Treiberfehler ebenso zugrunde liegen wie ein Hardwarefehler. Einfaach mal die verwendeten IRQ feststellen. Ob der Fehler im IDE-Bereich oder im NIC-Bereich liegt, wäre auch noch zu klären. Interessant wäre noch der Test von scp mit Bandbreitendrosselung, also scp -l 1024 oder so. -- Gruß, Tobias. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Martin Deppe

22 Sep 22 Sep

20:04

Tobias Crefeld schrieb:

...

On Sun, 21 Sep 2008 Martin Deppe wrote:

...
meinst Du nicht, wenn ein und derselbe Vorgang dann von einer anderen Festplatte respektive dem anderen IDE-Kanal erfolgreich verläuft, dass es recht unwahrscheinlich ist, dass es am Speicher liegt?

Meinst Du nicht, dass diese Information nicht ganz unbedeutend ist und bislang fehlte?!

Vollkommen richtig, aber ich habe diese Information gegeben, sobald ich sie hatte! Ich hatte den Test vorher noch nicht gemacht.

...

Nicht ganz auszuschließen ist in solchen Fällen ein IRQ-Konflikt. Dabei kann letztlich ein Treiberfehler ebenso zugrunde liegen wie ein Hardwarefehler. Einfaach mal die verwendeten IRQ feststellen. Ob der Fehler im IDE-Bereich oder im NIC-Bereich liegt, wäre auch noch zu klären.

Hardware Information (yast2) gibt mir folgende Interruptverteilung aus: 06: Floppy Disk Controller 16: IDE 16: Ultra133TX2 (2. IDE controller) 16: GeForce4 Ti 4200 with AGP8X 16: USB 1.1 (VT82xxxxx UHCI USB 1.1 Controller) 17: USB 2.0 17: AMD-766 [ViperPlus] USB 18: USB 1.1 (VT82xxxxx UHCI USB 1.1 Controller) 18: SBLive! Player 5.1 19: RTL-8169 Gigabit Ethernet (eth0)

...

Interessant wäre noch der Test von scp mit Bandbreitendrosselung, also scp -l 1024 oder so.

Das könnte ich auch noch mal ausprobieren! Danke Dir! Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

David Haller

21:59

Hallo, Am Mon, 22 Sep 2008, Martin Deppe schrieb:

...

Hardware Information (yast2) gibt mir folgende Interruptverteilung aus: 16: IDE 16: Ultra133TX2 (2. IDE controller) 16: GeForce4 Ti 4200 with AGP8X 16: USB 1.1 (VT82xxxxx UHCI USB 1.1 Controller)

Weia. IDE + IDE + Grafikkarte + USB auf einem Interrupt ist IMO tödlich. -dnh -- Und immer wenn du meinst "blöder geht's nicht mehr", dann kommt von irgendwo ein Merkel her ... -- Volker Pispers, "bis neulich" (2007) -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Martin Deppe

23 Sep 23 Sep

16:14

David Haller schrieb:

...

Hallo,

Am Mon, 22 Sep 2008, Martin Deppe schrieb:

...
Hardware Information (yast2) gibt mir folgende Interruptverteilung aus: 16: IDE 16: Ultra133TX2 (2. IDE controller) 16: GeForce4 Ti 4200 with AGP8X 16: USB 1.1 (VT82xxxxx UHCI USB 1.1 Controller)

Weia. IDE + IDE + Grafikkarte + USB auf einem Interrupt ist IMO tödlich.

Tja, sieht nicht toll aus, aber wie kann ich das ändern? Abgesehen davon, läuft es ja sehr gut, normalerweise! Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Emil Stephan

16:59

Am Tuesday 23 September 2008 18:14:44 schrieb Martin Deppe:

...

David Haller schrieb:

...
Hallo,

Am Mon, 22 Sep 2008, Martin Deppe schrieb:

...
Hardware Information (yast2) gibt mir folgende Interruptverteilung aus: 16: IDE 16: Ultra133TX2 (2. IDE controller) 16: GeForce4 Ti 4200 with AGP8X 16: USB 1.1 (VT82xxxxx UHCI USB 1.1 Controller)

Weia. IDE + IDE + Grafikkarte + USB auf einem Interrupt ist IMO tödlich.

Tja, sieht nicht toll aus, aber wie kann ich das ändern? Abgesehen davon, läuft es ja sehr gut, normalerweise!

Martin

Hallo Martin, die erste IDE ist vermutlich on Board, die GeForce4 sitzt bernutlich im einzigen AGP-Slot, die USB 1.1 ist bermutlich auch on Board. Bleibt also nur, die Ultra133TX2 (vermutlich Promise) in einen anderen PCI-Slot zu stecken (Evtl. mit einer anderen Karte zu tauschen), wenn verfügbar. Tschö, Emil -- Registered Linux User since 19940320 -------------------------------------------------- Emil Stephan, Marktplatz 39, 53773 Hennef, Germany voice: +49-2242-84438 Accelerate Windows: 9.81 m/sec^2 would be adequate -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Martin Deppe

18:02

Emil Stephan schrieb:

...

Am Tuesday 23 September 2008 18:14:44 schrieb Martin Deppe:

...
David Haller schrieb:

...
Hallo,

Am Mon, 22 Sep 2008, Martin Deppe schrieb:

...
Hardware Information (yast2) gibt mir folgende Interruptverteilung aus: 16: IDE 16: Ultra133TX2 (2. IDE controller) 16: GeForce4 Ti 4200 with AGP8X 16: USB 1.1 (VT82xxxxx UHCI USB 1.1 Controller)

Weia. IDE + IDE + Grafikkarte + USB auf einem Interrupt ist IMO tödlich.

Tja, sieht nicht toll aus, aber wie kann ich das ändern? Abgesehen davon, läuft es ja sehr gut, normalerweise!

Martin

Hallo Martin,

die erste IDE ist vermutlich on Board, die GeForce4 sitzt bernutlich im einzigen AGP-Slot, die USB 1.1 ist bermutlich auch on Board. Bleibt also nur, die Ultra133TX2 (vermutlich Promise) in einen anderen PCI-Slot zu stecken (Evtl. mit einer anderen Karte zu tauschen), wenn verfügbar.

Tschö, Emil

Hallo Emil, das ist alles richtig so, ändert denn das Umstecken des Promise Controllers den IRQ? Der Controller macht mir nämlich keinen Ärger - zumindest nicht, daß ich wüßte! Der Test hat ja schließlich ergeben, daß es mit dem Controller funktioniert hat! Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Emil Stephan

18:28

Am Tuesday 23 September 2008 20:02:00 schrieb Martin Deppe:

...

Emil Stephan schrieb:

...
Am Tuesday 23 September 2008 18:14:44 schrieb Martin Deppe:

...
David Haller schrieb:

...
Hallo,

Am Mon, 22 Sep 2008, Martin Deppe schrieb:

...
Hardware Information (yast2) gibt mir folgende Interruptverteilung aus: 16: IDE 16: Ultra133TX2 (2. IDE controller) 16: GeForce4 Ti 4200 with AGP8X 16: USB 1.1 (VT82xxxxx UHCI USB 1.1 Controller)

Weia. IDE + IDE + Grafikkarte + USB auf einem Interrupt ist IMO tödlich.

Tja, sieht nicht toll aus, aber wie kann ich das ändern? Abgesehen davon, läuft es ja sehr gut, normalerweise!

Martin

Hallo Martin,

die erste IDE ist vermutlich on Board, die GeForce4 sitzt bernutlich im einzigen AGP-Slot, die USB 1.1 ist bermutlich auch on Board. Bleibt also nur, die Ultra133TX2 (vermutlich Promise) in einen anderen PCI-Slot zu stecken (Evtl. mit einer anderen Karte zu tauschen), wenn verfügbar.

Tschö, Emil

Hallo Emil,

das ist alles richtig so, ändert denn das Umstecken des Promise Controllers den IRQ? Der Controller macht mir nämlich keinen Ärger - zumindest nicht, daß ich wüßte! Der Test hat ja schließlich ergeben, daß es mit dem Controller funktioniert hat!

Gruß Martin

Hallo Martin, der gesharte Interrupt macht aber evtl. den anderen Geräten Ärger. Tschö, Emil -- Registered Linux User since 19940320 -------------------------------------------------- Emil Stephan, Marktplatz 39, 53773 Hennef, Germany voice: +49-2242-84438 Accelerate Windows: 9.81 m/sec^2 would be adequate -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

David Haller

18:21

Hallo, Am Die, 23 Sep 2008, Martin Deppe schrieb:

...

David Haller schrieb:

...
Am Mon, 22 Sep 2008, Martin Deppe schrieb:

...
Hardware Information (yast2) gibt mir folgende Interruptverteilung aus: 16: IDE 16: Ultra133TX2 (2. IDE controller) 16: GeForce4 Ti 4200 with AGP8X 16: USB 1.1 (VT82xxxxx UHCI USB 1.1 Controller)

Weia. IDE + IDE + Grafikkarte + USB auf einem Interrupt ist IMO tödlich.

Tja, sieht nicht toll aus, aber wie kann ich das ändern? Abgesehen davon, läuft es ja sehr gut, normalerweise!

Naja, aber wenn dann mal was los ist... Ändern kannst du das für GraKa und den U133TX2 wohl im BIOS bei der IRQ / Slot Zuordnung, wobei das meist "INT-A .. INT-D" sind, die den Slots zugeordnet werden. Einer der Slots hängt dann meist an der gleichen IRQ-Leitung wie der AGP-Slot. Leider scheint keins der Treibermodule (pata_amd, pata_pdc*, nvidia, uhci_hcd) einen IRQ-Parameter zu haben... -dnh -- Die Geschichte macht die Menschen, nicht die Menschen Geschichte. -- in "Highlander", die Serie -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Martin Deppe

27 Sep 27 Sep

10:51

David Haller schrieb:

...

Hallo,

...

Naja, aber wenn dann mal was los ist...

Ändern kannst du das für GraKa und den U133TX2 wohl im BIOS bei der IRQ / Slot Zuordnung, wobei das meist "INT-A .. INT-D" sind, die den Slots zugeordnet werden. Einer der Slots hängt dann meist an der gleichen IRQ-Leitung wie der AGP-Slot.

Leider scheint keins der Treibermodule (pata_amd, pata_pdc*, nvidia, uhci_hcd) einen IRQ-Parameter zu haben...

-dnh Hallo David, hallo Emil,

@David: ich habe im BIOS nachgeschaut, habe aber nicht gefunden, wo respektive das ich die IRQs irgendwo dort einstellen könnte. @Emil: Ich habe dann mal die Promise Ultra in einen anderen Slot gesteckt und ich bin bass erstaunt, was das alles bewirkt hat: Die Interruptverteilung vor Umstecken der Promise Ultra133TX2: -------------------------------------------------------------- 06: Floppy Disk Controller 16: IDE 16: Ultra133TX2 (2. IDE controller) 16: GeForce4 Ti 4200 with AGP8X 16: USB 1.1 (VT82xxxxx UHCI USB 1.1 Controller) 17: USB 2.0 17: AMD-766 [ViperPlus] USB 18: USB 1.1 (VT82xxxxx UHCI USB 1.1 Controller) 18: SBLive! Player 5.1 19: RTL-8169 Gigabit Ethernet (eth0) Die Interruptverteilung nach Umstecken der Promise Ultra133TX2: --------------------------------------------------------------- 06: Floppy Disk Controller 16: IDE 16: Ultra133TX2 (2. IDE controller) 16: AMD-766 [ViperPlus] USB 16: USB 2.0 17: USB 1.1 (VT82xxxxx UHCI USB 1.1 Controller) - aktuell nicht benutzt 17: SBLive! Player 5.1 18: USB 1.1 (VT82xxxxx UHCI USB 1.1 Controller) - aktuell nicht benutzt 18: GeForce4 Ti 4200 with AGP8X 19: RTL-8169 Gigabit Ethernet (eth0) Für mein Verständnis, sieht das jetzt drastisch besser aus, als vorher! Zumal ich die USB 1.1 Kontroller gar nicht nutze und somit die GraKa und die Soundkarte allein einen IRQ belegen. Ich hoffe nur, dass sich diese Einstellung nicht nach einem Neustart ständig wieder verändert. Ich dann gerade den Test auf's exempel gemacht und er verlief deutlich besser, aber leider trat der Fehler dann nach 1GB, anstatt schon nach 100-200 MB wieder auf! Schade!!! Aber immerhin deutlich besser. Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Manfred Kreisl

11:27

Hallo Martin, Martin Deppe schrieb: [..]

...

Die Interruptverteilung nach Umstecken der Promise Ultra133TX2: --------------------------------------------------------------- 06: Floppy Disk Controller 16: IDE 16: Ultra133TX2 (2. IDE controller) 16: AMD-766 [ViperPlus] USB 16: USB 2.0 17: USB 1.1 (VT82xxxxx UHCI USB 1.1 Controller) - aktuell nicht benutzt 17: SBLive! Player 5.1 18: USB 1.1 (VT82xxxxx UHCI USB 1.1 Controller) - aktuell nicht benutzt 18: GeForce4 Ti 4200 with AGP8X 19: RTL-8169 Gigabit Ethernet (eth0)

Für mein Verständnis, sieht das jetzt drastisch besser aus, als vorher! Zumal ich die USB 1.1 Kontroller gar nicht nutze und somit die GraKa und die Soundkarte allein einen IRQ belegen. Ich hoffe nur, dass sich diese Einstellung nicht nach einem Neustart ständig wieder verändert.

Ich dann gerade den Test auf's exempel gemacht und er verlief deutlich besser, aber leider trat der Fehler dann nach 1GB, anstatt schon nach 100-200 MB wieder auf! Schade!!! Aber immerhin deutlich besser.

ich fühle mit dir aber schätze, dass du damit leben musst. Ich laboriere hier bei meinem Server auch schon seit Monaten (im Grunde genommen werden es bald Jahre) daran herum, sporadisch auftretende Systemhänger in den Griff zu bekommen, bislang erfolglos. Die Abstürze kommen bei mir so zwischen 7 und 21 Tagen, unabhängig davon was gerade läuft. Die Hardware schließe ich ich hierbei mittlerweile zu 99.9% aus, da mittlerweile die vierte völlig verschiedene Hardware (Athlon-XP 2100+ auf ASUS Board, Athlon-64 3500+ auf ASROCK Board, Pentium-M 740 auf DFI Board und jetzt Pentium-M 780 auf A-Open Board) zum Einsatz kommt und sich am Verhalten nichts nennenswertes geändert hat. Ich hab's jetzt endgültig aufgegeben :-( Meines Erachtens liegt es an Fehlern im Kernel bzw. Treiber, die halt im meiner Systemkonfiguration einfach nicht korrekt laufen - irgendwann knallt's halt dann. So ähnlich wird es vermutlich bei dir auch sein. Mein persönlicher Eindruck bzw. Erfahrung ist, dass mit dem zunehmenden Schickimicki-Linux die Systemstabilität massiv darunter leidet. Solche Hänger kannte ich bei meiner jahrelang eingesetzten SuSE 7.2 mit eigenen Kerneln nie (sowohl bei Home- als auch Firmenserver), auch eine ca. 2 Jahre eingesetzte SuSE 9.2 lief völlig absturzfrei. Der Ärger fing erst mit der 10.2 an und hält sich seitdem hartnäckig bis hin zur 11.0. Gruß Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Martin Deppe

15:49

Manfred Kreisl schrieb:

...

Hallo Martin,

[...]

ich fühle mit dir aber schätze, dass du damit leben musst.

Ich laboriere hier bei meinem Server auch schon seit Monaten (im Grunde genommen werden es bald Jahre) daran herum, sporadisch auftretende Systemhänger in den Griff zu bekommen, bislang erfolglos. Die Abstürze kommen bei mir so zwischen 7 und 21 Tagen, unabhängig davon was gerade läuft. Die Hardware schließe ich ich hierbei mittlerweile zu 99.9% aus, da mittlerweile die vierte völlig verschiedene Hardware (Athlon-XP 2100+ auf ASUS Board, Athlon-64 3500+ auf ASROCK Board, Pentium-M 740 auf DFI Board und jetzt Pentium-M 780 auf A-Open Board) zum Einsatz kommt und sich am Verhalten nichts nennenswertes geändert hat. Ich hab's jetzt endgültig aufgegeben :-( Meines Erachtens liegt es an Fehlern im Kernel bzw. Treiber, die halt im meiner Systemkonfiguration einfach nicht korrekt laufen - irgendwann knallt's halt dann.

So ähnlich wird es vermutlich bei dir auch sein.

Mein persönlicher Eindruck bzw. ErfahruDu erinnerst mich an etwas, was ich schon fast wieder vergessen hatte: Die Serverversion läuft immer noch deutlich stabiler als eine, bei der die grafische Oberfläche verwendet wird. Ich habe mir schon öfter gedacht, dass es nicht so einfach ist, fehlerfreie Soft- wie auch Hardware herzustellen, die so leistungsfähig ist, wie die heutigen Systeme es sind. Die Hardware und ihre Treiber müssen einfach perfekt sein; und nicht "nur" immer schneller! Tja, und da muß wohl jetzt auch Linux dran glauben, fürchte ich :-(ng ist, dass mit dem zunehmenden Schickimicki-Linux die Systemstabilität massiv darunter leidet. Solche Hänger kannte ich bei meiner jahrelang eingesetzten SuSE 7.2 mit eigenen Kerneln nie (sowohl bei Home- als auch Firmenserver), auch eine ca. 2 Jahre eingesetzte SuSE 9.2 lief völlig absturzfrei. Der Ärger fing erst mit der 10.2 an und hält sich seitdem hartnäckig bis hin zur 11.0.

Gruß Manfred

Danke Dir Manfred! Also, wenn ich mir so anschaue, was Du schreibst, frage ich mich jetzt, was hat sich kurz oder unmittelbar vor der 10.2 verändert? Andererseits mußte ich bisher fast immer erfahren, dass es sich um fehlerhafte Hardware handelte, wenn ich unter Linux ein Stabilitätsproblem hatte. Dazu muß ich natürlich erwähnen, dass ich eigentlich nie den allerneuesten Kernel einsetze, sondern lieber immer auf die stabile Version setze. Naja, jedenfalls läuft mein Server jetzt erst seit (nur) 20 Tagen ununterbrochen mit der Version 10.3 von openSuSE. Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

David Haller

17:05

Hallo, Am Sam, 27 Sep 2008, Martin Deppe schrieb:

...

David Haller schrieb: [..]

...
Ändern kannst du das für GraKa und den U133TX2 wohl im BIOS bei der IRQ / Slot Zuordnung, wobei das meist "INT-A .. INT-D" sind, die den Slots zugeordnet werden. Einer der Slots hängt dann meist an der gleichen IRQ-Leitung wie der AGP-Slot.

Leider scheint keins der Treibermodule (pata_amd, pata_pdc*, nvidia, uhci_hcd) einen IRQ-Parameter zu haben...

@David: ich habe im BIOS nachgeschaut, habe aber nicht gefunden, wo respektive das ich die IRQs irgendwo dort einstellen könnte.

Findet sich bei den üblichen BIOS (Award/Phoenix, AMI) meist unter "PNP/PCI Configuration" oder so ähnlich, dort evtl. noch ein Untermenü.

...

@Emil: Ich habe dann mal die Promise Ultra in einen anderen Slot gesteckt und ich bin bass erstaunt, was das alles bewirkt hat: [..] Die Interruptverteilung nach Umstecken der Promise Ultra133TX2: 06: Floppy Disk Controller 16: IDE 16: Ultra133TX2 (2. IDE controller) 16: AMD-766 [ViperPlus] USB 16: USB 2.0 17: USB 1.1 (VT82xxxxx UHCI USB 1.1 Controller) - aktuell nicht benutzt 17: SBLive! Player 5.1 18: USB 1.1 (VT82xxxxx UHCI USB 1.1 Controller) - aktuell nicht benutzt 18: GeForce4 Ti 4200 with AGP8X 19: RTL-8169 Gigabit Ethernet (eth0)

Für mein Verständnis, sieht das jetzt drastisch besser aus, als vorher!

Schonmal besser, v.a. daß die GraKa nicht mehr bei den IDE Controllern ist. Aber daß beide IDE und der Chipsatz-USB auf einem IRQ liegen ist nicht so gut.

...

Zumal ich die USB 1.1 Kontroller gar nicht nutze und somit die GraKa und die Soundkarte allein einen IRQ belegen. Ich hoffe nur, dass sich diese Einstellung nicht nach einem Neustart ständig wieder verändert.

Dürfte nicht sein.

...

Ich dann gerade den Test auf's exempel gemacht und er verlief deutlich besser, aber leider trat der Fehler dann nach 1GB, anstatt schon nach 100-200 MB wieder auf! Schade!!! Aber immerhin deutlich besser.

s.o. Versuch mal, den Promise noch einen Slot weiter (außer das ist der 4te ;) -- falls du nicht doch noch was im BIOS findest. -dnh -- A mouse is a device used to focus xterms. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

MfG

21 Sep 21 Sep

18:37

Am Sonntag, 21. September 2008 schrieb Emil Stephan:

...

Am Sunday 21 September 2008 18:44:53 schrieb Martin Deppe:

...
Hi,

mein PC läuft eigentlich sehr stabil, soweit! Leider bleibt er auch sehr stabil stehen, wenn ich per "scp" eine größere Datenmenge (mindestens 100 oder 200 MB) mit einer Datenrate von ca. 16 MB/s von ihm auf mein gateway kopiere. Dies ist reproduzierbar und tritt nicht auf, wenn ich die Daten z.B. per Samba mit einer Rate von etwa 2,5 MB/s kopiere.

Ich beobachte dieses Phänomen schon länger und vermute einen Hardwaredefekt im Controller bzw. IO-System auf dem Mainboard.

Hat jemand vielleicht eine Idee respektive Strategie, wie ich genauer rausfinden kann, was da abgeht? Das Problem ist nämlich außerdem, dass ich nichts mehr nachschauen kann, wenn es passiert.

Vielen Dank Martin

Hallo Martin,

scp verschlüsselt die Daten und braucht dafür CPU-Leistung, während beim unverschlüsselten Kopieren per Samba eher die IO-Leistung im Vordergrund steht. Wie sieht es denn aus, wenn Du rcp verwendest? Das arbeitet ohne Verschlüsselung. Brauchst Du die Verschlüsselung?

Tschö, Emil

-- Registered Linux User since 19940320

-------------------------------------------------- Emil Stephan, Marktplatz 39, 53773 Hennef, Germany voice: +49-2242-84438 Accelerate Windows: 9.81 m/sec^2 would be adequate

Ich würde auch mal auf das Netzteil tippen. Hatte damals auch das Problem mit dem "harten stehenbleiben" unter Linux und Windows. Also schied die Software schonmal aus. Nach langem hin und her und überprüfen sämtlicher Komponenten, brachte der Austausch des Netzteils schließlich abhilfe. Gruß Dirk -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

5696

Age (days ago)

5702

Last active (days ago)

List overview

Download

21 comments

8 participants

participants (8)

David Haller
Emil Stephan
Manfred Kreisl
Martin Deppe
MfG
Thomas Hertweck
Thomas Schirrmacher
Tobias Crefeld