Rechnerzeit läuft langsamer während des Brennvorgangs
Hallo, ich bin auf ein recht merkwürdiges Problem gestoßen (SuSE Linux 9.0): Während des Brennens des Images (nicht während des Lead-Out etc.) läuft die Systemzeit ca. 4x zu langsam. Dies tritt sowohl bei cdrecord als auch cdrdao auf. Ausprobiert habe ich es als user mit K3B und shell-basiert sowie als root shell-basiert. Immer wieder das gleiche Problem. Im Anschluss kann ich jedes Mal die Zeit neu einstellen. Woran kann das liegen? In den Logs habe ich nichts hilfreiches gefunden. Nur auf solche Meldungen kann ich mir keinen Reim machen: [...] Mar 29 15:38:00 client2 resmgr[803]: accepted connection from user chsch Mar 29 15:38:00 client2 resmgr[803]: disconnect from chsch Mar 29 15:38:00 client2 resmgr[803]: accepted connection from user chsch Mär 29 15:38:00 client2 k3b: resmgr: server response code 502 Mar 29 15:38:00 client2 resmgr[803]: disconnect from chsch Mar 29 15:38:00 client2 resmgr[803]: accepted connection from user chsch Mär 29 15:38:00 client2 k3b: resmgr: server response code 502 Mar 29 15:38:00 client2 resmgr[803]: disconnect from chsch [...] Vielen Dank schon mal. Tschüs, Christian
Am Dienstag, 30. März 2004 14:08 schrieb Christian Schneider:
Hallo,
ich bin auf ein recht merkwürdiges Problem gestoßen (SuSE Linux 9.0):
Während des Brennens des Images (nicht während des Lead-Out etc.) läuft die Systemzeit ca. 4x zu langsam. Dies tritt sowohl bei cdrecord als auch cdrdao auf. Ausprobiert habe ich es als user mit K3B und shell-basiert sowie als root shell-basiert. Immer wieder das gleiche Problem.
Im Anschluss kann ich jedes Mal die Zeit neu einstellen.
Woran kann das liegen? In den Logs habe ich nichts hilfreiches gefunden. Nur auf solche Meldungen kann ich mir keinen Reim machen:
[...] Mar 29 15:38:00 client2 resmgr[803]: accepted connection from user chsch Mar 29 15:38:00 client2 resmgr[803]: disconnect from chsch Mar 29 15:38:00 client2 resmgr[803]: accepted connection from user chsch Mär 29 15:38:00 client2 k3b: resmgr: server response code 502 Mar 29 15:38:00 client2 resmgr[803]: disconnect from chsch Mar 29 15:38:00 client2 resmgr[803]: accepted connection from user chsch Mär 29 15:38:00 client2 k3b: resmgr: server response code 502 Mar 29 15:38:00 client2 resmgr[803]: disconnect from chsch [...] Vieleicht mal mit hdparm schauen ob die umask ausgeschaltet ist oder ausschalten. Viele Grüße, Heinz Dittmar
Hallo, Am Dienstag, 30. März 2004 20:35 schrieb Heinz Dittmar:
Am Dienstag, 30. März 2004 14:08 schrieb Christian Schneider:
Hallo,
Während des Brennens des Images (nicht während des Lead-Out etc.) läuft die Systemzeit ca. 4x zu langsam. Dies tritt sowohl bei cdrecord als auch cdrdao auf. Ausprobiert habe ich es als user mit K3B und shell-basiert sowie als root shell-basiert. Immer wieder das gleiche Problem.
Im Anschluss kann ich jedes Mal die Zeit neu einstellen.
Woran kann das liegen? In den Logs habe ich nichts hilfreiches gefunden. Nur auf solche Meldungen kann ich mir keinen Reim machen:
[...] Mar 29 15:38:00 client2 resmgr[803]: accepted connection from user chsch Mar 29 15:38:00 client2 resmgr[803]: disconnect from chsch Mar 29 15:38:00 client2 resmgr[803]: accepted connection from user chsch Mär 29 15:38:00 client2 k3b: resmgr: server response code 502 Mar 29 15:38:00 client2 resmgr[803]: disconnect from chsch Mar 29 15:38:00 client2 resmgr[803]: accepted connection from user chsch Mär 29 15:38:00 client2 k3b: resmgr: server response code 502 Mar 29 15:38:00 client2 resmgr[803]: disconnect from chsch [...]
Vieleicht mal mit hdparm schauen ob die umask ausgeschaltet ist oder ausschalten. Viele Grüße, Heinz Dittmar
Zunächst: Sollte es vielleicht "unmask" heißen? Vielleicht könntest du mir noch ein paar Anhaltspunkte geben, da ich nicht verstehe, was ich da machen soll und wie das Problem/die Meldungen mit hdparm gelöst werden könnten? Hier ist die Ausgabe von hdparm (ausgeführt als user!): $ /sbin/hdparm /dev/cdrecorder /dev/cdrecorder not supported by hdparm Beim DVD-Laufwerk erhält man in der Ausgabe: "unmaskirq = 0 (off)". Da bei den beiden Lw. nicht mal dma eingeschaltet ist, glaube ich nicht, dass dann standardmäßig eine Option aktiviert wird, bei der Warnungen in der man page stehen?! Tschüs, Christian
Am Mittwoch, 31. März 2004 12:38 schrieb Christian Schneider:
Hallo,
Am Dienstag, 30. März 2004 20:35 schrieb Heinz Dittmar:
Am Dienstag, 30. März 2004 14:08 schrieb Christian Schneider:
Hallo,
Während des Brennens des Images (nicht während des Lead-Out etc.) läuft die Systemzeit ca. 4x zu langsam. Dies tritt sowohl bei cdrecord als auch cdrdao auf. Ausprobiert habe ich es als user mit K3B und shell-basiert sowie als root shell-basiert. Immer wieder das gleiche Problem.
Im Anschluss kann ich jedes Mal die Zeit neu einstellen.
Woran kann das liegen? In den Logs habe ich nichts hilfreiches gefunden. Nur auf solche Meldungen kann ich mir keinen Reim machen:
[...] Mar 29 15:38:00 client2 resmgr[803]: accepted connection from user chsch Mar 29 15:38:00 client2 resmgr[803]: disconnect from chsch Mar 29 15:38:00 client2 resmgr[803]: accepted connection from user chsch Mär 29 15:38:00 client2 k3b: resmgr: server response code 502 Mar 29 15:38:00 client2 resmgr[803]: disconnect from chsch Mar 29 15:38:00 client2 resmgr[803]: accepted connection from user chsch Mär 29 15:38:00 client2 k3b: resmgr: server response code 502 Mar 29 15:38:00 client2 resmgr[803]: disconnect from chsch [...]
Vieleicht mal mit hdparm schauen ob die umask ausgeschaltet ist oder ausschalten. Viele Grüße, Heinz Dittmar
Zunächst: Sollte es vielleicht "unmask" heißen?
Vielleicht könntest du mir noch ein paar Anhaltspunkte geben, da ich nicht verstehe, was ich da machen soll und wie das Problem/die Meldungen mit hdparm gelöst werden könnten?
Hier ist die Ausgabe von hdparm (ausgeführt als user!):
$ /sbin/hdparm /dev/cdrecorder /dev/cdrecorder not supported by hdparm
Beim DVD-Laufwerk erhält man in der Ausgabe: "unmaskirq = 0 (off)". Da bei den beiden Lw. nicht mal dma eingeschaltet ist, glaube ich nicht, dass dann standardmäßig eine Option aktiviert wird, bei der Warnungen in der man page stehen?! Natürlich DMA muss on sein, unmaskirq off. Sonst kann irq vom cdrecorder eine höhere Priorität besitzen. Viele Grüße, Heinz Dittmar
Hallo, Am Mittwoch, 31. März 2004 14:05 schrieb Heinz Dittmar:
Natürlich DMA muss on sein, unmaskirq off. Sonst kann irq vom cdrecorder eine höhere Priorität besitzen.
Ich habe deinen Rat befolgt und DMA aktiviert. Diesmal lief das Brennen (jedenfalls mit cdrecord) problemlos durch, ohne dass die Uhr sich verstellt hat. Allerdings brachte DMA nur teilweise Linderung: Während des _Einlesens_ einer CD mit cdrdao ist eine Differenz von 8 Sekunden zwischen System- und Hardwarezeit aufgetreten (Systemzeit geht jetzt nach). :-( In /var/log/messages erschien diese interessante Meldung, während cdrdao gelesen hatte: Apr 1 14:43:56 client2 kernel: spurious 8259A interrupt: IRQ7. Irgendeine Idee? Danke schon mal für deine Hilfe!
Viele Grüße, Heinz Dittmar
Tschüs, Christian
Am Donnerstag, 1. April 2004 15:12 schrieb Christian Schneider:
Hallo,
Am Mittwoch, 31. März 2004 14:05 schrieb Heinz Dittmar:
Natürlich DMA muss on sein, unmaskirq off. Sonst kann irq vom cdrecorder eine höhere Priorität besitzen.
Ich habe deinen Rat befolgt und DMA aktiviert. Diesmal lief das Brennen (jedenfalls mit cdrecord) problemlos durch, ohne dass die Uhr sich verstellt hat.
Allerdings brachte DMA nur teilweise Linderung: Während des _Einlesens_ einer CD mit cdrdao ist eine Differenz von 8 Sekunden zwischen System- und Hardwarezeit aufgetreten (Systemzeit geht jetzt nach). :-( Hast du den DMA auch auf maximale was Mutterboard oder CD-Brenner, je nach dem, wo die Beschränkung liegt, konfiguriert.
In /var/log/messages erschien diese interessante Meldung, während cdrdao gelesen hatte:
Apr 1 14:43:56 client2 kernel: spurious 8259A interrupt: IRQ7. Was für ein Rechner ist das ? Was für ein Kernel benutzt du ?
Irgendeine Idee? Viele Grüße, Heinz Dittmar
Am Donnerstag, 1. April 2004 17:05 schrieb Heinz Dittmar:
Am Donnerstag, 1. April 2004 15:12 schrieb Christian Schneider:
Hallo,
Am Mittwoch, 31. März 2004 14:05 schrieb Heinz Dittmar:
Natürlich DMA muss on sein, unmaskirq off. Sonst kann irq vom cdrecorder eine höhere Priorität besitzen.
Ich habe deinen Rat befolgt und DMA aktiviert. Diesmal lief das Brennen (jedenfalls mit cdrecord) problemlos durch, ohne dass die Uhr sich verstellt hat.
Allerdings brachte DMA nur teilweise Linderung: Während des _Einlesens_ einer CD mit cdrdao ist eine Differenz von 8 Sekunden zwischen System- und Hardwarezeit aufgetreten (Systemzeit geht jetzt nach). :-(
Hast du den DMA auch auf maximale was Mutterboard oder CD-Brenner, je nach dem, wo die Beschränkung liegt, konfiguriert.
Ich habe mit Yast (an hdparm habe ich mich nicht rangetraut, weil ich nicht 100%-ig wußte, welche Optionen ich nehmen sollte) den DMA-Modus "DMA an (Standardmodus)" gewählt. Damit wurde für die Laufwerke UltraDMA/33 aktiviert, mehr ist ohnehin nicht möglich (alternativ gäbe es nur noch DMA/16 oder UltraDMA/16 zur Auswahl).
In /var/log/messages erschien diese interessante Meldung, während cdrdao gelesen hatte:
Apr 1 14:43:56 client2 kernel: spurious 8259A interrupt: IRQ7.
Was für ein Rechner ist das ? Was für ein Kernel benutzt du ?
Welche Infos brauchst du speziell zum Rechner? MoBo: Asus P4PE CPU: Pentium 4 2400MHz CD-Recorder: LITE-ON LTR-52246S Kernel: 2.4.21-199-default (SuSE 9.0 Standard-Kernel) Das Problem trat übrigens unter SuSE Linux 8.1 noch nicht auf und ich glaube, da war noch nicht mal DMA eingeschaltet.
Irgendeine Idee?
Viele Grüße, Heinz Dittmar
Tschüs, Christian
* Donnerstag, 01. April 2004 um 18:45 (+0200) schrieb Christian Schneider:
Kernel: 2.4.21-199-default (SuSE 9.0 Standard-Kernel)
SuSE 9.0 und "Rechnerzeit langsam/schnell/falsch" -- da geht bei mir eine
Warnlampe an und auf der steht "desktop".
Entferne doch mal "desktop" aus den Boot-Optionen.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Am Donnerstag, 1. April 2004 18:45 schrieb Christian Schneider:
Am Donnerstag, 1. April 2004 17:05 schrieb Heinz Dittmar:
Am Donnerstag, 1. April 2004 15:12 schrieb Christian Schneider:
Hallo,
Am Mittwoch, 31. März 2004 14:05 schrieb Heinz Dittmar:
Natürlich DMA muss on sein, unmaskirq off. Sonst kann irq vom cdrecorder eine höhere Priorität besitzen.
Ich habe deinen Rat befolgt und DMA aktiviert. Diesmal lief das Brennen (jedenfalls mit cdrecord) problemlos durch, ohne dass die Uhr sich verstellt hat.
Allerdings brachte DMA nur teilweise Linderung: Während des _Einlesens_ einer CD mit cdrdao ist eine Differenz von 8 Sekunden zwischen System- und Hardwarezeit aufgetreten (Systemzeit geht jetzt nach). :-(
Hast du den DMA auch auf maximale was Mutterboard oder CD-Brenner, je nach dem, wo die Beschränkung liegt, konfiguriert.
Ich habe mit Yast (an hdparm habe ich mich nicht rangetraut, weil ich nicht 100%-ig wußte, welche Optionen ich nehmen sollte) den DMA-Modus "DMA an (Standardmodus)" gewählt. Damit wurde für die Laufwerke UltraDMA/33 aktiviert, mehr ist ohnehin nicht möglich (alternativ gäbe es nur noch DMA/16 oder UltraDMA/16 zur Auswahl). In einer root-console kannst du nachschauen was dein CD-Brenner maximal kann. : hdparm -i /dev/hd(x) bzw. hdparm -I /dev/hd(x) . Das (x) steht für je nachdem wo der CD-Brenner angeschlossen ist (b,c,oder d). Damit kannst du herausfinden was dein Brenner maximal kann Das selbe gilt natürlich auch für die Festplatte z.B. hdparm -i /dev/hda für die erste Festplatte.
In /var/log/messages erschien diese interessante Meldung, während cdrdao gelesen hatte:
Apr 1 14:43:56 client2 kernel: spurious 8259A interrupt: IRQ7. Liegt vermutlich am neuen Kernel. Der Fehler tritt bei mir auch ab und zu auf, ohne negative Einwirkungen. Ich habe es bei mir immer auf den veralteten Chip-Satz geschoben. Bei mir tritt die Fehler-meldung mit 2.6.4-xx.x-default auf. Da du ja einen Moderneren Rechner hast (siehe unten), kann es daran ja nicht liegen.
Was für ein Rechner ist das ? Was für ein Kernel benutzt du ?
Welche Infos brauchst du speziell zum Rechner?
MoBo: Asus P4PE Kann vermutlich auch (U)DMA 66 und 100, oder vieleicht auch 133. CPU: Pentium 4 2400MHz CD-Recorder: LITE-ON LTR-52246S
Kernel: 2.4.21-199-default (SuSE 9.0 Standard-Kernel)
Das Problem trat übrigens unter SuSE Linux 8.1 noch nicht auf und ich glaube, da war noch nicht mal DMA eingeschaltet.
Irgendeine Idee? Viele Grüße, Heinz Dittmar
Hallo! Am Donnerstag, 1. April 2004 19:47 schrieb Andreas Koenecke:
* Donnerstag, 01. April 2004 um 18:45 (+0200) schrieb Christian Schneider:
Kernel: 2.4.21-199-default (SuSE 9.0 Standard-Kernel)
SuSE 9.0 und "Rechnerzeit langsam/schnell/falsch" -- da geht bei mir eine Warnlampe an und auf der steht "desktop".
Wo bekommt man diese Lampen her? Ich könnte auch gut so eine gebrauchen. ;-)
Entferne doch mal "desktop" aus den Boot-Optionen.
Treffer! Unter gleichen Versuchsbedingungen trat beim Booten mit "desktop" und dem Einlesen einer CD mit cdrdao eine Zeitdifferenz von 9 Sekunden ein (inklusive der "spurios 8259A interrupt" Meldung), beim Booten ohne "desktop" war es nur eine Sekunde (ohne die Meldung). Optimal ist das zwar immer noch nicht, aber ich denke, damit lässt es sich leben.
Gruß
Andreas
Vielen Dank! Tschüs, Christian
Am Donnerstag, 1. April 2004 20:02 schrieb Heinz Dittmar:
Am Donnerstag, 1. April 2004 18:45 schrieb Christian Schneider:
Am Donnerstag, 1. April 2004 17:05 schrieb Heinz Dittmar:
Am Donnerstag, 1. April 2004 15:12 schrieb Christian Schneider:
Hallo,
Am Mittwoch, 31. März 2004 14:05 schrieb Heinz Dittmar:
Natürlich DMA muss on sein, unmaskirq off. Sonst kann irq vom cdrecorder eine höhere Priorität besitzen.
Ich habe deinen Rat befolgt und DMA aktiviert. Diesmal lief das Brennen (jedenfalls mit cdrecord) problemlos durch, ohne dass die Uhr sich verstellt hat.
Allerdings brachte DMA nur teilweise Linderung: Während des _Einlesens_ einer CD mit cdrdao ist eine Differenz von 8 Sekunden zwischen System- und Hardwarezeit aufgetreten (Systemzeit geht jetzt nach). :-(
Hast du den DMA auch auf maximale was Mutterboard oder CD-Brenner, je nach dem, wo die Beschränkung liegt, konfiguriert.
Ich habe mit Yast (an hdparm habe ich mich nicht rangetraut, weil ich nicht 100%-ig wußte, welche Optionen ich nehmen sollte) den DMA-Modus "DMA an (Standardmodus)" gewählt. Damit wurde für die Laufwerke UltraDMA/33 aktiviert, mehr ist ohnehin nicht möglich (alternativ gäbe es nur noch DMA/16 oder UltraDMA/16 zur Auswahl).
In einer root-console kannst du nachschauen was dein CD-Brenner maximal kann. : hdparm -i /dev/hd(x) bzw. hdparm -I /dev/hd(x) . Das (x) steht für je nachdem wo der CD-Brenner angeschlossen ist (b,c,oder d). Damit kannst du herausfinden was dein Brenner maximal kann Das selbe gilt natürlich auch für die Festplatte z.B. hdparm -i /dev/hda für die erste Festplatte.
[...] DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 *udma2 [...] Auch laut technischen Daten im Netz unterstützen sowohl Brenner als auch DVD-Laufwerk jeweils maximal Ultra-DMA Mode 2. D.h., dass momentan mit UltraDMA/33 alles, was MoBo (s.u.) und Laufwerke hergeben, eingestellt ist.
In /var/log/messages erschien diese interessante Meldung, während cdrdao gelesen hatte:
Apr 1 14:43:56 client2 kernel: spurious 8259A interrupt: IRQ7.
Liegt vermutlich am neuen Kernel. Der Fehler tritt bei mir auch ab und zu auf, ohne negative Einwirkungen. Ich habe es bei mir immer auf den veralteten Chip-Satz geschoben. Bei mir tritt die Fehler-meldung mit 2.6.4-xx.x-default auf. Da du ja einen Moderneren Rechner hast (siehe unten), kann es daran ja nicht liegen.
Was für ein Rechner ist das ? Was für ein Kernel benutzt du ?
Welche Infos brauchst du speziell zum Rechner?
MoBo: Asus P4PE
Kann vermutlich auch (U)DMA 66 und 100, oder vieleicht auch 133.
Handbuch: "IDE: 2 x UltraDMA 100/66/33 connectors"
CPU: Pentium 4 2400MHz CD-Recorder: LITE-ON LTR-52246S
Kernel: 2.4.21-199-default (SuSE 9.0 Standard-Kernel) [...] Viele Grüße, Heinz Dittmar
Tschüs, Christian
Am Freitag, 2. April 2004 16:04 schrieb Christian Schneider:
Am Donnerstag, 1. April 2004 20:02 schrieb Heinz Dittmar:
Am Donnerstag, 1. April 2004 18:45 schrieb Christian Schneider:
Am Donnerstag, 1. April 2004 17:05 schrieb Heinz Dittmar:
Am Donnerstag, 1. April 2004 15:12 schrieb Christian Schneider:
Hallo,
Am Mittwoch, 31. März 2004 14:05 schrieb Heinz Dittmar:
Natürlich DMA muss on sein, unmaskirq off. Sonst kann irq vom cdrecorder eine höhere Priorität besitzen.
Ich habe deinen Rat befolgt und DMA aktiviert. Diesmal lief das Brennen (jedenfalls mit cdrecord) problemlos durch, ohne dass die Uhr sich verstellt hat.
Allerdings brachte DMA nur teilweise Linderung: Während des _Einlesens_ einer CD mit cdrdao ist eine Differenz von 8 Sekunden zwischen System- und Hardwarezeit aufgetreten (Systemzeit geht jetzt nach). :-(
Hast du den DMA auch auf maximale was Mutterboard oder CD-Brenner, je nach dem, wo die Beschränkung liegt, konfiguriert.
Ich habe mit Yast (an hdparm habe ich mich nicht rangetraut, weil ich nicht 100%-ig wußte, welche Optionen ich nehmen sollte) den DMA-Modus "DMA an (Standardmodus)" gewählt. Damit wurde für die Laufwerke UltraDMA/33 aktiviert, mehr ist ohnehin nicht möglich (alternativ gäbe es nur noch DMA/16 oder UltraDMA/16 zur Auswahl).
In einer root-console kannst du nachschauen was dein CD-Brenner maximal kann. : hdparm -i /dev/hd(x) bzw. hdparm -I /dev/hd(x) . Das (x) steht für je nachdem wo der CD-Brenner angeschlossen ist (b,c,oder d). Damit kannst du herausfinden was dein Brenner maximal kann Das selbe gilt natürlich auch für die Festplatte z.B. hdparm -i /dev/hda für die erste Festplatte.
[...] DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 *udma2 [...]
Auch laut technischen Daten im Netz unterstützen sowohl Brenner als auch DVD-Laufwerk jeweils maximal Ultra-DMA Mode 2. Ja das ist OK. Das einzige was du noch machen kannst, in den 32 bit Modus zu schalten. Defaultmäsig stehen die immer auf 16 bit.
D.h., dass momentan mit UltraDMA/33 alles, was MoBo (s.u.) und Laufwerke hergeben, eingestellt ist.
In /var/log/messages erschien diese interessante Meldung, während cdrdao gelesen hatte:
Apr 1 14:43:56 client2 kernel: spurious 8259A interrupt: IRQ7.
Liegt vermutlich am neuen Kernel. Der Fehler tritt bei mir auch ab und zu auf, ohne negative Einwirkungen. Ich habe es bei mir immer auf den veralteten Chip-Satz geschoben. Bei mir tritt die Fehler-meldung mit 2.6.4-xx.x-default auf. Da du ja einen Moderneren Rechner hast (siehe unten), kann es daran ja nicht liegen.
Was für ein Rechner ist das ? Was für ein Kernel benutzt du ?
Welche Infos brauchst du speziell zum Rechner?
MoBo: Asus P4PE
Kann vermutlich auch (U)DMA 66 und 100, oder vieleicht auch 133.
Handbuch: "IDE: 2 x UltraDMA 100/66/33 connectors" Würde auf alle fälle schauen dass die Festplatten mit 100MHz laufen und im 32 bit Modus. Neue Festplatten können alle 100MHz, manche sogar 133MHz. Das kannst du genau so nachschauen wie oben erwähnt.
CPU: Pentium 4 2400MHz CD-Recorder: LITE-ON LTR-52246S
Kernel: 2.4.21-199-default (SuSE 9.0 Standard-Kernel)
[...]
Viele Grüße, Heinz Dittmar
Am Freitag, 2. April 2004 16:58 schrieb Heinz Dittmar:
Am Freitag, 2. April 2004 16:04 schrieb Christian Schneider:
Am Donnerstag, 1. April 2004 20:02 schrieb Heinz Dittmar:
Am Donnerstag, 1. April 2004 18:45 schrieb Christian Schneider:
Ich habe mit Yast (an hdparm habe ich mich nicht rangetraut, weil ich nicht 100%-ig wußte, welche Optionen ich nehmen sollte) den DMA-Modus "DMA an (Standardmodus)" gewählt. Damit wurde für die Laufwerke UltraDMA/33 aktiviert, mehr ist ohnehin nicht möglich (alternativ gäbe es nur noch DMA/16 oder UltraDMA/16 zur Auswahl).
In einer root-console kannst du nachschauen was dein CD-Brenner maximal kann. : hdparm -i /dev/hd(x) bzw. hdparm -I /dev/hd(x) . Das (x) steht für je nachdem wo der CD-Brenner angeschlossen ist (b,c,oder d). Damit kannst du herausfinden was dein Brenner maximal kann Das selbe gilt natürlich auch für die Festplatte z.B. hdparm -i /dev/hda für die erste Festplatte.
[...] DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 *udma2 [...]
Auch laut technischen Daten im Netz unterstützen sowohl Brenner als auch DVD-Laufwerk jeweils maximal Ultra-DMA Mode 2.
Ja das ist OK. Das einzige was du noch machen kannst, in den 32 bit Modus zu schalten. Defaultmäsig stehen die immer auf 16 bit.
Ich glaube, das hebe ich mir für später auf. Momentan läuft das System (dank DMA und dem weggelassenen "desktop" Boot-Parameter) ziemlich gut und v.a. stabil.
MoBo: Asus P4PE
Kann vermutlich auch (U)DMA 66 und 100, oder vieleicht auch 133.
Handbuch: "IDE: 2 x UltraDMA 100/66/33 connectors"
Würde auf alle fälle schauen dass die Festplatten mit 100MHz laufen und im 32 bit Modus. Neue Festplatten können alle 100MHz, manche sogar 133MHz. Das kannst du genau so nachschauen wie oben erwähnt.
Die Platte wurde standardmäßig schon während der Installation mit UltraDMA/100 konfiguriert. Nur bei den CD/DVD-Laufwerken war DMA nicht eingeschaltet. Der 32 bit Modus ist, soweit ich sehen kann, bei keinem IDE Laufwerk aktiviert. Ich glaube, das Experimentieren damit spare ich mir noch, v.a. wo ich gerade kein aktuelles Backup habe.
Viele Grüße, Heinz Dittmar
Besten Dank. Tschüs, Christian
participants (3)
-
Andreas Koenecke -
Christian Schneider -
Heinz Dittmar