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 - : send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
