|
|
About this capture | ||||||||||||||
The Windoze XP IDE Transfer Mode Failback “Feature” & Fix
DISCLAIMER
| PREAMBLE
| SYMPTOMS | SOLUTION
DISCLAIMER:
USE AT OWN RISK. There are instructions here for messing with
your Windoze Registry. Stuffing up the
Registry can kill your operating system; if you needed to be told that you
should probably close this page right now.
I don't want to hear back from any n00bz
who stuff up their computer; if you don't know what you're doing in the
Registry, why the fark are you following instructions in some text by some
unknown finkleroy on the internet huh?
If you do know what you're doing, you can easily verify what the
keys in the “Solution” section control using Google and online
resources/forums; I recommend everyone do that to please themselves that I’m
not trying to screw them over. This is a
fix I've found using those same resources plus a lot of trial and error
debunking most theories of this widespread (but generally unknown) issue.
Chipsets? My fix
method has worked perfectly on EVERY machine I've used it on myself: about a
dozen makes and models with various CPUs and BIOSes (I can only recall AMI & AWARD) and
chipsets (I can only
recall Intel & VIA) and differing versions of WinXP & its Service
Packs. The list includes 3 of my own
computers, friends’ machines, laptops & desktop machines at work. (The
latter number is growing steadily since I work on an I.T. helpdesk and the
corporate fleet just changed over to multimedia machines with DVD readers,
sometimes writers, and the outdated firmware tends to trigger the crippling PIO
compatibility mode.)
n00bz. If it doesn't work for you feel free to tell
me about it. Although I must concede
there may be a possibiliy it won't work on EVERY chipset, you must be prepared
that I quietly assume you're an idiot or somethin’ since I don't know any
better. (^.^) Even with the explicit instructions at the
bottom of this page sitting beside their keyboards, I still to this day look
over the shoulders of people who totally balls it up. So, you know, whatever.
Addendum 2007: This page is ancient. I haven't updated this in years. Reason: I am a slack b@$t@rd of course. Some of the information could be expanded to
cover the slight deviations seen in newer hardwares, and I could retract a
couple of the opinions I've stated but have since opined otherwise, and I could
upload my shiny golden script that automatically corrects any desktop
regardless of the nuances of certain hardwares and the effect those brands have
on the location of the critical Registry entries. But, as aforementioned, I am a slack b@$t@rd
after all.. and the site is probably going to be deleted soon by my ex-ISP..
so.. bah. Anyway, the meat of my old
ramblings is still essentially correct; enough to make the slight deviations obvious
for most people who can muck about in their Registry. Based on the feedback I still get daily via
the feedback form I judge this
to be the case anyway. Thank you everyone, by the way. I'm astounded how
many mails still come thru from this ramble spewed forth one bored Sunday
morning in 2004; I feel those very emotive thanks deep in the left ventricle of
my heart, for I too was once stabbing myself in the eye in furious frustration using
the screwdriver I'd just opened the case with again because of this stoopud Windoze "feature", heh. I try to answer many of them, but even if I
don't have time to respond to all rest assured I do get around to reading every
one. So, again, thanks. :`)
PREAMBLE:
I’m going
to blog on first about the problem, since so few people (even in the I.T.
profession), seem to be aware of it.
What is the PIO failback “feature”?
Most users don’t realise a Windoze routine is simply operating as
designed, attributing the symptoms instead to faulty hardware, or sweeping it
under the “just one of those things” rug when it happens to other people, or
the “what the fark!” pedestal when it happens to themselves. Just scroll to the Solution at the bottom if you’re impatient for the actual fix;
this is my blog so nyaa. (ô.ó)
For
several years on several machines (ever
since shortly after purchasing my first dvd drive in fact) I’d been
complaining to computer retailers & suppliers, and hardware development
gurus, but the most constructive suggested I’d ever receive was “reinstall
Windows.” Argh, that catch-cry became
the bane .. of my freakin' .. existance. (>.<)'
For
optimum transfer efficiency, the IDE channels should be using UDMA (Ultra
Direct Memory Access) and not PIO Mode (Programmed Input/Output). But Windoze frequently decides on many systems
to use the latter.
So what’s the diff between the major transfer mode
groupings? It’s most importantly about
what hardware in your system is providing the grunt for data transfers:
|
Mode |
Explanation |
|
PIO |
Programmed Input / Output The CPU manages the transfer of data between system
memory and the storage device.
Supports bus speeds up to 16MB/sec, if your processor can keep
up. Nothing built this century should
be using PIO. |
|
DMA |
Direct
Memory Access The
bus-mastering system controller (a.k.a. DMA controller) is programmed to
manage the transfer, freeing the CPU to do other stuff while the DMA
controller does its thing. It’ll also
support bus speeds up to about 16MB/sec.
These days DMA is ok for non-storage devices (eg: video cards) but
only really old hard drives should show a DMA or Multiword DMA transfer mode
in effect. |
|
UDMA |
Ultra
Direct Memory Access A
modern version of the DMA method. It’s
the current standard for high speed storage devices with bus speeds starting at
16MB/sec and now surpassing 100MB/sec. |
For the
"best" possible efficiency & compatibility, when Windoze first
detects new hardware it assigns a transfer mode to it. Old drives will use DMA or Multi-word DMA,
newer drives use Ultra DMA. Completely
farked drives will use PIO. Within each
method are numbered subgroupings, starting at 1 for the most basic
compatibility standard and higher numbers for better/more recent standards as
new hardware capability comes along (ie: UDMA Mode 5 is more recent than UDMA
Mode 1).
What do the transfer modes mean in real terms? It’s (most significantly) all about speed:
|
Mode |
Industry Specification |
Max Bus Speed |
|
PIO Mode 0 |
ATA (ATA-1) |
3.33 MB/sec |
|
DMA Mode 0 or
Multiword DMA Mode 0 |
ATA |
4.16 MB/sec |
|
PIO Mode 1 |
ATA |
5.22 MB/sec |
|
PIO Mode 2 |
ATA |
8.33 MB/sec |
|
PIO Mode 3 |
ATA-2 |
11.1 MB/sec |
|
DMA Mode 1 or
Multiword DMA Mode 1 |
ATA-2 |
13.3 MB/sec |
|
PIO Mode 4 |
ATA-2 |
16.6 MB/sec |
|
DMA Mode 2 or
Multiword DMA Mode 2 |
ATA-2 |
16.6 MB/sec |
|
Ultra DMA Mode 0 |
ATA/ATAPI-4 |
16.6 MB/sec |
|
Ultra DMA Mode 1 |
ATA/ATAPI-4 |
25.0 MB/sec |
|
Ultra DMA Mode 2,
UDMA33 or ATA/33 |
ATA/ATAPI-4 |
33.3 MB/sec |
|
Ultra DMA Mode 3 |
ATA/ATAPI-5 |
44.4 MB/sec |
|
Ultra DMA Mode 4,
UDMA66 or ATA/66 |
ATA/ATAPI-5 |
66.6 MB/sec |
|
Ultra DMA Mode 5,
UDMA100 or ATA/100 |
ATA/ATAPI-6 |
100 MB/sec |
|
…yes this list is now out of date -Duck |
|
|
A
maddeningly understated problem arises with how Windoze locks down what
it thinks is the best transfer mode
for each of your IDE devices. After the
initial hardware detection, XP keeps a running tally of the number of times a
drive fails access attempts. When this cummulative number reaches six,
it reduces the compatibility mode and tries again. At first XP will try downgrading within the
same transfer method, eg: from UDMA Mode 4 to UDMA Mode 3, but when these
sublevels run out it will assume DMA is no longer available and permanently
fail back to PIO Mode, because the transfer mode tweaking is one way
(downwards).
It’s a
handy no-fuss workaround (like most Windozey programming philosophies) if you
happen to have an aging hard drive where the magnetic surface is starting to
fail, or the electronics are becoming a little dodgy, or the mob who assembled
your various system components are n00btards, but what about optical media?! The characteristcs of these drives change
with each new read surface inserted in the tray!
Bad CDs
and DVDs are triggering this failback all
the time all over the world without users even noticing they’ve been
hamstrung; it’s usually a while (or not at all) before they make a connection
with the symptoms described in the next section. I once randomly audited 15 machines on the
floor I worked on; all but two were stuck on PIO.
What constitutes a bad (optical) read that can trigger access
errors and the PIO failback? These
fairly routine causes equate to frequent potential harm to your IDE config:
|
Cause |
Explanation |
|
Scratched |
Ever used those library or rental discs that look like
they were cleaned with sandpaper? Humans have no respect. And while I'm on
the subject, what the hell is that funky gelatinous bio-splatter on every
third disc anyway? (¬_¬) Stoopid
monkey. |
|
Incorrectly burnt |
Unfinished
/ buffer under-run / table of contents glitched / laser power fluctuations. |
|
Incompatibly burnt |
Open
session / multi-session / re-writeable media being used in a different drive
(trying to open DVD-RW on certain older DVD-R drives is almost as common as
the scratched disc cause). |
|
Dubious firmware |
The
media descriptors pre-written on the blank discs of each format (eg: DVD-R,
DVD+R, DVD-RW, DVD+RW) are supposed to be industry standard, but it seems
lately there is some flexibilty in these standards(?) Different disc brands seem to fail in
certain drives, even though the drive is supposed to be compatible with that
particular drive. Updating the drive’s firmware to the most recent (ie:
released in the last few months) has stopped the PIO failback problem
returning for a couple of DVD drives I’ve played with that kept tripping on
particular brands of disc. |
|
Wrong strap |
80-conductor
ATA cables shouldn’t be shorter than 25cm.
Neither 80-conductor nor 40-conductor straps should be longer than
45cm. 40-conductor cables can be
optionally swapped for 80s on devices higher than the ATA/33 standard
(33MB/sec) but shouldn’t be used at all past ATA/66. You can usually tell (at least with AMI and
AWARD BIOS) that a slow cable is attached to a fast device when you see “no
80 connector cable installed” during the POST (Power On Self Test). |
|
Devices with greatly
different access times share one IDE port |
Rather
than share an IDE cable and port, most technogeeks (including this one)
recommend having your hard drive(s) on the primary port (IDE1) and your
CD/DVD reader(s)/writer(s) on the seconary port (IDE2), especially when
video-DVD playback or disc burning is involved. So too, if you combine old drives and new
drives in a system, group them according to their speeds; don’t strap a
thoroughbred onto an old nag. If
you're having problems copying on-the-fly from one optical drive to another,
that might be a reason to break the rule of thumb and put one of them (the
reader rather than the burner) over on the first IDE port with the primary
hard drive. Think of the data queuing
logistics within the system. |
SYMPTOMS:
When should you be sus that PIO Mode has become your permanent
transfer method on one or all of your IDE devices?
|
Symptom |
Explanation |
|
PIO Mode is specified
in the Device Manager and refuses to switch back to UDMA Mode. (IF YOU DON’T HAVE THIS SYMPTOM, DON’T BOTHER
WITH MY FIX, DINGLEBERRY) |
Well yeah, that’s a giveaway. There are settings in the Device Manager’s
IDE/ATAPI Configuration that are supposed to let you select between “PIO”
(why!) and “DMA if available.” “PIO”
is automatically specified here after a transfer mode failback. You can’t change it back to “DMA if
available” though: according to the system, DMA is now not available
so the “Current Transfer Mode” will permanently & infuriatingly say
“PIO”. (If you can’t find the Device
Manager, go back and read the Disclaimer section again, will ya? And
be careful. More detailed info is
in the Solution section at the bottom if you still want to proceed.) |
|
Explorer.exe locks up
and/or crashes during file transfers. Desktop icons & Taskbar crash &
vanish for ½ min. Some Sys Tray icons don’t reappear. |
I
frequently move files from an incoming drive to an archive drive prior to
burning, as this performs a quick defrag of the highly segmented files that
have been downloading. With large
files this incapacitates Explorer for six or seven minutes at a time (based
on a 200MB file) if PIO is engaged.
Even refreshing the views of other apps is a supreme test of patience
with non-CPU intensive programs bowing before the lumbering efforts of
Explorer, redrawing the screen line by painstaking line. |
|
All tasks (not just
Explorer) accessing the drives seem highly CPU intensive. |
Explorer
is a good example again, using 90-95% of my main CPU during file transfers
instead of 3-5%. Nero tends to use
about the same instead of about 10-15% during DVD burns. MediaPlayer frequently hit 99% when trying
to play back video files situated on a PIO drive. (Also,
before killing the Windoze “Prefetch” - more on that issue which can also trigger a failback later - certain file
types the cursor touched in Explorer stayed file-locked for about 30-60
seconds before they could be moved / deleted / renamed. The Prefetch and PIO issues seem to inflame
each other.) |
|
Buffer under-run
failures during burns, or the buffer continually runs dry on burnproof
drives. |
When
the hard drives fail to PIO mode, my 25MB/sec drive is reduced to 2½MB/sec
and my 16MB/sec drive is reduced to 1½MB/sec.
(Nero was used to benchmark the drives.) Since DVD 1x spin is 1.3MB/sec this was
causing all sorts of malarkey during burns, with burning programs locking up,
or the resultant disc being damaged.
It was taking 1½ hours to burn 4.7GB and another hour to verify, and
heaven help me if I wanted to use the PC for anything else in the
meantime! 1x spin burn should only
take 54 minutes to write and 12 mins to verify on my system, and the PC can
do most other things besides videos and high-end computer games at the same
time. |
|
Severely reduced
video-DVD playback quality. |
I’ve
never owned a standalone DVD player; I’m a little leery of them as I’ve
always watched DVDs on a multimedia PC connected to a black-matrix telly. A
killer app called TV Tool also cleans the signal so it looks better than any
“real” player I’ve seen. At one time,
before I figured out the PIO glitch, I almost bought a real player because
for a month all my videos played back jerkily and had a distracting ¼-second
pause+jump every few seconds so you couldn’t even get used to the reduced
quality. At the same time, an ANNOYING
staccato popping sensation was broadcast from the sound system. It clicked in
time with the flashing LED on the DVD drive.
Grr! Argh! |
SOLUTION:
Force Windoze to redetect the drive’s
data transfer capability.
There is a checksum associated
with every storage device. If you
invalidate the checksum, Windoze must redetect the device’s capabilities,
including its preferred data transfer mode!
Oh yes. (o.O)
This solution talks about using DEVICE MANAGER and
REGISTRY EDITOR. If you’re a n00b and don’t know how to load and
use them, please reconsider messing with them as they are both powerful apps
that can kill your operating system.
But… whatever… if you still want to continue… Here’s how to load the apps
when you need to (you don’t have to start clicking right this instant, read the
whole damn instruction list first, will ya, sheesh):
To load the Device Manager (3 different ways to try; one or all
paths may be restricted depending on your access level):
To load the Registry Editor (again, this may be restricted
depending on your access level):
In DEVICE MANAGER..
Go to..
IDE ATA/ATAPI controllers > Primary IDE
Channel > Advanced Settings tab
IDE ATA/ATAPI controllers > Secondary
IDE Channel > Advanced Settings tab
Notes: If you don’t have the Advanced Settings tab, check
if you’re on an Intel chipset using a background app usually visible in the
System Tray called Intel Accelerator.
People I’ve seen with this thing installed never have the Advanced
Settings tab. Also, according to their
Registry settings, their DMAEnabled flag (see below) has never been
compromised. Are they imune to the PIO
failback? I’m still trying to find out.
It’s up to you if you want to find and use this proggy for your Intel
chipset (eg: IBM T40 laptop and Acer Veriton 3500/3600 series), but I’ve also
noticed inexplicable chicanery on these same machines when running the Intel
Accelerator, such as the video card suddenly failing back to safe mode in the
middle of a session, BSODs when returning from a reduced power mode,
application errors during swapfile flushes…
I can’t confirm any correlation yet -- may simply be a co-inkydink.
Modify..
Transfer Mode = DMA if available
Notes: If the Current
Transfer Mode is already DMA / Multi-word DMA / Ultra DMA mode then you are
reading the wrong fix: you don’t have the PIO failback glitch. Once you have set Transfer Mode to DMA and go back into the same settings, you’ll
probably notice the Current Transfer Mode
hasn’t changed and is still stuck on PIO.
You need to restart to see if it truly worked.
Reboot..
Notes: After you’ve rebooted, go back into the IDE
settings and see if DMA is available now.
If the Current Transfer Mode
is still PIO, then you were probably hit with the PIO failback glitch
after disk access errors, and not a simple DMA outage. Ensure your IDE settings still specify “DMA
if available” then proceed to the RegHack in the next set of instructions:
In REGISTRY EDITOR..
Go to..
[HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\Scsi\Scsi
Port 0]
[HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\Scsi\Scsi
Port 1]
Notes: These keys
are called SCSI solely for historic reasons;
Modify..
DMAEnabled = 1 (DWORD value)
Notes: This is
usually set to zero after a PIO failback.
Some systems may change your “1” to a “3” after a reboot - it seems to
depend on how heavy your computer is already with DMA-enabled hardware. One of my machines’ drives default to DMA3
and doesn’t seem to act any differently, but I can’t find a reference to this
behaviour anywhere online.. shrug.. The
machine in question is bristling with lots of tacked on hardware: 2 HDDs, CD,
DVD, 3D video with TV-Out, wireless keyb/mouse, onboard sound, network, 4 USB
devices.
Go to..
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}\0001]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}\0002]
Notes: 0001 is the key for IDE2 and 0002 is the key for IDE1, go
figure. The string associated to MatchingDeviceId will tell you for sure
what you’re looking at (ie: “primary_ide_channel” or
“secondary_ide_channel”. If you don’t
know what those basic nuts & bolts terms are, I really really really think
you should stop what you’re doing RIGHT NOW.)
Also, you don’t need to remember that entire long-winded numbered key,
4D36-etc… I just scan the fourth octet of the first dozen Class keys for “6A” (as underlined in the blue text above).
Delete..
MasterIdDataCheckSum
SlaveIdDataCheckSum
Notes: If you don’t
see a checksums associated with a particular slot, then there’s no device
detected. If you can’t work out which
slot goes with which drive, well, that gives me misgivings about you messing
about in RegEdit, but it doesn’t matter if you simply delete all the checksums
in the 0001 and 0002 keys (there can be a max of two devices for IDE1, two for
IDE2). At the next login, WinXP will
notice something is up when the detected devices don’t match the checksum flags
and the device’s capabilities will be re-examined.
Delete..
MasterDeviceDetectionTimeout
SlaveDeviceDetectionTimeout
Notes: Delete these
keys if present, if you have a device that is not detecting or doesn’t already
have a checksum associated with it. If
there’s a timeout=1 flag, Windoze doesn’t bother detecting for a device in that
slot at login. Again, this is just a
detection flag, so it doesn’t matter if you delete them willy-nilly; if there
truly is no device there, the timeout key will simply be recreated at next
login. If you still have access to a
hard drive that has a timeout flag like this, chances are it’s running in the
crippled “Dos Compatibility Mode” where XP is basically fudging your connection
to it in real time. I think you are told
this under Device Manager > Disk Drives > (appropriate device) >
General Properties tab, and also with a warning message at login. If it is a newly installed device, you may
have also forgotten to assign a partition and/or drive letter to it using the
Microsoft Management Console: Start > right-click My Computer > Manage
> Storage folder > Disk Management console. Not recommended for n00bs! Very dangerous!
Create..
ResetErrorCountersOnSuccess = 1 (DWORD
value)
Notes: If this flag
is present, the running tally of device access failures is reset to zero
after every successful access. (I
mentioned earlier that a transfer mode downgrade is triggered after a sixth cummulative
failure.) Hopefully, this will lengthen
the time before your next PIO failback as you’ll need six consecutive
failures to trigger it.
ADDENDUM – Microsoft finally released a "patch"
for the failback behaviour. However,
after minimal scrutiny all this atapi.sys upgrade
really does is change the trigger requirement of six cummulative fails to six
consecutive, which is what we've been doing for ages with this
reseterrorcounters flag anyway.
*sigh* :o/
Reboot..
Notes: After you’ve rebooted, go back into the IDE
settings and see if DMA is available now.
If the Current Transfer Mode
is still PIO, then I wash my hands of you. (splash splash) See that? I’m washing my hands.
Other things I resorted to before
finding that fix..
Several times I successfully
uninstalled (not simply disabled) a couple of machines’ IDE controllers using
the Device Manager (XP auto-reinstalls missing hardware drivers at login). I don’t normally recommend this method,
because on some machines - especially but not exclusively laptops for some
reason - it’s been a pain in the sphincter afterwards; BSODs (Blue Screens Of
Death) after the initial reboot, or failure to redetect the IDE controller for
several reboots (unnecessarily freaks out the computer’s n00by owner), or the
problem simply not going away after reboot.
On some administered computers in work places users even need special
rights for the Add New Hardware Wizard to function, a major headache when
you’ve just
The 2nd method I used for a long while was to swap the
dvd-reader and cd-burner which shared my secondary IDE port. This involves turning off the power, popping
the lid of the computer and changing the slave/master jumper pins on the two
devices. This kinda fiddly workaround is
handy if you have access into the hardware, but don’t have administrator access
into the Windoze management areas such as Device Manager. (Hmm, should you be opening the machine if
someone has decided you’re not even eligible for admin access to your local
login?) It won’t help you if you don’t
have two devices on the same IDE strap that you can reverse, ie: if one of them
is your primary boot partition (C: drive) which isn’t allowed to move. Also, some brands of drive hate relinquishing
their Master status and lock up your system during POST (Power On Self Test) if
you have the audacity to make them a Slave.
If you’re only using two drives in your entire system
(seems somehow inadequate to this geek, but many people who buy their computers
off the shelf only have one hard drive and one CD or DVD drive) and the problem
is not affecting your primary boot drive, only the secondary drive, your
DVD or whatever, then just move that second drive. If it’s a slave on the same strap as the hard
disk, change the jumper pins on it to become a Master and attach it to its own
strap on the secondary IDE port. If it’s
already on its own strap, change its jumper pins to become a Slave and attach
it to the same strap as the hard drive.
Forseeable problems with this: you might have to go buy a 40-connector
or 80-connector IDE strap if you don’t already have two straps in the system;
certain hard drive brands hate having
other certain other brands’ devices slaved to them (in my experience Seagate OEM
drives are most notorious for this). So to, other devices hate becoming a Slave, as described above.
Don’t forget to
ground yourself before poking around under the bonnet. If you don’t own a grounding bracelet (you
can get one from Dick Smith / Radio Shack / etc) just rest an arm on the metal
of the case or something before you start touching stuff, and avoid direct
contact with metal contacts (eg: pins) on circuit boards at all times. A human body can carry thousands of static
volts of electricity! Zap - toasted
computer innards. Also make sure you’re
doing all this with the computer turned off, and unplugged. The motherboard is
still charged if the mains are still feeding juice into the powerunit! The
power unit is still live even when the power button on the case is turned
off. The danger to yourself isn’t too
great, but again the computer could get fried with you rippin’ cords out and
stuff.
I got sick of repeatedly doing this and later I discovered
the restrapping and Master-Slave reversals (ie: repositioning of IDE devices)
was invalidating the device checksums in the Registry, which soon lead to the
RegEdit solution. (My machines are
stacked like a tower; it’s a pain in the bott-bott to unstack and open them.)
Meh, that's it for now... Thanks for everyone's feedback
so far. People have been most estatic to
finally put their finger on this Windoze chicanery. Hope this rant continues to restore sanity to
others.
Official
MS links acknowledging PIO shenanigans:
http://www.microsoft.com/whdc/hwdev/tech/storage/IDE-DMA.mspx
http://support.microsoft.com/?kbid=817472
DISCLAIMER
| PREAMBLE
| SYMPTOMS | SOLUTION
Editorial &
“Ninja Duck” artwork © 2003-2008 Brett Murtha
