Subversion Repositories or1k

ide.txt -- Information regarding the Enhanced IDE drive in Linux 2.0.xx

===============================================================================

Supported by:

        Mark Lord               -- disks, interfaces, probing

        Gadi Oxman      -- tapes, disks, whatever

        Scott Snyder    -- cdroms, ATAPI, audio

UDMA support was added for various chipsets, from kernel 2.0.35 on. Check

the udma.txt file in this directory for details.

   +-----------------------------------------------------------------+

   |  The hdparm utility for controlling various IDE features is     |

   |  packaged separately.  Look for it on popular linux FTP sites.  |

   +-----------------------------------------------------------------+

See description later on below for handling BIG IDE drives with >1024 cyls.

Major features of ide.c & ide-cd.c ("NEW!" marks changes since 1.2.13):

NEW!    - support for IDE ATAPI *floppy* drives

NEW!    - support for IDE ATAPI *tape* drives, courtesy of Gadi Oxman

                (re-run MAKEDEV.ide to create the tape device entries in /dev/)

NEW!    - support for up to *four* IDE interfaces on one or more IRQs

NEW!    - support for any mix of up to *eight* disk and/or cdrom drives

        - support for reading IDE ATAPI cdrom drives (NEC,MITSUMI,VERTOS,SONY)

        - support for audio functions

        - auto-detection of interfaces, drives, IRQs, and disk geometries

                - "single" drives should be jumpered as "master", not "slave"

NEW!              (both are now probed for)

        - support for BIOSs which report "more than 16 heads" on disk drives

        - uses LBA (slightly faster) on disk drives which support it

        - support for lots of fancy (E)IDE drive functions with hdparm utility

        - optional (compile time) support for 32-bit VLB data transfers

        - support for IDE multiple (block) mode (same as hd.c)

        - support for interrupt unmasking during I/O (better than hd.c)

        - improved handshaking and error detection/recovery

        - can co-exist with hd.c controlling the first interface

        - run-time selectable 32bit interface support (using hdparm-2.3)

NEW!    - support for reliable operation of buggy RZ1000 interfaces

                - PCI support is automatic when rz1000 support is configured

NEW!    - support for reliable operation of buggy CMD-640 interfaces

                - PCI support is automatic when cmd640 support is configured

                - for VLB, use kernel command line option:   ide0=cmd640_vlb

                - this support also enables the secondary i/f when needed

                - interface PIO timing & prefetch parameter support

NEW!    - experimental support for UMC 8672 interfaces

NEW!    - support for secondary interface on the FGI/Holtek HT-6560B VLB i/f

                - use kernel command line option:   ide0=ht6560

NEW!    - experimental support for various IDE chipsets

                - use appropriate kernel command line option from list below

NEW!    - support for drives with a stuck WRERR_STAT bit

NEW!    - support for removable devices, including door lock/unlock

NEW!    - transparent support for DiskManager 6.0x and "Dynamic Disk Overlay"

        - works with Linux fdisk, LILO, loadlin, bootln, etc..

NEW!    - mostly transparent support for EZ-Drive disk translation software

NEW!            - to use LILO with EZ, install LILO on the linux partition

                  rather than on the master boot record, and then mark the

                  linux partition as "bootable" or "active" using fdisk.

                  (courtesy of Juha Laiho ).

NEW!    - auto-detect of disk translations by examining partition table

NEW!    - ide-cd.c now compiles separate from ide.c

NEW!    - Bus-Master DMA support for Intel PCI Triton chipset IDE interfaces

                - for details, see comments at top of triton.c

NEW!    - ide-cd.c now supports door locking and auto-loading.

                - Also preliminary support for multisession

                  and direct reads of audio data.

NEW!    - experimental support for Promise DC4030VL caching interface card

NEW!            - email thanks/problems to: peterd@pnd-pc.demon.co.uk

NEW!    - the hdparm-3.1 package can be used to set PIO modes for some chipsets.

For work in progress, see the comments in ide.c, ide-cd.c, and triton.c.

Note that there is now a group actively working on support for the Promise

caching IDE cards, such as the DC4030VL, and early results are encouraging.

Look for this support to be added to the kernel soon.

***  IMPORTANT NOTICES:  BUGGY IDE CHIPSETS CAN CORRUPT DATA!!

***  =================

***  PCI versions of the CMD640 and RZ1000 interfaces are now detected

***  automatically at startup when PCI BIOS support is configured.

