lkml.org 
[lkml]   [2007]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: "Fix ATAPI transfer lengths" causes CD writing regression
    Ok, gave this a hard look.

    This is basically a behavior change with regards to how we program the
    bcount(low) and bcount(high) registers.

    Issues about FIFO draining and devices returning too-much data are
    ultimately tangential. Furthermore, this is an ATAPI PIO issue, as
    demonstrated by (a) Alan's patch did not change DMA lbam/lbah
    programming and (b) Daniel's report of the message "ata2.00: 66 bytes
    trailing data" which occurs in the PIO state machine.

    To survey the behaviors for ATAPI PIO:

    ide-cd: read/write commands, blimit = 32k
    others cmds, blimit = xfer_len

    old libata (pre-Alan): blimit = 8k

    new libata behavior: blimit = xfer_len

    thus Alan's patch was moving us CLOSER to ide-cd's behavior (if we
    ignore read/write commands for the moment, which are not at issue).

    and the end result is that the change from old-libata to new-libata
    behavior broke Daniel's case, which is a device known to ignore the SCSI
    command CDB's allocation length field.

    Additionally, let's add some background:

    libata was originally written for first-gen SATA controllers (incl.
    first-gen SATA bridges), most notably ata_piix, the controller Daniel is
    using.

    I chose blimit 8k because I felt that matches the maximum size of a SATA
    Data FIS. I felt -- this was a wild-added guess -- that setting blimit
    thusly would properly configure all the magic internal FIFOs and data
    buffers in silicon that handled these crazy ATAPI devices with random
    transfer lengths.

    I am not drawing any conclusions yet, but I'm thinking that blimit=8k
    may be a better choice for SATA ATAPI.

    Other comment:

    * as Tejun noted in IRC, we don't have a clear idea of what triggered
    the HSM violation. turning on debugging printk's would help, but
    unfortunately that means turning them on for everything, including hard
    drives.

    Jeff


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-11-01 10:51    [W:6.639 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site