Ultra-DMA einfach nicht möglich

Hallo Forumsgemeinde!

Ich bin neu hier und habe gleich ein verdammt nerviges Problem, an dem ich nun schon 3 Tage die Zeit verschwende und ich hoffe inständigst, dass ihr mir dabei helfen könnt.

Ich habe zu meiner Seagate 380021A (Primary Master) noch zusätzlich eine Samsung SP1614N dazugehängt (Secondary Master). So weit so gut. Nur leider schaffe ich es nicht, die Samsung in den Ultra-DMA-Modus 5 zu bekommen. Trotz "Übertragungsmodus: DMA, wenn verfügbar", beharrt Windows auf PIO. Ich habe auch schon die IDE-Controller zig Mal deinstalliert und rebootet, nur leider ohne Erfolg. Wenn ich die Samsung als Slave zu der Seagate hänge, laufen beide im PIO-Modus.
Die Festplattengröße wird sowohl im BIOS als auch in Windows korrekt erkannt, nur leider ist eben der Zugriff sehr langsam und mit viel CPU-Auslastung verbunden.

Mein System:

Athlon 2100+
512 MB RAM (PC 2700)
MSI KT3 ULTRA ARU (MS-6380E)
Seagate 380021A 80GB
SAMSUNG SP1614N 160GB
Asus DVD E-616 ROM, Lite-On 40x12x48 (jeweils Slave, jedoch derzeit versuchsweise abgehängt)
Enermax 350W Netzteil

WinXP Prof. SP1

Das BIOS ist das aktuellste - 6380ev57. Ich habe auch schon hutil laufen lassen und es wurden keine Fehler entdeckt. Probehalber habe ich noch ATA133 aktiviert und die neuesten 4in1-Treiber habe ich auch installiert (4.51)

Was mir aufgefallen ist, dass die Platte im BIOS erkannt wird (Name sowie Größe), jedoch bei Autodetect keine Zylinder, Köpfe usw. eingetragen werden (wie bei der Barracuda). Ob das eine Rolle spielt?
Weiters habe ich gelesen, dass das Board mit der Größe der neuen Platte dank des aktuellen BIOS keine Probleme haben sollte, nur woran kann es liegen, dass Windows auf PIO beharrt?

Verzweifelte Grüße

P.S.: die IDE-Kabel habe ich farblich richtig verbunden (Motherboard: blau, Master: schwarz, Slave: grau) und auch schon einmal ausgetauscht.

Hi,

das IDE/ATA-Kabel scheint defekt oder zu lang zu sein. Tausche es aus und deinstalliere den IDE-Controller erneut. Nach dem Reboot sollte die Platte dann im UDMA-5 Modus laufen.

Woran liegts? Sobald Windows Übertragungsfehler feststellt, schaltet es nach insgesamt 6 Zeitüberschreitungs- oder CRC-Fehlern jeweils einen Modus herunter. Dies geht soweit bis entweder der PIO-Modus erreicht wurde oder die Übertragungsfehler nicht mehr auftreten.

Nur die erneute Installation des IDE-Controllers oder das manuelle Ändern einiger Registryeinträge schaffen (zeitweise) Abhilfe. Schuld an diesen Übertragungsfehlern könnte beispielsweise (wie von mir vermutet) ein defektes IDE/ATA-Kabel oder der fehlerhafte IDE/ATA-Treiber des Chipsatzherstellers sein. Passiert dies trotz des wechselns des Kabels nach einer gewissen Zeit wieder, so solltest du probeweise den Standard-Zweikanal-PCI-IDE-Controller von Microsoft installieren.

Und übrigens, es ist egal, wo welches Laufwerk am Kabel hängt. Also, du kannst das als Master konfigurierte Laufwerk auch in der Mitte und das als Slave konfigurierte auch am Ende des Kabls betreiben. Nur bei einer Single-Drive-Configuration (da sollte das Laufwerk am Ende angeschlossen werden) und beim Cable-Select-Mode ist die Anordnung vorgeschrieben.

CU

Hallo Madnex,

das IDE-Kabel habe ich bereits mit dem der Seagate getauscht - mit dem Ergebnis, dass die Barracuda weiterhin problemlos im UDMA5 Modus läuft, die Samsung jedoch nicht (PIO). Am Kabeln liegt es also nicht.
Deinen Vorschlag mit dem Deinstallieren der IDE-Controller habe ich schon so oft versucht, jedoch immer ohne Erfolg - Windows richtet die Samsung immer wieder im PIO-Modus ein.

