Wenn gar nichts mehr geht
oder
Wie man renitente ATAPI-Devices wieder auf Ultra-DMA Kurs bringt

Jeder kennt das: Von einem auf den anderen Tag verhält sich ein Brenner seltsam.

• Die Transferrate beim Lesen bricht zusammen, DVDs ruckeln
• Die Warndioden für den Einsatz von Buffer Underrun Vermeidungstechniken flackern beim Brennvorgang im Dauerfeuer
• 16x Brennen klappt nicht mehr oder dauert so lang, daß man denkt, der brennt ja nur 2x.
• Qualitätsscans zeigen ungewöhnliche Scanverläufe für Rohlinge, die man meint, gut zu kennen. Insbesondere tritt eine PIF 1 Dauermessung auf.

Ursachen sind meist keine erkennbar. Evtl. fällt einem noch mal ein, daß man da vor ein paar Tagen beim Scannen mal 'ne ziemlich grottige DVD hatte, aber in den meisten Fällen bleibt die Ursache unklar, besonders, wenn der Fehler bei einer Festplatte auftritt (siehe z.b. http://www.bm-community.de/ftopic11274.html).

Doch genau eine solche, schlecht lesbare, DVD ist für das Desaster beim DVD-Brenner verantwortlich. Bei Festplatten ist es meist ein defekter Sektor, der später von der Festplattenelektronik "weggemappt" wird. Aber warum?

Windows (ab 2000!), bzw. der ATAPI-Treiber, prüft bei allen Lesevorgängen von Datenträgern permanent u.a. die Zuverlässigkeit der Datenübertragung im System. Kommt es zu Fehlern bei Datenträgerzugriffen, wird nach einiger Zeit oder einigen erfolgosen Zugriffsversuchen in wenigen Schritten die mögliche Übertragungsgeschwindigkeit der zugehörigen Schnittstelle zum Laufwerk reduziert. Hierzu wird ein interner Zähler verwendte, der jeweils nach 6 Fehlern die Übertragungsgeschwindigkeit um eine Stufe herabsenkt.
Benimmt sich ein Laufwerk (bzw. der Datenträger im Laufwerk) im Anschluß wieder "nett", bleibt es bei temporären Einschränkungen (z.B. Herabstufung von Ultra-DMA 5 auf PIO), die vom Anwender über den Geräte-Manager wieder einfach zurückgesetzt werden können. Leider wird der interne Zähler dabei nicht wieder auf "0" zurückgesetzt, so daß beim nächsten Fehler, das Theater wieder von vorne beginnt.

Treten somit Leseprobleme wiederholt auf, wird die Schnittstelle dauerhaft auf PIO zurückgesetzt und die Auswahlmöglichkeit im Datei-Manager "ausgegraut". Wie man im letzteren Fall das Problem beheben kann, wird im nächsten Schritt beschrieben.

Schritt 1: Lösung über den Geräte-Manager
oder:
Eleganz ist nicht alles

Voraussetzung 1: Die Hardware ist in Ordnung, alle Laufwerke sind hardwareseitig richtig verschaltet (ordentliche und festsitzende Kabel, korrekte Master-/Slave-Jumperung, genügend Energie) und auch im BIOS mit allen "Finessen" eingetragen sind (Ultra-DMA Modus, 32bit Datentransfer, etc.).
Voraussetzung 2: Die letzte Datensicherung liegt nicht wesentlich länger als 30 Minuten zurück!!

Dann sollten folgende Schritte in 90% aller Fälle zum Ziel führen:

1. Starte den Geräte-Manager (wer nicht weiß, wie das geht, kauft sich besser einen neuen Rechner )
2. Öffne den Ast IDE ATA/ATAPI-Controller
3. Wähle den IDE-Kanal, an dem das "zu langsame Laufwerk" hängt.
4. Klicke mit der rechten Maustaste auf den IDE-Kanal
5. Wähle "Deinstallieren" und bestätige ein paar Mal mit "JA" und "OK"
6. Fahre den Rechner herunter und starte ihn neu.
7. Stoßgebete können helfen, sind aber nicht zwingend notwendig
8. Melde Dich wieder an und prüfe im Geräte-Manager, ob Dein Eingriff erfolgreich war.

