No announcement yet.

HD transfer rate will go to 0.0 Mb/sec and never recovers

  • Filter
  • Time
  • Show
Clear All
new posts

  • HD transfer rate will go to 0.0 Mb/sec and never recovers

    When I am running BIT Pro 4.0 (1032) the HD transfer rate will go to 0.0 Mb/sec and never recovers. This problem appears to be intermittent and could happen after only running BIT Pro 4.0 (1032) a short as 1 hour or it could take up to 8 hours to appear. In the past the HD would go to 0.0 Mb/sec after running BIT Pro 4.0 (1032) for 8-10 hours. This was because BIT Pro was not cleaning up the temp files created while testing the HD. Are there any known issues with the HD transfer rate dropping to 0.0 Mb/sec after any period of time ? Any assistance that you could provide would be appreciated.

    Many Thanks,

  • #2
    We are also having HD transfer rate 0.0 MB/sec

    We are having similar problems. We are setting up burn-in stations for a custom motherboard being built for us by a contract manufacturer overseas. This is a fairly high-end motherboard for a piece of medical equipment:

    Two dual-core AMD Opterons
    4GB RAM
    NVIDIA nForce-Pro chipset (NVIDIA SATA driver V5.59)
    Three 250 GB SATA drives
    Two PCIe video cards with NVIDIA 7600 chips - Driver version 84.21
    Two gigabit ethernet ports
    10 USB 2.0 ports
    Windows XP-Pro (32-bit)

    Added for testing:
    PCI-X RAID controller with two 36GB drives as a RAID-1 pair (seen as one logical drive).
    Custom PCIe circuit board (not tested by BIT)
    9 USB2 loopback plugs
    10th port has USB2 hub with USB2 loopback plug, keyboard, mouse
    Two LCD/DVI monitors

    BIT configured for 8-hour cycle:
    CPU Math, CPU MMX/SSE, Memory (advanced), Video Memory, 3D Graphics, 4 drives, two network ports, 10 USB ports, Video Playback (clock.avi)
    All tests running at default 50% duty cycle.
    Task Manager shows CPU loading between 95-100%

    At anywhere from 1 to several hours, one or more (sometimes all four) drives goes to 0.0 MB/s transfer rate and stays there. BIT continues running, does not flag any errors, and at the end says PASS.

    I tried setting the Transfer Rate warning for when a drive goes below 0.01 MB/S. I did get warnings a couple of times, but usually not.

    After a drive goes to 0.0 MB/s, when you close BIT sometimes the PC fails to respond to user input (the mouse moves, but you can't do anything). If the PC does respond, Task Manager shows that the bit.exe process is still running, and can't stop it. Windows shutdown goes through the motions, but gets stuck at blue-screen, and we have to kill power. The Windows Event Log says that a process still had the Registry open when Windows tried to shut down. The drives will have ~bittest files left on them.

    We have been running BIT Pro V4.0 (1004). I tried V5.1 (1012) with similar results.
    Last edited by jduv; 09-08-2006, 06:15 PM. Reason: Added note about transfer-rate warning.


    • #3
      Over the last few weeks we have had about 3 reports of this problem. Because the problem only occurs at random and only after many hours of testing (and sometimes not at all), it was very time consuming to narrow down the problem.

      We tracked the problem back to a lockup in the Windows kernel. Which from a debugging point of view is close to a worst case scenario. As it is near impossible to debug the Windows kernel when you don't have the operating system source code. So for a while we were thinking it was a bug in Windows causing a dead lock.

      We continued testing on about 4 different versions of Windows, on a lot of different hardware with various different test combinations. After about 100 hours of testing over the last 2 weeks we now believe the problem is related to the latest versions of our USB2 loopback plug device driver. Version 2.1.1002 seems to have a problem that effects the I/O of hard disks. Both the USB and hard disks share some device I/O functions in the kernel, but we don't know exactly what the problem is at the moment.

      USB1 plugs don't seem to be effected. But both BurnInTest 4 and 5 are effected. As is Windows XP SP1 and SP2.

      Our testing has also shown that the slightly older USB2 drivers don't have the same problem (V2.0.1001). Here is a link.
      To test with this older driver, you must first uninstall the current drivers and then install the attached drivers. They must show Driver date: 25/11/2004 and Driver Version: 2.0.1001.0 - if not then something has gone wrong

      We are continuing to look at what the problem might be in the current USB2 drivers. But device driver debugging is a slow, complex process. Especially when we need to test each change we make for 24+ hours. My hope would be that we would have updated drivers available within a couple of weeks.


      • #4
        Thank You

        Thank you for the prompt reply. I appreciate (and commiserate with) your efforts to get the device driver debugged.

        I saw your post Saturday night, and went in to work and set our test stations to run the previous driver version as you suggested. They ran without any issues until we stopped them on Monday morning. This allowed us to ship the test stations to our contract manufacturer today (they were scheduled to ship last week).

        Again, thanks for the reply, and keep up the good work!


        • #5
          We have just released a new version of the USB2.0 Loopback device driver that corrects this problem, V2.1.1004. We recommend all users upgrade to this new driver.

          The new 32-bit and 64-bit drivers can be downloaded from:

          Best Regards


          • #6
            Install and Uninstall USB driver

            Do we have a way to install and uninstall this driver from scripting?


            • #7
              Not from a script no. Only from the Windows control panel.