>> For the first: busy/queue_full processing, the issue is that when we >> send out a command, we could get a BUSY or QUEUE_FULL return which comes >> back to us via IRQ context. Unfortunately, we could have multiple >> commands that do this and a command will be accepted as soon as the busy >> condition alleviates, so we could see say two commands go down in order, >> the first one will get BUSY, the second is accepted and only then do we >> get the IRQ that says BUSY to the first ... now we have out of order >> execution. > > Oh... I see. How many drivers do that? I can't think of good reasons > to report BUSY via IRQ for simpler transports (SATA/SPI). Maybe enable > ordered-tag selectively? This isn't a driver thing - this is a SCSI device thing. The disk array is temporarily out of resources so it BUSY's, or QUEUE_FULL's. But the next i/o may not encounter it. > >> For the second: Depending on the mode page (the QErr bit of the >> queueing page), most devices fail only a single command. We can set the >> QErr bit to return every command after the failing one (thus ensuring >> execution order), but the error handler would have to take them all back >> and resort them for submission. > > Actually blk layer will do the sorting part (this is what req->ordcolor > is for). Block drivers are only required to not successfully complete > later requests while retrying earlier ones, so setting QErr and retrying > all on-the-fly requests should do it (no EH code change). You're making the assumption that you can set QErr... It's under device control. -- james s - : 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
