unexpected scsi timeout [message #15174] |
Fri, 20 July 2007 12:02 ![Go to next message Go to next message](/theme/ovz3/images/down.png) |
vaverin
Messages: 708 Registered: September 2005
|
Senior Member |
|
|
Tejun, Jeff
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.
Could you please confirm that it is expected behavior? It's a bit strange for
me, IMHO other scsi drivers requests sense buffer without EH thread.
Thank you,
Vasily Averin
|
|
|
|
|
|
|
Re: unexpected scsi timeout [message #15267 is a reply to message #15258] |
Wed, 25 July 2007 13:06 ![Go to previous message Go to previous message](/theme/ovz3/images/up.png) |
James Bottomley
Messages: 17 Registered: May 2006
|
Junior Member |
|
|
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
|
|
|
Re: unexpected scsi timeout [message #15322 is a reply to message #15248] |
Wed, 25 July 2007 05:50 ![Go to previous message Go to previous message](/theme/ovz3/images/up.png) |
Albert Lee
Messages: 1 Registered: July 2007
|
Junior Member |
|
|
Vasily Averin wrote:
> Tejun Heo wrote:
>
>>[cc'ing Albert]
>>
>>Vasily Averin wrote:
>>
>>>Tejun, Jeff
>>>
>>>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.
>
>
> It was 2.6.22 kernel with pata_via and sata_via drivers, scsi and cdrom debug
> was temporally enabled via sysctl (please see logs near Jul 24 13:42:46 timestamp)
>
> Btw. I'm not sure that it was an error, I've looked on the sources and IMHO it's
> normal command processing cdrom without disk inserted into drive. I've checked
> 2.6.19, 2.6.20 and 2.6.22 kernels and got the same behavior.
>
Hi Vasily,
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.
--
albert
|
|
|