On 12 May 2003 at 19:01, René Matthäi wrote:

Hi,

Daniel Bauer schrieb:

...

ich habe div. alte Rechner rumstehen, wenn ich nun Linux auf eine Single Proz PIII500 installiere mit IDE Ausstattung, geht das recht zügig. Nun habe ich noch eine alte Dual Proz mit PII233 mit SCSI Ausstattung gefunden und dachte mir daraus einen Fileserver zu machen, leider kann man die kleinsten Aufrufe (yast) kaum erwarten, alles dauert ewig, als die Installation nun endlich beendet war, hat es sich leider auch kaum gebessert. Hat jemand eine Ahnung woran das liegen kann?

Habe die SuSE 8.2 auf einem Dual Pentium-I MMX 200 installiert, geht ok. Allerdings war es unter SuSE 8.1 eine Zumutung. Da hat sich echt einiges verbessert. Schnell ist es aber natürlich immer noch nicht ;-)

Hi René, ich habs mit der 7.2 und der 8.1 probiert, danke für den Tipp. Daniel

On 12 May 2003 at 19:31, Florian Gross wrote:

* Daniel Bauer textete am 12.05.03:

...

ich habe div. alte Rechner rumstehen, wenn ich nun Linux auf eine Single Proz PIII500 installiere mit IDE Ausstattung, geht das recht zügig. Nun habe ich noch eine alte Dual Proz mit PII233 mit SCSI Ausstattung gefunden und dachte mir daraus einen Fileserver zu machen, leider kann man die kleinsten Aufrufe (yast) kaum erwarten, alles dauert ewig, als die Installation nun endlich beendet war, hat es sich leider auch kaum gebessert. Hat jemand eine Ahnung woran das liegen kann?

Ich zerpflücke dich jetzt mal ein wenig... ;-)

aua ;)

Was bedeutet bei dir ewig? YaST oder YaST2? Welche SuSE- Version?

Leider Yast2, es ist eine 8.1, habe es allerdings mit der 7.2 ebf. probiert und allein die Installation läuft ca. 3 Tage!!!

Wieviel RAM ist drin? Hast du Kernel und Programme für den Dual-

1 GB ECC RAM linux:~ # uname -a Linux linux 2.4.19-64GB-SMP #1 SMP Fri Sep 13 13:15:53 UTC 2002 i686 unknown Das ist auch der einzige Unterschied den ich bei den Installationen feststellen konnte "64GB-SMP"

Betrieb? Welchen Durchsatz haben deine Festplatten? Steht was in der

Es sind wie gesagt SCSI Platten, 9 GB Seagate Cheetah, die dürften schnell genug sein, ich hab den NT Server nochmals angeschmissen, bevor ich in platt gemacht habe und dabei keinerlei Probleme bemerkt, er ist schnell und "sauber" gelaufen.

/var/log/messages?

Außer ständigen APIC Errors nichts, aber laut einigen Artikeln in der Liste und Google kann ich die ignorieren, das abschalten funktioniert leider nicht. Gruß + Dank Daniel

On 13 May 2003 at 19:02, Florian Gross wrote:

* Daniel Bauer textete am 13.05.03:

...

On 12 May 2003 at 19:31, Florian Gross wrote:

...

* Daniel Bauer textete am 12.05.03:

...

ich habe div. alte Rechner rumstehen, wenn ich nun Linux auf eine Single Proz PIII500 installiere mit IDE Ausstattung, geht das recht zügig. Nun habe ich noch eine alte Dual Proz mit PII233 mit SCSI Ausstattung gefunden und dachte mir daraus einen Fileserver zu machen, leider kann man die kleinsten Aufrufe (yast) kaum erwarten, alles dauert ewig, als die Installation nun endlich beendet war, hat es sich leider auch kaum gebessert. Hat jemand eine Ahnung woran das liegen kann?

Ich zerpflücke dich jetzt mal ein wenig... ;-)

aua ;)

Paßt. *g*

...

...

Was bedeutet bei dir ewig? YaST oder YaST2? Welche SuSE- Version?

Leider Yast2, es ist eine 8.1, habe es allerdings mit der 7.2 ebf. probiert und allein die Installation läuft ca. 3 Tage!!!

Also irgendwas geht bei dir gewaltig daneben. Die Installation der SuSE 7.3 mit YaST (ohne 2) hab' ich mit einem P166 in ca. 4h durchgezogen.

das denk ich auch, ich wüßt nur gerne was ;)

...

...

Wieviel RAM ist drin? Hast du Kernel und Programme für den Dual-

1 GB ECC RAM

linux:~ # uname -a Linux linux 2.4.19-64GB-SMP #1 SMP Fri Sep 13 13:15:53 UTC 2002 i686 unknown

Das ist auch der einzige Unterschied den ich bei den Installationen feststellen konnte "64GB-SMP"

4GB sollte doch durchaus genügen.

wo kann ich bei der 8.1er Installation denn den Kernel auswählen???

...

...

Betrieb? Welchen Durchsatz haben deine Festplatten? Steht was in der

Es sind wie gesagt SCSI Platten, 9 GB Seagate Cheetah, die dürften schnell genug sein, ich hab den NT Server nochmals angeschmissen, bevor ich in platt gemacht habe und dabei keinerlei Probleme bemerkt, er ist schnell und "sauber" gelaufen.

Was ergibt denn ein hdparm -Tt /dev/[deine Festplatten]

