Libata FAQ

From ata Wiki
Jump to: navigation, search

OBSOLETE CONTENT

This wiki has been archived and the content is no longer updated.

Contents

32-bit I/O support

Does libata support 32-bit I/O? Does libata support HDIO_SET_32BIT ioctl?

First, some background. 32-bit data transfer refers to the transfers between the host and the controller moving 32 bits at a time instead of 16 bits. This only has any meaning when PIO transfers are used, as when DMA is used the transfer always uses the full supported width of the bus. The vast majority of data transfer takes place via DMA, not PIO (except for very old controllers or devices or some CompactFlash cards, which don't support DMA). PIO taskfile data transfer is normally only used for rare, slow-path commands such as IDENTIFY DEVICE or SMART READ. On many newer controllers, such as AHCI, even with the transfers between the controller and device are PIO, the transfers between the host and the controller are DMA, and so 32-bit data transfer also has no meaning.

libata now supports 32-bit PIO transfers and the HDIO_SET_32BIT ioctl for a number of controllers which are known to work properly with 32-bit data transfers (and where there is any point in implementing them). For all controllers in which they are implemented, 32-bit transfers are enabled by default.

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.

SATA RAID

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.

How do I report a problem?

If you suspect a piece of hardware is causing a problem with libata or vice versa, first record the following information:

  • The output from dmesg

Search for any parts of the dmesg output which you feel are relevant on:

Provide this information to either [kernel bugzilla], or directly to the [mailing list].

Retrieved from "https://ata.wiki.kernel.org/index.php?title=Libata_FAQ&oldid=2602"
Personal tools