***

***  Linux disables the "prefetch" ("readahead") mode of the RZ1000

***  to prevent data corruption possible due to hardware design flaws.

***

***  For the CMD640, linux disables "IRQ unmasking" (hdparm -u1) on any

***  drive for which the "prefetch" mode of the CMD640 is turned on.

***  If "prefetch" is disabled (hdparm -p8), then "IRQ unmasking" can be

***  used again.

***

***  For the CMD640, linux disables "32bit I/O" (hdparm -c1) on any drive

***  for which the "prefetch" mode of the CMD640 is turned off.

***  If "prefetch" is enabled (hdparm -p9), then "32bit I/O" can be

***  used again.

***

***  The CMD640 is also used on some Vesa Local Bus (VLB) cards, and is *NOT*

***  automatically detected by Linux.  For safe, reliable operation with such

***  interfaces, one *MUST* use the "ide0=cmd640_vlb" kernel option.

***

***  Use of the "serialize" option is no longer necessary.

This is the multiple IDE interface driver, as evolved from hd.c.

It supports up to four IDE interfaces, on one or more IRQs (usually 14 & 15).

There can be up to two drives per interface, as per the ATA-2 spec.

Primary:    ide0, port 0x1f0; major=3;  hda is minor=0; hdb is minor=64

Secondary:  ide1, port 0x170; major=22; hdc is minor=0; hdd is minor=64

Tertiary:   ide2, port 0x1e8; major=33; hde is minor=0; hdf is minor=64

Quaternary: ide3, port 0x168; major=34; hdg is minor=0; hdh is minor=64

To access devices on the 2nd/3rd/4th interfaces, device entries must first be

created in /dev for them.  To create such entries, simply run the included

shell script:   /usr/src/linux/scripts/MAKEDEV.ide

Apparently many releases of Slackware 2.2/2.3 have incorrect entries

in /dev for hdc* and hdd* -- this can also be corrected by running MAKEDEV.ide

ide.c automatically probes for the standard four IDE interfaces,

for the drives/geometries attached to those interfaces, and for the

IRQ numbers being used by the interfaces (normally 14, 15, 11 and 10).

For special cases, interfaces may be specified using kernel "command line"

options.  For example,

        ide3=0x168,0x36e,10     /* ioports 0x168-0x16f,0x36e, irq 10 */

Normally the irq number need not be specified, as ide.c will probe for it:

        ide3=0x168,0x36e        /* ioports 0x168-0x16f,0x36e */

The standard port, and irq values are these:

        ide0=0x1f0,0x3f6,14

        ide1=0x170,0x376,15

        ide2=0x1e8,0x3ee,11

        ide3=0x168,0x36e,10

Note that the first parameter reserves 8 contiguous ioports, whereas the

second value denotes a single ioport. If in doubt, do a 'cat /proc/ioports'.

In all probability the device uses these ports and IRQs if it is attached

to the appropriate ide channel.  Pass the parameter for the correct ide

channel to the kernel, as explained above.

Any number of interfaces may share a single IRQ if necessary, at a slight

performance penalty, whether on separate cards or a single VLB card.

The IDE driver automatically detects and handles this.  However, this may

or may not be harmful to your hardware.. two or more cards driving the same IRQ

can potentially burn each other's bus driver, though in practice this

seldom occurs.  Be careful, and if in doubt, don't do it!

Drives are normally found by auto-probing and/or examining the CMOS/BIOS data.

For really weird situations, the apparent (fdisk) geometry can also be specified

on the kernel "command line" using LILO.  The format of such lines is:

        hdx=cyls,heads,sects,wpcom,irq

or      hdx=cdrom

where hdx can be any of hda through hdh, Three values are required

(cyls,heads,sects).  For example:

        hdc=1050,32,64  hdd=cdrom

either {hda,hdb} or {hdc,hdd}.  The results of successful auto-probing may

override the physical geometry/irq specified, though the "original" geometry

may be retained as the "logical" geometry for partitioning purposes (fdisk).

If the auto-probing during boot time confuses a drive (ie. the drive works

with hd.c but not with ide.c), then an command line option may be specified

for each drive for which you'd like the drive to skip the hardware

probe/identification sequence.  For example:

        hdb=noprobe

or

        hdc=768,16,32

        hdc=noprobe

Note that when only one IDE device is attached to an interface,

it should be jumpered as "single" or "master", *not* "slave".