linux:~ # hdparm -tT /dev/sda /dev/sda: Timing buffer-cache reads: 128 MB in 7.10 seconds = 18.03 MB/sec Timing buffered disk reads: 64 MB in 9.45 seconds = 6.77 MB/sec linux:~ # hdparm -tT /dev/system/lvm1 /dev/system/lvm1: Timing buffer-cache reads: 128 MB in 7.17 seconds = 17.85 MB/sec Timing buffered disk reads: 64 MB in 7.05 seconds = 9.08 MB/sec aber ich denke die schlechten resultate kommen aus der Installation, als ich Tests auf NT durchgeführt habe hatte ca. 60 MB/sec, dahinter steckt ein Raid 5 angesteuert durch einen Mylex DAC960PD. Habe nun auch noch ne Primergy 560 in die Hände bekommen, auch hier zeigen sich die gleichen Symptome ...

...

...

/var/log/messages?

Außer ständigen APIC Errors nichts, aber laut einigen Artikeln in der Liste und Google kann ich die ignorieren, das abschalten funktioniert leider nicht.

Und irgendwas, was auf die Festplatten oder CD/DVD- Laufwerksprobleme schließen läßt, gar nichts? Oha...

Nein, nichts, zumal dieses sch... NT sauber lief :( Gruß Daniel

Hallo, On Wed, 14 May 2003, Florian Gross wrote:

* Daniel Bauer textete am 14.05.03:

...

On 13 May 2003 at 19:02, Florian Gross wrote:

...

* Daniel Bauer textete am 13.05.03:

...

On 12 May 2003 at 19:31, Florian Gross wrote:

...

* Daniel Bauer textete am 12.05.03:

[SuSE 8.1 läuft unter PII233 Dual- Prozessor- System _sehr_ langsam]

...

...

...

...

Wieviel RAM ist drin? Hast du Kernel und Programme für den Dual-

1 GB ECC RAM

linux:~ # uname -a Linux linux 2.4.19-64GB-SMP #1 SMP Fri Sep 13 13:15:53 UTC 2002 i686 unknown

Das ist auch der einzige Unterschied den ich bei den Installationen feststellen konnte "64GB-SMP"

4GB sollte doch durchaus genügen.

wo kann ich bei der 8.1er Installation denn den Kernel auswählen???

Weiß nicht. Ich habe die 7.3 und das wird auch meine letzte SuSE bleiben.

Apropos: im Zweifel wuerde ich mal nen eigenen backen ;)

...

...

...

...

Betrieb? Welchen Durchsatz haben deine Festplatten? Steht was in der

Es sind wie gesagt SCSI Platten, 9 GB Seagate Cheetah, die dürften schnell genug sein, ich hab den NT Server nochmals angeschmissen, bevor ich in platt gemacht habe und dabei keinerlei Probleme bemerkt, er ist schnell und "sauber" gelaufen.

Was ergibt denn ein hdparm -Tt /dev/[deine Festplatten]

linux:~ # hdparm -tT /dev/sda /dev/sda: Timing buffer-cache reads: 128 MB in 7.10 seconds = 18.03 MB/sec Timing buffered disk reads: 64 MB in 9.45 seconds = 6.77 MB/sec

linux:~ # hdparm -tT /dev/system/lvm1 /dev/system/lvm1: Timing buffer-cache reads: 128 MB in 7.17 seconds = 17.85 MB/sec Timing buffered disk reads: 64 MB in 7.05 seconds = 9.08 MB/sec

Auch nach mehrmaligem Aufruf keine Änderung?

Zumindest bei "Timing buffer-cache reads" sollte IMO einiges mehr rauskommen. Sehr viel mehr.

Oh ja. Naja, kommt auf die CPU/FSB/RAM Kombination an...

Bei mir werden grad 256MB RAM erkannt, ich hab' _einen_ PII233 drin. Allerdings habe ich IDE- Platten.

grossing:/home/florian # hdparm -tT /dev/hd[a,e,f]

/dev/hda: Timing buffer-cache reads: 128 MB in 1.69 seconds = 75.74 MB/sec Timing buffered disk reads: 64 MB in 23.23 seconds = 2.76 MB/sec

/dev/hde: Timing buffer-cache reads: 128 MB in 1.69 seconds = 75.74 MB/sec Timing buffered disk reads: 64 MB in 3.97 seconds = 16.12 MB/sec

/dev/hdf: Timing buffer-cache reads: 128 MB in 1.80 seconds = 71.11 MB/sec Timing buffered disk reads: 64 MB in 3.65 seconds = 17.53 MB/sec grossing:/home/florian # hdparm -i /dev/hd[a,e,f]

