Re: AHCI/ATA_CAM for dummies?

>1. Add "options ATA_CAM" to my kernel config. AFAICS it's not
>necessary to do anything special with ahci, that's included in ata_cam.

If you have AHCI-capable hardware and compatible BIOS, then there are
now *two* AHCI drivers:

[1] ataahci, together with the other ata(4) code, and
[2] ahci(4), which doesn't need ata(4).

ahci(4) is better, so you should use that if you can.  You only need
ata(4) if you want to use non-AHCI hardware, or, rarely, AHCI hardware
in legacy mode. If you place both in your kernel, ahci(4) should take
priority over ata(4) and attach to devices where possible.

See the ahci(4) manpage and

http://lists.freebsd.org/pipermail/svn-src-all/2009-December/016791.html

>2. I already had atapicam in my kernel (which I commented out since
>it's included in ata_cam as well), but I'm assuming that at least the
>following are needed:
>device          scbus   # SCSI bus (required for SCSI)
>device          da      # Direct Access (disks)
>device          cd      # CD
>device          pass    # Passthrough device (direct SCSI access)

Yes.  But see above -- you may want to add:

device ahci

>3. Comment out everything ata-related EXCEPT "device ata". Without
>that one the kernel boots but stops cold when it tries to mount the
>root file system.

Again, see above.  You may not actually need ata(4).  Even if you do
want it, you don't actually need all of ata(4); you can just add the
portion you need:

device atacore

and the chipset-specific parts that correspond to your hardware.
Usually, something like:

atapci
ataahci
atanvidia

for example.  See src/sys/conf/NOTES.  You can also have ataisa,
atabus, and atacard if you need them; but you should remove device
atadisk, ataraid, atapicd, atapifd, atapist, and atapicam if you have
ATA_CAM, which uses other means to give equivalent functionality,
except in the case of ataraid.  For that, ATA_CAM has no replacement;
see

http://lists.freebsd.org/pipermail/freebsd-current/2009-December/013956.html

where mav_at_ states:

"The main regression of the new mode is a lack of ataraid alternative, to
support cheap BIOS-based ATA RAIDs. If somebody has time and wish to
port that code from inside ata(4) into GEOM module, to make it work over
CAM also, I would appreciate that and propose a help, if needed."

and

http://lists.freebsd.org/pipermail/freebsd-arch/2009-December/009742.html

...

>So far so good. :)  I am actually kind of curious as to why "device
>ata" is needed, but it doesn't seem to be hurting anything.

It is needed if you have AHCI hardware, and are operating in AHCI
mode, but don't have ahci(4) in your kernel; or if you don't have AHCI
hardware, or have AHCI hardware operating in legacy mode, and still
want to use ATA devices.

...

>Is there something I need to change to make this work, or is NCQ not
>available for SATA 1.x devices? Are there any other parameters worth
>tweaking?

It may be available, but you need to look at the messages regarding
your other hardware, not just your disk drive.  Do you have an
AHCI-capable motherboard and chipset?  Are you in AHCI mode?  The
following kinds of considerations may be relevant as well, for others,
if not for your specific case (although these messages were written
before the last round of revisions, and mav_at_ may have made some
changes):

http://lists.freebsd.org/pipermail/freebsd-stable/2009-December/053381.html
http://lists.freebsd.org/pipermail/freebsd-current/2009-November/013477.html
http://lists.freebsd.org/pipermail/freebsd-current/2009-November/013639.html

Some non-AHCI hardware can do NCQ, but needs drivers that mav_at_ has not
written, and probably won't write.  Someone willing to take the time
to do so could port some of these drivers from Linux.

b.