On Wed, 2007-07-25 at 16:42 +0900, Tejun Heo wrote: > Vasily Averin wrote: > > Albert Lee wrote: > >>>> Vasily Averin wrote: > >>>>> I've noticed that some scsi commands for DVD-drive attached to pata_via > >>>>> successfully finishes without any delays but reports about TIMEOUT condition. It > >>>>> happens because of ATA_ERR bit is set in status register. As result for each > >>>>> command Error Handler thread awakened, requests sense buffer and go to sleep again. > >>>> Need more info. Please post boot dmesg and the result of 'lspci -nn' > >>>> and 'hdparm -I /dev/srX' and when such errors occur. > >> Your log looks ok. It's normal for TEST_UNIT_READY to return ATA_ERR when no disc > >> inside and libata EH triggered to request sense. > > > > It's a bit strange for me, IMHO other scsi drivers requests sense buffer without > > EH thread assistance. > > Currently we know that ATA_ERR can be returned; it is not error, but one of > > expected responses. Why we cannot request sense without EH? I would like to > > understand is it implementation drawback or I missed something probably? > > That was a design choice. It's easier to implement that way. And just so we're clear what SCSI allows: On ordinary SCSI devices, when the device goes into a check condition state, it won't accept any more commands until it sees a request sense. For SCSI devices this can be a problem (because there are several thousand sense conditions, some of which correspond to everything's alright), so a large number of SCSI drivers implement auto request sense emulation, which means that in the driver, as soon as they see the check condition, they immediately send a REQUEST SENSE command to pick up the sense code (minimising the time the device is blocked). For drivers that don't want to implement this (and we have a few in SCSI) the alternative mechanism is to have the eh thread collect the sense data. This is the route libata has chosen. James - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