Das ist aber auch schon relativ lahm, da deine (Flo's) HW schon in Ehren gealtert ist. Auch mit meiner HW bekomme ich z.B.: # hdparm -tT /dev/hd{a,b,c} | sed '/^$/d' /dev/hda: Timing buffer-cache reads: 128 MB in 0.91 seconds =140.66 MB/sec Timing buffered disk reads: 64 MB in 2.49 seconds = 25.70 MB/sec /dev/hdb: Timing buffer-cache reads: 128 MB in 0.93 seconds =137.63 MB/sec Timing buffered disk reads: 64 MB in 2.74 seconds = 23.36 MB/sec /dev/hdc: Timing buffer-cache reads: 128 MB in 0.91 seconds =140.66 MB/sec Timing buffered disk reads: 64 MB in 3.24 seconds = 19.75 MB/sec Hier sieht man auch sehr schoen, dass die buffer-cache reads _NICHT_ ueber den PCI Bus laufen, denn der schafft eben bei normaler HW (32bit/33MHz) nur 125 MB/s! Das RAM ist bei mir eben schon schneller angebunden ;) CPU/Chipsatz: AMD Athlon 500 (model 1!) / AMD Irongate Northbridge (AMD-751) + AMD Viper (Southbridge (und IDE-Controller) AMD-756). Die Platten laufen alle 3 im UDMA Mode2 (aka UDMA 33).

Was für Platten hast du denn drin? Die müssen ja steinalt sein.

Nicht unbedingt. Nach dem, was ich bisher so gelesen habe liegt das Problem woanders. Mein Tipp ist irgendeine *heftige* Fehlkonfig...

...

Habe nun auch noch ne Primergy 560 in die Hände bekommen, auch hier zeigen sich die gleichen Symptome ...

Ist wohl auch 'ne Platte, oder?

Ne, das is ne PC-Baureihe von (Fujitsu-)Siemens/Nixdorf...

...

Nein, nichts, zumal dieses sch... NT sauber lief :(

Das sagt prinzipiell nur sehr wenig aus, verhaertet aber meine Vermutung einer Fehlconfig unter Linux bzw. gegen eine HW-Defekt. @Daniel: maile doch bitte mal die Ausgabe von cat /proc/interrupts /proc/ioports Und als PM an mich am besten auch gleich noch die /var/log/boot.msg... -dnh -- SprintLINK makes proton decay look fast. -- Jude Charles Giampaolo

Hallo, On Thu, 15 May 2003, Daniel Bauer wrote:

On 14 May 2003 at 22:29, David Haller wrote: [..]

...

@Daniel: maile doch bitte mal die Ausgabe von cat /proc/interrupts /proc/ioports

anbei die Ausgaben:

linux:~ # cat /proc/interrupts CPU0 CPU1 [IRQs ok] NMI: 0 0 LOC: 31489473 31489473 ERR: 6361 MIS: 0

Oha! Ich hab da ueberall nur '0'... (ok, die Kiste laeuft heut noch nicht lange ;) Ah, LOC sind offenbar die Local APIC IRQs, bei mir ohne APIC fehlen die natuerlich. Die IRQ-Fehler ("ERR") bei CPU0 sind aber bedenklich.

linux:~ # cat /proc/ioports [keine Konflikte]

[per PM hab ich die boot.msg bekommen, dort u.a.: <3>APIC error on CPU1: 00(08) <3>APIC error on CPU0: 00(02) weiters wird 'disableapic' als Kernelparameter verwendet. ] Du hast offenbar ein Problem mit APIC/SMP. Aha, ich hab mal in arch/i386/kernel/apic.c gekruschtelt, dort findet sich: ==== /* * This interrupt should never happen with our APIC/SMP architecture */ asmlinkage void smp_error_interrupt(void) [..] /* Here is what the APIC error bits mean: 0: Send CS error 1: Receive CS error a 2: Send accept error 3: Receive accept error 4: Reserved 5: Send illegal vector 6: Received illegal vector 7: Illegal register address */ [..] printk (KERN_ERR "APIC error on CPU%d: %02lx(%02lx)\n", smp_processor_id(), v , v1); ==== Die APIC-Fehler sind also: APIC error on CPU1: 0x00(0x08) == 0 ( 00001000b ) -> Bit 3 -> "Receive accept error" APIC error on CPU0: 0x00(0x02) == 0 ( 00000010b ) -> Bit 1 -> "Receive CS error" Leider kann ich damit auch nichts weiter anfangen... Ich hoffe ich konnte zumindest mal helfen, eine moegliche Fehlerursache einzugrenzen ;) -dnh --

(void *)'\0' Didn't you see the sign? It said VOID WHERE PROHIBITED Don't tell me you can't C. -- the Internet Oracle [#1307-01]

On Thu, 15 May 2003 17:14:37 +0200 "Daniel Bauer" wrote:

On 15 May 2003 at 12:41, David Haller wrote:

...

Hallo,

On Thu, 15 May 2003, Daniel Bauer wrote:

...

On 14 May 2003 at 22:29, David Haller wrote: [..]

...

@Daniel: maile doch bitte mal die Ausgabe von cat /proc/interrupts /proc/ioports

anbei die Ausgaben:

linux:~ # cat /proc/interrupts CPU0 CPU1 [IRQs ok] NMI: 0 0 LOC: 31489473 31489473 ERR: 6361 MIS: 0

Oha! Ich hab da ueberall nur '0'... (ok, die Kiste laeuft heut noch nicht lange ;) Ah, LOC sind offenbar die Local APIC IRQs, bei mir ohne APIC fehlen die natuerlich. Die IRQ-Fehler ("ERR") bei CPU0 sind aber bedenklich.

...

[per PM hab ich die boot.msg bekommen, dort u.a.: <3>APIC error on CPU1: 00(08) <3>APIC error on CPU0: 00(02) weiters wird 'disableapic' als Kernelparameter verwendet. ]

Du hast offenbar ein Problem mit APIC/SMP.

...

...

Die APIC-Fehler sind also:

APIC error on CPU1: 0x00(0x08) == 0 ( 00001000b ) -> Bit 3 -> "Receive accept error" APIC error on CPU0: 0x00(0x02) == 0 ( 00000010b ) -> Bit 1 -> "Receive CS error"

Werde mal versuchen mit nur einem Prozessor, bzw. anderen Prozessoren zu arbeiten, vielleicht haben die ja ein Problem, allerdings zeigt sich wie gesagt auf der Primergy der gleiche Effekt.

Ältere Gigabyte-Boards sind bekannt für fehlerhafte SMP-Implementationen. Ob das bei Deinem Board zutrifft, weiss ich natürlich nicht. Ich habe ein GA586DX-Board mit 2 x PI 233, das mit 2.4-Kernels nicht nutzbar ist. Aber ein 2.2.19 mit Kernoption "noapic" läuft (dann macht nur noch CPU#0 die Interrupt-Behandlung). Du könntest also auch einen Versuch mit dem älteren Kernel der 7.2 machen. Gruß, Thomas

On Thu, 15 May 2003 20:35:47 +0200 David Haller wrote:

On Thu, 15 May 2003, Thomas Lippert wrote:

...

Ich habe ein GA586DX-Board mit 2 x PI 233, das mit 2.4-Kernels nicht nutzbar ist. Aber ein 2.2.19 mit Kernoption "noapic" läuft (dann macht nur noch CPU#0 die Interrupt-Behandlung). Du könntest also auch einen Versuch mit dem älteren Kernel der 7.2 machen.

Das 'noapic' wuerde ich auch so mal probieren.

Ja, das stimmt. Ob's wirkt, siehst Du sofort in /proc/interrupts. Bei mir ging es mit 2.4-Kerneln nicht (hab ich nie verstanden). Gruß, Thomas

On 15 May 2003 at 18:08, Thomas Lippert wrote:

On Thu, 15 May 2003 17:14:37 +0200 "Daniel Bauer" wrote:

...

On 15 May 2003 at 12:41, David Haller wrote:

...

Hallo,

On Thu, 15 May 2003, Daniel Bauer wrote:

...

On 14 May 2003 at 22:29, David Haller wrote: [..]

...

@Daniel: maile doch bitte mal die Ausgabe von cat /proc/interrupts /proc/ioports

anbei die Ausgaben:

linux:~ # cat /proc/interrupts CPU0 CPU1 [IRQs ok] NMI: 0 0 LOC: 31489473 31489473 ERR: 6361 MIS: 0

Oha! Ich hab da ueberall nur '0'... (ok, die Kiste laeuft heut noch nicht lange ;) Ah, LOC sind offenbar die Local APIC IRQs, bei mir ohne APIC fehlen die natuerlich. Die IRQ-Fehler ("ERR") bei CPU0 sind aber bedenklich.

...

[per PM hab ich die boot.msg bekommen, dort u.a.: <3>APIC error on CPU1: 00(08) <3>APIC error on CPU0: 00(02) weiters wird 'disableapic' als Kernelparameter verwendet. ]

Du hast offenbar ein Problem mit APIC/SMP.

...

...

Die APIC-Fehler sind also:

APIC error on CPU1: 0x00(0x08) == 0 ( 00001000b ) -> Bit 3 -> "Receive accept error" APIC error on CPU0: 0x00(0x02) == 0 ( 00000010b ) -> Bit 1 -> "Receive CS error"

Werde mal versuchen mit nur einem Prozessor, bzw. anderen Prozessoren zu arbeiten, vielleicht haben die ja ein Problem, allerdings zeigt sich wie gesagt auf der Primergy der gleiche Effekt.

Ältere Gigabyte-Boards sind bekannt für fehlerhafte SMP-Implementationen. Ob das bei Deinem Board zutrifft, weiss ich natürlich nicht. Ich habe ein GA586DX-Board mit 2 x PI 233, das mit 2.4-Kernels nicht nutzbar ist. Aber ein 2.2.19 mit Kernoption "noapic" läuft (dann macht nur noch CPU#0 die Interrupt-Behandlung). Du könntest also auch einen Versuch mit dem älteren Kernel der 7.2 machen.

Hallo Thomas, kann ich das irgendwo herausfinden??? Es ist ein GA-686DLX. Danke Daniel

On 14 May 2003 at 20:13, Florian Gross wrote:

* Daniel Bauer textete am 14.05.03:

...

On 13 May 2003 at 19:02, Florian Gross wrote:

...

* Daniel Bauer textete am 13.05.03:

...

On 12 May 2003 at 19:31, Florian Gross wrote:

...

* Daniel Bauer textete am 12.05.03:

[SuSE 8.1 läuft unter PII233 Dual- Prozessor- System _sehr_ langsam]

...

...

...

...

Wieviel RAM ist drin? Hast du Kernel und Programme für den Dual-

1 GB ECC RAM

linux:~ # uname -a Linux linux 2.4.19-64GB-SMP #1 SMP Fri Sep 13 13:15:53 UTC 2002 i686 unknown

Das ist auch der einzige Unterschied den ich bei den Installationen feststellen konnte "64GB-SMP"

4GB sollte doch durchaus genügen.

wo kann ich bei der 8.1er Installation denn den Kernel auswählen???

Weiß nicht. Ich habe die 7.3 und das wird auch meine letzte SuSE bleiben.

Ich wäre auch gerne bei der 7.2er geblieben, allerdings brauche ich einige neue Sachen und die lassen sich nicht ohne weiteres auf der 7.2er installieren, also habe ich den Schritt gemacht. Aber wie gesagt es läuft auch unter der 7.2er schon so langsam.

...

...

...

...

Betrieb? Welchen Durchsatz haben deine Festplatten? Steht was in der

Es sind wie gesagt SCSI Platten, 9 GB Seagate Cheetah, die dürften schnell genug sein, ich hab den NT Server nochmals angeschmissen, bevor ich in platt gemacht habe und dabei keinerlei Probleme bemerkt, er ist schnell und "sauber" gelaufen.

Was ergibt denn ein hdparm -Tt /dev/[deine Festplatten]

linux:~ # hdparm -tT /dev/sda /dev/sda: Timing buffer-cache reads: 128 MB in 7.10 seconds = 18.03 MB/sec Timing buffered disk reads: 64 MB in 9.45 seconds = 6.77 MB/sec

linux:~ # hdparm -tT /dev/system/lvm1 /dev/system/lvm1: Timing buffer-cache reads: 128 MB in 7.17 seconds = 17.85 MB/sec Timing buffered disk reads: 64 MB in 7.05 seconds = 9.08 MB/sec

Auch nach mehrmaligem Aufruf keine Änderung?

Zumindest bei "Timing buffer-cache reads" sollte IMO einiges mehr rauskommen. Sehr viel mehr.

Bei mir werden grad 256MB RAM erkannt, ich hab' _einen_ PII233 drin. Allerdings habe ich IDE- Platten.

grossing:/home/florian # hdparm -tT /dev/hd[a,e,f]

/dev/hda: Timing buffer-cache reads: 128 MB in 1.69 seconds = 75.74 MB/sec Timing buffered disk reads: 64 MB in 23.23 seconds = 2.76 MB/sec

/dev/hde: Timing buffer-cache reads: 128 MB in 1.69 seconds = 75.74 MB/sec Timing buffered disk reads: 64 MB in 3.97 seconds = 16.12 MB/sec

/dev/hdf: Timing buffer-cache reads: 128 MB in 1.80 seconds = 71.11 MB/sec Timing buffered disk reads: 64 MB in 3.65 seconds = 17.53 MB/sec grossing:/home/florian # hdparm -i /dev/hd[a,e,f]

Wobei /dev/hda:

Model=Conner Peripherals 540MB - CFS540A, FwRev=6OT0.04p, SerialNo=EW902RD DMA modes: mdma0 *mdma1

eine uralte Platte ist. Beim buffer-cache read dürfte wohl der RAM eine entscheidende Rolle spielen, vorher waren's da so um die 36MB/sec. Moment... ja, da zählt RAM, CPU aber _nicht_ die Platte!

Die Platte hängt am on-Board- Controller, der wohl kein UDMA kann. Egal, die Platte auch nicht. *g*

/dev/hde:

Model=ST340810A, FwRev=3.39, SerialNo=6FB1PENY DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 udma5 Ist eine 40GB- Platte und

/dev/hdf:

Model=ST320413A, FwRev=3.39, SerialNo=7ED2R4G7 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 udma5

ist eine 20GB- Platte, beide an einem UDMA-100- Controller, laufen beide mit udma2. Mehr geht aus irgendeinem Grund bei mir nicht. Vielleicht ist da der PCI- Bus zu langsam oder so. Keine Ahnung.

Was für Platten hast du denn drin? Die müssen ja steinalt sein.

Die Seagate Cheetah hat eigentlich allein schon einen Datenstrom von ca. 30 MB/s IMHO. Waren ja auch Serverplatten mit 15k rpm ... Ich weiß nicht woran das liegt ...

...

aber ich denke die schlechten resultate kommen aus der Installation, als ich Tests auf NT durchgeführt habe hatte ca. 60 MB/sec, dahinter steckt ein Raid 5 angesteuert durch einen Mylex DAC960PD.

Bei was waren die 60MB/sec? Lesen aus dem Buffer-cache (RAM) oder beim lesen von der Platte?

Kann ich nicht sagen ich kenne nichts vergleichbares wie hdparm auf NT, ich habe das per copy und Stoppuhr ermittelt ;)

...

Habe nun auch noch ne Primergy 560 in die Hände bekommen, auch hier zeigen sich die gleichen Symptome ...

Ist wohl auch 'ne Platte, oder?

Ne ein alter Dual Proz Server von Siemens ...

...

...

...

...

/var/log/messages?

Außer ständigen APIC Errors nichts, aber laut einigen Artikeln in der Liste und Google kann ich die ignorieren, das abschalten funktioniert leider nicht.

Und irgendwas, was auf die Festplatten oder CD/DVD- Laufwerksprobleme schließen läßt, gar nichts? Oha...

Nein, nichts, zumal dieses sch... NT sauber lief :(

Hmmm, wenn sich NT so wie manches andere Windows verhält, läuft dort noch Hardware, die Linux als defekt abgestempelt hat.

Was passiert denn, wenn du einen Kernel für ein Single-CPU- System nimmst?[1] Ändert sich da was?

Ich glaub das geht nicht ... Ich weiß auch nicht wo ich den Kernel auswählen könnte, habe mir auch schon überlegt mich mal ins Kernel backen und Programme compilieren einzusteigen, damit ich wieder auf die 7.2 kann, aber das war die Installation ja auch unter aller Kanone ...

Oder dein Board wird nicht so gut unterstützt, das würde mir jetzt noch einfallen.

nicht das ich wüßte ... werde vielleicht mal einen Prozessor rausnehmen und als SingleSys installieren. Gruß Daniel

On 12 May 2003 at 19:39, Thomas Hertweck wrote:

Daniel Bauer schrieb:

...

ich habe div. alte Rechner rumstehen, wenn ich nun Linux auf eine Single Proz PIII500 installiere mit IDE Ausstattung, geht das recht zügig. Nun habe ich noch eine alte Dual Proz mit PII233 mit SCSI Ausstattung gefunden und dachte mir daraus einen Fileserver zu machen, leider kann man die kleinsten Aufrufe (yast) kaum erwarten, alles dauert ewig, als die Installation nun endlich beendet war, hat es sich leider auch kaum gebessert. Hat jemand eine Ahnung woran das liegen kann?

Das kann einige Ursachen haben, von IRQ Konflikt, schlechte

Habe nur APIC Errors gefunden, die ich aber lt. Liste und Google ignorieren kann, abschalten funktioniert leider nicht ...

Chipsatzunterstuetzung, Treiberprobleme, bis hin zu einfach

Es ist ein Gigabyte GA-686DLX

zu wenig RAM... Du hast leider nichts ueber die Speicheraus-

sicherlich nicht, es befinden sich 1 GB ECC RAM drin ...

stattung der Rechner geschrieben. Hier lief eine SuSE 6.4 bis vor kurzem auf einem P133, und das ging ganz gut, selbst mit KDE 2 (96 MB RAM Ausstattung).

SuSe 8.1: An KDE will ich ja noch nicht mal denken ;) ich rufe von der Bash yast auf, wähle Online Update aus und muß ca. 30 min. warten. Bis dann Daniel

On 13 May 2003 at 13:17, Thomas Lippert wrote:

On Tue, 13 May 2003 07:47:46 +0200 "Daniel Bauer" wrote:

...

Habe nur APIC Errors gefunden, die ich aber lt. Liste und Google ignorieren kann, abschalten funktioniert leider nicht ...

Hast Du - neben den APIC Errors - nicht doch das eine oder andere "Stuck on TLB IPI wait" mit CPU #0 oder #1 im Log stehen?

Hallo Thomas, habe gerade mit grep alles in /var/log/ durchsucht, aber nichts gefunden. Gruß Daniel

Hi, Am Dienstag, 13. Mai 2003 14:07 schrieb Dominik: [...]

sonst kann ich aber alles machen solang ich nicht konquere öffne ... kann mir jemand eine lösung sagen ??

- nimm rox als Dateimanager - nimm Mozilla/ Opera/ lynx/ w3m/ ... als Internetbrowser - poste neue Nachrichten nie als Reply sondern in eigenem Thread - poste mit Nachnamen Gruß Philipp -- registered Linux user number 258854 HOW-TO? -> GOTO http://counter.li.org/

Hi, Am Dienstag, 13. Mai 2003 18:55 schrieb Dominik Müller:

Am Dienstag, 13. Mai 2003 16:33 schrieb Philipp Zacharias:

...

Am Dienstag, 13. Mai 2003 14:07 schrieb Dominik: [...]

...

sonst kann ich aber alles machen solang ich nicht konquere öffne ... kann mir jemand eine lösung sagen ??

- nimm rox als Dateimanager - nimm Mozilla/ Opera/ lynx/ w3m/ ... als Internetbrowser

das ist so wie "der Mixer ist kaputt nehm ich halt den Toster" weil irgendwo muss ja ein problem sein !?!

nein, das ist das "Der Internet Explorer ist scheiße, ich nehm Mozilla-Konzept". Oder das "Der Kernel ist buggy ich nehm nen neuen Konzept". Und das ist durchaus legitim. Warum sich mit defekter Software herumschlagen, wenn es schnellere und bessere Alternativen gibt, die weniger bis keine Defekte haben?

...

- poste mit Nachnamen

sobald ich den nachnamen in der identität angebe kann ich mit Kmails keine emaisl mehr verschicken !?!

Hm, das kann ich bei mir nicht nachvollziehen. Gruß Philipp -- registered Linux user number 258854 HOW-TO? -> GOTO http://counter.li.org/

Am Dienstag, 13. Mai 2003 14:07 schrieb Dominik:

Hi ich habe ein problem ... sobald ich versuche mit Konquere versuche im Web zu browsen ... schreibt er die Auslagerungs datei komplett

Von Deiner KMail-Version ausgehend vermute ich mal Du hast ne SuSE 8.1 mit KDE 3.1.1. Schreib sowas bitte dazu und häng Dich nicht an fremde Threads mit nem neuen Thema. Tritt das nur bei bestimmten Seiten auf, oder generell? Welche Plugins sind installiert? Neuinstallation, oder Update von ner älteren SuSE? Schon mal die konqueror-Einstellungen unter ~/.kde/share/config gelöscht, eventuell ist da was kaputt? Schon mal in /tmp aufgeräumt? Mal top oder die KDE-Systemüberwachung mitlaufen lassen um festzustellen, wer genau den Speicher zieht? -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de

On 13 May 2003 at 21:45, Manfred Tremmel wrote:

Am Montag, 12. Mai 2003 18:44 schrieb Daniel Bauer:

...

ich habe div. alte Rechner rumstehen, wenn ich nun Linux auf eine Single Proz PIII500 installiere mit IDE Ausstattung, geht das recht zügig. Nun habe ich noch eine alte Dual Proz mit PII233 mit SCSI Ausstattung gefunden und dachte mir daraus einen Fileserver zu machen, leider kann man die kleinsten Aufrufe (yast) kaum erwarten,

Wieviel Speicher hast Du denn drinnen? Es gibt nichts womit Du nen Rechner besser ausbremsen kannst, als mit swappen, drum sollten es bei einer der heute üblichen Desktopumgebungen wie Gnome oder KDE schon mindestens 128 MByte sein. Für ne Textumgebung sollte es auch deutlich weniger tun, aber yast schluckt auch im Textmodus ganz schön.

Hallo Manfred, 1 GB ECC RAM sind drin ;) ich sehe das die Swap Part. die meiste Zeit unbenutzt ist. Gruß Daniel

Peter Baumgartner wrote:

[...] Ich habe selbst einen alten dual MMX 200 als Server laufen, der ist, von der Mach 64 Grafik abgesehen, fast so schnell wie mein 1GHz Desktop.

Dann wird Dein Server aber auch nicht sehr be- ansprucht. So allgemein gilt Deine Aussage si- cherlich nicht, es haengt eben schwer davon ab, was der Server alles zu leisten hat und wen er alles bedienen soll. CU, Th. -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH)

On 14 May 2003 at 8:41, Peter Baumgartner wrote:

Am Montag, 12. Mai 2003 18:44 schrieb Daniel Bauer:

...

Hallo zusammen,

ich habe div. alte Rechner rumstehen, wenn ich nun Linux auf eine Single Proz PIII500 installiere mit IDE Ausstattung, geht das recht zügig. Nun habe ich noch eine alte Dual Proz mit PII233 mit SCSI Ausstattung gefunden und dachte mir daraus einen Fileserver zu machen, leider kann man die kleinsten Aufrufe (yast) kaum erwarten, alles dauert ewig, als die Installation nun endlich beendet war, hat es sich leider auch kaum gebessert. Hat jemand eine Ahnung woran das liegen kann? Ja! Yast installiert per default einen Single Prozessor Kernel. Du mußt erst einen SMP-Kernel backen und installieren. Wieviel Speicher ist denn drin? Swapt er viel? Was für eine Grafikkarte ist drin? Ich habe selbst einen alten dual MMX 200 als Server laufen, der ist, von der Mach 64 Grafik abgesehen, fast so schnell wie mein 1GHz Desktop.

Hallo Peter, dem kann ich nicht zustimmen, nach der Installation hatte ich einen SMP Kernel drauf ... uname -a Linux linux 2.4.19-64GB-SMP #1 SMP Fri Sep 13 13:15:53 UTC 2002 i686 unknown Als Grafikkarte habe ich eine ATI 32 MB AGP drin, allerdings laß ich die Kiste eh nur im Textmodus laufen im Runlevel 3. Gruß Daniel

Hi Peter, On 14 May 2003 at 21:26, Peter Baumgartner wrote:

Am Mittwoch, 14. Mai 2003 11:18 schrieb Daniel Bauer:

...

On 14 May 2003 at 8:41, Peter Baumgartner wrote:

...

Am Montag, 12. Mai 2003 18:44 schrieb Daniel Bauer: [...] Hallo Peter,

dem kann ich nicht zustimmen, nach der Installation hatte ich einen SMP Kernel drauf ... Schön für Dich - Wunder des Yast2

uname -a Linux linux 2.4.19-64GB-SMP #1 SMP Fri Sep 13 13:15:53 UTC 2002 i686 unknown Hm, 4GB würde ja auch reichen, aber auf 64 GB hat er bei mir auch bestanden, allerdings eben als Single. > > Als Grafikkarte habe ich eine ATI 32 MB AGP drin, allerdings laß ich > die Kiste eh nur im Textmodus laufen im Runlevel 3. Hast Du mal mit Top oder xosview (falls Du Dich zu einem minimalen X Server "durchringen" kannst) nach den Prozessen geschaut? Benchmarke doch mal was und vergleiche es mit

Habe ich schon gemacht, der yast od. ssh frißt einen Prozessor zu 100% ;)

