• T
    libata: bump transfer chunk size if it's odd · e190222d
    Tejun Heo 提交于
    None of the drives I have follows what the standard says about
    transfer chunk size.  Of the four SATA and six PATA ATAPI devices
    tested, four ignore transfer chunk size completely and the ones which
    honor it don't behave according to the spec when it's odd.
    
    According to the spec, transfer chunk size can be odd if the amount of
    data to transfer equals or is smaller than the chunk size and the
    device can indicate the same odd number and transfer the whole thing
    at one go with a pad byte appended.  However, in reality, none of the
    drives I have does that.  They all indicate and transfer even number
    of bytes one byte shorter than the chunk size first; then indicate and
    transfer two bytes, which is clearly out of spec.
    
    In addition to unnecessary second PIO data phase, this also creates a
    weird problem when combined with SATA controllers which perform PIO
    via DMA.  Some of these controllers use actualy number of bytes
    received to update DMA pointer so chunks which are sized 4n + 2 makes
    DMA pointer off by two bytes.  This causes data corruption and buffer
    overruns.
    
    This patch rounds nbytes up to the nearest even number such that ATAPI
    devices don't split data transfer for the last odd byte.  This
    shouldn't confuse controllers which depend on transfer chunk size as
    devices will report the rounded-up number, actually transfer that much
    and padding buffer is there to receive them.
    Signed-off-by: NTejun Heo <htejun@gmail.com>
    Signed-off-by: NJeff Garzik <jeff@garzik.org>
    e190222d
libata-scsi.c 91.0 KB