Re: "Fix ATAPI transfer lengths" causes CD writing regression

Jeff Garzik
2007-11-01T09:48:39Z

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