einem "bekannten" Rechner. Hast Du den Swap >= Hauptspeicher angelegt? begin glaskugel da soll es doch laut irgendeinem früheren Beitrag bei manchen Kerneln Probleme geben, wenn der kleiner ist end glaskugel

Der Swap steht bei 2 GB, echt sind 1 GB drin, ich kenne nur die Regel das der Swap doppelt so groß sein sollte wie das RAM. Gruß + Dank Daniel

On 15 May 2003 at 22:17, Manfred Tremmel wrote:

Am Mittwoch, 14. Mai 2003 11:18 schrieb Daniel Bauer:

...

uname -a Linux linux 2.4.19-64GB-SMP #1 SMP Fri Sep 13 13:15:53 UTC 2002 i686 unknown

Hast Du schon mal versucht anstelle des k_smp den k_psmp kernel zu installieren. IMHO ist der smp Kernel für ältere Maschinen nicht sonderlich geeignet, der psmp hingegen schon

Hallo Manfred, würd ich ja gerne probieren, wenn ich nur wüßte wie ;) Thx Daniel

Am Freitag, 16. Mai 2003 12:00 schrieb Christian Schoepplein:

Bin wahrlich kein Experte was dein HW-Problem angeht und evtl ist der folgende Tipp auch doof, aber ich würde einen Kernel folgendermaßen umstellen:

