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

[Albert Lee <albertcc@tw.ibm.com>]

Dario Oliva wrote:
> 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.
>>
>>
>>
>>   
> 
> 
> 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.
> 

The GoVault drives implement the obsolete "CDB interrupts".
(Don't why Quantum implements the CDB interrupts on a native SATA drive...)

If possible, could you please try the "upstream" branch of Jeff's
libata-dev tree. It should fix the problem of GoVault.

Or, if you can wait, the 2.6.18 libata will have the patch for the
"CDB interrupts".

--
albert