Re: [PATCH] Re: 2.6.19.1, sata_sil: sata dvd writer doesn't work

[Tejun Heo <htejun@gmail.com>]

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