1. SuSE 8.1 / 7.2 DVD bzw. 1. CD rein und mounten.

Nein, bei SuSE < 8.2 würd ich dringend einen vom pthread-bug bereinigten Kernel von SuSE ziehen und nicht die Version von der DVD/CD verwenden.

2. Ins Verz. suse/i586 auf der CD / DVD wechseln und dann folgendes eingeben (z.B. auf 'ner 8.2):

# rpm -Uvh k_psmp-2.4.20-39.i586.rpm --nodeps --force

Oder vorher den anderen deinstallieren.

3. Ein

mk_initrd

Im Prinzip richtig, kann man aber beim rpm installieren schaun, ob das nicht eh automatisch ausgeführt wird.

ausführen und grub / lilo neu auf Platte schreiben.

Bei lilo ja, bei grub nicht notwendig, weil der den Kernel aus dem Filesystem liest und nicht wie lilo einfach direkt von der Platte kratzt und deshalb die exakte Position kennen muß.

4. Rebooten.

5. Daumen drücken, dass es klappt ;-) -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de

Daniel Bauer wrote:

[...] Das Mainboad hat 4 Steckplätze, jeder für sich funktioniert, jeder Baustein funktioniert ebenfalls, aber und das ist der Clou, bei Belegung aller Steckplätze tritt dieses Problem auf, ich verstehe zwar nicht warum, aber ich betreibe jetzt die Maschine mit 768 MB und sie rennt wie der Teufel ;)