Sicher, dass die Platte richtig gejumpert ist? Wenn Laufwerke alleine am Kabel hängen, müssen sie am Ende angeschlossen werden. Versuchs mal mit dem Standard-Zweikanal-PCI-IDE-Controller von Microsoft.

Ja, ist auf Master gejumpert und hängt am schwarzen Stecker. Hatte versuchsweise auch schon Cable-Select probiert, leider auch ohne Erfolg.
Wie installiere ich den von dir angesprochenen "Standard-Zweikanal-PCI-IDE-Controller von Microsoft"? Mir installiert Windows immer automatisch den VIA IDE-Bus Controller, der allerdings auch von Microsoft ist (den Treiberinformationen zufolge). Oder meintest du diesen?

Schau mal hier: klick!

Bei dir siehst du halt keinen NVIDIA sondern einen VIA Treiber. Aber die Schritte sind die selben.

Vielen Dank. Werde es sofort ausprobieren wenn ich heimkomme.

So, habe den Tipp nun befolgt und den Standard-Zweikanal-PCI-IDE-Controller eingerichtet. Nur Leider ohne jegliche Verbesserung.

Was mir aufgefallen ist: in der Ereignisanzeige sehe ich ein paar Mal im 10sec Abstand die ATAPI-Fehlermeldung: "Das Gerät \Device\Ide\IdePort1 hat innerhalb der Fehlerwartezeit nicht geantwortet." Das ist wahrscheinlich der Grund, warum Windows auf PIO zurückschraubt - nur warum antwortet das Gerät nicht?

Dann wird das Laufwerk wohl defekt sein. Teste es doch mal, wenn möglich, an einem anderen Rechner. Wenn es dort genauso ist, ist die Platte defekt.

Original geschrieben von Madnex
Dann wird das Laufwerk wohl defekt sein. Teste es doch mal, wenn möglich, an einem anderen Rechner. Wenn es dort genauso ist, ist die Platte defekt.

Zum Vergrößern anklicken....

Hatte ich mir schon vorgenommen, denn normal kann das nicht sein (auch wenn hutil keine Fehler meldet). Jedenfalls vielen Dank für deine Bemühungen.

ich glaube dein problem heisst via-bug, liegt an der rev. der SB und zu dem thema kann man soviel googlen, dass einem schon schlecht wird.

greets
tobi

Original geschrieben von Beschleunigen
ich glaube dein problem heisst via-bug, liegt an der rev. der SB und zu dem thema kann man soviel googlen, dass einem schon schlecht wird.

greets
tobi

Zum Vergrößern anklicken....

klär mich mal auf: Ich dachte bisher immer, der berühmte via-bug mit ide-Problemen beträfe die 686B-Southbrige. Dachte eigentlich, die neuen SBs am Vlink sind i.O., bzgl. VT8235 und VT8237 kann ich aus eigener Erfahrung sprechen, dass die prima sind. Auf dem MSI sitzt ein VT8233A, k.A. obs da Probleme mit gibt, kann mich aber nicht erinnern, was über ein systematisches Problem gehört zu haben.......

Original geschrieben von Beschleunigen
ich glaube dein problem heisst via-bug, liegt an der rev. der SB und zu dem thema kann man soviel googlen, dass einem schon schlecht wird.

greets
tobi

Zum Vergrößern anklicken....

vielleicht solltest du selbst mal ein bisschen googeln und dich über den via southbridge-bug informieren.

larsbo hat es ja schon angesprochen, die probleme betrafen via's 686b baustein, das war noch zu einer
zeit als north- und southbridge per pci gekoppelt waren.

aber warum googeln, wenn man hier bei p3d quasi an der quelle sitzt, siehe

http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=987081379


mfg
cruger

Sprich am Via-Chip wird es wahrscheinlich nicht liegen?

Soooooda - habe jetzt die Platte umgetauscht und siehe da: sie läuft jetzt im UDMA6-Modus. So lob ich mir das.
Nochmals vielen Dank für die Tipps und Vorschläge!

Original geschrieben von Brettljausn
Hallo Forumsgemeinde!

Ich bin neu hier und habe gleich ein verdammt nerviges Problem, an dem ich nun schon 3 Tage die Zeit verschwende und ich hoffe inständigst, dass ihr mir dabei helfen könnt.

