[BUG] ATAPI command TEST_UNIT_READY never succeeds!

[BUG] ATAPI command TEST_UNIT_READY never succeeds!

[Conke Hu]

Hi,
    Do you ever noticed that the ATAPI command TEST_UNIT_READY always
fails to execute !?
    I debugged in the following environments:
        piix + Intel ICH6/ICH7 PATA
        atiixp + ATI SB600 PATA
        libata + ata_piix + Intel ICH6/ICH7 PATA
        libata + sata_sil24 + Silicon Image 3132
        libata + ahci + ATI SB600 SATA
        libata + ahci + Intel AHCI
    but none of them can execute TEST_UNIT_READY command successfully.
    For example, in ahci driver, ahci_interrupt() reads port status as
0x4000_0000, which indicates an taskfile error.


Conke

Re: [BUG] ATAPI command TEST_UNIT_READY never succeeds!

[Conke Hu]

On 3/7/07, Conke Hu <conke.hu@gmail.com> wrote:
> Hi,
>     Do you ever noticed that the ATAPI command TEST_UNIT_READY always
> fails to execute !?
>     I debugged in the following environments:
>         piix + Intel ICH6/ICH7 PATA
>         atiixp + ATI SB600 PATA
>         libata + ata_piix + Intel ICH6/ICH7 PATA
>         libata + sata_sil24 + Silicon Image 3132
>         libata + ahci + ATI SB600 SATA
>         libata + ahci + Intel AHCI
>     but none of them can execute TEST_UNIT_READY command successfully.
>     For example, in ahci driver, ahci_interrupt() reads port status as
> 0x4000_0000, which indicates an taskfile error.
 ~~~~~~~~~~~~~~~~~~

0x4000_0001, not 0x4000_0000, sorry.

more precisely speaking, ahci_host_intr() reads PORT_IRQ_STAT as
0x4000_0001, not the  expected 0x0000_0001.

Conke

Re: [BUG] ATAPI command TEST_UNIT_READY never succeeds!

[Tejun Heo]

Conke Hu wrote:
> On 3/7/07, Conke Hu <conke.hu@gmail.com> wrote:
>> Hi,
>>     Do you ever noticed that the ATAPI command TEST_UNIT_READY always
>> fails to execute !?
>>     I debugged in the following environments:
>>         piix + Intel ICH6/ICH7 PATA
>>         atiixp + ATI SB600 PATA
>>         libata + ata_piix + Intel ICH6/ICH7 PATA
>>         libata + sata_sil24 + Silicon Image 3132
>>         libata + ahci + ATI SB600 SATA
>>         libata + ahci + Intel AHCI
>>     but none of them can execute TEST_UNIT_READY command successfully.
>>     For example, in ahci driver, ahci_interrupt() reads port status as
>> 0x4000_0000, which indicates an taskfile error.
> ~~~~~~~~~~~~~~~~~~
> 
> 0x4000_0001, not 0x4000_0000, sorry.
> 
> more precisely speaking, ahci_host_intr() reads PORT_IRQ_STAT as
> 0x4000_0001, not the  expected 0x0000_0001.

I've read your last posting about this, but forgot to follow up.  TUR is
supposed to fail if ATAPI device doesn't have media loaded.  TUR fails
and sense data returns device not ready - media not present.  That's the
normal operation.  Does TUR fail even with media loaded or is sense data
not properly fetched?

-- 
tejun

Re: [BUG] ATAPI command TEST_UNIT_READY never succeeds!

[Conke Hu]

On 3/7/07, Tejun Heo <htejun@gmail.com> wrote:
> (snip)
> I've read your last posting about this, but forgot to follow up.  TUR is
> supposed to fail if ATAPI device doesn't have media loaded.  TUR fails
> and sense data returns device not ready - media not present.  That's the
> normal operation.  Does TUR fail even with media loaded or is sense data
> not properly fetched?
>

Thank you, Tejun! I did forget to load any media :(
When I load media and retry, TUR succeeds but there is still a
problem: when using ahci driver, TUR will not succeed unless it runs
twice, and the following loop always runs till retries==2
-------------------- code in sr.c, get_capabilities() -------------------------
	retries = 0;
	do {
		memset((void *)cmd, 0, MAX_COMMAND_SIZE);
		cmd[0] = TEST_UNIT_READY;

		the_result = scsi_execute_req (cd->device, cmd, DMA_NONE, NULL,
					       0, &sshdr, SR_TIMEOUT,
					       MAX_RETRIES);

		retries++;
	} while (retries < 5 &&
		 (!scsi_status_is_good(the_result) ||
		  (scsi_sense_valid(&sshdr) &&
		   sshdr.sense_key == UNIT_ATTENTION)));
------------------------------------- end code
-------------------------------------

this issue only occurs in ahci driver,  and libata + pata driver is OK.

Conke

Re: [BUG] ATAPI command TEST_UNIT_READY never succeeds!

[Tejun Heo]

Conke Hu wrote:
> On 3/7/07, Tejun Heo <htejun@gmail.com> wrote:
>> (snip)
>> I've read your last posting about this, but forgot to follow up.  TUR is
>> supposed to fail if ATAPI device doesn't have media loaded.  TUR fails
>> and sense data returns device not ready - media not present.  That's the
>> normal operation.  Does TUR fail even with media loaded or is sense data
>> not properly fetched?
>>
> 
> Thank you, Tejun! I did forget to load any media :(
> When I load media and retry, TUR succeeds but there is still a
> problem: when using ahci driver, TUR will not succeed unless it runs
> twice, and the following loop always runs till retries==2
> -------------------- code in sr.c, get_capabilities()
> -------------------------
>     retries = 0;
>     do {
>         memset((void *)cmd, 0, MAX_COMMAND_SIZE);
>         cmd[0] = TEST_UNIT_READY;
> 
>         the_result = scsi_execute_req (cd->device, cmd, DMA_NONE, NULL,
>                            0, &sshdr, SR_TIMEOUT,
>                            MAX_RETRIES);
> 
>         retries++;
>     } while (retries < 5 &&
>          (!scsi_status_is_good(the_result) ||
>           (scsi_sense_valid(&sshdr) &&
>            sshdr.sense_key == UNIT_ATTENTION)));
> ------------------------------------- end code
> -------------------------------------
> 
> this issue only occurs in ahci driver,  and libata + pata driver is OK.

After media is loaded, it takes some time for the device to get ready,
and it's supposed to raise UNIT_ATTENTION to tell the driver that media
has changed.  TUR fails with UA and sense data reports media exchanged
and the next TUR succeeds.  In SATA, you might also see unit reset UA
due to the probing sequence.  Those are why TUR is tried several times
in the first place.

So, there's nothing wrong with failing TURs, it's perfectly normal that
they fail first one or two tries.

-- 
tejun