2nd internal drive, Unibody MBP 15", UltraDMA CRC errors in Boot Camp XP

Discussion in 'MacBook Pro' started by arfle18, Apr 27, 2009.

  1. arfle18 macrumors newbie

    Joined:
    Apr 27, 2009
    Location:
    Brooklyn, NY
    #1
    Howdy,

    If anyone has experience using a 2nd internal hard drive in their Macbook Pro, particularly with a Boot Camp installation of Win XP (SP 3), I'd like to see if you're getting the same behavior. Essentially, everything seems to be behaving fine, except for the fact that my SMART disk-checking utilities list numerous Ultra DMA CRC errors with the new drive. I'll keep it as brief as I can while mentioning potentially relevant stuff:

    I recently installed a 2nd internal hard drive (purchased new) into my Unibody MBP 15", using MCE's Optibay kit to connect it where the optical drive would be. The new hard drive has the same specs as the OEM drive; both are Hitachi 320 GB 7200 RPM SATA 'Travelstars.' (HTS723232L9A360 is the model of the newer drive, HTS723232L9SA62 is the system drive.) Prior to installation, I hooked up the new drive via USB through Apricorn's DriveWire just to check it out, successfully scanned it, copied data on and off it without problem, etc.

    Physical installation went fine, the cable was seated properly, and the drive was recognized by both OS X and Windows. As I use it for shared program data between both OSs, I opted for formatting with NTFS, and use the Paragon NTFS driver (v.7) to read, write, and scan on the Mac side, which works very well. Internal transfer speed from one HD to the other was oddly slow under OS X with the drive formatted with a GUID table, so I switched to MBR, which seemed to fix the problem.

    On the Windows side, however, internal transfer was still very slow, 1/10 or so what it should be. After investigation, I found that the Secondary IDE channel in the Device Manager would start in UltraDMA Mode 6, but while transferring large amounts of data from one drive to another, progressively bump itself down to lower DMA modes, eventually landing in cruddy old PIO mode. On restarting, the DMA mode would reset to UltraDMA 6, but go down again to PIO if I transferred lots of data, streamed large amounts of audio from the 2nd drive, etc.

    I searched online, and finally found a little VB Script that someone had written to force Windows' IDE channels into DMA mode (http://winhlp.com/node/10), which, happily enough, seemed to correct the problem; the Secondary IDE channel now always stays on UltraDMA 6, internal transfer from drive to drive is equally fast under both OS X and Windows, the data is always readable and can be copied without any errors, I can stream many audio tracks without dropouts, and things have been fine for the month or so since I installed it.

    I have run numerous disk checks of the drive on both the Mac and Windows side, and all reports are normal, with no corrupted areas or anything, EXCEPT that my SMART-checking utilities, DiskCheckup for XP and SMART Utility for OS X, find that the 2nd hard drive has thousands of UltraDMA CRC errors. Testing this, I checked the numbers they reported, copied 2GB or so of data back and forth from drive to drive, and sure enough, the number had risen by 30 or so under both utilities. This seems consistent with Windows' bumping the drive's transfer speed down before, except that now things are being forced to stay in UltraDMA mode, even though the errors may still be occurring. I assume OS X just forces a higher transfer rate, and hadn't bumped down the rate before as Windows had, but the UDMA CRC errors are occurring when copying data under both OSs.

    So my question is: given that everything to all appearances really seems to be fine and stable, behaviorwise, datawise, and disk scan-wise, is this something I need to worry about? Is this an anomaly on my machine, or are other people with 2nd internal drives also seeing this behavior with transfer speeds dropping to PIO, or getting UltraDMA CRC errors in their SMART disk checking programs?

    Thanks,
    Howie
     
  2. panzer06 macrumors 68030

    panzer06

    Joined:
    Sep 23, 2006
    Location:
    Kilrath
    #2
    Is it possible the optibay doesn't properly support SMART? I have a few external housings that do not. Could the CRC error reports be false? Seems that you'd have corrupt data by now if there was a genuine problem. Just a thought.

    Cheers,
     
  3. MacModMachine macrumors 68020

    MacModMachine

    Joined:
    Apr 3, 2009
    Location:
    Canada
    #3
    hi,

    im using 128gb corsair and 500gb hdd , homemade sata optical bay cable and i have had no problems,

    i have run several os's from the 500gb and ssd.

    hope this helps
     
  4. arfle18 thread starter macrumors newbie

    Joined:
    Apr 27, 2009
    Location:
    Brooklyn, NY
    #4
    Thanks for the replies, folks.

    panzer06 - I assume the optibay does support SMART, as it shows up in the list of SMART drives under all my SMART utility programs, and other drives I've attached by USB and whatnot don't show up there. Good thought, though, maybe I'll check with MCE. As you said, it seems like I definitely would have seen problems by now if the reports weren't bogus.

    MacModMachine - Have you checked out your UltraDMA CRC error count in any SMART Utility program, before and after copying more than about 2GB of data at once from one internal drive to another? To all outside appearances, everything is fine here for me, but copying lots of data definitely raises the CRC count. I'd be curious to see if you get the same results!

    Thanks!
     
  5. arfle18 thread starter macrumors newbie

    Joined:
    Apr 27, 2009
    Location:
    Brooklyn, NY
    #5
    Resolved, it seems.

    Well, after trying out a few things, just for the hell of it, I swapped the hard drives' positions, so now the former system drive is in the optibay and the old optibay drive is in the system position. For some reason, this seemed to correct the problem; I don't get any more CRC errors when copying data in either direction. I had thought it might have been a cable seating error, but on switching them back to test that out, the problem reappeared.

    So, now they've swapped places in their bays, and who knows why it worked, but the problem does seem to have been corrected!

    Thanks
     

Share This Page