Für den Fall, daß Du erfolgreich warst, klopfe Dir auf die Schulter (sonst tut's ja keiner )
Für den Fall, daß das Laufwerk immer noch beharrlich im PIO-Modus verbleibt, hilft Dir der nächste Teil.

Schritt 2: Hardcore-Registry-Hacking
oder
Die Operation am offenen Hirnstamm

Voraussetzungen: Siehe Schritt 1.

Windows speichert seine Messungen und daraus resultierende "Einschätzungen" zur Qualität der angeschlossenen Datenträgergeräte in der Registry ab. Je nach den dort enthaltenen Werten und verwendeten Parametern läßt sich ein Laufwerk mit der Methode 1 wieder vom PIO-Modus auf den Ultra-DMA-Modus zurücksetzen.

Die Informationen liegen (beim Standard Microsoft IDE ATA/ATAPI-Treiber!!) unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}.
Bei NVIDIA- oder VIA-Chipsätzen (mit eigenen Treibern!!) könnten hier andere Pfade auftreten, die ich nicht kenne und daher hier auch nicht beschreiben kann. Vielleicht läßt sich dort aber eine abgeleitete Technik verwenden.

Die numerischen Unterzweige stellen jeweils den Controller dar, sowie die jeweiligen "Primären" und "Sekundären" IDE-Kanäle.

- 0000 ist dabei der erste Controller (meist IDE ATA/ATAPI)
- 0001 ist der erste primäre Kanal
- 0002 ist der erste sekundäre Kanal

Bei modernen Boards mit SATA Ports kommen dann noch

- 0003 für den zweiten Controller (SATA)
- 0004 ist der zweite primäre Kanal
- 0005 ist der zweite sekundäre Kanal

Wird ein Anschluß im System neu angelegt, ohne daß ein Gerät angeschlossen wird, dann enthält er nur die nachfolgenden Parameter und Werte (mein zweiter SATA-Port ist immer noch leer) für die einzelnen Anschlüsse:

"EnumPropPages32"="storprop.dll,IdePropPageProvider"
"InfPath"="mshdc.inf"
"InfSection"="atapi_Inst_secondary"
"ProviderName"="Microsoft"
"DriverDateData"=hex:00,80,62,c5,c0,01,c1,01
"DriverDate"="7-1-2001"
"DriverVersion"="5.1.2600.2180"
"MatchingDeviceId"="secondary_ide_channel"
"DriverDesc"="Sekundärer IDE-Kanal"
"MasterDeviceType"=dword:00000000
"MasterDeviceDetectionTimeout"=dword:00000001
"MasterDeviceTimingMode"=dword:00000000
"SlaveDeviceType"=dword:00000000
"SlaveDeviceDetectionTimeout"=dword:00000001
"SlaveDeviceTimingMode"=dword:00000000

Ein "renitenter" IDE-Anschluß weist dagegen auch noch weitere Parameter auf. Die nachfolgenden Parameter

- "MasterIdDataCheckSum"
- "MasterDeviceTimingMode"
- "MasterDeviceTimingModeAllowed"
- "UserMasterDeviceTimingModeAllowed"

(die es mit "Slave" auch noch mal für den Slave-Anschluß gibt) sind dabei die Ursache, für das Scheitern von Schritt 1. Ausgelöst wird das dadurch, daß ein interner Fehlerzähler mehr als 6 Fehler festgestellt hat und daher der ATAPI-Treiber eine Stufe heruntergesetzt wird.

Wenn man also alle IDE-Kanäle (im Bezug auf "Master"- und "Slave"-Parameter) auf die nachfolgenden 6 Parameter reduziert:

- "MasterDeviceType"=dword:00000000
- "MasterDeviceDetectionTimeout"=dword:00000001
- "MasterDeviceTimingMode"=dword:00000000
- "SlaveDeviceType"=dword:00000000
- "SlaveDeviceDetectionTimeout"=dword:00000001
- "SlaveDeviceTimingMode"=dword:00000000

dann gibt Windows beim nächsten Systemstart allen IDE ATA/ATAPI/SATA-Geräten die Chance, sich neu mit der Schnittstelle über Timings, Übertragungsraten und dergleichen auszutauschen.

Gibt man nun pro IDE-Kanal noch den Parameter

- "ResetErrorCountersOnSuccess" = dword:00000001

ein, dann wird der von Windows intern verwendete Fehlerzähler beim ersten erfolgreichen Lesevorgang wieder auf "0" gesetzt (was sonst nicht geschieht!!). Hierdurch tritt der Effekt des "Verlangsamens" des IDE-Kanals nicht mehr ganz so häufig auf. Näheres hierzu findet man bei Microsoft.

Wie wichtig ein solcher Artikel gewesen wäre, sieht man übrigens hier.

Hatte das Problem zwar noch nicht, finde aber, das wäre schon einen Sticky wert.

hab ich doch schon gemacht ...

Hab' ich auch schon gemerkt...

Rückschau
oder
Wenn wir gewußt hätten, ...

