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?
Thanks again for all your help - we really appreciate it.
Bob H.
-----Original Message-----
From: Tejun Heo <tj@kernel.org>
Sent: Aug 6, 2008 7:15 PM
To: the4hoffmans@earthlink.net
Cc: Jeff Garzik <redacted>, linux-ide@vger.kernel.org, blward@micron.com
Subject: Re: Issue with AHCI driver
the4hoffmans@earthlink.net wrote:
quoted
which would you recommend? We tried 2.6.24.7 and saw problems...
The latest one 2.6.26.2. Hmmm.. IIRC 2.6.24.7 should have the class
code matching tho. Anyways, please give a shot at 2.6.26.2.
--
tejun
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