Date: Fri, 05 Jun 2009 19:54:27 +0300 From: Alexander Motin <mav@mavhome.dp.ua> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: FreeBSD-Current <freebsd-current@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration Message-ID: <4A294DC3.5010008@mavhome.dp.ua> In-Reply-To: <200906050703.n5573x5Q071765@apollo.backplane.com> References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi. Matthew Dillon wrote: > The biggest issue with AHCI (and ATA) interfacing is that AHCI devices > attach either as DISK or ATAPI. A device which attaches as a DISK > does not typically support ATAPI commands (though it would be an > interesting experiment to see if some did). This means that no matter > what you do a SCSI<->ATA translation layer needs to do some significant > fake-ups for DISK attachments, similar to what OpenBSD does in their > SCSI<->ATA layer. ATA DISK attachments simply do not support enough > of the SCSI command set for direct integration into CAM (IMHO). I think ATAPI disk device is theoretically possible, but I believe it does not exist in practice, as industry do not need it. It will become SCSI disk opponent from commands PoV, but with all ATA interface ugly growth problems. And I am not sure that it will have more benefits then contras comparing to SCSI or plain ATA. When I was talking about common CAM layer, I was directly speaking that there will be _no_command_translation_ for ATA disks! There will be separate native ATA disk driver withing CAM infrastructure. > The second biggest issue is that it is really unclear to me how the > hell one probes an ATAPI device for NCQ support. The OpenBSD driver > only uses AHCI-NCQ for DISK attachments, where the NCQ support is > returned in the IDENTIFY command. I'm sure there must be a way to > probe an ATAPI device for NCQ support but I don't know what it is. I have never seen opposite, and I believe that NCQ is just not implemented for ATAPI devices. NCQ requires different ATA commands usage for ATA disk drives and that makes drive to behave very different on FIS level. NCQ uses First Party DMA and special command completion FISes, that IMHO just not implemented for ATA PACKET command. > The OpenBSD driver does not have port multiplier support but adding > it to the DFly driver will be pretty easy... I just need some hardware > to test it with (it's on the way). Unfortunately the AHCI-1.0 > specfication says it cannot be used for high-performance multi-disk > I/O because all parallel commands in operation are only allowed to go > to a single target at a time. i.e. you can't mix parallel commands > to different targets on the same port. That's a serious problem. > > (Does anyone know if the AHCI-1.1 or 1.2 specifications do anything > about that?). Latest AHCI specifications define feature named FIS Based Switching. It allows controller independently track state of every device beyond port multiplier. It should be quite easy to use it, but actually none of my controllers have that capability. > It is unclear to me from reading the specification as to whether > AHCI-NCQ is supported for SATA ATAPI attachments. If anyone has an > answer to that I'm looking for a way to probe the device's > max-commands for ATAPI. for DISKs the IDENTIFY command has the > necessary feature bits and information. I'm sure the host controller > supports it natively but the real question is how to probe > the capability on the attached device and whether the device(s) > support it. ATAPI devices have their own equivalent of ATA IDENTIFY command. > Ultimately the best way to expand-out an AHCI interface is with > SCSI pass-through over ATAPI, assuming NCQ can be supported somehow. > The port-multiplier spec is badly broken (at least in Intel's AHCI-1.0 > spec). It is a bit annoying, actually, I wouldn't have though that > Intel would have made such a basic mistake. All they had to do was > implement 4 bits in the FIS and the problem would have been solved. > Instead they have routing bits in a port register. Sigh. Latest AHCI specifications are definitely better, but now we have a lot of hardware conforming early 1.0 and 1.1 revisions. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A294DC3.5010008>