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:
>>
>>> 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