On 10/15/06, Mark Rustad <mrustad@xxxxxxx> wrote:
[...] > Hm... if I put in some debug printks in the qc_issue code, I get the > same symptoms. I've observed that once again we get hung up on ATA > commands where the tag number > 0. I also noticed this pattern: > > 1. ATA command w/ tag 0 (command A) issued. > 2. Command A goes out to sas-ata. > 2. ATA command w/ tag 1 (command B) issued. > 3. Command A completes > 4. Command B goes out to sas-ata. > [...] > 5. Command B times out. > > Very odd that this all works if there are no printks. I don't see > anything obvious that would suggest why this apparent race seems to > happen--unless there's some conflict between issuing an ATA command > while completing another one. We have found in our system, using libata with Luben's driver, that the aic94xx sequencer expects the SATA commands to always have a tag of 0. The sequencer assigns its own tag before passing it to the drive. Interestingly, it seems to OR-in its generated tag value, so if a non-zero tag value is passed in, a real mess ensues.
Mark speaks the truth. If you're going to use libata as a SATL, then you have to force the sector count to 0 before feeding the taskfile to the aic94xx code. There may be a role for a flag to libata that lets it totally skip the tag allocation, when used with smart adapters like the 9410. There's little point maintaining the bitfields if they are going to be ignored anyway. You're also in for a bunch of fun servicing the SIGNAL_NCQ_ERROR escbs, suspending/clearing all outstanding I/O, issuing a read log page 10 command, mapping the tag back onto the original scb via the sister ddb, erroring that one, and retrying the rest. I'm working with mostly frozen code, so patches to the current de-Lubenised code are difficult (to put it mildly.) Sorry. -- Andy - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
