Testing CAM wrapper for ata(4) controller drivers

Alexander Motin mav at FreeBSD.org
Wed Dec 2 13:56:15 UTC 2009


I would like to present for testing patch, turning ata(4) controllers
drivers into native SIMs of new CAM ATA infrastructure. This patch adds
new ATA_CAM kernel option, which allows switching between legacy and new
 CAM-based operation modes. To enable new mode you should add
options	ATA_CAM
line to the kernel configuration file in addition to the ones required
by CAM infrastructure and rebuild/reinstall the kernel.

In legacy mode, the only difference will be - the way in which SATA
speeds reported. Instead of mixing SATA revisions with PATA modes, they
were separated, as they should be, allowing, for example, DMA-incapable
or buggy SATA devices (usually PATA devices with built-in PATA/SATA
converter) to work in PIO mode.

While doing it, I had to completely rewrite ata(4) mode setting code, so
legacy operation also need to be tested. I have successfully tested it
on Intel, NVidia, VIA, Marvell, JMicron PATA controllers with all
PIO/DMA modes. Different controllers feedbacks are especially welcome.

In new mode, everything becomes different. atacontrol tool will not
report ATA buses any more. All management should be done via camcontrol
tool now. atadisk, ataraid, atapicd, atapifd, atapist and atapicam
kernel options and respective code are useless now. Instead of ad, acd,
afd, ast devices you'll get ada, cd, da, sa.

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.

In new mode some tools, like burncd, using legacy ata(4) interfaces
(acd), are no longer applicable and should be replaced by alternatives,
working via SCSI interfaces (cd). SMART support for new mode implemented
in smartmontools SVN, and will be present in next release.

New mode at this moment won't give much benefits to the old controllers,
not supported by new ahci(4) and siis(4) drivers, may be just more fair
scheduling for PATA devices sharing cable. But it is required step to
unify infrastructure. After this step will be done, it will be possible
to improve functionality, where it is supported by hardware. Until that
time it would require too much extra work to keep compatibility with
both world.

Present patch can be found here:

It applies to both recent HEAD and 8-STABLE. To work in new mode on
8-STABLE it requires recent SVN revision 200008 to be merged from HEAD.
Respective patch for now could be found here:

Feedbacks are welcome. On any problems, don't forget to enable verbose
kernel debug messages to obtain more information.

Alexander Motin

More information about the freebsd-current mailing list