LDP/LDP/retired/Ultra-DMA.sgml

<!doctype linuxdoc system>

<!-- The Ultra-DMA Mini Howto SGML source
  Version 3.01, 6/dec/2001
  by Brion Vibber - brion@pobox.com
-->

<article>

<title>The Linux Ultra-DMA Mini-Howto
<author>Brion Vibber, <tt><htmlurl url="mailto:brion@pobox.com" 
name="brion@pobox.com"></tt>
<date>v3.01, 6 December 2001

<abstract>
This document is intended to explain how to use Ultra-DMA aka Ultra-ATA
aka Ultra33 and Ultra66 hard drives and interfaces with Linux. The most
recent version of this mini-Howto can be obtained in HTML format at 
<htmlurl url="http://pobox.com/~brion/linux/Ultra-DMA.html" 
name="http://pobox.com/&tilde;brion/linux/Ultra-DMA.html">.
</abstract>

<toc>

<sect>Introduction and Disclaimer<label id="main-intro">
<p>

  This document is intended to explain how to use Ultra-DMA aka Ultra-ATA
  aka Ultra33 and Ultra66 hard drives and interfaces with Linux. In many cases there is 
  no difficulty in using them, but some tweaking can increase performance. In 
  other cases, you need to go to extraordinary lengths simply to access your 
  hard drives.

<sect1>Disclaimer<label id="disclaimer">
<p>

  The information in this is document is, to the best of my knowledge, correct, and
  should work. However, there may be typos, there may be mysterious 
  transmission errors, and there may be strange incompatibilities within your 
  own system that prevent the techniques described herein from working 
  properly. So... before you go fiddling around with you hard drive, <bf>BACK
  UP ANY DATA YOU WANT TO KEEP!</bf> If you are not already performing regular
  backups, please start doing so for your own good.

<sect1>Credits<label id="credits">
<p>

  <url name="Michel Aubry" url="mailto:giovanni@sudfr.com"> - UDMA-enabled
   VIA-related patch for &lt;=2.0.33
   &amp; more info, grand unified UDMA patch for 2.0.34+

  <url name="Andrew Balsa" url="mailto:andrebalsa@altern.org"> - Provided
  some general UDMA info and the udma-generic patch for Intel TX, SiS, and VP1
  on &lt;=2.0.33; also the grand unified UDMA patch for 2.0.34+

  Maxime Baudin - French translation
  
  Bokonon - ``Controller'' vs. ``interface''
  
  <url name="John G." url="mailto:prefect@ipass.net"> -
  VIA VP2 patch for &lt;=2.0.33 &amp; info

  Martin Gaitan - Promise Ultra33 ide0/ide1 installation workaround

  <url name="Andre M. Hedrick" url="mailto:andre@suse.com"> -
   current Linux IDE subsystem maintainer

  H<>vard Tautra Knutsen - Norwegian translation

  Norman Jacobowitz - Bugged me to add info on the VP3
  
  John Levon - Info on TX Pro mobos
  
  Peter Monta - Info on using two Ultra33 cards
  
  Masayoshi Nakano - Japanese translation

  <url name="Gadi Oxman" url="mailto:gadio@netvision.net.il"> - The
  Promise Ultra33 patch for &lt;=2.0.34 &amp; finding the secret
  numbers for the workaround

  Andy Pearce - Suggested adding info on the additional device files for hde-h

  <url name="Andrei Pitis" url="mailto:pink@roedu.net"> - LILO patch
  
  <url name="Brion Vibber" url="mailto:brion@pobox.com"> - The document itself

<sect1>Document History<label id="history">
<p>

  v3.01, 6 December 2001: Relicensed under <htmlurl
    url="http://www.gnu.org/copyleft/fdl.html"
    name="GNU Free Documentation License">; no content changes.

  v3.0, 9 November 1999: Finally found time to update some key changes such as
    the relocation of the IDE patch archive to the <url name="Kernel.org archives"
    url="http://www.kernel.org/pub/linux/kernel/people/hedrick">... pesky school!
    Updated all sunsite links to new <htmlurl url="ftp://metalab.unc.edu"
    name="metalab.unc.edu"> or <htmlurl url="http://www.linuxdoc.org"
    name="www.linuxdoc.org">

  v2.1, 27 May 1999: Corrects some minor omissions and errors from 2.0 and adds
    information on the Promise Ultra66 and 2.2/2.3 kernels.

  v2.0, 7 August 1998: Major updates and almost total restructuring of the
    document into onboard (motherboard) and offboard (add-in cards) interfaces;
    the Grand Unified UDMA patch(a part of the Jumbo patch)
    for 2.0.35. Put credits in alphabetical order by last name. Changed
    ``controller'' to ``interface'' in many cases to be more technically
    correct. Added info on enabling/disabling UDMA, the blacklist, and more!

  v1.45, 6 July 1998: Minor updates - Red Hat 5.1 and 2.0.34 patch for
    Promise Ultra33, LILO patch for booting off of PCI interfaces such as
    the Promise Ultra33

  v1.41, 3 May 1998: Fixed a couple of typos, added translators to credits.

  v1.4, 28 April 1998: UDMA-Generic patch, some more general info. Copying
    section added.

  v1.3, 5 March 1998: VIA VP3 info, better patching instructions,
    pointer to more recent Promise patch.

  v1.2, 27 January 1998: Additional Promise workaround info.

  v1.1, 21 January 1998: New info about VIA chipset, installing <em/around/ 
    the Promise Ultra33, and enabling Bus Master & UDMA transfer modes.

  v1.0, 19 January 1998: More or less complete, first version done in SGML.