Aeltere Boards hatten teilweise die Eigenschaft, Cache nur bis zu einer bestimmten RAM-Groesse verwenden zu koennen - diese Groesse wurde als "Cacheable Area" bezeichnet. Natuerlich wurde das nur sehr ungern zugegeben und die Hersteller bauten auch fleissig Speicherbaenke auf die Boards, so dass man als Anwender durchaus mehr RAM ein- bauen konnte (obwohl das dann gar nicht viel Sinn machte). Beim Einbau von mehr Speicher ging dann naemlich alles am Cache vorbei, d.h. die Perfor- mance ging in den Keller statt mit dem zusaetzli- chen RAM zu steigen. Evtl. bist Du genau diesem Phaenomen aufgesessen. Schau mal in die Doku Dei- nes Motherboards... Gruesse, Thomson -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH)

Am Montag, 19. Mai 2003 13:14 schrieb Thomas Hertweck:

Daniel Bauer wrote:

...

[...] [...] Aeltere Boards hatten teilweise die Eigenschaft, Cache nur bis zu einer bestimmten RAM-Groesse verwenden zu koennen - diese Groesse wurde als "Cacheable Area" bezeichnet. Natuerlich wurde das nur sehr ungern zugegeben und die Hersteller bauten auch fleissig Speicherbaenke auf die Boards, so dass man als Anwender durchaus mehr RAM ein- bauen konnte (obwohl das dann gar nicht viel Sinn machte). Beim Einbau von mehr Speicher ging dann naemlich alles am Cache vorbei, d.h. die Perfor- mance ging in den Keller statt mit dem zusaetzli- chen RAM zu steigen. Evtl. bist Du genau diesem Phaenomen aufgesessen. Schau mal in die Doku Dei- nes Motherboards...

