Re: Issue with AHCI driver

[Jeff Garzik <jgarzik@pobox.com>]

the4hoffmans@earthlink.net wrote:
> Update:
> 
> We got Fedora 2.6.25-14 build running.  It recognizes our card.  It identifies our device but at some point after that we die.  Using an analyzer we found that the problem is due to a buffer alignment issue.
> 
> Our card is a prototype and currently under development.  It currently only supports memory buffers that are quadword aligned.  We are dying because we get a buffer for a subsequent identify command that is on a dword boundary.  That is the problem we need to solve next.
> 
> We know we need to change our hardware and we will do that.  However, is there a way during driver init to specify quadword buffer alignment so we can continue our testing with Linux?

Not easily, no :/  The entirety of SATA, both devices, the protocol, and 
controllers, are all very 32-bit-centric.  Given that each SATA FIS is 
one or more dwords, this fundamental feature propagates through 
everything touched by SATA:  Linux kernel drivers, controller 
interfaces, etc.

I would be surprised if standard filesystem I/O (via bio's) was 
unaligned... but all the ATA commands we use for control, various 
internal [and often controller-specific] data structures that are 
DMA-mapped and directly accessed are usually found on 32-bit boundaries, 
but nothing more than that.

Avoiding commands outside the READ DMA / WRITE DMA realm may help you 
limp along... if you want to hack things up to speed up local 
development, I would turn on libata DEBUG and VERBOSE_DEBUG, follow the 
trace until you find the failing (non-aligned) command, and try to omit 
that from the probing process.  The main non-data operation during 
probing we really care about is IDENTIFY [PACKET] DEVICE, and that 
/should/ be aligned at a minimum on a quadword boundary, if I'm not 
mistaken.

Also, avoid ATAPI devices and testing ATAPI, as you will _definitely_ 
not be getting quadword alignment there.

	Jeff