<sect1>Copying<label id="copying">
<p>

  Copyright (c) 1998-2001 Brion L. Vibber

  Permission is granted to copy, distribute and/or modify this document
  under the terms of the GNU Free Documentation License, Version 1.1
  or any later version published by the Free Software Foundation;
  with the Invariant Sections being &quot;Introduction and Disclaimer&quot;, with no
  Front-Cover Texts, and with no Back-Cover Texts.

  You should have received a copy of the GNU Free Documentation License
  along with this document; if you did not, you may find it at
  <htmlurl url="http://www.gnu.org/copyleft/fdl.html"
  name="http://www.gnu.org/copyleft/fdl.html">.

<sect>What is Ultra-DMA and why do I want it?<label id="udma-intro">
<p>

Here's a brief overview of IDE-based drive technologies:

<sect1>IDE, EIDE, &amp; ATAPI<label id="classic">
<p>

  These are older drive technologies. Most non-SCSI hard drives and drive 
  interfaces that you can buy today or are likely to be using are EIDE,
  although many of the larger drives now available are UDMA.

<sect1>Bus Master DMA<label id="bm">
<p>

  Bus Master DMA is a technology for increasing the speed of hard disk data 
  transfers which requires support from the motherboard and the BIOS, and at 
  least some support from the drive.

  You can learn more at <htmlurl 
  url="http://developer.intel.com/design/pcisets/busmastr/FAQs.htm"
  name="http://developer.intel.com/design/pcisets/busmastr/FAQs.htm">.

<sect1>Ultra-DMA aka Ultra-ATA aka Ultra33 aka...<label id="udma">
<p>
  Ultra-DMA has many names, but we'll just call it UDMA in here.

  UDMA is a more advanced technology which provides for even faster 
  throughput, up to 33.3 MB/s in UDMA mode 2 and 66.7 MB/s in UDMA mode 4,
  twice to four times that of EIDE, for much lower prices
  than SCSI. Many new computers come with large UDMA drives and UDMA 
  interfaces, and it's possible to add a UDMA interface card (such as 
  the Promise Ultra33 or Ultra66) to an existing system to boost speed, even on older 
  non-UDMA drives.

  You can learn great details about UDMA at
  <htmlurl url="http://www.quantum.com/src/whitepapers/ultraata/"
    name="http://www.quantum.com/src/whitepapers/ultraata/">

  Note that cable length should be kept shorter for UDMA, compared to plain DMA,
  preferably less than 30 cm (12&quot;) maximum length though 18 inches will
  usually be fine. 66 MB/s requires a special 80-conductor cable and should
  definately not be longer. If you get a lot of CRC errors, try using a shorter
  cable.
  

<sect1>Just how ``Ultra'' is it anyway?<label id="speed">
<p>

  Before we get any farther, let's clear up a misconception. That 33 or 66 MB/sec
  figure is the <bf/burst transfer rate/, and it's not something you're going to
  see very often. To explain, here is a clip from udma<6D>generic's UDMA.txt:

<tscreen><verb>
Burst (instantaneous) transfer rates are supposed to go from 16.6MB/s (PIO
mode 4) to 16.6MB/s (DMA mode 2) up to 33MB/s (UDMA). In his patch against
kernel 2.1.55, Kim-Hoe Pang actually checked the UDMA burst transfer rate
with a logic analiser: 60ns/word, which translates into 33MB/s.

Note that burst transfer rates only affect data transfers to/from the EIDE
drive cache (476kB for the IBM 6.4GB drive), and IMHO are not particularly
relevant for most Linux users.

