busTRACE Technologies - 1394 Delayed Write Failures Blog

This blog originally started in August of 2003 with details on 1394 delayed write failures that we encountered. We detail below how we discovered the root cause of the failure as well as provide links to firmware updates and driver updates.

Since then, this site has generated quite a bit of traffic and a lot of useful information has been added from others who also encountered delayed write failures. If you are having a delayed write failure with a 1394 hard drive, a resolution to your problem can probably be found below. Unfortunately, there is a lot of information to wade through. This is because there appear to be many reasons for the failure. There are a myriad of causes from bridge chip firmware defects, cable issues, controller problems, speed issues, power management, OS bugs, etc.

Below are a few links from Microsoft (if you have Windows XP SP2) that you might find useful. They are also referenced in the information below. They are placed here for easy access:

http://support.microsoft.com/kb/885464
http://support.microsoft.com/kb/887170

In September of 2005, we added a feedback forum where other users experiencing delayed write failures can add their own comments:

Visit 1394 Delayed Write Feedback Forum

August 1, 2003

Do you own a 1394/FireWire drive and are experiencing "Delayed Write Failures" under Windows 2000 or Windows XP? Do you experience data loss and/or a hard drive lockup when this occurs? If so, read on to learn the similar frustrations one of our developers has experienced.

I own two 1394 hard drives. One is a SmartDisk FireLite 20GB drive while the other is an ATA drive I inserted into an ADS Technologies PYRO 1394 Drive Kit. I use the SmartDisk drive extensively. I purchased it to replace an older model SmartDisk 20GB drive. When experiencing heavy disk activity, at seemingly random times, my drive would lock up and I would get that annoying "Delayed Write Failure" as reported by Windows 2000 and Windows XP. The drive was locked up solid. I would either need to disconnect and reconnect it from the bus or, more typically, I would simply reboot my system. As you can imagine, such a failure can and did result in data loss for me.

With my original SmartDisk drive, this would happen very infrequently. I learned to live with it. With my newer SmartDisk drive, it happened several times a day. Thinking it was a problem just with SmartDisk, I took my reliable ATA drive, placed it into the ADS Technologies box, and tried that. To my surprise, I received the EXACT "Delayed Write Failure".

I was ready to write off 1394 hard drives as being just plain flaky and unreliable and not reliable enough to trust my data. I researched several 1394 drive vendors' WEB sites and some did mention this problem, but they had no idea what was causing it.

Having spent my hard earned money on these drives, I decided to dig deeper and determine the root cause of the failure. Fortunately, I own busTRACE so I was able to capture and analyze the I/O activity going on between my Windows PC and my 1394 hard drive. I started a capture sequence and ran a software app that would often cause this type of drive failure to occur. After a few minutes of trying, I captured the error!

I looked at the specific I/O that was failing and I noticed that Windows was attempting to write out 3FFh sectors (1023 sectors) in a single I/O. This is approximately 512K worth of data in a single I/O. I thought this was interesting as Windows typically does not send an I/O larger than 64K and very rarely above 128K. The I/O eventually timed out but the drive was now "hung" and further communication with the drive was impossible. Windows was left in a state of needing to read/write to the drive, but it couldn't. When Windows cannot flush its buffers, it reports the "Delayed Write Failure" telling you that data may be lost.

512K worth of data in a single I/O was a clue so I wrote a special test app that would read/write starting with 1 sector and keep going up until 1024 sectors. I wanted to find out where the failure boundary was. As it turns out, both of my 1394 drives would crash when the request was larger than 128K. In digging a little deeper, and in talking to various people, this seems to be a known limitation with some (not all!!!) 1394 bridge chips. I was told that a firmware upgrade might/should resolve it.

I searched long and hard for any firmware updates to my SmartDisk and ADS Technologies drives but I couldn't find any. If you know of any such updates, I encourage you to contact me so that I can update this WEB site with that link information. Determined to fix this problem, and get confidence back in 1394 hard drives, I decided to write my own little filter driver to limit I/Os to no larger than 128K.

What has been the result of my driver? Well, in many months of running my SmartDisk drive, I have not seen that Delayed Write Failure again. If you're seeing this failure as well, it is highly likely that you are experiencing the same problem I did.

What can you do to resolve this in your case? For one, contact your drive vendor and/or 1394 enclosure company. They are the ones that should come up with a resolution for you. If they have heard of the problem before, but do not know the root cause, point them to this WEB site. I have described in detail exactly what the problem is. If they have a driver writer on staff, they should be able to easily generate a driver to resolve the problem.

Please do not ask us for our driver. While it works fine in our case, it is only intended as an internal driver and is not something we would consider distributing outside the company. Thank you.

December 1, 2003

Since originally posting this WEB page, we have received a number of e-mails from end users receiving the "Delayed Write" failure with their 1394 drive. In working with some of them, the write failure that they are experiencing is different than the one above. Their drive is able to write > 128K sectors but still fails with delayed write errors intermittently. The cause of their failure is unknown at this time.

If you are reading this because your 1394 drive is failing with delayed writes, and if you are wondering if the > 128K sector failure we see is identical to yours, we are providing a test applet that you can download. This application will read/write 128 sectors sequentially up to 512K sectors. If this applet does NOT generate the delayed write failure, then you are not experiencing the same problem we are. Before using this utility, be sure to backup your entire 1394 drive as delayed write failures can corrupt your drive. You assume all risk by using this software.

Please be sure to review our Terms of Use before downloading our software. After you run the test, please let us know of your results so we can keep this page updated. Click here to download the file 1394Test.exe. It is only 228KB in size and is compatible with Windows 2000 and above.

December 11, 2003

If you are looking for our 1394 stress tester, to see if your drive has the delayed write failure we experience, you can find the details in the "December 1, 2003" section above.

Since we posted our December 1, 2003, update, we have received a number of e-mails from end-users with the results of their test. Our test app does duplicate the failure for a number of users. For them, this indicates that their failure matches our failure and the drive is having problems handling larger than 128K transfers. We have heard rumors that there is a firmware upgrade to fix this but have no official confirmation. If you know more, please let us know.

There are other users that run our test app and it works perfectly with no delayed write failure and no data loss. Even though our test app passes, these users still experience the delayed write failure at other times. In these cases, the root cause of the failure is unknown. Some users have had success by lowering the drive's UDMA speed for 6 down to 5, or even down to 2. To do this requires a utility from the drive vendor. Of course this is not a real solution but at least it might get you past the problem, albeit with a slower drive. That's the latest status as we know it. If you know of any solutions, please let us know and we'll update this page.

December 19, 2003

It is difficult, at times, to determine why you might be experiencing the delayed write failure. It could be a problem on the computer, on the target peripheral, with the 1394 cable, or with the software on your system. Some users, for example, have rectified their delayed write failure by exchanging their 1394 cable. The only real way to analyze the problem is to have a variety of systems, cables, and hard drives to compare against. With access to this equipment, you can usually isolate it down to who is at fault. Of course, getting the party at fault to resolve the issue is a different story.

For those of you that have taken the time to let us know of any additional information you have, we thank you. We hope all of you have success in resolving this particularly nasty problem.

December 31, 2003

1394 hard drives are actually IDE/ATA hard drives put into an external case with a "bridge" chip between the 1394 bus and the IDE/ATA bus. When we talk about the 128K problem above, we are talking about the "bridge" chip being at fault. The IDE/ATA drive inside the case is likely just fine. If our test application passes without failure, then your drive / bridge chip do not have the problem we discovered (as explained above).

January 23, 2004

An end user has pointed us to a WEB site with an actual firmware upgrade that fixed their delayed write failure. This site comes from Macally Peripherals. They actually post a firmware upgrade for their firewire drives that contain the Oxford Semiconductor OXFW911 (revision 3.8). Details are here:

http://www.macally.com/techsupport/drivers.html

Use with caution and use at your own risk. We didn't update our drive firmware (which has the OXFW911 bridge chip) because we purchased from a different vendor and cannot be certain that the update would even work with our drive (let alone render our drive useless). In addition, it is rather annoying that the firmware update requires you to download the Java run-time from Sun (if you don't have it installed already).

February 2, 2004

Another end user has found a resolution to their 1394 delayed write failure. This is with a DVICO kit. If you have such a kit, you can find a software workaround here. It is not clear from reviewing their web site if their delayed write failures match the one we describe above. However, if you have such a DVICO hard drive kit, and you are experiencing the delayed write failure, this might be the solution for you.

Please continue letting us know of your success stories getting the Delayed Write Failure solved!

February 23, 2004

One end user has a VIA chipset on their motherboard (ABIT KR7A-Raid) with an Orange Micro FireWire card. This user was experiencing delayed write failures on their 1394 hard drive. Their resolution was to install the "PCI Latency" patch for VIA chipsets from http://www.georgebreese.com/net/software and to disable the Fast User Switching Compatibility Service. It is working fine for them.

The resolution that this user found is an interesting one and not too uncommon. It is possible that the changes the user made did not actually fix the problem. What I mean by that is that the root cause of the failure may still be there. However, making changes such as he did can affect the timing of the system which might cause the delayed write failure to never occur. Of course, this is just one possibility. The resolution above could very well be the precise fix needed.

Determining exactly what component is at fault is difficult (and frustrating). Keep letting us know of your success stories and we'll let others know. We're especially interested in hearing from 1394 drive vendors and bridge chip vendors. This WEB page receives a lot of traffic and it would be helpful to post official resolutions to issues you might be aware of.

March 17, 2004

We have received a detailed e-mail from an end-user (thanks Andrew) with information from the 1394 drive vendors about the delayed write failure. He relays that one of the more common causes of the delayed write failure is due to the firmware and chipset of earlier revisions (as has been discussed above).

He goes onto say that if you have an Oxford 1394/ATA bridge in your external chassis, you can download the latest 1394 firmware for oxford-based chipsets from http://www.byteccusa.com/drive.htm. The file you want is http://www.byteccusa.com/download/me-350f.zip. Apparently, there is nothing in this file that is specific to ByteCC products. For him, updating the firmware not only fixed the delayed write failure but also some other problems he was experiencing.

