Messages in this thread | | | Date | Thu, 01 Nov 2007 05:48:15 -0400 | From | Jeff Garzik <> | Subject | Re: "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/
| |