The Linux kernel uses as much RAM as possible to cache hard disk data
accesses, and so if data is not in the kernel cache there is little chance
that it will be in the (much smaller) hard disk cache.
</verb></tscreen>

  Much more relevant is the <bf/sustained transfer rate/, the speed at
  which data can be transferred from the drive to main memory where it
  can be used. An easy way to measure the sustained transfer rate is to
  use <tt/hdparm/, for instance ``<tt>hdparm <20>Tt /dev/hda</tt>'' to measure
  the rate of the first IDE device.

<tscreen><verb>
Here is some data gathered after extensive testing, using the hdparm utility
(also written by Mark Lord):

PIO mode 4 transfer rates under Linux:   +/- 5.2MB/s

DMA mode 2 transfer rates under Linux:   +/- 7.2MB/s

UDMA mode 2 transfer rates under Linux:  +/- 9.8MB/s
</verb></tscreen>

  As you can see, UDMA is still almost twice as fast as plain EIDE and
  significantly faster than plain bus mastering DMA. Most current UDMA drives
  will give you between 10 and 15 MB/s using UDMA mode 2 (33 MB/s) or 4 (66 MB/s)
  enabled.
  
  Also, using DMA vastly reduces CPU usage during disk I/O vs PIO.

<sect1>How does UDMA compare to SCSI?<label id="udma-vs-scsi">
<p>

  I don't have any hard numbers to give you, but the general consensus is that
  high-end SCSI can give better performance than UDMA. However if you've looked
  at the price tags on any hard drives lately you'll notice that UDMA drives
  tend to be much less expensive. The performance/price ratio favors UDMA in
  most cases.

<sect>Using your UDMA hard drive with an EIDE interface<label id="udma-on-eide">
<p>

  This is easy to do. Since all UDMA drives are fully EIDE backward-compatible,
  just plunk your drive on your EIDE interface like it was any old hard
  drive and Linux should have no problems detecting or using it.
  However, you will of course be limited to the slower speed of EIDE.

<sect>Using your hard drives with a UDMA interface<label id="using-udma">
<p>

  Well, there is good news and there is bad news. The good news is that a UDMA
  interface can be used with both UDMA hard drives and legacy EIDE hard
  drives, and will be a lot faster than an EIDE interface.
  
  The bad news is that the old stock kernels (2.0.x) do not currently
  support UDMA very well. The new 2.2.x kernels do support UDMA33, however,
  and kernel patches are available to add UDMA support for kernels that lack it.
  
  In addition, certain UDMA interfaces that are add-in cards rather than built
  into the motherboard require either a patch or some trickery to use on older kernels. That is why
  this document exists - to explain how to get the patches and work the trickery.

<sect>Offboard PCI UDMA interfaces<label id="pci">
<p>

  These are UDMA interfaces on PCI cards that can be used to add UDMA
  support to an existing computer without replacing the motherboard, or
  for adding support for an additional four drives to a machine which has
  had its onboard interfaces filled. They can also be found preinstalled
  in some computers, especially Gateway 2000 and Dell machines.

  Most of them are not supported by the old stable kernels (2.0.x), but many should
  work with a 2.2.x kernel - the Red Hat 6.0 and SuSE 6.1 distributions are
  based on 2.2.x kernels, as are the most recent versions of most other distros.
  However some of the latest cards (the Promise Ultra66 for instance) won't
  work even with the current 2.2.x kernels, if you have this or can't get a
  newer distribution then you must apply a kernel patch or upgrade to a newer
  kernel version.
  If you need to install Linux onto a hard drive on one of these interfaces
  in this case, you will need to use a few odd tricks.

<sect1>Promise Ultra33<label id="promise">
<p>

  This is a PCI card that has two UDMA channels on it, supporting up to four
  drives total. You can look up specifications &amp; pricing at
  <htmlurl url="http://www.promise.com" name="http://www.promise.com">.
  This card shipped in early model Gateway 2000 Pentium II systems.

  Kernels 2.0.35 and later and all 2.2.x kernels support the Ultra33 and
  you should have no trouble installing a distribution that uses these kernels.
  However, the older stable kernels (2.0.34 and below) do not, and
  since most older Linux distributions include these older kernels it can
  be a little difficult to get Linux installed if you can't or don't want
  to use a newer version (for instance if you are standardized on a particular
  version of a distribution throughout your organization).
  
  <bf/Installing Linux with the Ultra33/

  Although there is a patch for the Ultra33 interface,
  it is not very easy to apply a patch and recompile your kernel if you have
  not installed Linux yet! So, here is a workaround which allows you to
  install. Thanks to Gadi Oxman for the following information on getting the
  interface settings:

<tscreen><verb>
If we can access the console with the installation disk, we can also
use "cat /proc/pci" to display the Promise interface settings:

    RAID bus interface: Promise Technology Unknown device (rev 1).
      Vendor id=105a. Device id=4d33.
      Medium devsel.  IRQ 12.  Master Capable.  Latency=32.
      I/O at 0xe000.   (a)
      I/O at 0xd804.   (b)
      I/O at 0xd400.   (c)
      I/O at 0xd004.   (d)
      I/O at 0xc800.   (e)

and pass "ide2=a,b+2 ide3=c,d+2" as a command line parameter to the kernel.
</verb></tscreen>

  Note that the numbers probably are not the same as what you will have.
  Just as an example, the parameters to use for the above set of numbers
  would be ``<tt/ide2=0xe000,0xd806 ide3=0xd400,0xd006/''.
  If you are only using the first channel on the Ultra33 (for
  instance, if you only have one drive, or two if they are master and slave on
  the same channel), then you won't need to specify <tt/ide3/.

  <bf/Red Hat 5.1:/ Boot with the boot diskette and press enter when prompted.
  The kernel will load, and then you will be asked for a language, keyboard
  type, and installation method. You may be prompted for additional information
  about the source media; it doesn't matter right now what you tell it as long
  as you can get to the next step. Next you should see a screen titled
  ``Select Installation Path''; press Alt-F2 now to get to a command prompt.
  Run ``<tt>cat /proc/pci</tt>'', write down
  the numbers as above, and reboot from the boot disk. This time, type
  ``<tt>linux ide2=</tt> <em/(this is where you put the numbers like shown
  above)/<tt/ ide3=/<em/(more numbers)/''. It should now be able to install
  onto your hard disk without difficulty, however LILO will probably not be able to
  install; instead make a boot floppy and boot it with the same parameters
  until you can patch LILO and and the kernel.

  <bf/Red Hat 5.0/ and <bf/Slackware 3.4:/ These are similar, but with the wrinkle
  that the setup programs ignore <tt>/dev/hde-h</tt> (the drives on <tt/ide2/ and <tt/ide3/).
  In order to install to or from these drives it is necessary to override one or 
  both of the onboard interface's channels. However be sure not to override a
  device that you need to install; for instance if you are installing from a CD-ROM drive on
  <tt>/dev/hdd</tt> (<tt/ide1/ - onboard interface) to a hard drive on <tt>/dev/hde</tt>
  (<tt/ide2/ - the Ultra33), you should override the non-essential <tt/ide0/ with
  <tt/ide2/ and leave <tt/ide1/ intact. Assuming the numbers above you would boot with
  ``<tt/ide0=0xe000,0xd806/''. Red Hat 5.0 will give you a shell prompt if you use
  the rescue disk capability, and Slackware includes a shell in the regular installation
  process. However Red Hat 5.0 is difficult to boot after installation; if you have
  problems you could try downloading a Slackware boot disk from <htmlurl
  url="ftp://ftp.cdrom.com/pub/linux/slackware-3.5/bootdsks.144/"
  name="ftp://ftp.cdrom.com/pub/linux/slackware-3.5/bootdsks.144/">
  and using that to boot.

  With another Linux distribution you will have to improvise a bit, but the
  process should be about the same as the above.

  <bf><em>IMPORTANT:</em></bf> Without the patch (discussed in the
  section <ref id="unified" name="Unified IDE">), the
  kernel <bf>needs</bf> these boot parameters in order to access your hard
  disk! Therefore it is very important that when you configure LILO, either on
  the hard disk or on a boot floppy, that you give it the <bf>exact same
  parameters</bf> that you gave when installing. Otherwise your system won't
  boot! It should be possible to give them to LILO when you boot (ie, press
  Shift, type in ``<tt/linux ide2=/<em/...../'' each time you boot), but only
  if you kept the numbers! It is recommended that you patch your kernel as soon
  as possible so you will not have to worry about that anymore; once you are
  booting with a patched kernel, you can get rid of the boot parameters. Also,
  as far as I know there is no way to pass boot parameters to a plain kernel
  boot floppy (as made with ``<tt/make zdisk/''), you <bf>must</bf> use LILO or
  another loader (such as LOADLIN) that lets you pass boot parameters.

  However, unpatched kernels and installation programs often have a difficult
  time actually using ide2 and ide3, even if the drives are detected properly.
  So if you can't get Linux to install using the above technique, try
  specifying ide0 or ide1 instead of ide2 or ide3 (thanks to Martin Gaitan for
  this technique). This essentially replaces the on-board interface
  with the Promise Ultra33 as far as the kernel is concerned, and you can
  follow the directions in the next section as if you had physically moved it.
  Note that if you're using an IDE CD-ROM drive connected to your on-board
  interface to install from, you will want to make sure that you do not take
  over the interface that the CD is on or you will not be able to install! If
  the CD is hda or hdb, use ide1 for your hard drive, and if it is hdc or hdd,
  then use ide0.

  <bf/Installing Linux Around the Ultra33/

  If you cannot get the software workaround to work, you will have to try a
  more brute force approach. Here's an alternative method that is virtually
  guaranteed to work, but  will require you to open up your computer and mess
  about in it. <bf/NOTE:/ If you are not familiar with the process of
  connecting and disconnecting IDE drives, <bf/read the manuals/ that came
  with your computer, your hard drive, and/or the Promise Ultra33 before
  attempting this! If you screw something up and don't know how to put it
  back, you could end up being sorry!
  
  That being said, it's all really quite simple. Most motherboards these days 
  have built-in EIDE interfaces. Disconnect your hard drive from the Ultra33 
  and connect it to the onboard interface. If you have other IDE devices,
  such as a CD-ROM, tape, or ZIP drive, on your oboard interface, it is 
  easiest if you either add the hard drive on an unused channel (the secondary
  instead of the primary) or temporarily displace a device that you don not
  need immediately (such as ZIP or tape). Install Linux. Download and apply 
  the Promise UDMA patch (see next section).
  
  Now you are ready to move the drive back onto the Promise... almost. To be
  safe, make a kernel-image boot floppy (<tt>cd /usr/src/linux ; make
  zdisk</tt>), which you  will be able to use to boot your system in case LILO
  doesn't work. Actually, to be <em/very/ safe, make two and put one away for
  now.
  
  Okay, now it is time
  to think a little... if you have just one hard drive and it is going to be on
  the Promise, then it will most likely be <tt>/dev/hde</tt> (<tt/a/ and 
  <tt/b/ are for the primary
  onboard interface, <tt/c/ and <tt/d/ for the secondary onboard interface).
  If you are going to put any other drives on it, then the slave of the
  Promise's first channel will be <tt>/dev/hdf</tt>, the master of the second
  will be <tt>/dev/hdg</tt>, and the slave of the second will be
  <tt>/dev/hdh</tt>. 
  
  Edit <tt>/etc/fstab</tt>, and change all the partitions of the hard drives
  you are moving from the onboard drives (<tt>/dev/hda</tt>, <tt>hdb</tt>,
  etc) to their new locations  on the Promise (<tt>/dev/hde</tt>, <tt>hdf</tt>,
  etc). If you had to displace any devices (such as a CD-ROM or ZIP drive)
  that you want to leave on the onboard interface, then change them to their
  new locations as well. For instance, if your CD-ROM was originally the
  master on the primary channel (<tt>/dev/hda</tt>), but you put your hard disk
  there and had to bump the CD to the slave  (<tt>/dev/hdb</tt>) or to the
  secondary channel (<tt>/dev/hdc</tt>), and now you want to put  it back, then
  change it to <tt>/dev/hda</tt>.
  
  If you are using LILO, reconfigure LILO to use the new location of the drive
  (LILO configuration is beyond the scope of this document, if you do not know
  how, read the <url url="http://www.linuxdoc.org/HOWTO/mini/LILO.html"
  name="LILO mini-HOWTO">),
  or else it probably will not be able to boot unless you use that boot floppy
  I had you make, which you will also want to configure to boot off the new 
  partition. This is done using the <tt/rdev/ command. Put the floppy in the 
  drive and type ``<tt>rdev /dev/fd0 /dev/hde1</tt>''. Of course that's assuming
  your root partition is the first on your first UDMA drive. If not (mine is 
  <tt>/dev/hde7</tt>, for instance), then obviously use the appropriate 
  partition number!
  
  Reboot. Your system should now work fine.

  <bf/Patching for the Ultra33/

  Kernels 2.0.35 and later support the Promise Ultra33 natively; download an upgrade
  from your Linux distribution or from <htmlurl name="http://www.kernel.org"
  url="http://www.kernel.org">.

  For instructions on how to compile the kernel, read the <htmlurl name="Kernel HOWTO"
  url="http://www.linuxdoc.org/HOWTO/Kernel<65>HOWTO.html">.
  
  <bf/Using two Ultra33 cards in one machine/
  
  This is currently not working correctly... don't do it right now unless you're
  willing to fiddle with the kernel to try to get things to work.