We took one of our 1394 delayed write failure drives, with the Oxford Semiconductor chipset in it, and downloaded the file above so that we could check it out. Unfortunately, the utility above is very VERY cryptic (in my opinion). All I want is a utility that says "You have firmware revision x.y. Would you like to upgrade to revision a.b?" Is that too much to ask? The ZIP file you download above extracts multiple files, multiple firmware revisions, and difficult to read documentation. Ugh, download and try the above at your own risk! We chose to leave our drive alone and not attempt an update. Good luck, you'll need it.

March 21, 2004

If you have a Lava FireDrive hard drive enclosure, we have been notified of the following WEB page with instructions on resolving their delayed write issue:

http://www.lavalink.com/techsupport/faq/faqtext/delayed_write_errors_win2k_xp.html

I must admit, reading through their solution, I can't help but wonder "what difference is that going to make?!?!" Oh well, stranger things have happened I suppose. If you have such an enclosure, and this really is the solution for you, please let us know.

March 24, 2004

An end-user having 1394 delayed write failures read through our messages above and responded to us with his success story:

I am contacting you in reference to your page about the 1394 firewire problem. I downloaded the java uploader from the Macally Peripherals site and I managed to configure the chip and upload firmware and it seems that my problems are over. My enclosure is a Constar ST-2312 C with a Maxtor 120 GB HDD and another one is with a IBM DTLA-307045 45 GB HDD and in both cases I upgraded the FW and configured the drives with the included config file and it solved the problem even on a Macintosh. Thanks for the help.

Perhaps the link cited above, with the java uploader, is the best option for those of us having problems with the Oxford Semiconductor bridge chip? If I get a chance, I "might" try it on my own drive. As always, please let us know of your success (or failures).

April 7, 2004

Thanks to another end-user report, we have received another link for a delayed write firmware fix. If you have a LaCie firewire drive, you might want to check out:

http://www.lacie.com/support/drivers

April 29, 2004

The 128K failure that we started this WEB page with appears to be a very common, if not the most common, cause of 1394 delayed write failures. However, there are other causes too. One end-user writes us with a method they found successful:

I noticed some mentioning of PCI latency settings possibly being the cause for some people. After some research I found a utility called powerstrip that allows you to manually configure the PCI latency settings on all most of your system devices. Once I upped my PCI latency for my firewire adapter, the delayed write errors stopped and I was able to write a 35 gb backup file to the external hard drive. I hope this information can help other people, because it saved me from a gigantic headache.

Another user writes us to tell us that our test application (described above) does NOT fail on their system, yet they still receive delayed write failures. This indicates that it is not the 128K failure we discuss above. However, the information above did lead him to a resolution for his delayed write failure. He writes:

I downloaded the DVICO software workaround from the link on your site and that eliminated my Delayed Write Failures. However with the software workaround installed, StandBy and Hibernate does not work. Perhaps you might know why power features no longer work?

Keep letting us know of your success stories. It seems like there are many users experiencing delayed write failures. We'll try and keep this site updated with any new information we find out. Windows XP SP2 (when released) might workaround many of the issues cited above. We shall see.

May 4, 2004

Thanks to to those of you reading this page and letting us know of your success stories. We have yet another solution for a delayed write failure for a specific 1394 drive enclosure. The end-user writes us with:

