Issues with SIS 964 chipset on SATA

Issues with SIS 964 chipset on SATA

[Gary Poppitz]

We tracked down a problem with the 964 chipset with a 0x180 ID code 
that may save someone on the list some time.

The chip will only transfer multiples of 4 bytes. Anything else will 
cause it to hang.

Our specific case occurred in cdrom.c in cdrom_get_disc_info.

There the code asks for 2 bytes to get the data length and in our case, 
got a value of 34 bytes to read.

Both transfers would fail if not rounded up.


The next part that is interesting is that this error caused the process 
to hang. There was an assertion failure in ata_qc_complete for 
qc->flags & ATA_QUEUE_ACTIVE.

Again, in our case, when the 2 byte transfer failed, the attempt at the 
next read would hang the process when it attempted to queue the 
command. There is wait for lock which never gets satisfied.

It may be that this SIS error has uncovered an issue in the Linux code. 
If anyone who understands the command queueing process would like more 
trace data, I will try to provide it.

Gary Poppitz
Iomega

Re: Issues with SIS 964 chipset on SATA

[Jeff Garzik]

Gary Poppitz wrote:
> We tracked down a problem with the 964 chipset with a 0x180 ID code that 
> may save someone on the list some time.
> 
> The chip will only transfer multiples of 4 bytes. Anything else will 
> cause it to hang.

Interesting, either ULi or SiS set me a needs-to-be-cleaned-up-a-lot fix 
for this.

SATA transport is dword-based, so this is not surprising.

For the SIS (or ULi, I forget) controller, and perhaps others, a 
workaround needs to be applied.  Suggestions/patches welcome.

We may want to guarantee _DMA_ of 4-byte-aligned chunks, but still only 
reflect the true amount in ATAPI CDB.

	Jeff

Re: Issues with SIS 964 chipset on SATA

[Jeff Garzik]

Gary Poppitz wrote:
> We tracked down a problem with the 964 chipset with a 0x180 ID code that 
> may save someone on the list some time.
> 
> The chip will only transfer multiples of 4 bytes. Anything else will 
> cause it to hang.


After further research, this is popping up on a number of chips (and 
worked around in several vendor drivers).

It looks like I will need to do a workaround for all SATA ATAPI devices: 
  if the transfer is not a multiple of 4 bytes, pad it with an DMA 1-3 
byte DMA segment.

	Jeff

Re: Issues with SIS 964 chipset on SATA

[Jens Axboe]

On Thu, Feb 17 2005, Jeff Garzik wrote:
> Gary Poppitz wrote:
> >We tracked down a problem with the 964 chipset with a 0x180 ID code that 
> >may save someone on the list some time.
> >
> >The chip will only transfer multiples of 4 bytes. Anything else will 
> >cause it to hang.
> 
> 
> After further research, this is popping up on a number of chips (and 
> worked around in several vendor drivers).
> 
> It looks like I will need to do a workaround for all SATA ATAPI devices: 
>  if the transfer is not a multiple of 4 bytes, pad it with an DMA 1-3 
> byte DMA segment.

Yeah we definitely need something like that. The optimal solution is to
make sure that all requests are fed through the bounce logic like fs
requests.

-- 
Jens Axboe

Re: Issues with SIS 964 chipset on SATA

[Mark Lord]

Jens Axboe wrote:
>
>>It looks like I will need to do a workaround for all SATA ATAPI devices: 
>> if the transfer is not a multiple of 4 bytes, pad it with an DMA 1-3 
>>byte DMA segment.

Yup, that requirement has existed on most of the hardware
I've done drivers for, both SATA and a lot of PATA chips too.

Cheers

Re: Issues with SIS 964 chipset on SATA

[Jeff Garzik]

Mark Lord wrote:
> Jens Axboe wrote:
> 
>>
>>> It looks like I will need to do a workaround for all SATA ATAPI 
>>> devices: if the transfer is not a multiple of 4 bytes, pad it with an 
>>> DMA 1-3 byte DMA segment.
> 
> 
> Yup, that requirement has existed on most of the hardware
> I've done drivers for, both SATA and a lot of PATA chips too.

PATA too?  Interesting...

	Jeff

Re: Issues with SIS 964 chipset on SATA

[Jeff Garzik]

Jens Axboe wrote:
> On Thu, Feb 17 2005, Jeff Garzik wrote:
>>It looks like I will need to do a workaround for all SATA ATAPI devices: 
>> if the transfer is not a multiple of 4 bytes, pad it with an DMA 1-3 
>>byte DMA segment.
> 
> 
> Yeah we definitely need something like that. The optimal solution is to
> make sure that all requests are fed through the bounce logic like fs
> requests.


Could you elaborate?  I'm not sure I follow.

I hope you're not suggesting leaking 1-3 bytes of random memory, past 
the end of the request, into the DMA stream?

	Jeff

ATAPI issues (was Re: Issues with SIS 964 chipset on SATA)

[Jeff Garzik]

Another issue with ATAPI is that it _may_ or may not send an interrupt 
prior writing the CDB.

This behavior is dependent on an obsolete and undocumented in ATAPI7 bit 
5 of IDENTIFY PACKET DEVICE word 0, apparently.

	Jeff