[dAImon]

Probabil aţi mai întâlnit şi voi minunăţia asta : introduci un disc zgâriat în unitate, Windowsul (XP, of course) întâlneşte erori de citire, CRC, şi trece unitatea în modul PIO. Observabil imediat prin faptul că orice transfer de fişiere va duce la 100% processor usage. Am găsit pe net următoarea soluţie pentru revenire :

Citeaza

Run REGEDIT. Go to the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}

It has subkeys like 0000, 0001, 0002, etc. Normally 0001 is the primary IDE channel, 0002 the secondary, but other numbers can occur under certain circumstances. You have to go through these subkeys and check the DriverDesc value until you find the proper IDE channel.

Delete MasterIdDataChecksum or SlaveIdDataChecksum, depending on whether the device in question is attached as master or slave, but it can't actually hurt to delete both. Reboot. The drive DMA capabilities will be redetected.

Note that many CD and DVD drives only use UDMA-2, because their data rate is much lower than that of a hard disk. This is normal and no reason to worry.


2006-01-19 – Horst Schülke wrote that it is sufficient to empty the content of these values. But you can also delete the values entirely. Windows will automatically recreate them anyway, with new content.

Citeaza

There are three keys that work together:

MasterDeviceTimingMode
MasterDeviceTimingModeAllowed
UserMasterDeviceTimingModeAllowed

Each bit in these values means a transfer mode that the device may or may not be capable of. Somewhere at MS some of these bits can be looked up.

MasterDeviceTimingMode:

This is the actual mode the device is running at.

MasterDeviceTimingModeAllowed:

This entry may be the problem child. Peter wrote: "Normally not present in XP, it is created as a reaction to errors. This entry has absolute priority." However, there are doubts whether this is the absolute truth. It is still not entirely clear where this entry comes from. Erasing it or setting it to a DWORD value of 0xFFFFFFFF, rebooting, re-enabling DMA mode, and rebooting again seems to have solved the problem in some cases.

UserMasterDeviceTimingModeAllowed:

This entry contains the user's setting, manually entered in the advanced device properties. Has the same structure as MasterDeviceTimingMode. This entry appears when the user sets a limited mode manually, such as PIO only.

Another key that seems to create the problem is MasterIdDataChecksum.

All these parameters also exist for the slave drive as SlaveDeviceTimingMode, etc.

Am ataşat un fişier (extensia corectă este .vbs) care ar trebui să facă treaba asta în mod automat. Problema este că rularea lui nu are întotdeauna efect. Mai ştiti o altă aplicaţie care poate reseta modul de acces la unităţile de stocare?

Fisiere atasate

•  resetdma.txt (3.01K)
  Number of downloads: 5

[argv]

Numai tie ti se pot intampla chestii din astea

[argv]

Poate te ajuta asta:

http://www.onthegoso..._setting_nt.htm

[harald]

daimon, la Jan 23 2008, 12:50 PM, a spus:

Am ataşat un fişier (extensia corectă este .vbs) care ar trebui să facă treaba asta în mod automat. Problema este că rularea lui nu are întotdeauna efect. Mai ştiti o altă aplicaţie care poate reseta modul de acces la unităţile de stocare?

Eu zic că mai bine ştergi manual cheile respective. Aşa ai ocazia să-ţi aduci aminte ce unităţi optice şi ce hard-disk-uri au mai trecut prin sistemul tău cu diverse ocazii mai ştergi o placă video veche rămasă pe-acolo, descoperi că Windows-ul a inversat magistralele IDE şi o consideră primary pe aia la care scrie "secondary" pe mufa de pe placa-bază etc.

Oricât de frumoasă şi utilă e o chestie automată pentru înlocuit chei de Registry, tot mai eficient e să-ţi bagi singur nasul acolo.

Argv, la Jan 23 2008, 12:54 PM, a spus:

Numai tie ti se pot intampla chestii din astea

Cred că la peste jumătate din calculatoarele la care poţi intra în Device Manager, ai să te sperii cu ce setări de controller IDE merg. Am văzut HDD de 160 GB accesat în mod PIO