Many folks have had "trouble" with cdroms because of this requirement,

so ide.c now probes for both units, though success is more likely

when the drive is jumpered correctly.

Courtesy of Scott Snyder, the driver supports ATAPI cdrom drives

such as the NEC-260 and the new MITSUMI triple/quad speed drives.

Such drives will be identified at boot time, just like a hard disk.

If for some reason your cdrom drive is *not* found at boot time, you can force

the probe to look harder by supplying a kernel command line parameter

via LILO, such as:

        hdc=cdrom       /* hdc = "master" on second interface */

or

        hdd=cdrom       /* hdd = "slave" on second interface */

For example, a GW2000 system might have a hard drive on the primary

interface (/dev/hda) and an IDE cdrom drive on the secondary interface

(/dev/hdc).  To mount a CD in the cdrom drive, one would use something like:

        ln -sf /dev/hdc /dev/cdrom

        mkdir /cd

        mount /dev/cdrom /cd -t iso9660 -o ro

If, after doing all of the above, mount doesn't work and you see

errors from the driver (with dmesg) complaining about `status=0xff',

this means that the hardware is not responding to the driver's attempts

to read it.  One of the following is probably the problem:

  - Your hardware is broken.

  - You are using the wrong address for the device, or you have the

    drive jumpered wrong.  Review the configuration instructions above.

  - Your IDE controller requires some nonstandard initialization sequence

    before it will work properly.  If this is the case, there will often

    be a separate MS-DOS driver just for the controller.  IDE interfaces

    on sound cards usually fall into this category.  Such configurations

    can often be made to work by first booting MS-DOS, loading the

    appropriate drivers, and then warm-booting linux (without powering

    off).  This can be automated using loadlin in the MS-DOS autoexec.

If you always get timeout errors, interrupts from the drive are probably

not making it to the host.  Check how you have the hardware jumpered

and make sure it matches what the driver expects (see the configuration

instructions above).  If you have a PCI system, also check the BIOS

setup; i've had one report of a system which was shipped with IRQ 15

disabled by the BIOS.

The kernel is able to execute binaries directly off of the cdrom,

provided it is mounted with the default block size of 1024 (as above).

Please pass on any feedback on the cdrom stuff to the author & maintainer,

Scott Snyder (snyder@fnald0.fnal.gov).

Note that if BOTH hd.c and ide.c are configured into the kernel,

hd.c will normally be allowed to control the primary IDE interface.

This is useful for older hardware that may be incompatible with ide.c,

and still allows newer hardware to run on the 2nd/3rd/4th IDE ports

under control of ide.c.   To have ide.c also "take over" the primary

IDE port in this situation, use the "command line" parameter:  ide0=0x1f0

mlord@pobox.com

snyder@fnald0.fnal.gov

================================================================================

Summary of ide driver parameters for kernel "command line":

----------------------------------------------------------

 "hdx="  is recognized for all "x" from "a" to "h", such as "hdc".

 "idex=" is recognized for all "x" from "0" to "3", such as "ide1".

 "hdx=noprobe"          : drive may be present, but do not probe for it

 "hdx=none"             : drive is NOT present, ignore cmos and do not probe

 "hdx=nowerr"           : ignore the WRERR_STAT bit on this drive

 "hdx=cdrom"            : drive is present, and is a cdrom drive

 "hdx=cyl,head,sect"    : disk drive is present, with specified geometry

 "hdx=autotune"         : driver will attempt to tune interface speed

                                to the fastest PIO mode supported,

                                if possible for this drive only.

                                Not fully supported by all chipset types,

                                and quite likely to cause trouble with

                                older/odd IDE drives.

 "hdx=slow"             : insert a huge pause after each access to the data

                                port. Should be used only as a last resort.

 "hdx=ide-scsi"         : use the ide-scsi driver for hdx

 "idebus=xx"            : inform IDE driver of VESA/PCI bus speed in Mhz,

                                where "xx" is between 20 and 66 inclusive,

                                used when tuning chipset PIO modes.

                                For PCI bus, 25 is correct for a P75 system,

                                30 is correct for P90,P120,P180 systems,

                                and 33 is used for P100,P133,P166 systems.

                                If in doubt, use idebus=33 for PCI.

                                As for VLB, it is safest to not specify it.

                                Bigger values are safer than smaller ones.

 "idex=noprobe"         : do not attempt to access/use this interface

 "idex=base"            : probe for an interface at the addr specified,

                                where "base" is usually 0x1f0 or 0x170

                                and "ctl" is assumed to be "base"+0x206

 "idex=base,ctl"        : specify both base and ctl

 "idex=base,ctl,irq"    : specify base, ctl, and irq number

 "idex=autotune"        : driver will attempt to tune interface speed

                                to the fastest PIO mode supported,

                                for all drives on this interface.

                                Not fully supported by all chipset types,

                                and quite likely to cause trouble with

                                older/odd IDE drives.

 "idex=noautotune"      : driver will NOT attempt to tune interface speed

                                This is the default for most chipsets,

                                except the cmd640.

 "idex=serialize"       : do not overlap operations on idex and ide(x^1)

 The following are valid ONLY on ide0,

 and the defaults for the base,ctl ports must not be altered.

 "ide0=dtc2278"         : probe/support DTC2278 interface

 "ide0=ht6560b"         : probe/support HT6560B interface

 "ide0=cmd640_vlb"      : *REQUIRED* for VLB cards with the CMD640 chip

                          (not for PCI -- automatically detected)

 "ide0=qd6580"          : probe/support qd6580 interface

 "ide0=ali14xx"         : probe/support ali14xx chipsets (ALI M1439/M1445)

 "ide0=umc8672"         : probe/support umc8672 chipsets

Everything else is rejected with a "BAD OPTION" message.

================================================================================

Some Terminology

----------------

IDE = Integrated Drive Electronics, meaning that each drive has a built-in

controller, which is why an "IDE interface card" is not a "controller card".

IDE drives are designed to attach almost directly to the ISA bus of an AT-style

computer.  The typical IDE interface card merely provides I/O port address

decoding and tri-state buffers, although several newer localbus cards go much

beyond the basics.  When purchasing a localbus IDE interface, avoid cards with

an onboard BIOS and those which require special drivers.  Instead, look for a

card which uses hardware switches/jumpers to select the interface timing speed,

to allow much faster data transfers than the original 8Mhz ISA bus allows.

ATA = AT (the old IBM 286 computer) Attachment Interface, a draft American

National Standard for connecting hard drives to PCs.  This is the official

name for "IDE".

The latest standards define some enhancements, known as the ATA-2 spec,

which grew out of vendor-specific "Enhanced IDE" (EIDE) implementations.

ATAPI = ATA Packet Interface, a new protocol for controlling the drives,

similar to SCSI protocols, created at the same time as the ATA2 standard.

ATAPI is currently used for controlling CDROM and TAPE devices, and will

likely also soon be used for Floppy drives, removable R/W cartridges,

and for high capacity hard disk drives.

How To Use *Big* ATA/IDE drives with Linux

------------------------------------------

The ATA Interface spec for IDE disk drives allows a total of 28 bits

(8 bits for sector, 16 bits for cylinder, and 4 bits for head) for addressing

individual disk sectors of 512 bytes each (in "Linear Block Address" (LBA)

mode, there is still only a total of 28 bits available in the hardware).

This "limits" the capacity of an IDE drive to no more than 128GB (Giga-bytes).

All current day IDE drives are somewhat smaller than this upper limit, and

within a few years, ATAPI disk drives will raise the limit considerably.

All IDE disk drives "suffer" from a "16-heads" limitation:  the hardware has

only a four bit field for head selection, restricting the number of "physical"

heads to 16 or less.  Since the BIOS usually has a 63 sectors/track limit,

this means that all IDE drivers larger than 504MB (528Meg) must use a "physical"

geometry with more than 1024 cylinders.

   (1024cyls * 16heads * 63sects * 512bytes/sector) / (1024 * 1024) == 504MB

(Some BIOSs (and controllers with onboard BIOS) pretend to allow "32" or "64"

 heads per drive (discussed below), but can only do so by playing games with

 the real (hidden) geometry, which is always limited to 16 or fewer heads).

This presents two problems to most systems:

        1. The INT13 interface to the BIOS only allows 10-bits for cylinder

        addresses, giving a limit of 1024cyls for programs which use it.

        2. The physical geometry fields of the disk partition table only

        allow 10-bits for cylinder addresses, giving a similar limit of 1024

        cyls for operating systems that do not use the "sector count" fields

        instead of the physical Cyl/Head/Sect (CHS) geometry fields.

Neither of these limitations affects Linux itself, as it (1) does not use the

BIOS for disk access, and it (2) is clever enough to use the "sector count"

fields of the partition table instead of the physical CHS geometry fields.

        a) Most folks use LILO to load linux.  LILO uses the INT13 interface

        to the BIOS to load the kernel at boot time.  Therefore, LILO can only

        load linux if the files it needs (usually just the kernel images) are

        located below the magic 1024 cylinder "boundary" (more on this later).

        b) Many folks also like to have bootable DOS partitions on their

        drive(s).  DOS also uses the INT13 interface to the BIOS, not only

        for booting, but also for operation after booting.  Therefore, DOS

        can normally only access partitions which are contained entirely below

        the magic 1024 cylinder "boundary".

There are at least seven commonly used schemes for kludging DOS to work

around this "limitation".  In the long term, the problem is being solved

by introduction of an alternative BIOS interface that does not have the

same limitations as the INT13 interface.  New versions of DOS are expected

to detect and use this interface in systems whose BIOS provides it.

But in the present day, alternative solutions are necessary.

The most popular solution in newer systems is to have the BIOS shift bits

between the cylinder and head number fields.  This is activated by entering

a translated logical geometry into the BIOS/CMOS setup for the drive.

Thus, if the drive has a geometry of 2100/16/63 (CHS), then the BIOS could

present a "logical" geometry of 525/64/63 by "shifting" two bits from the

cylinder number into the head number field for purposes of the partition table,

CMOS setup, and INT13 interfaces.  Linux kernels 1.1.39 and higher detect and

"handle" this translation automatically, making this a rather painless solution

for the 1024 cyls problem.  If for some reason Linux gets confused (unlikely),

then use the kernel command line parameters to pass the *logical* geometry,

as in:  hda=525,64,63

If the BIOS does not support this form of drive translation, then several

options remain, listed below in order of popularity:

        - use a partition below the 1024 cyl boundary to hold the linux

        boot files (kernel images and /boot directory), and place the rest

        of linux anywhere else on the drive.  These files can reside in a DOS

        partition, or in a tailor-made linux boot partition.

        - use DiskManager software from OnTrack, supplied free with

        many new hard drive purchases.

        - use EZ-Drive software (similar to DiskManager).  Note though,

        that LILO must *not* use the MBR when EZ-Drive is present.

        Instead, install LILO on the first sector of your linux partition,

        and mark it as "active" or "bootable" with fdisk.

        - boot from a floppy disk instead of the hard drive (takes 10 seconds).

If you cannot use drive translation, *and* your BIOS also restricts you to

entering no more than 1024 cylinders in the geometry field in the CMOS setup,

then just set it to 1024.  As of v3.5 of this driver, Linux automatically

determines the *real* number of cylinders for fdisk to use, allowing easy

access to the full disk capacity without having to fiddle around.

Regardless of what you do, all DOS partitions *must* be contained entirely

within the first 1024 logical cylinders.  For a 1Gig WD disk drive, here's

a good "half and half" partitioning scheme to start with:

        geometry = 2100/16/63

        /dev/hda1 from cyl    1 to  992         dos

        /dev/hda2 from cyl  993 to 1023         swap

        /dev/hda3 from cyl 1024 to 2100         linux

To ensure that LILO can boot linux, the boot files (kernel and /boot/*)

must reside within the first 1024 cylinders of the drive.  If your linux

root partition is *not* completely within the first 1024 cyls (quite common),

then you can use LILO to boot linux from files on your DOS partition

by doing the following after installing Slackware (or whatever):

        0. Boot from the "boot floppy" created during the installation

        1. Mount your DOS partition as /dos (and stick it in /etc/fstab)

        2. Move your kernel (/vmlinuz) to /dos/vmlinuz with:  mv /vmlinuz /dos

        3. Edit /etc/lilo.conf to change /vmlinuz to /dos/vmlinuz

        4. Move /boot to /dos/boot with:  cp -a /boot /dos ; rm -r /boot

        5. Create a symlink for LILO to use with:  ln -s /dos/boot /boot

        6. Re-run LILO with:  lilo

        A danger with this approach is that whenever an MS-DOS "defragmentation"

        program is run (like Norton "speeddisk"), it may move the Linux boot

        files around, confusing LILO and making the (Linux) system unbootable.

        Be sure to keep a kernel "boot floppy" at hand for such circumstances.

        A possible workaround is to mark the Linux files as S+H+R (System,

        Hidden, Readonly), to prevent most defragmentation programs from

        moving the files around.

If you "don't do DOS", then partition as you please, but remember to create

a small partition to hold the /boot directory (and vmlinuz) as described above

such that they stay within the first 1024 cylinders.

Note that when creating partitions that span beyond cylinder 1024,

Linux fdisk will complain about "Partition X has different physical/logical

endings" and emit messages such as "This is larger than 1024, and may cause

problems with some software".   Ignore this for linux partitions.  The "some

software" refers to DOS, the BIOS, and LILO, as described previously.

Western Digital ships a "DiskManager 6.03" diskette with all of their big

hard drives.  Use BIOS translation instead of this if possible, as it is a

more generally compatible method of achieving the same results (DOS access

to the entire disk).  However, if you must use DiskManager, it now works

with Linux 1.3.x in most cases.  Let me know if you still have trouble.

My recommendations to anyone who asks about NEW systems are:

        - buy a motherboard that uses the Intel Triton chipset -- very common.

        - use IDE for the first two drives, placing them on separate interfaces.

        - place the IDE cdrom drive as slave on either interface.

        - if additional disks are to be connected, consider your needs:

                - fileserver?  Buy a SC200 SCSI adaptor for the next few drives.

                - personal system?  Use IDE for the next two drives.

                - still not enough?  Keep adding SC200 SCSI cards as needed.

Most manufacturers make both IDE and SCSI-2 versions of each of their drives.

The IDE ones are usually faster and cheaper, due to the higher data transfer

speed of PIO mode4 (ATA2), 16.6MBytes/sec versus 10Mbytes/sec for SCSI-2.

In particular, I recommend Quantum FireBalls as cheap and exceptionally fast.

The new WD1.6GB models are also cheap screamers.

For really high end systems, go for fast/wide 7200rpm SCSI.  But it'll cost ya!

mlord@pobox.com

================================================================================

DMA Bus Master transfer

-----------------------

The triton.c driver provides support for the DMA Bus Mastering functions of

the Intel PCI Triton I/II chipsets (i82371FB or i82371SB).

Pretty much the same code will work for the OPTi "Viper" chipset. Look for

DMA support for this in linux kernel 2.1.xx, when it appears.

DMA is currently supported only for hard disk drives (not cdroms).

Support for cdroms will likely be added at a later date, after broader

experience has been obtained with hard disks.

Up to four drives may be enabled for DMA, and the motherboard chipset will

(hopefully) arbitrate the PCI bus among them.  Note that the i82371 chip

provides a single "line buffer" for the BM IDE function, so performance of

multiple (two) drives doing DMA simultaneously will suffer somewhat, as they

contest for that resource bottleneck.  This is handled transparently inside

the i82371 chip.

The SiS 5513 controller has two completely independent IDE controller units,

each with a 64-byte line buffer (same size as the Intel); there is no

bottleneck in simultaneous (U)DMA transfers for this resource. The 5513 is

built-in the SiS 5571, 5598 and 5591 chipsets.

The VIA chipsets like the Intel have a single 64 byte line buffer, but it

can be split 1/2-1/2 or 1/4-3/4 between both channels.

By default, DMA support is prepared for use, but is currently enabled only

for drives which support multi-word DMA mode2 (mword2), or which are

recognized as "good" (see table below).  Drives with only mode0 or mode1

(single or multi) DMA should also work with this chipset/driver (eg.

MC2112A) but are not enabled by default.  Use "hdparm -i" to view modes

supported by a given drive.

The hdparm-3.3 (patched) utility can be used to manually enable /disable DMA

support, but must be (re-)compiled against this kernel version or later.

Michel Aubry has produced a patch against hdparm-3.3 to support UDMA.

To enable DMA, use "hdparm -d1 /dev/hd?" on a per-drive basis after booting.

If problems arise, ide.c will disable DMA operation after a few retries.

This error recovery mechanism works and has been extremely well exercised.

IDE drives, depending on their vintage, may support several different modes

of DMA operation.  The boot-time modes are indicated with a "*" in the

"hdparm -I" listing, and can be changed with *knowledgeable* use of the

"hdparm -X" feature (X32 for DMA 0, X33 for DMA 1, X34 for DMA 2, X64 for

UDMA 0, X65 for UDMA 1 and X66 for UDMA 2).

Testing was done with an ASUS P55TP4XE/100 system and the following drives:

  Quantum Fireball 1080A (1Gig w/83kB buffer), DMA mode2, PIO mode4.

        - DMA mode2 works well (7.4MB/sec), despite the tiny on-drive buffer.

        - This drive also does PIO mode4, at about the same speed as DMA mode2.

          An awesome drive for the price!

  Fujitsu M1606TA (1Gig w/256kB buffer), DMA mode2, PIO mode4.

        - DMA mode2 gives horrible performance (1.6MB/sec), despite the good

          size of the on-drive buffer and a boasted 10ms average access time.

        - PIO mode4 was better, but peaked at a mere 4.5MB/sec.

  Micropolis MC2112A (1Gig w/508kB buffer), drive pre-dates EIDE and ATA2.

        - DMA works fine (2.2MB/sec), probably due to the large on-drive buffer.

        - This older drive can also be tweaked for fastPIO (3.7MB/sec) by using

          maximum clock settings (5,4) and setting all flags except prefetch.

  Western Digital AC31000H (1Gig w/128kB buffer), DMA mode1, PIO mode3.

        - DMA does not work reliably.  The drive appears to be somewhat tardy

          in deasserting DMARQ at the end of a sector.  This is evident in

          the observation that WRITEs work most of the time, depending on

          cache-buffer occupancy, but multi-sector reads seldom work.

Testing was done with a Gigabyte GA-586 ATE system and the following drive:

(Uwe Bonnes - bon@elektron.ikp.physik.th-darmstadt.de)

  Western Digital AC31600H (1.6Gig w/128kB buffer), DMA mode2, PIO mode4.

        - much better than its 1Gig cousin, this drive is reported to work

          very well with DMA (7.3MB/sec).

Other drives:

  Maxtor 7540AV (515Meg w/32kB buffer), DMA modes mword0/sword2, PIO mode3.

        - a budget drive, with budget performance, around 3MB/sec.

  Western Digital AC2850F (814Meg w/64kB buffer), DMA mode1, PIO mode3.

        - another "caviar" drive, similar to the AC31000, except that this one

          worked with DMA in at least one system.  Throughput is about 3.8MB/sec

          for both DMA and PIO.

  Conner CFS850A (812Meg w/64kB buffer), DMA mode2, PIO mode4.

        - like most Conner models, this drive proves that even a fast interface

          cannot improve slow media.  Both DMA and PIO peak around 3.5MB/sec.

  Maxtor 71260AT (1204Meg w/256kB buffer), DMA mword0/sword2, PIO mode3.

        - works with DMA, on some systems (but not always on others, eg. Dell),

          giving 3-4MB/sec performance, about the same as mode3.

  IBM DHEA 36480 (6197Meg w/476kB buffer), DMA mode2, PIO mode4, UDMA mode2

        - works with DMA and UDMA on systems that support it. This drive and its

          larger 8.4GB cousin provide throughput of 9.8MB/sec under UDMA.

If you have any drive models to add, email your results to:  mlord@pobox.com

Keep an eye on /var/adm/messages for "DMA disabled" messages.

Some people have reported trouble with Intel Zappa motherboards.

This can be fixed by upgrading the AMI BIOS to version 1.00.04.BS0,

available from ftp://ftp.intel.com/pub/bios/10004bs0.exe

(thanks to Glen Morrell  for researching this).

And, yes, Intel Zappa boards really *do* use the Triton IDE ports.

Changes by Michel Aubry, Andre Hedrick and Andrew D. Balsa, June 1998:

  a) Added support for non-Intel chipsets that support Bus Mastering DMA.

  b) Added support for UDMA (33Mb/s) drives and controllers. Note that UDMA

     support must be enabled in the BIOS, and that both the hard disk drive

     _and_ the chipset must support UDMA.

  On the IBM DHEA-36480 drive, transfer rates go from 7.76Mb/s to 9.76Mb/s,

  a 25% improvement with zero cost (DMA mode2 to UDMA mode2).

Extra UDMA PCI controller card support by Andre M. Hedrick, June 1998:

  - PDC20246 Promise Ultra33 UDMA.

  - AEC6210  Artop Electronics Corp. ACARD

        sold under SIIG CN2449 UltraIDE Pro.

  - HPT343   Triones Technologies (HighPoint Technologies) Inc.

        future support -- nonbooting cards, need MNDA approval for

        information release.

        sold under Digital Research DRIDEUDMA.

For more information on UDMA support, check /Documentation/udma.txt.