locked
Sandisk Extreme Pro 64GB only shows 31 GB RRS feed

  • Question

  • I have a 64GB SanDisk Extreme Pro. We are trying to read it in a JMicron based PCIe to ATA controller we have designed into our product. In the Mac, either ExFAT or FAT formatting shows 64 GB as expected. Under Windows (Vista through 8) it only shows up as 31 GB.

    I traced it back to inconsistent information in the results of the ATA IDENTIFY command - the command that returns the number of cylinders/heads/sectors-per-track, name, capacity, model, etc. The Sandisk reports:

    0xffff cylinders (Word 1, also Word 54)

    0x0010 heads (Word 3, also Word 55)

    0x003f sectors/track (Word 6, also Word 56)

    0x03effc10 sectors capacity (Word 57)

    0x07736000 sectors LBA capacity (Word 60)

    ??? Two different sector counts?  0x07736000 (LBA count) is  64000884736 = 64 GB while 0x03effc10 ("legacy CHS") is 33822351360 = 31 GB.

    So, it would appear that disk.sys is using the CHS numbers to compute the size. IOCTL_GET_GEOMETRY shows that it has been slightly modified, but still has the same number of sectors:

    0x1010 cylinders

    0x00ff tracks

    0x003f sectors/track

    IOCTL_STORAGE_QUERY_PROPERTY shows a bus type of BusTypeAta. I wonder if this is special cased, since the BusTypeSCSI and BusTypeSATA no doubt use the LBA properties. Is my analysis correct? What can I do to get around this?


    Henry Kannapell Sonnet Technologies, Inc

    Friday, September 27, 2013 9:20 PM

Answers

  • t turns out that the issue is in the ataport driver, in the
    IdeSelectDeviceGeometry routine.  That is also why most people don't see
    it, as the USB based readers don't use the ataport driver.

    The IdeSelectDeviceGeometry goes through the checks to see if LBA-48 is
    supported on the device (which it is) but then makes the fateful check
    comparing the LBA-48 read from the Identify Command words 100-103 against
    0x10000000, which is the 28 bit 137 GB limit.  If the capacity is less than
    this, it ASSUMES that the CHS is valid, and not the LBA, even though all
    other indications are that LBA is supported.

    Unfortunately, there is also a "33.8 GB Limit", which is the largest
    capacity that can exist with the defaults of 0x10 heads and 0x3f
    sectors/track.  I'm not sure where this comes from, but it results in
    0xffff cylinders, which is what the SanDisk (and a Lexar) 64 GB devices
    have in their CHS entries.

    So, it looks like devices less than 33.8 GB and greater than 137 GB would
    have worked correctly, but devices in between will not if the CHS doesn't
    match the LBA. It appears that this behavior is different than the
    corresponding logic in the USB stack.  I say would have worked, because
    when I changed IDE_DEVICE_PARAMETERS in atapiHwInitialize to the correct
    LBA, it only worked if ATA_ADDRESS_TRANSLATION was set to lbaMode.  It did
    not work if it was set to lba48BitMode.


    Henry Kannapell Sonnet Technologies, Inc

    Wednesday, December 18, 2013 4:22 PM

All replies

  • Source for disk.sys is in the wdk, why not look at that?

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Saturday, September 28, 2013 12:33 AM
  • No, I formatted as FAT on the Mac (64GB) and then brought it to Win 7. It appears to read the partition map, but shows 31 GB size. It displays "31.5 GB RAW Healthy Partition". So, it appears to be a disk problem.

    On Doron's suggestion, we are looking at the disk.sys source code. There is a lot of CHS references in there. Since that is now obsolete per the ATA/ATAPI specs (only LBA is valid), I'm thinking that is where the problem is.


    Henry Kannapell Sonnet Technologies, Inc

    Monday, September 30, 2013 1:21 PM
  • Wow - I didn't realize that it was there. Thanks, we'll investigate in more detail and post our findings.


    Henry Kannapell Sonnet Technologies, Inc

    Monday, September 30, 2013 1:22 PM
  • t turns out that the issue is in the ataport driver, in the
    IdeSelectDeviceGeometry routine.  That is also why most people don't see
    it, as the USB based readers don't use the ataport driver.

    The IdeSelectDeviceGeometry goes through the checks to see if LBA-48 is
    supported on the device (which it is) but then makes the fateful check
    comparing the LBA-48 read from the Identify Command words 100-103 against
    0x10000000, which is the 28 bit 137 GB limit.  If the capacity is less than
    this, it ASSUMES that the CHS is valid, and not the LBA, even though all
    other indications are that LBA is supported.

    Unfortunately, there is also a "33.8 GB Limit", which is the largest
    capacity that can exist with the defaults of 0x10 heads and 0x3f
    sectors/track.  I'm not sure where this comes from, but it results in
    0xffff cylinders, which is what the SanDisk (and a Lexar) 64 GB devices
    have in their CHS entries.

    So, it looks like devices less than 33.8 GB and greater than 137 GB would
    have worked correctly, but devices in between will not if the CHS doesn't
    match the LBA. It appears that this behavior is different than the
    corresponding logic in the USB stack.  I say would have worked, because
    when I changed IDE_DEVICE_PARAMETERS in atapiHwInitialize to the correct
    LBA, it only worked if ATA_ADDRESS_TRANSLATION was set to lbaMode.  It did
    not work if it was set to lba48BitMode.


    Henry Kannapell Sonnet Technologies, Inc

    Wednesday, December 18, 2013 4:22 PM