<sect1>Promise Ultra66<label id="promise66">
<p>
  This is essentially the same as the Ultra33 with support for the new UDMA mode 4
  66 MB/sec transfer speed. Unfortunately it is not yet supported by 2.2.x
  kernels.
  
  There is a patch for 2.0.x and 2.2.x kernels availabe at
  <htmlurl url="http://www.kernel.org/pub/linux/kernel/people/hedrick"
  name="http://www.kernel.org/pub/linux/kernel/people/hedrick">, and support is
  included in the 2.3.x development kernel series at least as of 2.3.3.
  
  However to get far enough to patch or upgrade the kernel you'll have to pull
  the same dirty tricks as for the Ultra33 as in the section above, or else
  use a boot disk image <url name="provided by Promise"
  url="http://www.promise.com/latest/latedrivers.htm#linuxu66">

<sect1>Artop ATP850UF<label id="artop">
<p>

  This card is supported by the unified IDE code. Installation of Linux onto a system
  with one of these as the interface for the target disk may be similar to the
  workarounds for the Promise Ultra33.

<sect1>Adding device files
<p>

  The tertiary and quaternary IDE interfaces (ide2 and ide3) use device files of
  the form <tt>/dev/hde*</tt> through <tt>/dev/hdh*</tt>. On older kernels these
  devices were not automatically created, so you may need to add them manually
  for things to work properly.
  
  This can be done easily if you have a current copy of the Linux kernel source
  installed; simply run <tt>/usr/src/linux/scripts/MAKEDEV.ide</tt> and it will create
  all relevant device files.

