--- Andy Warner <andyw@xxxxxxxxx> wrote: > 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. Justin Gibbs explained many years ago the why and how of SCSI tags right here in linux-scsi in a thread. Their "domain", who is reponsible of allocating them and why, and why they are needed for (i.e. it is impossible to) managing SCSI Domains. Although not as detailed as I had mentioned above, his explanation is still true and holds today, as it did back then. > 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, Mark, SAS/SATL is now at 1.2.7, both having been updated as SAS and SAT had been updated. Luben - 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