Ich habe mir heute - so als Nachbrenner - mal die Mühe gemacht und mal einige Threads aus diesem Jahr rausgesucht, in denen die obigen 3 Beiträge hätten hilfreich sein können. Dazu habe ich noch einen Link gefunden, der das ganze Thema auch ziemlich breit erörtert, allerdings - IMHO - etwas unstrukturiert.

Hier die Links...

• Pc braucht kapp eine halbe Stunde um 800 Mb zu entpacken!!!
• Buffer-Level nicht konstant
• Pioneer 111D nur PIO-Mode und kein Flashen möglich
• Warum läuft das DVD-ROM nur im Pio Modus HILFE !!!!!! ?????
• Brennabbruch mit den verschiedensten Programmen
• Samsung SH-W163A

Und hier der Link in die weite Welt...
Das angegebene Programm habe ich mir mal angesehen. Das haut letztlich nur die von mir schon angemerkten Parameter

- "MasterIdDataChecksum"
- "SlaveIdDataChecksum"
- "MasterDeviceTimingModeAllowed"
- "SlaveDeviceTimingModeAllowed"

für Master und Slave weg und gibt im Anschluß eine Erfolgsmeldung aus.

Mal schauen, ob ich mir auch noch ein solches "Tool" baue.

Mir ist es mal passiert dass die Festplatte in den PIO-Modus gefallen ist, das hat den Rechner deutlich spürbar verlangsamt. Das ging sogar soweit, dass Winamp aussetzer gezeigt hat, wenn man Fenster verschoben hat, Spiele haben extrem gelaggt, wenn auf die Festplatte zugegriffen wurde etc.
Hatte das Problem damals mit einer Anleitung aus dem Internet gelöst, soweit ich mich erinnern kann war sie so ähnlich wie der Teil "Schritt 2: Hardcore-Registry-Hacking". So eine Anleitung kann in solch einem Fall echt nützlich sein !

dazu braucht es gar keinen aufregenden tools
man erstelle eine normale textdatei mit dem editor wo das zwischen den ******* drin steht:

**********************
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}\0001\]
"SlaveDeviceTimingMode"=-
"MasterDeviceTimingMode"=-
"MasterIdDataCheckSum"=-
"SlaveIdDataCheckSum"=-
"MasterDeviceTimingModeAllowed"=-
"SlaveDeviceTimingModeAllowed"=-
"UserMasterDeviceTimingModeAllowed"=-
"UserSlaveDeviceTimingModeAllowed"=-
"ResetErrorCountersOnSuccess" = dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}\0002\]
"SlaveDeviceTimingMode"=-
"MasterDeviceTimingMode"=-
"MasterIdDataCheckSum"=-
"SlaveIdDataCheckSum"=-
"MasterDeviceTimingModeAllowed"=-
"SlaveDeviceTimingModeAllowed"=-
"UserMasterDeviceTimingModeAllowed"=-
"UserSlaveDeviceTimingModeAllowed"=-
"ResetErrorCountersOnSuccess" = dword:00000001

***********************
oder alternativ die schlüssel ganz löschen und neu schreiben:




***********************

Windows Registry Editor Version 5.00

[-HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}\0001\]
[-HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}\0002\]

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}\0001\]

MasterDeviceType"=dword:00000000
"MasterDeviceDetectionTimeout"=dword:00000001
"MasterDeviceTimingMode"=dword:00000000
"SlaveDeviceType"=dword:00000000
"SlaveDeviceDetectionTimeout"=dword:00000001
"SlaveDeviceTimingMode"=dword:00000000
"ResetErrorCountersOnSuccess" = dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}\0002\]

MasterDeviceType"=dword:00000000
"MasterDeviceDetectionTimeout"=dword:00000001
"MasterDeviceTimingMode"=dword:00000000
"SlaveDeviceType"=dword:00000000
"SlaveDeviceDetectionTimeout"=dword:00000001
"SlaveDeviceTimingMode"=dword:00000000
"ResetErrorCountersOnSuccess" = dword:00000001

*************************


anschliessend zb. als "hauwechdenpio.reg" oder was auch immer abspeichern (ichtig ist nur die änderung .reg

dann doppelklick auf die datei und alle hier beschriebenen änderungen sind vollzogen

Hallo Luc,

so wie Du das beschreibst, klappt das nur für die ersten beiden Controller.

nörgelpeter

war auch nur als denkanstoss gedacht. ist entstanden, weil bei mir dort die optik hängt- der rest läuft eh über in dieser hinsicht störunanfälliges raid.

mal grade 000x\ in den passenden controller umwandeln sollte hier aber jeder schaffen. und in zukunft reicht dann ein klick

man muß für diese dönekens nun wirklich kein aufwändiges programm schreiben und hat so eine quicki-lösung, ohne sich immer durch die reg hangeln zu müssen