Hallo Thomas, das Problem kenne ich von früher. Weist du zufällig ob es neuere Boards gibt (P3, P4 oder entsprechende Athlon-Boards) wo es dieses Problem auch noch gibt? Gerade die neuesten Boards unterstützen ja oft Ram --> 3 GB. Danke für die Auskunft.

Gruesse, Thomson

Gruß Joachim

Hallo Thomas Am Dienstag, 20. Mai 2003 09:13 schrieb Thomas Hertweck:

Joachim Kurpel wrote:

...

[... RAM und Cacheable Area...] das Problem kenne ich von früher. Weist du zufällig ob es neuere Boards gibt (P3, P4 oder entsprechende Athlon-Boards) wo es dieses Problem auch noch gibt? Gerade die neuesten Boards unterstützen ja oft Ram --> 3 GB.

Davon waren hpts. aeltere Boards betroffen, z.B. Boards mit Sockel 7. Platinen mit Slot 1 haben nach Spezifikation mind. 512MB Cacheable Area. Bei einigen Boards konnte man den Cache-Speicher oder das Tag-RAM vergroessern, was auch die Cacheable Area vergroes- serte (ausser bei einige speziellen Intel-Chipsaetzen). Seitdem es fuer den L2-Cache keine externen Module mehr gibt, hat sich das Problem eigentlich erledigt. Ab den Pentium Pro CPUs ist der L2-Cache auf dem Prozessormo- dul untergebracht und damit nicht mehr vom Chipsatz ab- haengig. Moderne Systeme koennen eigentlich alle mit 4GB RAM umgehen - zumindest theoretisch. Sind alle Speicherbaenke aber voll bestueckt, so kenne ich man- ches Board, was nicht mehr stabil arbeitet. Da kommen dann aber auch noch andere Dinge wie Waermeentwicklung und Stromversorgung etc. ins Spiel. Mit Cacheable Area hat das alles nichts mehr zu tun - diese Problematik sollte heute nicht mehr anzutreffen sein.

