Hello, Daniel Beichl wrote: > I gave the whole thing some thought. You suspected the sil dma engine to > cause the issue, because it might only be usable with a certain command > packet size. > If these commands result in packets their size is not zero. Not all > packet commands transfer > data sectors, but they themselves have a size. > > So i investigated libata and learnt from libata-scsi.c that nbytes is > set to the size of the scsi > command corresponding to the atapi command that should be sent to the > device near the end of atapi_xlat(). > > I added code to dump the packet size and data direction as set in the > scsi command and noticed that the > controller freezes the port if a packet with the direction DMA_TO_DEVICE > and a length smaller than ~60 bytes is issued, the command type does not > matter at all. Hmmmmm.... This is weird. < ~60 bytes? The zero-length protocol thing is a plain bug but this is something completely different. Can you test this with a different controller? Is the problem always reproducible? > I tried this with the cdrecord -atip option which generate packets of > command cdb[0] = 0x00, length 60 and 16 in said direction. > The first command succeeds, the second one triggers the dma bug. > > The question now is, is the dma engine of the sil chip indeed the > problem, or did i cover > another problem located somewhere else by restricting dma to packets not > smaller than 60 bytes. > The datasheet of the sil3512 does not specify a lower limit for dma > transfers. > > It does not appear to be a modulo N issue either as i have seen the > transfer of > packets of 12 or 16 bytes fail but then again packets of 60 bytes succeeds. > > size result > ========== > 001100 fail > 010000 fail > 111100 succeed > > A thing that crossed my mind was a timing issue. Perhaps the dmaing of < > 60 bytes is that > fast that the interrupt that causes it is not yet handled correctly. But > this is just a very wild guess. I don't think that can happen. Controllers are required to queue interrupt till FIFO is flushed. Can you post dmesg after such errors? > I tried your latest patch and the dma bug did show up. I have attached a > patch to this mail that > decides based on the dma direction and the command size in the > sil_check_atapi_dma() routine > whether to allow dma or not. This fixed the dvd auth issue and the > cdrecord -atip issue for me, > but i am pretty sure there is a better solution. I'm not really sure what we're looking at and where the problem actually is. We need to find out more about this problem. -- tejun - To unsubscribe from this list: 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