Ich habe zu meiner Seagate 380021A (Primary Master) noch zusätzlich eine Samsung SP1614N dazugehängt (Secondary Master). So weit so gut. Nur leider schaffe ich es nicht, die Samsung in den Ultra-DMA-Modus 5 zu bekommen. Trotz "Übertragungsmodus: DMA, wenn verfügbar", beharrt Windows auf PIO. Ich habe auch schon die IDE-Controller zig Mal deinstalliert und rebootet, nur leider ohne Erfolg. Wenn ich die Samsung als Slave zu der Seagate hänge, laufen beide im PIO-Modus.
Die Festplattengröße wird sowohl im BIOS als auch in Windows korrekt erkannt, nur leider ist eben der Zugriff sehr langsam und mit viel CPU-Auslastung verbunden.

Mein System:

Athlon 2100+
512 MB RAM (PC 2700)
MSI KT3 ULTRA ARU (MS-6380E)
Seagate 380021A 80GB
SAMSUNG SP1614N 160GB
Asus DVD E-616 ROM, Lite-On 40x12x48 (jeweils Slave, jedoch derzeit versuchsweise abgehängt)
Enermax 350W Netzteil

WinXP Prof. SP1

Das BIOS ist das aktuellste - 6380ev57. Ich habe auch schon hutil laufen lassen und es wurden keine Fehler entdeckt. Probehalber habe ich noch ATA133 aktiviert und die neuesten 4in1-Treiber habe ich auch installiert (4.51)

Was mir aufgefallen ist, dass die Platte im BIOS erkannt wird (Name sowie Größe), jedoch bei Autodetect keine Zylinder, Köpfe usw. eingetragen werden (wie bei der Barracuda). Ob das eine Rolle spielt?
Weiters habe ich gelesen, dass das Board mit der Größe der neuen Platte dank des aktuellen BIOS keine Probleme haben sollte, nur woran kann es liegen, dass Windows auf PIO beharrt?

Verzweifelte Grüße

P.S.: die IDE-Kabel habe ich farblich richtig verbunden (Motherboard: blau, Master: schwarz, Slave: grau) und auch schon einmal ausgetauscht.

Zum Vergrößern anklicken....

Tja bei meinem System hatte ich vor kurzem genau den gleichen Fehler. Meine Masterplatte (SP1614N) lief im U-DMA-Mode und meine Slaveplatte 4G120J6 ließ auf einmal nicht mehr in was höheres als PIO-Mode bewegen. Ich habe die VIA-Treiber neu installiert, ich habe das Kabel gewechselt, habe alles möglich im BIOS gecheckt. Nichts brachte Besserung... bis mir einfiel, daß ich sowas auf meinem alten Board auch schonmal hatte... und zwar genau nachdem ich damals zum Spiel den Patch v1.1 eingespielt hatte, hatte ich diesmal den Patch v1.3 eingespielt. In meiner Verzweiflung habe ich Windows auf den Wiederherstellungspunkt vor dem Patcheinspielen zurückgesetzt und siehe da: Die Platten liefen wieder beide friedlich im UMA-Modus, wie es soll. Einzige Erklärung: Crytech muß mit der Patchinstallation versucht haben, irgendeinen DRM-Scheiß ins System zu fuschen, was bei mir schief ging...

SirThor schrieb:

aus diesem Posting

Tja bei meinem System hatte ich vor kurzem genau den gleichen Fehler. Meine Masterplatte (SP1614N) lief im U-DMA-Mode und meine Slaveplatte 4G120J6 ließ auf einmal nicht mehr in was höheres als PIO-Mode bewegen. Ich habe die VIA-Treiber neu installiert, ich habe das Kabel gewechselt, habe alles möglich im BIOS gecheckt. Nichts brachte Besserung... bis mir einfiel, daß ich sowas auf meinem alten Board auch schonmal hatte... und zwar genau nachdem ich damals zum Spiel den Patch v1.1 eingespielt hatte, hatte ich diesmal den Patch v1.3 eingespielt. In meiner Verzweiflung habe ich Windows auf den Wiederherstellungspunkt vor dem Patcheinspielen zurückgesetzt und siehe da: Die Platten liefen wieder beide friedlich im UMA-Modus, wie es soll. Einzige Erklärung: Crytech muß mit der Patchinstallation versucht haben, irgendeinen DRM-Scheiß ins System zu fuschen, was bei mir schief ging...

Zum Vergrößern anklicken....

Bei mir ists mit den Versuchen genau das Gleiche, FarCry ist auch auf der Platte, aber an den Patches liegt es nicht... wird meine ST3200822A wohl defekt sein...