patch-pre2.0.2 linux/drivers/block/README.ide

Next file: linux/drivers/block/ide.c
Previous file: linux/drivers/block/MAKEDEV.ide
Back to the patch index
Back to the overall index

diff -u --recursive --new-file pre2.0.1/linux/drivers/block/README.ide linux/drivers/block/README.ide
@@ -1,559 +1,3 @@
-README.ide -- Information regarding ide.c and ide-cd.c (IDE driver in 1.3/2.0)
-================================================================================
-Supported by:  mlord@pobox.com        -- disks, interfaces, probing
-               snyder@fnald0.fnal.gov -- cdroms, ATAPI, audio
-
-   +-----------------------------------------------------------------+
-   |  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 *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 on most cards
-		- experimental interface timing 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 <jlaiho@ichaos.nullnet.fi>).
-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-2.7 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 (for kernel versions after 1.3.21)
-***  =================
-***  PCI versions of the CMD640 and RZ1000 interfaces are now detected
-***  automatically at startup when PCI BIOS support is configured.
-***  Linux disables the "pre-fetch" or "read-ahead" modes of these interfaces
-***  to prevent data corruption possible due to hardware design flaws.
-***  Use of the "serialize" option is no longer necessary.
-***
-***  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.
-
-
-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:   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 primary and secondary interfaces,
-for the drives/geometries attached to those interfaces, and for the
-IRQ numbers being used by the interfaces (normally IRQ14 & IRQ15).
-
-Interfaces beyond the first two are not normally probed for, but may be
-specified using kernel "command line" options.  For example,
-
-	ide3=0x1e8,0x3f0,11	/* ioports 0x1e8-0x1ef,0x3f0, irq 11 */
-
-Normally the irq number need not be specified, as ide.c will probe for it:
-
-	ide3=0x1e8,0x3f0	/* ioports 0x1e8-0x1ef,0x3f0 */
-
-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 harddisk.
-
-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 harddrive 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.
-
- "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
-
-================================================================================
-EIDE card compatibility reports:
-================================================================================
-
-comp.os.linux.hardware #18483 (7 + 0 more)                            (1)--[1]
-From: test <a>
-[1] Re: Promise EIDEMAX
-Date: Fri Aug 11 23:17:39 EDT 1995
-Organization: Technical University of Brno, Czech Republic
-Lines: 14
-Mime-Version: 1.0
-Content-Type: text/plain; charset=us-ascii
-Content-Transfer-Encoding: 7bit
-X-Mailer: Mozilla 1.1N (X11; I; Linux 1.2.11 i486)
-To: rmorton@VNET.IBM.COM
-X-URL: news:19950806.154256.872@almaden.ibm.com
-
-I have a Promise <sth>2300 board with DX2/80 w/ 32Mb ram.
-
-This one is a bit schizophrenic - half (2 drives) at VLBUS and
-the rest 2 on ISA.
-
-Works quite well, Linux works with it (4 HDDs), it
-also supports its dual irq mechanism (14 & 15).
-In the documentation I've found that there are certain things made about this
-controller(in kernel).
-My current kernel is 1.2.11 and Promise should be supported in all 1.2.xx
-kernels I think.
-
-   Vladimir Myslik
-
-comp.sys.intel #41571 (1 + 2 more)              --(1)--(1)+-(1)--(1)
-From: triblet@almaden.ibm.com (Chuck Tribolet)            \-(1)--(1)--(1)--(1)
-Newsgroups: comp.sys.intel,comp.os.os2.bugs
-[1] Re: RZ1000 errorIntel motherboards and RZ1000
-Date: Tue Aug 29 11:00:12 EDT 1995
-Organization: IBM Almaden Research Center
-Lines: 20
-X-Newsreader: IBM NewsReader/2 v1.02
-
-In <41ip85$gf9@park.uvsc.edu>, Terry Lambert <terry@cs.weber.edu> writes:
->Try running a real OS.  BIOS drivers so not initiate bus mastering
->DMA, and DOS does not interleave I/O.
-
-1: The RZ1000 can't do DMA.
-2: I was running OS/2 (2.11 back then).
-
-I agreed that you might be able to concoct a benchmark that was affected,
-but it has had no real world effect for me or a lot of other people.  Disabling
-IDE prefetch has the effect of a small increase in PCI bus busy at a time
-when the CPU is giving all its CPU cycles to the IDE driver (because the
-RZ1000 can't run DMA and the driver has to be in a PIO loop) and therefore
-the CPU can't do much of anything else anyway.
-
-
-Chuck Tribolet
-Triblet@Almaden.IBM.Com
-San Jose, CA
- 
-Silicon Valley - best day job in the world
-
-================================================================================
-
- 1995 Nov 16 at 08:25  EST
- from:       'dwhysong@dolphin.physics.ucsb.edu' (BNR400)
-
-[I'm cc'ing this to Mark Lord: FYI, I've got at DTC2278S VLB EIDE
-controller with a Connor CFA850A as /dev/hda and a Maxtor 7213A as
-/dev/hdb using Linux 1.2.13 w/patches for assembly strcpy and the kswap
-patches. I'm getting strange behavior and an unstable system when I try to
-use 32 bit VLB data transfer to the interface card. However, hdparm
-reports that the Connor is extremely fast when I can get the 32 bit mode
-enabled using hdparm -c1 /dev/hd(a|b). However, if I don't do hdparm -c1
-on both /dev/hda and /dev/hdb, then when I run "hdparm -t /dev/hda" the
-disk subsystem locks up... the disk LED comes on and stays on, and no
-other programs are able to get disk access (I can switch VC's, but I can't
-get past the username prompt). I thought you should know about this. I'm
-not sure if it's a problem with the support for the DTC cards, or a
-peculiarity with my hardware configuration. I doubt that my hardware
-itself is flaky, though that's always a possibility.]
-
-On Wed, 15 Nov 1995, Michael Faurot wrote:
-
-> > The trick is setting BOTH drives to use the 32 bit interface.
->
-> Congrats on getting it going.  Those are some great transfer
-> rates.  I noticed you did switch on the unmasking.  Noticed any
-> problems with things under extreme load or with serial transfers?
-
-I've never had any problems which I could trace to interrupt unmasking.
-Of course, my system usually doesn't have a really heavy load, either.
-These numbers seem way too high for a disk with something like 3500 (?)
-RPM.
-
-Sleepy# hdparm -t /dev/hda
-
-/dev/hda:
- Timing buffer-cache reads:   32 MB in  2.24 seconds =14.29 MB/sec
- Timing buffered disk reads:  16 MB in  3.63 seconds = 4.41 MB/sec
- Estimating raw driver speed: 16 MB in  2.51 seconds = 6.37 MB/sec
-
-> Not sure I was much help to you, but I'm glad to hear you got it
-> working--and pretty impressively at that. :-)
-
-Mmm, well, about that... I've found that my Connor drive (/dev/hda) is
-pretty fast when I have my system configured like this. I'm still not
-sure I trust the "hdparm -t"  results, though. However, when I try
-"hdparm -t /dev/hdb" (/dev/hdb is an older Maxtor 7213A) I have the same
-problem I had before with my disk subsystem locking up.
-
-I've tried just about every possible combination of flags in ide.c and
-hdparm, and I can't get decent performance out of this drive/controller
-combination without some kind of instability creeping in. I'm living with
-the situation now only because /dev/hdb is a DOS-only drive, and I don't
-need it under Linux. However, I don't really like the situation.
-
--Dave
-dwhysong@physics.ucsb.edu
-
-(Why can't this stuff be simple? Plug the card in, and it works? Every
-hardware manufacturer has to have their own way of doing things...)
+The IDE driver Documentation is now in the linux/Documentation directory.
 
+-mlord@pobox.com

FUNET's LINUX-ADM group, linux-adm@nic.funet.fi
TCL-scripts by Sam Shen, slshen@lbl.gov with Sam's (original) version
of this