Re: Infinite loop on MODE-SENSE with a removable ATAPI sata device on VIA chipset

[Dario Oliva <anikami1@gmail.com>]

Albert Lee wrote:
> Dario Oliva wrote:
>   
>> Albert Lee wrote:
>>
>>     
>>> Dario Oliva wrote:
>>>
>>>       
>>>> Attached are some kernel messeges. I ran dmesg several times and
>>>> appended the output to the attached file, so there may be some
>>>> redudancy. However some of the commands or debug lines do appear to
>>>> repeat themselves. As you requested, I changed "#undef ATA_DEBUG" to
>>>> "#define ATA_DEBUG".
>>>>
>>>> As far as the device is concerned, is an unreleased product of the
>>>> company I work for. That's why I did not give a name, because we don't
>>>> have an official name yet. But like I said, it is SATA, removalbe ATAPI.
>>>> If you want/need more information let me know.
>>>>
>>>>         
>>> Is the ATAPI device native SATA or PATA with some bridge chip used?
>>>
>>>       
>>>> From the log, some MODE SENSE did work at first: (So, seems not
>>>> DMADIR problem.)
>>>>         
>>> ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 3f 00 00 00 00 00 08
>>> ata_sg_setup: 1 sg elements mapped
>>> ata_exec_command_pio: ata1: cmd 0xA0
>>> atapi_packet_task: busy wait
>>> atapi_packet_task: send cdb
>>> ata_host_intr: ata1: protocol 7 (dev_stat 0x50)  <= irq received.
>>> ATAPI DMA ok
>>> sda: Write Protect is off
>>>
>>> ===============================================================
>>>
>>> Later, irq lost for the following MODE SENSE command:
>>>
>>> ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 08 00 00 00 00 00 1c
>>> ata_sg_setup: 1 sg elements mapped
>>> ata_exec_command_pio: ata1: cmd 0xA0
>>> atapi_packet_task: busy wait
>>> atapi_packet_task: send cdb
>>> ata_scsi_error: ENTER              <= timeout. ata_eng_timeout: ENTER
>>> ata_qc_timeout: ENTER
>>> ata1: command 0xa0 timeout, stat 0xd0 host_stat 0x1   <= device is
>>> still busy. The old EH doesn't reset the device.
>>> ata1: translated ATA stat/err 0xd0/00 to SCSI SK/ASC/ASCQ 0xb/47/00
>>> ata_qc_timeout: EXIT
>>> ata_eng_timeout: EXIT
>>> ata_scsi_error: EXIT
>>> ====================================================================
>>>
>>> After the timeout, the device is in BUSY state and can't handle any
>>> new commands.
>>> That's why the "infinite loop" seen. (Tejun's new EH can reset the
>>> device and bring
>>> it back to work.)
>>>
>>> Don't know what caused the timeout. From the device status 0xd0, it seems
>>> the device is waiting for something (maybe data transfer?). It is not
>>> irq lost
>>> because the irq is not yet generated when the device status is still
>>> BUSY.
>>>
>>> Is it possible to attach a protocol analyzer to the SATA cable
>>> and check whether the ATAPI DMA data is actually transferred?
>>> Could you also post the dmesg log with ATA_DEBUG for the working
>>> Intel/nVidia
>>> adapter? Maybe we can find some clue by comparing the problematic MODE
>>> SENSE transation of both logs.
>>>
>>> I've done minimal testing with my VIA VT6421 + ATAPI but unable to
>>> reproduce
>>> the problem.
>>>
>>> Thanks,
>>>
>>> Albert
>>>
>>>
>>>       
>> Sorry it took so long to get you the information. In case you need me to
>> refresh the information here is the body of the original email I had
>> sent out.
>>
>> "We have a removable, ATAPI, SATA device and we are having the following
>> problem with Linux (kernel version 2.6.15.6). The device recieves a MODE
>> SENSE command. After receiving this command, it is supposed to receive a
>> 12-byte packet command, which it recieves. Afterwards there is supposed
>> to be an IRQ, and then the data is read from the device. However, in one
>> computer we have with a VIA chipset, the device keeps getting zeroes
>> without stopping. In other words, it gets the 12-bytes and the continues
>> to recive bytes all of which are zero. The device never gets the IRQ,
>> therefore it does not respond."
>>
>>
>>     
>
> Hi Dario,
>
> Could you please try the new 2.6.17-rc6 kernel? The "flush" after sending
> the ATAPI CDB, etc. has been added to 2.6.17-rcX and it might help to
> your sata_via problem.
>
> Thanks,
>
> Albetr
>
>
>
>   

The 2.6.17-rc6 kernel no longer hangs/loops infinitely on MODE-SENSE. 
But I have another problem. This time is on writes. A hardware engineer 
used a protocol analyzer and this is how he describes it

When we write to the ATAPI advice an ODD number of blocks, for example 
33 blocks, the data transfer goes as follows:

 
                        1. Transfer of 8192 bytes (16 blocks)

                        2. Transfer of 8192 bytes (16 blocks)

                        3. Last transfer of 536 bytes.  (1 block and 24 
bytes)

 

The last transfer should be 512 (1 block) and not 536. (There are 24 
extra bytes).

The device (Quantum GoVault) hung up since they are not expecting the 
extra data.

Testing the same kernel with a computer without the VIA chipset that 
problem do not exist.