Danke dir für die ausfühliche Erklärung.

Gruesse, Thomson

Gruß und schönen Tag Joachim

-- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH)

On 19 May 2003 at 13:26, Heinz W. Pahlke wrote:

Hallo,

On 19-May-2003 Daniel Bauer wrote:

...

Ich werde in der nächsten Zeit dieses auch an der Primergy testen, wenn dort ebf. der gleich Effekt auftritt ... Naja, dann kann ich nur noch raten immer einen Steckplatz frei zu lassen ;)

Nein, das Handbuch zu lesen :-)

Ich hatte hier einen Rechner, der verfuegte zwar ueber vier Steckplaetze, aber abhaengig von der Groesse und Stueckelung ;-) der RAM-Bausteine konnten mal drei und mal vier Steckplaetze genutzt werden.

Hallo Heinz, davon habe ich nichts lesen können in der Beschreibung, aber wie ich auch schon Thomson geschrieben habe: Auf einer anderen Primergy habe ich 8 x 128 MB drin und auch die rennt, auf der 2. habe ich 16 x 32 MB und die zeigt die gleichen Symptome wie das Gigabyte Modell. Werd auf jeden Fall bescheid sagen ;) Daniel Gruß Daniel

On 19 May 2003 at 17:03, h.pahlke@nexgo.de wrote:

Hallo,

On 19-May-2003 Daniel Bauer wrote:

...

davon habe ich nichts lesen können in der Beschreibung, aber wie ich auch schon Thomson geschrieben habe:

Auf einer anderen Primergy habe ich 8 x 128 MB drin und auch die rennt, auf der 2. habe ich 16 x 32 MB und die zeigt die gleichen Symptome wie das Gigabyte Modell.

Vielleicht lohnt sich auch, mal die Firmware-Versionen zu vergleichen bzw. bei den Herstellern nach Updates zu schauen. Meinem jetzigen DFI-Board musste ich auch erst einmal ein solches Bugfix spendieren.

Hallo Heinz, habe ich bei beiden Maschinen aus verschiedenen Gründen schon gemacht. Jetzt liegt halt noch ein 256 MB Steinchen rum ;) Ich finde es sicherlich merkwürdig und 1 GB RAM wäre schon ok, aber vielleicht kann ich damit auch nochmal einen anderen Rechner testen, habe bei einem A7V 1,5 GB eingebaut und einen "fehlerhaften" Riegel ausgemacht, ich werde den nochmals alleine überprüfen, vielleicht taugt der ja noch ;) Gruß Daniel