32-bit I/O support
Why doesn't libata support 32-bit I/O? Does libata support HDIO_SET_32BIT ioctl?
First, some background. The vast majority of data transfer takes place via DMA. For newer SATA controllers, DMA is a requirement, even for the so-called PIO taskfile data transfers.
PIO taskfile data transfer, a.k.a. I/O data transfer, is only used for rare, slow-path commands such as IDENTIFY DEVICE or SMART READ. 16-bit I/O was hardcoded into libata because this supports the maximal number of controllers with the least amount of code.
Unless you are one of a few rare cases such as PATA CompactFlash, you don't need to care about this.
Eventually 32-bit I/O will be supported, but it is very low priority.
Intel combined mode
Why does my IDE hard drive run at 3MB/s, while SATA runs at full speed? Why does my IDE drive or CD-ROM not use DMA, while SATA works just fine?
This is an unfortunate side-effect of two things: "combined mode" — a particular configuration of Intel motherboard devices, where PATA and SATA are combined into a single PCI function — and the state of libata, which at the time of the design decision had stable ATA disk support, but not ATAPI device support.
The net result is that two drivers, the drivers/ide IDE driver and libata, are both trying to drive [different parts of] the same piece of hardware. That's possible, but only if one (and only one) driver does DMA.
This default configuration must stay in place these days only for backwards compatibility, and may be overridden in a multitude of ways:
- Recommended (where BIOS permits): Change BIOS IDE mode from "legacy" or "combined" mode to "AHCI" (recommended), "RAID" or "native".
- Boot with the kernel commandline parameter "combined_mode=libata" or "combined_mode=ide" to allow the specified driver to claim all IDE ports.
- Disable libata (CONFIG_ATA) entirely, and enable CONFIG_BLK_DEV_IDE_SATA.
- (newer choice, with less field testing) Disable CONFIG_IDE, and permit libata to run all your IDE and SATA ports.
Older, unsupported ioctls
Why does HDIO_SET_DMA fail? I want to use DMA! Why does HDIO_SET_UNMASKINTR fail?
libata intentionally does not support all the HDIO_xxx ioctls that were supported by the older IDE driver. It is now preferred to use SG_IO as a generalized ATA command submission method, rather than creating a myriad of ioctls for each specific purpose.
The design decision was made only to support the HDIO_xxx ioctls that were heavily used by other programs. Generally the driver always programs the hardware to its maximum capability automatically, completely without user intervention. Therefore, for example, HDIO_SET_DMA is not needed for the vast majority of users because DMA is automatically enabled and used where available.
Why isn't my SATA RAID supported? I created a RAID array in BIOS, but it does not appear in Linux. Why?
See the SATA RAID FAQ for a tongue-in-cheek, but nonetheless factual, answer. The short version is that a lot of "SATA RAID" solutions are really software RAID.
Enabling, disabling and checking NCQ
How do I enable NCQ? How do I disable NCQ? How do I know if NCQ is enabled? Why are only 31 tags used, rather than 32?
Linux NCQ (SATA native command queueing) support is enabled automatically, if your SATA drive supports it. At boot, you will see a line in dmesg (or kernel log) like
ata2.00: ATA-7, max UDMA/133, 321672960 sectors: LBA48 NCQ (depth 31/32)
If the line containing the sector count and maximum UDMA speed does not mention NCQ, your drive does not support it.
If NCQ is present but disabled, you may see "depth 0":
ata2.00: ATA-7, max UDMA/133, 321672960 sectors: LBA48 NCQ (depth 0/32)
You may disable NCQ, and use normal READ/WRITE DMA commands, by setting the queue depth to 1:
$ echo 1 > /sys/block/sdX/device/queue_depth
Enabling NCQ, if supported, is the same:
$ echo 31 > /sys/block/sdX/device/queue_depth
Both the host controller and device constrain the number of NCQ commands that can be outstanding. The SATA specification maximum is 32 tags. Most devices support 32 tags, but the standard permits devices to support less. Similarly, most host controllers support 32 tags.
However, the ATA standard has a design flaw. The NCQ tag is presumed to be a 32-bit bitmap (32-bit dword). If all 32 tags are asserted, this produces a value (0xffffffff) that is the same value returned by reading a hardware register after the hardware has been hot-unplugged, or suffers a major failure. Thus, to distinguish this condition, libata artificially limits all NCQ configurations to 31 tags rather than 32.