Pesky ATA/66 disk caddies

In an earlier entry, I mentioned the problems I had when upgrading an old ATA66 drive to a shiny new ATA133 drive. The old drive had been in an ATA66 removable disk caddy, and it didn’t behave too well at ATA133.

I resolved that problem by simply uninstalling the drive caddy and connecting the new drive directly to the motherboard via a decent ATA133 cable. (HDTach still shows the performance as a little choppy, but it’s not bad, averaging around 50 MBps transfer rate and peaking at 78 MBps.)

Well, I had a 120 GB drive die a few days ago, also in a caddy. Maxtor sent me a replacement, and once again, it was ATA133. Exactly the same problem as before – really bad performance, making the PC close to unusable.

I didn’t want to give up another caddy, so I buckled down and did a bit of research. It’s been well documented that Windows XP will drop down to PIO mode for hard disk transfers after six DMA timeouts have occurred. However, my problem was different – I suspected transfer errors (which result in a retry) rather than timeouts.

You can check which mode Windows is currently using for a drive by going into System / Hardware / Device Manager, then opening IDE / ATAPI controllers and double-clicking the Primary or Secondary IDE controller. Under Advanced Settings, you’ll see the current transfer mode used for each drive.

I knew from the PIO/DMA discussions that the registry key HKEY_LOCAL_MACHINE \ SYSTEM \ ControlSet001 \ Control \ Class \ {4D36E96A-E325-11CE-BFC1-08002BE10318} was responsible for configuring the ATA IDE driver. However, documentation of the various fields was hard to come by. I eventually figured it out by trial and error.

This key has a Default value of “IDE ATA/ATAPI controllers”, which is a handy way to check you’re in the right place. If you’re searching for it manually, it’s usually about the 10th class down in the (gigantic) list of classes from the top, so it’s easy enough to locate.

Inside the key are several numbered sub-keys: 0000, 0001, 0002, etc. 0000 is for the IDE controller, 0001 and 0002 are the primary and secondary interfaces. If you have multiple IDE controllers (e.g. SATA and PATA), then there will be more than three keys here – be careful to modify the correct one! The SATA controller is usually listed before the PATA controller, but you may just need to use trial and error.

Anyway, once you have identified the correct subkey, corresponding to the interface the problematic drive is attached to, you’ll see a few sub-keys:

  • MasterDeviceTimingMode – set to the fastest supported transfer mode when the drive initialises.
  • MasterDeviceTimingModeAllowed – defines what modes are supported by Windows; usually set to 0xFFFFFFFF, but we can tweak it to stop certain modes being used.
  • MasterIdDataCheckSum – I believe Windows uses this to detect when a new drive has been attached to the cable. If you delete this key, it forces Windows to treat the drive as new next time it boots up, and restore full DMA access. This is one way to force a drive that Windows has reduced to PIO mode back to UDMA mode again.

(The same settings also exist with a Slave prefix; which set you modify depends on whether your drive is the master or slave.)

Let’s look at the MasterDeviceTimingModeAllowed value in more detail. This defines a 32-bit mask, allowing up to 32 options to be individually permitted or prohibited. The default value of 0xFFFFFFFF means all supported operations are permitted. By selectively turning off certain bits, we can make Windows avoid using those features. These same bits are reflected in MasterDeviceTimingMode, so that’s a good place to start.

On my UDMA6 drives, MasterDeviceTimingMode was set to 0x20010, which is 0x00020010 in 8-digit hex. I also knew that 0x00002010 was UDMA2. It seemed logical that the in-between positions corresponded to UDMA3 (0x4010), UDMA4 (0x8010) and UDMA5 (0x10010). The 0x10 at the end is probably multi-word transfer, though I haven’t confirmed this.

Right so. To disable, for example, UDMA5 and UDMA6 (ATA100 and ATA133 support respectively), we just need to turn off the appropriate bits in the Allowed mask. Instead of 0xFFFFFFFF, we can use 0xFFFCFFFF. All the other modes up to and including UDMA4 (ATA66) will still be allowed.

My problematic drive was attached to the secondary master IDE interface, so I went ahead and set MasterDeviceTimingModeAllowed for that interface to 0xFFFCFFFF, then rebooted. Sure enough, Device Manager now shows that the drive is running UltraDMA 4 instead of UltraDMA 6. Better, the performance is now usable again, averaging around 20 MB/s transfer rate. I suspect the caddy is still introducing errors (HDTach is a bit choppy still) but it’s hugely better than it was before.

This is crying out for a little applet to let you tweak the individual bits in this mask from a nice GUI. Perhaps I’ll write one if I get some spare time…