I managed to fix the write delay problem I was having on my firewire external harddrive by downloading new firmware for the external harddrive interface. The casing itself is produced by a company in Taiwan (http://www.argosy.com.tw) and sold under a couple of different names. The website above contains a link to the updated firmware drivers which I downloaded and installed without a problem.

In addition to the resolution above, another user wrote us with the steps he took to resolve his delayed write failures. His deals with changing the page file size (i.e. virtual memory). As I read through that message, it makes believe that the actual root cause of the failure is still there. In other words, the defect that is causing the delayed write failure is still there. However, by changing the I/O patterns (which can occur when you change the virtual memory size), you create a scenario where you cause the failure to disappear. This might be a solution for some so I'll go ahead and post his message here. Thank you again to everyone that keep us updated with their delayed write resolutions:

UPDATE TO 1394 DELAYED WRITE FAILURES: NEW SOLUTION
My System: IBM Thinkpad A30, 1.13GHz, 384Mb RAM, WinXP

I have a laptop and use a PCMCIA 3-Port 1394 Card to connect two external drives; a 60Gb Buslink and a 200Gb Lacie d2. For the past 5 months I have been receiving Delayed Write Failures with both my drives, frequently corrupting them and forcing total data recovery. This was especially frustrating because these were supposed to be my backup drives, so there was no backup for them. I was forced to switch the information back and forth between whichever drive was working, and reformat the other.

Because the two drives were from separate manufacturers and both were suffering from "Delayed Write Failures", i knew the problem rested in either the PCMCIA Card, my IBM Thinkpad A30 Hardware, or with Windows XP.

I tested many things, including the ATi problems, VIA chipset problems, startech pcmcia updates and most other solutions presented. Nothing seemed to change the results whatsoever. I even received a firmware update from Lacie (http://www.lacie.com/support/drivers) which should fix the problem, but i couldn't read my firmware as my Lacie drive was corrupted, and i couldnt reformat it because i had valuable files on it (restoring 78Gb to a 60Gb Drive and 20Gb master disk that are both partially full is quite the tedious art). FINALLY, Lacie offered a suggestion that seems to have cleared EVERYTHING up.

Windows uses virtual memory paging files on the hard disk as if it were RAM. By increasing the paging file size, your computer is able to handle larger data transfers with more comfort. Initially, my computer was set with an initial PF size of 576Mb, with a maximum size of 1152Mb. This would seem more than enough, but as Lacie suggested, I increased these values x1.5. My new PF values were an initial PF size of 864Mb, and a maximum size of 1728Mb. Immediately after, without even restarting, i tried to recover 13Gb of data, and it worked completely successfully, with no failures whatsoever (never happened before).

HOW TO CHANGE YOUR PAGING FILE ALLOCATIONS:

Right click My Computer.
Select Properties.
Select the Advanced Tab.
Select the Settings Button under Performance.
Select the Advanced Tab under Performance Options.
Select the Change button under virtual memory.
Click on the Custom Size option for C: and multiply both the Initial and Maximum size values by 1.5.

I noticed that I could also change the PF allocations for my external drives, so I set them to "System Managed". This fixed ALL the problems I have been having!

Hope this works for others as well! Happy Troubleshooting!

May 14, 2004

This page is dedicated to helping end-users resolve delayed write failures with 1394 hard drives. However, we have received a useful e-mail from an end-user who has resolved delayed write failures with his USB hard drive. The following two links were provided:

short-media.com

microsoft.com

May 26, 2004

A few days ago I hooked up a DV camera to my computer (via the 1394 connection) and started to capture video into my computer. The video was being saved to my local ATA drive, NOT my 1394 drive. However, it wasn't working. At seemingly random times, the capture would abort saying the camera was disconnected (which it wasn't). Repeated attempts failed. Hmmm, another 1394 failure? Well, given my negative experience with 1394 hard drives, I had a hunch that this might be the cause. So, I disconnected the 1394 drive and tried capturing the video again. It worked perfectly.

Does anyone bother to test interoperability? Given the frequent visits to this WEB page, these are not isolated cases. I don't know if this most recent failure is caused by the drive, the controller, the camera, or the OS. I suppose I could spend more time trying to diagnose whose at fault but I have more important things to work on.

Let's get back to the "delayed write" failures. We have more reports from end users on how they fixed their delayed write failure. An end user has given us information from Maxtor on how their users can resolve the delayed write failure on Maxtor 1394 drives. The link can be found here:

http://forums.viaarena.com/messageview.cfm?catid=16&threadid=50469

Look for the post by "netguy" on Tuesday May 04, 2004 10:39 AM.

Another user writes us with:

I have sony vaio PCG-FX802 laptop with iomega 120 GB external firewire drive. I was not able to write to the drive without SBP2port error 9 showing in the system log and the device timed out and disappeared from the explorer list of devices. I downladed your test prog and it showed that the device could handle 132 sectors but failed after 133. I went to the http://www.dvico.com/su_down_content.html website and downloaded 1394MaxRec_v127.exe I installed and ran it and so far have not had any more problems with the drive. Thank you for helping with this. Neither Sony help or Iomega could help me with this. Thanks again.

The start of this blog centered around our discovery of 1394 bridge chips not handling larger than 128K transfers. This caused the delayed write failure. Given the number of e-mails and hits to our WEB page, this has also been the root cause of many of your delayed write failures (not all though, see above). Rumor has had it that Windows XP Service Pack 2 would work around this problem. I thought I'd check on that by installing Windows XP Service Pack 2 RC1.

I took a test system and did a fresh Windows XP installation and ran our 1394 tester applet. Click here to download the file 1394Test.exe. Sure enough, it failed at 257 sectors (>128K). I then updated the system with Windows XP Service Pack 2 RC1 on the system, rebooted, and tried our 1394 tester applet once more. What was the result?

I'm sorry to report that the delayed write failure STILL appears with RC1 of SP2. Perhaps it will resolve other delayed write failures, but it does not appear to resolve the >128K failure that we experience. Since SP2 is not released yet, there is still the chance that it might be added prior to the release, though I think this would be unlikely.

June 16, 2004

If you have an Argosy 1394 case, you might find a resolution to delayed write failures here:

http://www.argosy.com.tw/drivers/faq/english/faqhd360c.htm

July 5, 2004

Since our original post last August of 2003, we have received thousands of hits to this WEB page. Clearly 1394 delayed write failures are rather common (particularly with older chipsets and firmware). As I've stated before, it makes you wonder if vendors thoroughly tested their devices or not. Anyway, back to the topic at hand.

From the very beginning, we've talked about this larger than 128K transfer problem that many 1394 bridge chips have. We wrote our own filter driver to work around the problem and it works great. We never made it available outside the company because it was only intended as an internal hack to resolve the annoying and frustrating delayed write failures we were experiencing. An end-user, also frustrated by this delayed write failure, went about learning how to write filter drivers so he could resolve the problem for his system too. He has gone ahead and made his driver available for others to try. We have not used the driver here at busTRACE Technologies but it could be a solution for you. Details can be found on his WEB site:

http://member.newsguy.com/~siccos

Quite a few of you have taken the time to let us know of your delayed write failures and we thank you. Your assistance has made this site that much more helpful to everyone else.

July 13, 2004

If you have read through this whole web page, you'll notice that there are many different solutions to the 1394 delayed write failure. Unfortunately, there is no one magic bullet to solve all problems. I do believe that Windows XP SP2, when released, will work around many of these chip/firmware defects (we shall see).

The root cause of most delayed write failures (most, but not all) is the 1394 bridge chip that sits between the 1394 bus and the ATA bus that the actual hard drive is connected to. Whether the chip is by Oxford Semiconductor, Prolific, or others, many of these vendors seem to have delayed write problems (at least their older chipsets and firmware do).

One solution for Oxford Semiconductor chips was to download the latest firmware. On March 17 (above), we talked about an Oxford firmware update utility that was very cryptic and confusing. An end user has e-mailed us letting us know that the firmware update did resolve the delayed write for them. He went ahead and provided us step-by-step instructions on how he updated his firmware. We thought this might be of value to you. Here is what he has to say:

I came across your very helpful page about 1394 Delayed Write Failures tonight. I also have an ADS Pyro 1394 drive kit, and it's been nothing but trouble since I got it.

Since it seemed a firmware upgrade was the last hope to salvage it, and I was installing a new hard drive anyway so there was no data to loose, I took a look at the updater you mention in your March 17, 2004 notes.
While you suggested it was too difficult to use, I have (un?)fortunately accumulated a lot of practice at navigating this sort of utility over the years. I applied an update to my ADS system, and so far it's running much better than ever before. I'm going to push a few hundred gigabytes through it before I really trust the drive, but I wanted to pass along the installation instructions I used so you can consider trying it yourself.

As you'd hoped, there is a way to get an installer that shows the current firmware version you have installed and allows an update to a newer one, if you're running Windows. Instructions go like this:

Download the .zip file with all the files you need from:

http://www.byteccusa.com/download/me-350f.zip

Extract this to a temporary directory, you'll need to pull a couple of files out of it.

Install the Oxford Windows firmware updater by running

me-350f\make1394-faster\Uploader v4_12\setup

Reboot as directed

There won't be any icons or start menu installed to run the program, but it's there. On your Windows system drive, the program is installed into

\Program Files\Oxford Semiconductor\OXFW900 Uploader

Head into that directory and run the "FwUpload" utility. The interface is pretty simple. It will show the current firmware revision on your device at the bottom. My enclosure had a firmware from early 2002 when I started,
and that version was incredibly buggy.

Click on the "Upload/upgrade device firmware" to install a newer version. It will default to the directory the program was installed into, but the only one in there is an ancient firmware (20020104, which is even older than the useless version my ADS Pyro shipped with).

To find the firmware you want, go back to where you originally unzipped and use

me-350f/patch file need for firewire/fw20030722

That will upgrade your Oxford 911 to the Jul 22, 2003 firmware (which Oxford refers to as their v3.8 firmware). Windows will complain that you've unplugged the drive without stopping it first when the new firmware installs and the enclosure disconnects for a moment.

There is another useful feature available when you're in this utility. If you navigate to:

Modify device configuration settings/Advanced

you'll find some parameters you can adjust. Some people have reported that they can solve some compatibility problems with the Oxford chipset (in particular with faster CD-RW drives, http://www.xlr8yourmac.com/firewire/ads_pyro_case_cdrw_reports.html) by turning on the "Detect drives with non-std. signature" feature here. I found the following recommendations from one web page that mentions this
utility:

"We recommend turning on ONLY the following options:

Enable GPI Drive Detect
Detect drives with non-std signature
Wait 6s before polling drive
We DO NOT recommend using any other settings - LEAVE THEM OFF"

---

For people who want to navigate the Java version of the utility instead on a Mac, there is a useful walkthrough of the same procedure available at:

http://www.fwdepot.com/firewiredepot/firmware/firmware.html

(that's also where I snagged the advanced recommendations above from). It does cover using the Windows utility, but their installation procedure is more complicated than the one I outline.

By the way: you point to a firmware upgrade utility for LaCie drives in your April 7, 2004 notes. If you look into that program, you'll discover that it includes a OXFS911_030722.dat file that presumably is the same V3.8 firmware installed by the process I outline above. Note that LaCie uses a totally different storage format for the upgrade so the data files aren't interchangeable. It appears that every vendor supplying new firmware for Oxford 911 based devices is using the V3.8 firmware from 07/22/2003, so I would be very surprised if it that one doesn't help your situation. If the updater utility correctly identifies your chipset and current running version, it should be safe to update.

Your concern about compatibility certainly is warranted, as there are plenty of sites giving out bad versions (i.e.
http://www.cooldrives.com/firewireinfo.html )

This end-user contacted us again a few days later saying that the Oxford Semiconductor delayed write failure was now fixed since he updated the chip firmware. He does, however, appear to have power management issues in the Maxtor drive itself. In case this information is useful, we wanted to post it as well. He goes on to say:

One final comment on this whole mess. After leaving the drive connected but unused for a few hours, it never came back again properly and I had the old delayed write failure again. There are lots of reports of issues with Maxtor drives connected with Firewire doing this: a good set is at

http://www.macintouch.com/maxtor.html

Sure enough, my drive is one of the Maxtor DiamondMax models referenced there.

So it appears that as long as I keep the drive doing something occasionally while it's connected, it's fine. But if the drive ever is unused for long enough that it starts sleeping, it won't come out of that properly and should be disconnected before being used again. I can live with that.

Hope this helps.

July 29, 2004

If you have a laptop and are experiencing delayed write failures, one end-user has told us that they only started noticing the failure when they switched their computer's power management scheme to "Portable/Laptop." You may want to try adjust this setting to see if it makes a difference.

August 12, 2004

Windows XP Service Pack 2 is now released and we have some initial test results to share with you. In the messages above, we talked about how our SmartDisk FireLite drive has the bridge chip/firmware problem that does not allow it to handle larger than 128K transfers. We produced a test application that showed the delayed write failure always. We have heard that Windows XP Service Pack 2 would work around some of these device bugs. Although an initial release candidate of Service Pack 2 didn't work around it, we are happy to report that the released version of Service Pack 2 does indeed solve the problem for us. If you are running Windows XP, and if you are experiencing any delayed write failures, you should see if Service Pack 2 improves the situation for you. If it doesn't, some of the solutions cited above may work for you.

While I have your attention, I have another 1394 gripe. I have not retested this with Service Pack 2 so I do not know if this problem is solved or not. The problem is this. I have my bus powered 1394 drive on my system and it's working fine. I then attach another 1394 drive. It could be a 1394 DVD recorder or whatever. When I hot plug the device into my 1394 controller (not to my hard drive), my hard drive completely shuts down. The overall system gets unstable. This has happened to me several times now. It's probably related to an earlier problem I cited where I couldn't stream from my DV camera to my ATA hard drive when a 1394 drive was on the 1394 controller as well. Whose fault is it? Is it the OS? The drive? The controller? I don't know but I have been very frustrated with all the stability problems I have had with 1394. Personally, I'm going to try and just use my 1394 card for a DV camera and nothing else. Your mileage, of course, may vary.

August 16, 2004

One of our links above, http://member.newsguy.com/~siccos, also has updated firmware for the Prolific PL-3507 bridge chip that you can download (at least for some models of the Prolific chip). This update can fix the delayed write failure if your 1394 case uses this chip.

August 24, 2004

Another end-user has written to us letting us know that Microsoft has had an XP 1394 patch available for some time on their WEB site. In reading through their site, this could be the fix for the problem we've seen where hot plugging a 1394 drive shuts down the 1394 bus. I do not know if this patch addresses any delayed write failures. Since these changes are in Windows XP Service Pack 2, you don't need to worry about this patch if you've updated your OS. However, if you do not want to upgrade to Service Pack 2 (for whatever reason), you can still download this one individual patch. Details are here:

http://support.microsoft.com/default.aspx?scid=kb;en-us;329256

You can download the patch from here.

Given the severity of the problem, it's unfortunate this patch wasn't made available through a more obvious means, such as the Windows updater. Could have saved me a few headaches :-).

September 15, 2004

I have received a number of e-mails from end-users letting me know that this site has helped them resolve their delayed write failure problems. Thank you for taking the time to keep us updated.

As for my own 1394 hard drive status, things are going reasonably well. I do have one remaining problem. I use suspend/resume quite a bit. Once in a while, and it is not always reproducible, my 1394 hard drive locks up when the system resumes. I can sometimes get it out of this state by unplugging it and plugging it back in. Usually it results in an unstable system and a reboot is required. Fortunately this doesn't happen very often. I don't have enough time to try and diagnose who is at fault with this issue so I'll just live with it. The "delayed write failure" is gone for me with Service Pack 2, but I still keep my little filter driver installed as a secondary safety check. I figure it served me well for well over a year; why tempt fate? :-)

An end-user has written us with some additional tips we thought we'd pass on:

I stopped my delayed write failed with the OXFW900 Uploader.
I disabled UDMA5 and set the maximum transfer to 1024 with the utility. I have Windows XP SP2 and now I have no message error again. But if I try to set the max transfer to 2048 the message error is back. So with the maximum transfer set to 1024 and Udma5 disabled my external drive is now stable.
Hardware: LaCie 160Go Firewire drive
**********************************************************
Before i found this trick I put all my drive in PIO mode (internal drive with WinXP,cd burner and dvd player). The error never come back but my system was very slow.
**********************************************************
So I'm now happy that I can use my external drive after 5 month of testing all possible things. It's very important to test a lot of settings to resolve the problem.

And another user writes:

My LaCie Porsche drives and Thinkpad T41 were not working well with SIIG or Adaptec CardBus 1394 adapters. Surfed, experimented, and eventually found solution: in the Setup, disable PCI bus power management.

October 27, 2004

The majority of problems end-users have reported to us seems to stem from this 128K bridge chip limitation (described in detail above). There are many other causes, unfortunately. We continue to get an occasional e-mail with yet more solutions. Here are some recent reports.

One end user found a solution at http://www.tangent-systems.com/support/delayedwrite.html.

Another end user reports resolving delayed write failures on a USB drive by changing the ATA drive setting (inside the USB case) from master to slave.

November 17, 2004

Although Windows XP Service Pack 2 is a solution to the delayed write failure for some users, for other users, we are getting reports that SP2 generates more delayed write failures. If this is your case, a workaround to your problem is likely above. First try our delayed write test application and see if it fails at 257 sectors (backup your hard drive first!!!). If it fails at 257 sectors, you have the 128K bridge chip limitation; workarounds are cited above.

November 29, 2004

We receive quite a few e-mails from end-users telling us that they found a solution above to their delayed write failure. Here is one such e-mail with a slight twist to a resolution found above. Perhaps it might help others:

I found your doc at www.bustrace.com/delayedwrite very useful in resolving a problem with an Iomega external HDD connected via the 1394 controller.

I have included details here as it may help someone else. The guts of the solution that worked for me is the same as that posted under the entry for 26 May 04 but there are some differences which may be useful to note.

The May 26 posting was:
"I have sony vaio PCG-FX802 laptop with iomega 120 GB external firewire drive. I was not able to write to the drive without SBP2port error 9 showing in the system log and the device timed out and disappeared from the explorer list of devices. I downladed your test prog and it showed that the device could handle 132 sectors but failed after 133. I went to the http://www.dvico.com/su_down_content.html website and downloaded 1394MaxRec_v127.exe I installed and ran it and so far have not had any more problems with the drive. Thank you for helping with this. Neither Sony help or Iomega could help me with this. Thanks again."

My details are:

His drive was an Iomega 120 GB, Mine is an Iomega 250Gb

He mentions it's a Sony Laptop in his case I'm using it on a desktop (Motherboard = ASUS P4C800-E Deluxe: Chipset = i875P) IEE 1394 controller = 'VIA OHCI Compliant 1394 Controller'

His drive exhibited a problem when he used your test prog, mine passed the test OK.

I'm using the 1394 drive as a backup disk, it was OK when I backup IDE drives to it, and OK when I back up a Raid array that is comprised of IDE drives, but the timeout problem occurred consistently on attempts to back up a Raid array comprised of S-ATA drives.

installing the MaxRec driver as detailed in the original posting solved the problem.

Thanks again for collating this info together, I found it extremely helpful.

December 6, 2004

This web page receives a considerable amount of traffic each day. It would seem that the delayed write failure with 1394 drives is still pervasive. Most end-users we have communicated with have found a resolution to their delayed write failures above. However, we still occasionally receive e-mails with new twists and solutions. Here are two interesting e-mails we have received from end-users who wanted to share their story.

Nick writes us with:

Hi, I'm another victim of the delayed write error, but not anymore. If you don't mind, I'll tell you all of what happened, in hopes it will help someone else.

I started experiencing the error naturally on a Maxtor Diamondmax Plus 160GB in an Oxford 911 enclosure, the ByteCC ME-740F (the 3.5 inch version of the oft-mentioned ME-350F). I was plugging it in to a VIA VT6306-based firewire card.

I tested the enclosure + drive under XP Professional SP1, with no issues. I moved to XP SP2, and sure enough, I started to get delayed write errors under odd circumstances--usually, when some program or another went to save a file, but not under normal file transfers.

So I tried flashing the firmware. I came across three different versions of Oxford's flash utility, the latest of which does not allow modification of the all-important settings, block size and DMA.

I quickly found out that if I ran the flash program with ANYTHING else running on my computer--a browser, a music player, whatever--the write process would go south. I should know better, really, but I was pretty overzealous/overtired at the time. But it brought up an interesting point--that the firmware uploader seems to be very touchy, and should only be run by itself.

Anyways, in that process, I ended up performing an incomplete write to the flash memory. Luckily, the uploader that comes from ByteCC, for the 350F, turned out to be the most useful of them all--in the directory "FW9", there is a command-line program to reset the flash memory to receive for its initial firmware in the factory. Had to use that, and I was back to square one.

So once I had a grasp of the whole process, I first tried the old, original firmware, from 2001. At 2048 block size, at UDMA5, I received delayed write errors under Service Pack 2, followed by lockups. At 1024 block size, at UDMA4, the drive worked correctly.

Then I flashed to the most recent firmware. At 2048 block size, at UDMA5, it worked just right.

But I'm leaving out the real problem, and this is what I really want to talk about.

I have a JVC GR-DV900 camera, which runs under the AVC-Compliant DV device drivers in WinXP. I plugged that into my firewire card, right next to my external enclosure.

The SECOND I turned on the camera, there were tons of delayed write failures no matter what the Oxford settings were. These crippled my system a couple times, because I turned on the camera while in Avid XPress Pro (I'm a film student), and the program kept trying to write to the external drive.

Of course, with delayed write failures of that magnitude, it damages all the directories on the drive, often to the point where the drive has to be reformatted completely.

The solution to this connectivity problem is hinted at in documents on firewire, and in Microsoft's knowledge base, but in my opinion, this should be a disclaimer in the manual for ANYTHING firewire:

THE SLOWEST DEVICES SHOULD ALWAYS BE AT THE END OF A FIREWIRE CHAIN.

I had NO idea this was true, and I've never even heard it mentioned among anyone else with a firewire setup. Maybe I'm sheltered. But when I plugged the camera and drive into my card on two seperate ports, the drive was slowing down to 100mbps, the speed of the camera, and hence, the delayed writes.

So I established a chain... from firewire card, to Oxford 911 enclosure, to DV camera. Not only did this work, but detection of all components was faster and more reliable.

Funny thing is, this has never been an issue on Macs, from what I've seen. You can chain things and/or plug them into system ports, and it makes the adjustments for you. So I'm pretty sure it's an issue with the Windows XP not understanding the varying speeds in a less-than-perfect firewire setup. Service Pack 2 only makes the problem worse.

I hope this information proves useful, and I apologize for the lengthy message. I'm just surprised how rare your site is in having information on this phenomenon. Without it, I probably wouldn't have come to the conclusions I did to fix my own problems.

So thank you, very much.

Our second message comes from Pete who writes us with:

I came to your site from the Dell forum regarding the delayed write problem documented there some time ago. I'm not sure whether the issue is still 'alive,' so to speak, but if so I would like to add my 2 cents worth.

I have and Inspiron 8500 and recently bought a Firewire/USB 2.0 Combo drive that is effectively a 200 Gb Western Digital drive enclosed in an aluminium case with its own power supply.

>From the very first moment I used it via the Firewire port I had the
>problems identified by many others - writing for a small time then
>freezing and disconnecting and the delayed write failure message. When
>I connected it via USB, it has performed flawlessly albeit slightly
>slower.

With your 1394Test utility the problem was reproducible every time I ran it, sometimes getting to around 45 percent through, sometimes only 15 percent. I am running Windows XP Pro SP-1 and have not yet made the SP-2 upgrade, but I installed the 1394 patch offered by Microsoft. This made no difference whatsoever, but given that it wasn't specifically for the delay write problem, I am not surprised.

I also played around with various Virtual Memory settings as that seems to have been an area where some have found success. I had little initial success until I settled on 1024 Mb for the initial size and 2048 Mb for the maximum size. That's double my physical RAM (512 Mb) for min and quadruple for max.

With these new settings, the problem *appears* to have been resolved. I just ran your 1394Test utility three times consecutively without an error being reported. I'm keeping my fingers crossed.

Some might think that my Virtual memory settings are extreme, but I normally use different min and max values of about half the size I reported that now appears to work.

I hope this assists your cataloguing of information on this problem. Thanks for your good work.

December 17, 2004

Thanks to Andrew, we have been made aware of a Microsoft update to XP Service Pack 2 that apparently fixes some 1394 issues, including delayed write failures. The Microsoft site states:

After you install Windows XP Service Pack 2, some 1394 devices (such as digital cameras that use S400 speed) may not perform as expected. Install this update to help prevent this issue. After you install this update, you will have to restart your computer.

Click here for full details.

December 20, 2004

Adrian writes us:

I have been delving into your pages on Firewire / delayed write problems, and thought I would report my experience in case it was useful.

I bought at LaCie Porsche design 160GB external drive with IEEE1394 interface. The disk inside is a Western Digital one. The Athlon 900 PC running XP SP2 and with a VIA 133 chipset recognised the drive, but then the delayed write problem reared its head. I tried your tester, and it happily wrote all the sectors, so that told me a little more, but not much.

The Firewire card is one provided by Pinnacle with Pinnacle Studio 8, is certified on Microsoft's hardware compatibility web site and works fine with my Minolta 5400 scanner, although it had failed to communicate properly with my wife's Mini I-Pod. This should have been a clue, but I had forgotten this.

The LaCie troubleshooting utility from their web site recognised the drive OK and it passed all the tests there, including extracting the internal disc information.

Losing the will to live, I drove to work to get my Sony Vaio SRX51 laptop with has a 4 pin IEEE1394 connection. Bingo, drive behaved perfectly, and I threw a 150MB file at it which it accepted in no time with no errors at all. So it appears to be the card: I checked and the drivers for the IEEE1394 hardware are identical on both computers. I have since written about 20 GB to the disc from the laptop with no error at all.

The only difference between the firewire devices that I can see is that the successful Sony laptop reports a "Texas Instruments OHCI Compliant Host Controller" whereas the one in the PC in which I was having the trouble reports "IEEE 1394 OHCI Compliant Host Controller Vendor."

So it looks like I need a better quality IEEE1394 card, and not to rely on Microsoft certification to tell me that it will actually work! (By the way, I did try two different 6 pin to 6 pin 1394 cables between PC and external; didn't make any difference.)

December 21, 2004

Joseph writes us:

Got to your web site from googleing "delayed write error". I tried everything including buying "File Scavenger" to recover files lost when that $mft error showed up. What worked was nick's suggestion on putting the slowest device (Pioneer A08 DVDRW) at the end of the link.

What didnt fix it but may have helped anyway: Maxtor's 48bit large disk enabler, Latest (sept 04) firmware for Prolific 3507 chipset, that Microsoft XP patch KB885222 including SP2. With all those patches and firmware I still got no further than about 9% into your 1394test program. This is what I finally discovered while debugging:

With DVD-RW on oxford 910 (old,?? didnt see 911 markings) chipset closest to computer and Prolific 3507 (ME-350U2F) at end with large drive, the test fails if the DVDRW is populated on the oxford controller. If unpopulated (drive does not show up, but oxford controller does) your test runs 100%. I then put the oxford 910 DVDRW at the end of the chain and populated the drives and your test runs to completion no error. AFAICT, nick is correct in that the slowest device must be at the end. This test was run using a 64bit PPA 800 controller. Only the 400 speed was used since my boxes are 400 only. Since the Pioneer A08 is a high performance device, UDMA mode 4, I assume that is still slow. However, I am only guessing as to what that old oxford enclosure was using. Maybe it was only using pio mode. Is there a way to tell?

December 29, 2004

Joseph has e-mailed us again to let us know that he received a patch from Microsoft for Windows XP Service Pack 2 that fixes his 1394 hard drive problems. Microsoft has a KB article that details this. The symptoms are:

When you have a single Institute of Electrical and Electronics Engineers (IEEE) 1394 device connected to your Microsoft Windows XP Service Pack 2 (SP2)-based computer, you may experience problems when you disconnect the device. For example, you may receive an error message, or the computer may stop responding. The specific symptom may depend on the software that you use in conjunction with the IEEE 1394 device.

This problem does not occur if you have more than one IEEE 1394 device connected, and then you disconnect a device.

The KB article can be found here:

You experience problems when you disconnect a single IEEE 1394 device from a computer that is running Windows XP SP2

January 3, 2005

Tom writes us:

I am not sure if I am contacting the right department. But...... I did want to share this information. There is a newer firmware release out for the PL-3507 combo USB2/1394 chipsets, that has eliminated any/all Delayed Write problems with my Hard Drives housed in Prolific bridgeboard based external cases. You will find it at:

http://member.newsguy.com/~siccos/PL3507%20Firmware.htm

It is the d11904 firmware V185. Use ROM Updater 2.2 also on the site. Update via USB.

I have run your Bustrace Test several times with "no" errors. I could not do this with earlier Prolific firmware versions. I had my share of "delayed write" failures, corrupted files and unreadable hard drives with previous firmware releases. I was about to give up using my external cases for anything but DVD writers until I found this V185 version. Since upgrading, I have successfully transferred 4GB, 8GB, 20Gb & 90+GB file copies. I have done file compare to Original and copied back to original drive all with no errors. I would hope those who use this new firmware release will have similar results. I would like to credit "showarthing" for sharing this release. Thanks for posting this.

January 12, 2005

Adam writes us:

Thank you so much for your help! I recently purchased a 250GB Hitachi drive and put it in an enclosure with a Prolific PL-3507 chipset and was having the dreaded "Delayed Write Failed" error. I am a bit compulsive so have been up searching since about 8 hours ago. When I found your site, complete with warnings of drive falure from your test, I backed up 20 gigs or so onto DVDs, and ran the latest firmware update (November's) with the latest ROM installer (2.2). The first time I ran the test, it failed at 384, and wouldn't even show a % complete. After the ROM update, the test completed in about a minute, with no errors. Flawless. Thank you so much!

January 20, 2005

Will writes us with another link from Microsoft that can resolve some 1394 failures, including delayed write failures. The article is titled "SBP-2 drive stops responding when you try to write data in Windows XP."

http://support.microsoft.com/kb/885464

January 24, 2005

We have received several more "success" stories on resolving delayed write failures. Gerald writes us:

Re firewire problems with XP.

Very useful test program... blows away my drives before it says 1%.

Th XP "hotfix" is not publicly available.... :-(

But...
http://fwdepot.com/firewiredepot/firmware/firmware.html
At the top of the page as a 911 .bin file called

http://fwdepot.com/firewiredepot/firmware/FW911_V4_00_0000_Release.bin

I burnt it into a 911 bridge board, using the Oxsemi uploader after burning it says...

Currently Running 13:59:47 Oct 15 2004 (v 4.0) firmware.

Now I can run your test program. about 30secs. and even properly unplug the device afterwards, a major step forward.

Thanks for running this issue.

Josh writes us:

Hi...I just wanted to share my experience with delayed write failures on an external USB 2.0/Firewire drive that I own.

Ever since I upgraded to SP2, I've been experience delayed write failures with a Lacie D2 USB/Firewire combo drive that I purchased in late 2003. Lacie tech support could not help me and I was ready to scrap the drive. It had already corrupted about 250 gigabytes of music that I had ripped from my music collection. Every friggin' song had CRC failures; in fact, I think the actual quality of the song was degraded. Many of my songs had pops and skips.

Anyway, after reading the log that bustrace has on delayed write failures, i decided to first increase my virtual memory to 1.5x the available memory on my system. This did not work. When I used your 1394 stress tester, the CRC failed after the program was 1% complete. Then I began to read about the Oxford bridge problem. So, I dismantled my lacie drive. I took off the alumnium casing and unscrewed the IDE to USB/Firewire bridge. Sure enough, the bridge was made by Oxford. So, I downloaded the Macally files that another reader used to update the 128k bridge problem. But, like the log said, it was very cryptic but from what I discovered, there is an "uploader" program that updated the bridge firmware. But, you need to connect the drive via firewire, not USB.

I live in NYC and trekked through the recent snowstorm to J&R computers to pick up a 9-pin to 4-pin firewire cord. Luckily for Lacie drive owners, Lacie publishes an updater. But the information on the updater does not say that it is used to fix the Oxford adapter used in all their drives. But that is its sole purpose.

Once I updated the Lacie drive using the firmware, the stress test program has worked beautifully and I am ready to begin transferring files back on the drive that I was ready to toss.

Will writes us:

I solved my delay write failed issue in windows 2000 SP4. Turns out I needed a PCI Performance Enhancer provided by Pinnacle systems. They made my card which has the Agere FW323-05 chipset.
Link: http://www.pinnaclesys.com/support/display.asp?FileID=1237&ProductID=428

I followed up with MS Support Regarding KB Article
http://support.microsoft.com/kb/885464
They said it didn't apply to Windows 2000 SP4 and was a XP specific problem. They took me through a bunch of steps but eventually it just came down to that little piece of software.

February 2, 2005

Michael writes us to let us know that he did not have the 128K problem we cite above, and our test program worked without any issues. Still, he would receive delayed write failures. The solutions cited above did not work for him either. He ended up resolving his problem by updating the 1394 Windows drivers from Unibrain using their ubCore 3.3 package. Details are here:

http://www.unibrain.com/1394_products/ubcore/ubcore.htm

February 11, 2005

Fabian writes us to let us know that a firmware upgrade for his Prolific bridge chip fixed his 1394 and USB failures:

My drive (bought in december) was from "Chiligreen" (lousily assembled, tighten all the screws before use!), a 200Gb with the Prolific chip (USB + Firewire). First crash after a few days (after running for some hours it suddenly said "Could not write Mft..." and I could watch files disappear) - I returned the thing and got a new one (this time 250 Gb, USB + Firewire). Same thing several times - I went crazy. By the way: Ontrack Easy Recovery is a great utility, it recovers most of the things within a few hours. But in this special case NEVER let chkdsk repair something - then everything is lost! I updated with the November 2004 firmware and the 2.2 Flasher - the disc has been heavily used (USB and Firewire) for two weeks now, and no errors. I saved the old firmware, but could not figure out which version it was. Anyway, thanks a lot to all the guys for the information!

February 14, 2005

Rick writes us with an interesting story that we wanted to pass on.

I recently bought an external USB/FW enclosure called "Icybox" which uses the Prolific PL3507 chipset with an Hitachi/IBM 250GB 7K250. I used it with the firewire connection flawlessly on a friends MSI Mega 180 barebone, but as soon as I connected it to my own Shuttle SN45G which uses the Realtek chipset, within 15 minutes the drive was totally ruined. Chkdsk says "unable to determine NTFS version info". The 1394test.exe worked perfectly, no problems found. I downloaded and flashed using the latest Prolific firmware which had no effect. Using the USB connection I have had no problems whatsoever, but only get around 25 MB/s read, 20MB/s write. Firewire was around 35MB/s. I'm running Windows 2000 with SP4.

February 21, 2005

Jim writes us:

Thanks for the excellent web page on this very frustrating problem. I have a Maxtor One Touch external drive and an IBM Thinkpad T30. I was not having the problem you had; instead, I could write maybe 200MB of large files via 1394, and then I'd get a series of DWFs. I applied the Maxtor patch referenced above, and the Microsoft patch also, but saw no difference. I could write just fine via USB2, and from your site I suspected that my problem had to do with the ADS Pyro Pro PCMCIA card I was using. Maxtor suggested the same, so I bought a new 1394 card and bingo--no more Delayed Write Failures. It took a week of futzing around, but the problem is gone, thanks in large part to your site!

February 28, 2005

Chow writes us with a solution to his delayed write failures with a Sarotech USB/1394 box:

I am writing to warn on how I slagged my Sarotech Hardbox (plastic) combo case.

I was using a Sarotech Hardbox (plastic), with an older chipset that uses an unknown USB chip and an OXFORD 911 chip for the firewire.

I downloaded and used the OXFORD 912 updater from the an obsure link on the Sarotech website http://www.sarotech.com/cgi/main_eng.cgi?cmd=drive_01

which contained a link to the file FHD-354UFb.zip

and found that it has a firmware for the 911 chipset. So I patched my firmware and it worked fine. Unfortunately I tweaked one of the reserved settings with the OXFORD firmware utility and now even the hardware reset for the 911 doesn't work because there is an external flash ROM for the 911 and the USB chip, which I don't know how to reset.

Apparently my Sarotech's OXFORD 911 configuration was set to IDE drives only and tweaking the firmware allows it to change to support ATAPI CDROMs. I was trying to allow support for 2 IDE devices (master and slave) when I... er... set the wrong... er.. switch... opps.

Anyway my newer Sarotech devices were all using the Prolific 3507 chipset (which allows support for CDROMs and hard disks) which I patched with the November firmware and they are also working perfect now.

Furthermore my cousin's Ranger Hardbox, which is identical to the Sarotech Hardbox, was using a PL3507, which was also successfully patched.

So thanks for the info on your page... it really helped!

March 2, 2005

Lynn writes us:

Two things:

Thank you for all of the work you've done on the Firewire hard disk problem(s).
The only solution that worked for me was to purchase the Unibrain ubCore drivers. The driver replaces the MS 1394 stack for the Firewire controller. This driver eliminated all of my Firewire disk problems. But there is a caveat: the driver is not OHCI compliant. So other devices like scanners probably will not work with the ubCore drivers.

Again, thanks for the wonderful job you're doing.

March 9, 2005

Eric writes us:

Thank you for keeping the information forum on the delayed write failures (DWF). I would like to inform you about some troubles resolved by updating the Oxford 911 firmware under Windows XP SP2 with KB855222 hotfix.

Firewire operation of an external firewire + USB 2.0 Seagate 160 GB hard drive became significantly more stable after applying the Oxford 911 firmware 4.0 update that replaced the original 3.7 version. Before the update, DWF such as ("Windows was unable to save the file G:\$Mft" etc) would regularly occur for this drive when daisy-chaining another firewire device, or running both devices through a firewire hub. After the firmware update, DWF were not observed for three weeks:

when the drive was connected as the only device on the firewire bus;
when the drive was connected as the first device (closest to firewire controller) in the daisy chain configuration.

However, delayed write failures would still occur if the drive was daisy-chained as a second device on the firewire bus, and the first device malfunctioned.

Operation of this drive as a USB 2.0 device has been stable both before and after the firmware update.

March 10, 2005

An end-user writes:

I just want to say thank you for the following page http://www.bustrace.com/delayedwrite
as regard the 1394 error.

I have a EZQuest 1394 drive with an Oxford 911 chip. After I upgraded my Dell 8500 to XP SP2, this drive has been acting for ever. I finally hit this page, the firmwire updating did the trick. My drive is well and sound now.

Thank you very much.

March 15, 2005

Alan writes us with an interesting story:

(Thanks for your very helpful Delayed Write Failure page.)

I have a Plumax enclosure with a PL-3507 (rev. C) chip. Your super helpful test program fails at the 450 or 500 sector transfer (varies). I flashed it to the latest firmware, 11.09.2004, which didn't help -- very disappointing.

Over USB, your test program passes, and takes about 40 seconds.

In desperation I applied the Max128K device filter referenced on your page. Sure enough, this works -- the test program passes! But the hitch is that the transfers are now limited to such small chunks that it takes 120 seconds -- 3x slower than USB! Oh well. So much for PL-3507 firewire.

This is interesting because I would not expect limiting the I/O size to 128K to have any performance impact. Perhaps there is something else causing the performance difference. Then again, I have not used the Max128K driver so I do not know exactly what it is doing. It is also interesting to hear that the firmware update made no difference for this user.

March 27, 2005

Scruge writes us:

I've been having some of the same problems as others have mentioned earlier.
I purchased 2 PL3507 based 1394/usb2 combo enclosures several months ago and have been trying to trouble shoot their (1394) problems. Usually both drives will become corrupted to the point of not being readable by the OS. Requiring a file recovery program such as ezrecovery followed by a full initialization of the drive. I've updated both the drives since with the 11-09-04 prolific (chip C) firmware, and the problems with one drive have seemed to deminish. However strange as it may seem the other drive will not work with Windows 2000 (detects, but list as nonoperational) after the update, but works radomly with Winxp.
Based on my opersevation I'm beginning to think the problems with the Prolific bridges are more quality and design related issues than firmware. I think the firmware updates are attempts at masking a poor design or quality by the foundry. For those of you interested, you may find this link helpful for the current firmware updates. http://tech.prolific.com.tw/visitor/v_fileBrw.asp

FYI. both drives were identical configurations. Maxtor Quickview 250gb hdd. I actually swapped the Prolific bridge boards between the 2 enclosures only to find the problem moved with the board.

April 5, 2005

Richard writes us:

Like a previous poster, I have had data multiple data loses with Shuttle SFF & IcyBox Enclosures (but not LaCie).

I do not know what the solution is BUT I spent hours try various software tools for recovering data where the external drive had apparently corrupted MFT tables & ' lost its NTFS format.

The only one that worked was FILE SCAVENGER 2.1 from QueTeK, cost $40.

Worth every cent and recovered over 240GB on the Exhaustive Search option.

PS I am so sick of this I am buying a RAID enclosure for Storage.

" I recently bought an external USB/FW enclosure called "Icybox" which uses the Prolific PL3507 chipset with an Hitachi/IBM 250GB 7K250. I used it with the firewire connection flawlessly on a friends MSI Mega 180 barebone, but as soon as I connected it to my own Shuttle SN45G which uses the Realtek chipset, within 15 minutes the drive was totally ruined. Chkdsk says "unable to determine NTFS version info". The 1394test.exe worked perfectly, no problems found. I downloaded and flashed using the latest Prolific firmware which had no effect. Using the USB connection I have had no problems whatsoever, but only get around 25 MB/s read, 20MB/s write. Firewire was around 35MB/s. I'm running Windows 2000 with SP4. "

May 22, 2005

Keith writes us:

Just a quick note regarding the 1394 DWF page. Firstly - thanks! A very useful resource and by far the most useful I found when googling. One thing it *might* be worth mentioning is to check for overclocking. After trying more-or-less all the various approaches to fixing the DWF with my Lacie P3 and KT266a-based PC with no luck, I eventually remembered that I'd applied a 5% overclock - FSB from 133 to 140. Resetting the BIOS to go back to 133 fixed the problem.

Stupid, I know - it's the first thing you need to check when you have problems. It was such a minor O/C (Athlon XP1700 to XP1800, woo!) and had been done so long ago, however, that I clean forgot about it. However I've just successfully copied 14Gb of photographs to the 1394 drive without a hitch - whereas previously it would DWF,DWF,DWF then disconnect. Probably, most people who o/c would think to back off if this sort of problem occurred - but you never know.

Anyhow, thanks again - I've bookmarked the page incase I ever have a similar problem in future.

George writes us:

Hello this is George Again.

After failing to use the Maxtor fix mentioned, I tried again. Someone said follow the instructions. I didn't.......

When it says "Remove the FireWire Drive from the system", make sure you follow the step to use the "Safely Remove Hardware" icon in the lower right corner next to the clock. DO NOT REMOVE THE 1394 FireWire cable as a way to remove the firwwire drive from the sytem.

I remember in Windows-ME you were suppose to disconnect using this method, and Windows XP solved that problem. So I assumed they wanted me to remove the 1394 firewire cable to remove the firewire drive. WRONG.

Leave the 1394 cable in then run the Maxtor fix with the file 1tchcfg.exe and it worked this time. Files transfer without a Delayed Write Error, but as someone mentioned at a slower rate. So now I can use the FireWire cable to transfer. Better then nothing until microsoft and the vendors get this fixed so I can run at full speed.

The fix was mentioned by the NETGUY post to this page.... http://forums.viaarena.com/messageview.cfm?catid=16&threadid=50469
which has the fix from Maxtor that worked on my 250G One-touch drive. I originally tested the drive using the test file 1394Test.exe and it showed errors, but after installing the fix from the link above I'm running without the dreaded "Delayed write Failed"

Otto writes us:

First thanks a lot for this great page.

I was able to fix the delayed write failures that I encountered in my old USB1/Firewire (Oxford 911) case.

The disk in the case is a Maxtor 40GB. Using the 1394Test.exe tool I was able to reproduce the problem every time. The problem happened in 3 diferent machines running W2K, WXP SP1 and WXP Sp2. I tested several firewire cards with the following chipsets: TI, NEC, Ageere, Via and Ricoh.

The first thing I attempted was updating the firmware from version 2.x to 4.0 and no luck. Then I attempted some of the tools listed in here, but all of them failed. Finally I attempted changing several parameters of the Oxford 911 chipset and one of them did the trick. After lowering the transfer rate from ATA-5 (100) to ATA-4 (66) the problem is gone.

June 13, 2005

We have a couple more end-user reports of how they resolved their delayed write failures:

Catalin writes us:

Thanks for your excellent thread on this issue. I have a sunnytek firewire/USB enclosure (Oxford 911 chipset) with a WD 160GB harddrive. I had constant write delay problems. This is how I solved it (thanks to all comments in the thread):

installed me.350f (installed the Oxford chip uploader)
downloaded the latest firmware from http://fwdepot.com/firewiredepot/firmware/FW911_V4_00_0000_Release.bin
Open FWUpload.exe (C:\Program Files\Oxford Semiconductor\OXFW900 Uploader)
"Upload/Upgrade device firmware" search for the directory where you have downloaded the .bin file and select it, press ok
Repeat step 3 but press "modify design configuration settings" --> Go to "Advanced"
Make sure transfer is at 1024 and UDM 4 (max), Enable "GPI Drive Detect", "Detect drives with non-std signature" and "Wait 6s before polling drive" - that's it!

Note: Check with 1394test.exe before step 5 (you might not need step 5 and 6).
Note: I had all sorts of applications running in the background but it did not seem to interfere.
Note: The pagefile configurations ("managed by Windows" for internal drives and "no pagefile" for external drive) did not seem to make any difference.

Thanks a lot to busTRACE support!!

Ryan writes us:

I have had 'delayed write failed' errors for over a year, and after reading your page on the subject, I know I don't need to describe the utter frustration they caused.

Just wanted to relate that after trying several solutons described by other users, installing the firewire controller from unibrain finally did the trick! Best 15 bucks I ever spent. FYI - I didn't receive errors from the test program, and I am sensing that users who don't receive an error from the test program all seem to be fixing the problem by installing the ubCore. If true, this might be worth pointing out.

Thank you, thank you, thank you for hosting this page!

Matthias writes us:

Thank you for keeping your page up to date, and for all the useful information collected.

I never could tell if the problem on my two external 1394 drives was due to delayed write failures because all my tested configurations passed your 1394 test successfully, still both drives unmounted randomly when writing large (or even a lot of small) files to it. Microsoft describes this at kb885464, but as a win xp problem. I had exactly the same problem in W2K.

Both of my drives use the prolific 3507 chipset. I tested all firmware versions, I tested pinnacles pci bus enhancer ppe.exe (versions 1.11-1.15). the filter driver at http://www.dvico.com/Download%20SW/1394%20MaxRec%20Filter%20driver/1394MaxRec_v127.exe did help but reduced the performance by 20% (!).

Finally I could solve my problem:
I went to http://ryanvm.msfn.org/ and got the package with all the latest patches from MS and integrated it in a XP CD and set up my system new. All problems are gone. Before I tried to integrate all new versions of sys files (1394....sys, sbp2port.sys etc) manually into my system which did not help. Only the complete reinstallation works as expected. Maybe the problem was more connected with others like pci drivers, chipset drivers etc.

Anyway, thanks again

Jeff writes us:

I've written an article about a solution to the Windows Delayed Write Failure you might be interested in. There are some good links on that page to recommendations by LaCie too.

http://www.jeffzimmerlin.com/Pages/FeatureArticle.php?Number=21

June 20, 2005

Don writes us:

Purchased an external Iomega HDD 120GB Dual USB/Firewire drive over a year ago to use as a backup media with Retrospect 6.5 and later 7.0. From the beginning, I was able to complete the backup using the USB port. However, backups using the firewire port failed with "Communication failure errors" and the drive would disappear. Disconnecting the drive and reconnecting or rebooting would bring it back. I never had a problem with the drive except with Retrospect so I was not sure I was actually dealing with the Delayed Write issue. The drive passed your delayed write failure test.

I tried the following solutions mentioned on this site to no avail: Updating to SP2; Installing the Microsoft hotfix KB885464; and Using the 1394 MaxRec software. I finally cracked open the case of the HDD 120 GB and found that the drive had a Prolific PL3507 03511C bridge chip with a firmware version 8/13/2003(200). I installed the firmware update fw_pl3507B_d120904.zip using Romwriter rw_pl3507_icp_v221.zip found on the website http://tech.prolific.com.tw/visitor/v_filebrw_result.asp. (I read the chip FW version using the RomWriter software.) No problems with the drive and Retrospect since.

July 5, 2005

Like many end-users who contact us, Luigi resolved his delayed write failures by updating his bridge chip firmware. He writes:

1394 delayed write failures - A success story.

The configuration:
- Seagate External 300GB FireWire/USB2 hdd (OXSEMI FW911);
- Sitecom FW-008 FireWire/USB2 PCI adapter (Agere OHCI 1.0);
- Giga-byte GA-7VTXE motherboard (VIA KT266A).

The tragedy:
I've bought an expensive external hdd unit, which was literally unusable under NT5.0sp4: connecting it, the system hung and the ext hd filesystem became heavily corrupted. Under NT5.1sp2, the system was more stable, but randomly (not necessarily under load) the infamous message appeared and all the data was gone. The 1394 Delayed Write Stress Test passed with success if the write cache was disabled, with failure with write cache enabled.

The solution:
I've wandered for any solutions different from the firmware upgrade, but with no success. I was very struggled about the FW upgrade, but finally I've decided: I must risk! Well, i've flashed the ROM with the fw rel4.0 (from fwdepot.com) using the OxSemi Uploader v4.2 - despite a message which told me that the release was older than that installed -, and all problem was gone! I've received again once a corruption message, but only due the OxSemi Uploader program (used for settings verify) which blind locked the drive forcing me to a brutal bus disconnection. This isolated issue apart, the drive had a rebirth, and the new firmware consents restfully some settings (BS=2048, UDMA=5, WriteCache Enabled) that, in conjunction with a increased PCI timing (32 to 64 clock's cycles), have boost my drive with absolutely no failures nor file or filesystem corruption.

Epilogue:
Now I'm an happy man; despite of this I will buy an internal 200GB PATA hdd to put beside the my olds 40GB + 2x30GB RAID hdds, and leave the 300GB ext hdd only for temp and backup purposes. Is better to not dare the fortune...

Thanks a lot for your page,
Luigi

July 15, 2005

Michal writes us with a link to a delayed write failure resolution with the Maxtor OneTouch (Oxford 911 based enclosure):

http://club.cdfreaks.com/showthread.php?t=142210

August 1, 2005

Jason writes us:

Found your page while searching for a solution to my slow firewire transfers. When I'd attempt to store large amounts of data, the drive would pop the Delayed Write failure notice, regardless of settings. Within your tidbits tho was a hint to try Lacie 400 card, so off to Ebay and I bought one for $14.

I replaced my VIA VT6212 chipset card (USB2/FW) with the VT6306(I think) Lacie.

Upped the UDMA to 5 and the transfer to 2048 (max) and the Oxford 911 chips worked just fine for an 80gb transfer.

So for me, yanking my cheap firewire card NEC compatible solved my problems. Everything else failed, but the max length utility worked fine too.

Dominik writes us:

Some time ago I got a HDD enclosure based on the Prolific 3507 chip. I immediately started getting Delayed Write Failures. I tested many configurations to the following effects:

The problem was almost nonexistent in Windows 2000 SP4.
The problem was worse in Windows XP SP1, making the enclosure practically useless.
The problem got critical in Windows XP SP2. Any attempt to write to the external drive resulted in an immediate write failure. Installing the KB885464 hotfix from Microsoft helped only a little (the write failure occured after about 2 secs instead of immediately).
Upgrading the firmware to the latest version did not help in WinXP (SP1 or SP2) at all.
On the other hand, the enclosure works flawlessly on a Mac. All this would point to either a problem with the FW controller in the computer (I cannot check what it is as it's a notebook, but I guess it's a VIA) or buggy buggy drivers from Microsoft - especially since different OS versions have different symptoms.

Quite recently I bought a second enclosure, this one based on the Genesys GL711FW chip. I have already copied hundreds of gigabytes to and from it and have not had a single delayed write failure (tested under Windows XP SP1 and on a Mac).

So I guess it all comes down to finding the right combination of controller chips in the computer and the external device.

NOTE: This sounds to me like the Prolific bug discussed previously. Changing to a different enclosure fixed the problem.

August 17, 2005

Curt writes us:

I recently dealt with a client who'd bought a cheap USB2 HD caddy from ebay.

We couldn't copy any more than 100Mb before the drive failed - your utility showed us that the problem was indeed identical to the firewall problem you and your viewers have been suffering

Unsure of the controller make or any other info (he wouldn't let me strip the case without trying every other option first) I started with the basics.

Microsoft XP SP1 was installed, added the USB2 update as mentioned on your page

Turned off write behind on ALL hard drives (this seems to have been a big part of the key) - now we could write about 1400Mb before the drive failed - not a bad improvement.

Still, when copying say a home movie onto the drive, it would fail.

I tried everything, even jumpered the drive as CS Master Slave and Limit at 40gig. Nothing worked past there.

Then the simplest of solutions hit me - it's not perfect, but it works.

I re-enabled everything I'd disabled, other than write behind, and plugged the USB2 lead into a USB2 port right next to another which went off to a powered hub.

My thought was simple, if the packets are getting interrupted by other packets to and from the printer, scanner, keyboard, mouse etc - would the other peripherals become unstable too?

I successfully copied 60Gb of data from one drive to the USB2 drive without a hitch... And at USB2 speed (i checked to ensure this WASN'T a USB1.1 port before I plugged in, we already knew 1.1 worked fine)

The motherboard is a Gigabyte K8VT800M. 64 Bit Athlon processor, Windows XPSp1, other devices on the USB2 were HP Scanner, Printer, Philips Toucam 740Pcvc, Logitec Mouse/KB and a GPS module.

I don't know if this is a help to anyone, but sometimes the simplest solutions can lead to the most brilliant results.

All the best, and thanks for the information!!

Abi writes us:

I was getting Delayed Write Failure writing large files onto my external HD enclosure using firewire and I came across this site.

The enclosure has USB 2.0 & firewire ports. The USB port works just fine, but the firewire port gives me DWF when writing large files. It's using Prolific PL3507 chipset. After much unfruitful experiments and long nights troubleshooting, I gave up and bought an Adaptec fireconnect. I'm still crossing my fingers, but it's been working without a hitch for a couple of days now.

The difference between the two controllers are the chipsets. NEC chipset results in DWF while TI doesn't.

September 6, 2005

Harry writes us:

Gentlemen, First thanks for giving people a place to share their bad (and good) experiences with Windows XP and Firewire drives. You're doing a great service here.

After a long and fruitless search for a solution to the delayed write error syndrome that made my multibay Firewire enclosures unusable, and having lost many hundreds of gigabytes of data, I am overjoyed to report that the solution for me was so simple that I could almost kick myself for not thinking of it myself a long time ago.

First, I am running Windows XP SP2 on an Athlon XP 2500+ powered Asus A7N8X-E motherboard. I am using an ATI 9800XT for the graphics. I also have 1 GB of system memory. The problem was so bad that I actually did not have to be doing anything on the PC to get a DWE error. I could simply turn the enclosures on, and the drives would be enumerated by Windows and then I could simply walk away for a few minutes and when I came back, there would be the popup in the system tray telling me that there was DWE error. I have tried ALL the suggested remedies on your page. Firmware updates, 1394 drivers from uniBrain, PCI latency adjustments, pagefile adjustments, 128k filter driver, registry mods, tricking Windows into accepting pre-SP2 firewire drivers and much much more. Nothing worked. For the last several months I have not turned on my Firewire enclosures for fear of losing more data. Finally in a last ditch attempt, I surfed the net to see if anyone had any new suggestions. I found two suggestions

Set the "Turn off Hard Disks" to <Never>, in the Power Management applet in the Control panel.---> At the same time go into the bios settings and turn off the Hard Disk Spin Down timer in the Power Management section of the Bios setup program. This is the only setting that I changed. The rest I left in the default state.
I downloaded a copy of Cacheman, a shareware/freeware utility to manage Windows memory and cache settings. The version number is 5.5.0.30 Please see the page at http://www.computing.net/windowsxp/wwwboard/forum/133276.html and scroll down to response # 9.

As of this writing, I have been DWE free for 24 hours straight. I am running 6 hard drives in 2 multibay enclosures and have not had a single hiccup. I am now almost confident that I won't be seeing a DWE anytime soon (knock on wood).I just had to share this with you and the rest of the folks who have had problems with this issue. I hope that it works for everyone.

We received a follow-up e-mail from Harry who writes:

I would like to add something of possible to my entry. I am using a TI chipset based FW controller card so just having a TI chipset is no guarantee that the DWErrors will not occur. The post immediately before and after, seem to suggest that a TI chipset will cure DWE.

And as of now, several days later, I STILL have not had a single Delayed Write Error.

September 8, 2005

Ralph writes us:

Hello all, excellent reporting forum for the 'Delayed write error' problem with windows. Just thought I would report my results with this situation. Recently purchased Nextstar2 525UF unit, with Prolific PL-3507 05034C Chipset. I am running Xp SP1 and am using a Compaq Presario 902AU which uses the Texas Instruments firewire controller. Have copied 36GB of 600mb+ movie files onto WD250Gb caviar drive without so much as a whine so far. Loving the TI chipset I guess. Haven't had to install or alter anything, just running fine. Best of luck all, Ralph.

September 9, 2005

As you see from above, we receive e-mails on a regular basis with questions and answers regarding delayed write failures under Windows. We have created a feedback forum where anyone can add their own comments.

Visit 1394 Delayed Write Feedback Forum

June 27, 2006

This blog, as well as our feedback forum, should provide you the means to fix your 1394 delayed write failure. Because the information you'll need is likely already here, we have not taken on any more submissions. However, we have recently received one additional resolution that we thought others might find useful. The author writes us:

Hi, probably you guys are fed up with being the central place of information for "delayed write" problems. but as i was spending hours of trying things suggested here without success, i'd like to share what worked for me now:

i have an hp - compaq nx9105 notebook which has a built in texas instruments firewire chipset. i have two raidsonic (IB-360UE & IB-350UE) firewire+usb combi enclosures, both using the prolific 3507 chipset. The problems were mainly with the older of the enclosures, the 350UE, constantly having the dreaded "delayed write" problems, but also messing up the whole chain of firewire devices (the drives and my DVD burner) when getting stuck... Now, i dont have problems with delayed write anymore using this solution:

Part 1 - Prolific Firmware Update---http://club.cdfreaks.com/showthread.php?t=150025 in this post they suggest downloading a new firmware from prolific which is here: ---

Part 2 - XP Sp2 Hotfixas user Luke points out in your guestbook it is possible to grab the KB885464 Windows XP SP2 Hotfix from an HP Notebook service pack -> http://h18007.www1.hp.com/support/files/Compaqtabletpc/u s/download/22721.html

I dont know if either of this would have done the same thing but as a combination it did work fine!thanks for your website.

December 20, 2006

My experiences with the released version of Vista follows.

I just installed the released version of Windows Vista on a brand new development system. I put a 1394 card into the system and plugged my hard drive into it. Vista couldn't mount the file system at all. I couldn't see any files. Unable to get it to work, I brought my 1394 external hard drive back to a Windows XP system where it worked fine. I copied the files to the local drive, reformatted the 1394 drive, copied the files back onto the 1394 drive, and brought the drive back to the new Vista system.

The good news is, with the newly reformatted drive, Vista could successfully mount the drive. I do not know why I had this problem. I suspect most will not, but I thought I would mention it.

Having run my drive for several days on Vista, I have noticed a recurring annoying problem. I do not believe it is the delayed write problem. Every now and then, the drive just disappears from Vista. The drive letter is gone. The drive is still powered up (it's bus powered) but the drive letter is gone. I have to disconnect the 1394 cable and plug it back in to make it reappear. I think it has something to do with power management issues but I don't know for sure. This really messes up any apps that have open files on the drive.

Rather than trying to debug this issue, I've decided to give up on 1394 hard drives for Windows. I wanted to get a faster drive anyway so now I'm going with a USB hard drive. Not that USB is better, but I do believe it is a better "tested" interface and that is key for me. I want my external hard drive to be stable.

My new drive should arrive next week. I hope those of you that are visiting with 1394 delayed write failures will find a solution on our site.

January 3, 2007

I purchased a Seagate 100 GB Portable External USB Hard Drive to replace my 1394 Hard Drive due to the problems I had with Vista (see December 20, 2006 post above). I have been able to use the drive for a week now and I thought I would share my results.

First off, I have not had any problems with this drive under Vista. It's bus powered so I only have the USB cable going from my PC to the drive. It is formatted with NTFS. It is physically bigger than my older drive but it is still small enough.

I do have a couple of minor issues with the drive:

The USB connector going into the back of the drive is the micro USB connector even though there is plenty of room for a normal USB connector. This should not matter either way but I have found that the micro connector is more susceptible to bent pins. Since I plug this drive in and out a lot, it's a concern.
The drive spins down on its own too quickly. In my normal use the drive's firmware spins the drive down and then it quickly spins back up again whenever I access the drive. In just my normal everyday use, it will spin up and down all the time. I worry about the unnecessary wear on the drive. I have an e-mail into Seagate asking how to adjust this setting in the drive.
When the computer is in sleep mode (i.e. suspend), the drive light stays solid on. It does this on multiple test systems. Obviously the drive is still getting power from the USB bus. I do not know how good Seagate is about trying to reduce power in this state but obviously they didn't care that the light on the drive would stay solid on. How could anyone at Seagate miss this obvious point? It's rather bizarre.

January 25, 2007

My new USB hard drive (replacing my 1394 hard drive) has been working without any issue on Windows Vista and Windows XP. My only concern is the frequent spin down/up I cite above.

Anyway, Keith sent us an e-mail with some information that might be useful to those of you with continuing delayed write failures. He states that he has some useful information for those of you with the Prolific chipset. He was able to download updated firmware from:

http://www.prolific.com.tw/eng/Download-2.asp?ID=18

Enjoy.

April 23, 2007

On January 3, 2007, I purchased a Seagate 100 GB Portable External USB Hard Drive to replace my 1394 hard drive. I had a couple of minor complaints but was overall happy with the drive. No delayed write failures encountered.

Well, as it turns out, a major problem occurred this past weekend. No, this is not any delayed write failure, this is a complete loss of any ability to access the drive. I turned on my Windows Vista PC on Saturday morning and Vista was looking for drivers for the Cypress AT2LP RC42. No drive letter for my Seagate drive appeared. I had no ability to access the device.

I went to the Seagate web site and did a search for for this error thinking that I would find a software fix for this. I couldn't find one. Doing a Google search, however, turned up quite a few hits. This is not an isolated case and Seagate gets a big thumbs down for not having any information on their web site for this error or how to fix it. I came upon this thread that proved interesting:

http://www.everythingusb.com/forums/showthread.php?threadid=8760

Some discuss a flash utility you can download that resolved the issue for them. I didn't try this approach because I wanted to use another bridge controller instead.

Another site I read said that Seagate stated this as a drive failure and would fix it if the drive was under warranty. A call to Seagate technical support was useless as it was the weekend and they were closed. So there I was, with no ability to access my data, and no approved method to fix it. I felt the actual drive inside the casing was good. This was yet another bridge chip bug. Something caused the Cypress chip to lose its programming and default back to some initial state.

I couldn't wait until Monday to try and contact Seagate nor was I optimistic that they would help me. So, I decided to open up the case and remove the actual physical hard drive. Note that with Seagate, they do NOT make it easy to open the case. I didn't have the right tool. Knowing I wouldn't be using the Cypress bridge chip again, I cracked open the case, and removed the ATA hard drive from the bridge controller.

Here is the bridge controller. Note the mini USB connector in the upper left, to its right the optional power plug, and below it, the ATA connector.

Flipping the circuit board around, we see the now infamous Cypress chipset. The model number is:

CY7C68300B-56PVXC
B 04 PHI 0625
CYP 644711

Do a Google search on CY7C68300B and you'll find additional information on this Cypress chip if you're interested.

If you remove your 2.5" hard drive like I did, be very careful, it is easy to bend the ATA connector pins on your hard drive when you remove it from the bridge controller.

I wanted to make sure my data vas still valid on the hard drive. As discussed above many times, I previously used a SmartDisk FireLite 20GB drive. I still had the drive but no longer needed it. I decided to open up the SmartDisk case and use its bridge controller instead. Here is the SmartDisk 1394 bridge controller. Note that this was manufactured back in 2001 so this explains why the controller is more than three times the size of the Cypress controller.

Note the ATA connector on the left. I expected to find an Oxford Semiconductor chip based on my previous SmartDisk drive. I was a little surprised to find a Texas Instruments bridge chip. So in the case of my FireLite drive, it was the TI chip that was causing the delayed write failures.

Here is the TI chip:

26D7FTT
TSB42AA9APZT

A quick Google search shows this chip to be the TI StorageLynx 1394 Link-Layer Controller for ATA/ATAPI Storage Products.

Here is the back side where the 2.5" ATA hard drive rested. Note the two 1394 connectors on the right side.

With the Seagate 100GB hard drive now attached to my 1394 bridge controller, it was time to plug it into my Vista system. The good news is that my data was still present. I immediately copied over the data onto my PC's hard drive to have a backup.

I needed a permanent solution to this since I didn't want to use this 1394 bridge controller (which had its own set of issues). So, I went down to Fry's Electronics and purchased an inexpensive 2.5" USB 2.0 HDD Enclosure. Actually, since they were so inexpensive, I bought two of them from different vendors. This way, if one bridge controller flakes out, I'll have a backup.

I detached my 2.5" ATA hard drive from the 1394 bridge controller, put it into its new home, plugged in the USB cable, and I'm back up and running.

My recommendation is that you first contact your drive enclosure company before you take a drastic approach like I did. Hopefully they will provide you a software solution and you will not need to open up your case. If you do open your case up, be very careful removing the hard drive from the bridge controller. Mess up your hard drive and you'll be in a world of hurt.

November 20, 2007

This site continues to get a lot of monthly visitors. Earlier I showed how I put a new USB external case for my 2.5" hard drive. This drive was powered by the bus. I used both USB inputs to make sure there was enough power for my drive.

After using this configuration for months, I noticed a recurring problem. Every now and then, the USB drive would just shut down and I would lose access to it. Needless to say, if I was reading/writing to the drive at the time, this would be problematic. I was guessing it had something to do with being bus powered but I had no proof. Unplugging the hard drive and plugging it back in got it out of this situation. I didn't have an AC adapter to plug into the drive to see if that would solve it.

The problem has annoyed me and so a week ago I purchased a 3.5" USB external hard drive (with larger capacity). This drive is not bus powered and so far things are working fine. However, given all my bad experience with external storage on Windows, I wouldn't be surprised if another problem comes up.

We received an e-mail from another end-user. Normally we do not post these, as we already have so many solutions on this site, but I thought this might be helpful:

I have XP SP2 and facing delayed writes on my Lacie BigDisk 500GB dual interface (USB/Firewire) since a few years.

What worked for me at the end (and thanks for the wonderful source of information and ideas you provide) was a combination of firmware updates, microsoft updates and interface changes.

The USB interface was giving me random delayed writes, but i could not flash the drive as the Lacie software for my disk only works with the Firewire interface, which was not functioning on my computer.

The solution came with "WindowsXP-KB885222-v2-x86-ENU.exe" which enabled again the malfunctioning driver of the "Texas Instruments OHCI Compliant IEEE 1394 Host Controller". After this was installed, the drive was recognized via the firewire interface and i was able to flash the drive using the utility from the Lacie website. I tested the drive with the "1394 Delayed Write Stress Tester v1.0.002" utility and it went flawless. Thank you so much for helping me with a problem i was enduring for years.