<sect>Onboard UDMA interfaces<label id="onboard">
<p>

  These are UDMA<4D>capable drive interfaces built into motherboards. They use
  the standard IDE I/O ports and so are fully usable at the slower non<6F>UDMA
  speeds on an unpatched 2.0.x kernel such as are used when installing Linux.
  Thus they should not cause any difficulties during installation, and patching
  for UDMA speed is a welcome luxury instead of a necessary step. Some UDMA
  support is in the latest 2.0.x kernels I believe, and is built into current
  2.2.x kernels for the Intel chipsets.

<sect1>Intel FX, HX, VX, TX, LX, and BX<label id="intel">
<p>

  Thanks again to Gadi for this info:

<tscreen><verb>
Bus mastering DMA support for the Intel TX chipset is available in 2.0.31
and above.
</verb></tscreen>

  In older kernels (such as Slackware 3.4's 2.0.30), the interface will be
  used in the slower EIDE mode.
  In either case the interface will be automatically detected by the kernel
  and you should have no trouble using it.

  Full UDMA mode 2 support for these chipsets is included in 2.2.x kernels
  and the unified IDE patch; see <ref id="unified" name="Unified IDE">.

<sect1>The VIA VP2 and Related Chipsets<label id="via">
<p>

  This interface also can be autodetected and used in EIDE mode by an unpatched
  kernel, but if you have one of these, you will want to grab a patch so you
  can get faster throughput and do away with annoying "unkown PCI device"
  messages.
  
  One is available at
  <htmlurl url="http://www.ipass.net/~prefect"
    name="http://www.ipass.net/&tilde;prefect/">; it is designed for the VIA VP2/97
  chipset, found on FIC's PA-2007 and PA-2011 motherboards, but may work on related chipsets.
  It has been reported that it functions on the newer VIA VP3 chipset, your mileage may vary.

  Note that this patch only supports Bus Mastering mode,
  not full UDMA mode, but it's still better than plain-vanilla EIDE mode.
  Follow the directions at the patch's site for enabling BMDMA mode.

  There is another patch that supports full UDMA mode at
  <htmlurl url="http://www.pyreneesweb.com/Udma/udma.html"
    name="http://www.pyreneesweb.com/Udma/udma.html">,
  designed for the VIA VT82C586B, and it ought to work on the
  VP2, VP3, VPX, P6 and AGP Apollo chipsets. Follow the directions 
  for installation and UDMA enabling there, but it is recommended that you
  back up any data you want to keep, as there are potential problems with 
  incompatible motherboards. But, if it does work, it should work without 
  problems.
  
  Note that the VP1 chipset is not known to work with these patches,
  but is supported by the <ref id="unified" name="Unified IDE"> patch.

<sect1>TX Pro and other ``Pro'' boards
<p>

  UDMA is not currently supported for the TX Pro motherboards. They are not
  the same as a TX mobo, and apparently misreport their DMA capabilities hence
  the problem. Someone is working on this I hear, so a patch may appear some
  time in the future but not yet.

<sect1>HPT 366<label id="hpt366">
<p>

  This chipset is on the popular Abit BP-6 motherboard and others, and provides
  UDMA mode 4 66MB/s support on two generals, generally in addition to two
  other mode 2 33MB/s channels. It is supported by the current <ref id="unified"
  name="unified IDE code"> but not in any current release kernels. Installation
  thus may require workarounds similar to the <ref id="promise"
  name="Promise Ultra33"> did on older 2.0.x kernels.
  
  

<sect>Unified IDE Patches<label id="unified">
<p>

  The unified IDE patches provide support for many chipsets and offboard cards,
  and are available for 2.0.x, 2.2.x, and the 2.3.x development kernels. If your
  chipset isn't supported by a current stock kernel, you'll want to patch it with
  these.
  
  The unified IDE code is maintained by <url name="Andre Hedrick" url="mailto:andre@suse.com">,
  and patches are available at <url name="your local kernel archive mirror"
  url="http://www.kernel.org/pub/linux/kernel/people/hedrick">.
  
  UDMA support is provided for at least the following chipsets, and probably
  many more I don't know about:

<itemize>
<item>All Intel chipsets: FX, HX, VX, TX, LX
<item>All SiS chipsets (only SiS5598 tested, but this entire family of
  chipsets has the same bult-in 5513 interface device).
<item>VIA chipsets (only 82C586B tested, but again this family of
  chipsets has the same interface structure). Special diagnostics
  support is available for the VIA interfaces.
<item>Promise and Artop PCI UDMA interface cards support.
<item>Aladdin V (ALi15x3) chipset
<item>HPT343 board and HPT366 onboard chipset (caveat, see <ref id="hpt366" name="Abit BP-6">)
</itemize>

  It is also designed to be easy to extend to support other chipsets.
  
Here are a few notes from Andre Balsa, the author of an earlier patch:

<tscreen><verb>
Performance with IBM UDMA drives on a good motherboard approches the
maximum head transfer rates: about 10 Mb/s (measured with hdparm -t -T).

The Intel TX chipset has a single FIFO for hard disk data shared by
its two IDE interfaces, so using 2 UDMA drives will not yield such a
great improvement over a single UDMA drive.
However, the SiS5598 has two completely separate interfaces, each with
its own FIFO. Theoretically, one could approach 66Mb/s burt transfer
rates on motherboards with the SiS5598 chip, using the md driver and
data striping over two drives. The SiS5571 has the same interface
architecture, I think. I don't have the VIA chipsets datasheets, so I
can't say anything about those.

The Linux IDE (U)DMA kernel driver by Mark Lord has a particularly
low setup time (i.e. latency for data transfers). It is ideal for
frequent, small data transfers (such as those in Linux news servers),
and might be in some cases superior to its SCSI counterparts.
</verb></tscreen>


<sect>Activating and Deactivating UDMA<label id="activate">
<p>

  Normally, a UDMA-aware kernel will automatically enable UDMA support for
  drives and interfaces that support it. In most cases that it doesn't, the kernel
  either doesn't know how to drive your IDE chipset (get yourself a patch, see
  <ref id="unified" name="above">) or doesn't believe it is safe to enable
  it (meaning you shouldn't!).
  
  However in some cases the drive is capable of UDMA but the BIOS drops the ball
  and doesn't report it properly, and forcing the issue can be useful.

<sect1>Using kernel boot parameters<label id="bootparam">
<p>

  On kernels 2.1.113 and up, you can enable DMA for both drives on a given IDE
  interface using the <tt/ideX=dma/ kernel parameter, where X is the number
  of the interface (the first is 0). This may not actually force UDMA though.
  
  Kernel boot parameters can be set using LILO, LOADLIN, or most Linux boot
  loaders. For more information see the <htmlurl name="Bootdisk HOWTO"
  url="http://www.linuxdoc.org/HOWTO/Bootdisk-HOWTO.html">.
  

<sect1>Using hdparm<label id="hdparm">
<p>

  <tt/hdparm/ is a program used to tweak the parameters of hard drives under
  Linux. Among other things you can use it to enable or disable UDMA for a
  drive and test its sustained transfer rate.
  
  The current version of <tt/hdparm/, is 3.6 as of this writing. Unpatched older versions
  will not properly report or set information on UDMA, so be sure to upgrade! You
  can obtain the source code for hdparm 3.6 at
  <htmlurl url="http://metalab.unc.edu/pub/Linux/system/hardware/hdparm-3.6.tar.gz"
  name="http://metalab.unc.edu/pub/Linux/system/hardware/hdparm-3.6.tar.gz">.
  
  Compile and install it something like this:
  
<tscreen><verb>
tar zxvf /tmp/download/hdparm-3.6.tar.gz
cd hdparm-3.5
make
su root
(type password when prompted)
make install
cp /usr/local/sbin/hdparm /sbin/hdparm
exit
</verb></tscreen>

  <bf/To enable DMA for a hard drive:/ <tt>hdparm -d1 /dev/hda</tt>
  
  <bf/To disable DMA for a hard drive:/ <tt>hdparm -d0 /dev/hda</tt>
  
  <bf/To measure transfer rate of a hard drive:/ <tt>hdparm -Tt /dev/hda</tt>
  
  <bf/To see what options are enabled for a hard drive:/ <tt>hdparm /dev/hda</tt>
  
  <bf/To see more info on your drive than you wanted to know/: (this will show which UDMA
  modes are supported/enabled)
  <tt>hdparm -i /dev/hda</tt>
  
  For more detailed info (such as how to choose which UDMA mode to use) read
  the man page (``<tt/man 8 hdparm/'').

<sect>Problems

<sect1>The UDMA Blacklist<label id="blacklist">
<p>

  The following drives are ``blacklisted''. You should <bf/not/ use UDMA with
  these drives as it may cause corruption of data. To avoid this, the driver
  should automatically disable DMA for these drives.

<itemize>
  <item>Western Digital WDC AC11000H, AC22100H, AC32500H, AC33100H, AC31600H - all versions
  <item>Western Digital WDC AC32100H revision 24.09P07
  <item>Western Digital WDC AC23200L revision 21.10N21
</itemize>

<sect1>Are you overclocking?
<p>

  If you are, beware! Here is a quote from the old udma-generic documentation:

<tscreen><verb>
DON'T OVERCLOCK the PCI bus. 37.5MHz is the maximum supported speed for
the PCI bus. Some (supposedly compatible) UDMA drives will not even take
37.5MHz, but should be OK at 33.3MHz.

In any case, NEVER, NEVER set the PCI bus to 41.5MHz.

The RECOMMENDED safe setting is 33MHz.
</verb></tscreen>

<sect1>Is your BIOS current?
<p>

  Here is another clip from the udma-generic docs:

<tscreen><verb>
The real work involved in setting up the chips for DMA transfers is done
mostly by the BIOS of each motherboard. Now of course one hopes that the
BIOS has been correctly programmed...

For example, the ASUS SP-97V motherboard with its original BIOS (Rev. 1.03)
would malfunction with the modified Linux driver in both DMA mode 2 and UDMA
modes; it would work well using PIO mode 4, or under Windows 95 in all
modes. I downloaded the latest BIOS image (Rev. 1.06) from the ASUS Web site
and flashed the BIOS EPROM with the latest BIOS revision. It has been
working perfectly ever since (at 66 MHz bus speeds).

What this tells us is that the BIOS sets up the DMA controller with specific
timing parameters (active pulse and recovery clock cycles). My initial BIOS
revision probably had bad timings. Since the Windows 95 driver sets up those
timings by itself (i.e. it does not depend on the BIOS to setup the hard
disk controller timing parameters), I initially had problems only with the
Linux driver, while Windows 95 worked well.

So, let me state this again: this Linux (U)DMA driver depends on the BIOS for
correct (U)DMA controller setup. If you have problems, first check that you
have the latest BIOS revision for your specific motherboard.

...

New BIOS revisions can be downloaded from your motherboard manufacturer's
Web site. Flashing a new BIOS image is a simple operation but one must
strictly follow the steps explained on the motherboard manual.

Late Award BIOS revisions seem stable with respect to UDMA. Anything with a
date of 1998 should be fine.
</verb></tscreen>

<sect1>If you still can't get it to work!<label id="help">
<p>

  If nothing in this document proved helpful, or at least not helpful enough
  to get your machine working, your best bet is to write up a message that
  fully describes your difficulty, what type of UDMA interface you have,
  whether it is onboard or on a card, if your drive is actually UDMA or plain
  EIDE, exactly what configuration of drives you have, what version (distribution
  &amp; kernel versions if possible) of Linux you are using, and anything
  else that sounds useful, and post it to the newsgroup
  <htmlurl url="news:comp.os.linux.hardware" name="comp.os.linux.hardware">.
  You will probably get some helpful suggestions soon.

<sect>If you have some information about UDMA stuff that's not in this mini-howto...
<label id="suggest">
<p>

  Great! If you know something I don't, by all means send it to me
  (<htmlurl url="mailto:brion@pobox.com" name="brion@pobox.com">)
  and I will put it in this document and update it fairly soon.

</article>