D: Author and maintainer of the QIC-02 tape driver
S: The Netherlands
+N: Ross Biro
+E: bir7@leland.Stanford.Edu
+D: Original author of the Linux networking code
+
N: Thomas Bogendoerfer
E: tsbogend@bigbug.franken.de
D: Lance32 driver
S: 91452 Wilhermsdorf
S: Germany
-N: Ross Biro
-E: bir7@leland.Stanford.Edu
-D: Original author of the Linux networking code
-
N: Bill Bogstad
E: bogstad@cs.jhu.edu
D: Wrote /proc/self patch
S: Boulder, Colorado 80302
S: USA
+N: Heiko Eissfeldt
+E: heiko@colossus.escape.de heiko@unifix.de
+D: verify_area stuff, generic scsi fixes
+D: SCSI Programming HOWTO
+D: POSIX.1 compliance testing
+S: Unifix Software GmbH
+S: Bueltenweg 27a
+S: D-38106 Braunschweig
+S: Germany
+
N: Bjorn Ekwall
E: bj0rn@blox.se
W: http://www.pi.se/blox/
S: Chapel Hill, North Carolina 27514-4818
S: USA
+N: Bernhard Kaindl
+E: bartelt@computerhaus.at
+D: Author of a menu based configuration tool, kmenu, which
+D: is the predecessor of 'make menuconfig' and 'make xconfig'.
+S: Tallak 95
+S: 8103 Rein
+S: Austria
+
N: Fred N. van Kempen
E: waltje@uwalt.nl.mugnet.org
D: NET-2
E: rfkoenig@immd4.informatik.uni-erlangen.de
D: The Linux Support Team Erlangen
+N: Gero Kuhlmann
+E: gero@gkminix.han.de
+D: mounting root via NFS
+S: Donarweg 4
+S: D-30657 Hannover
+S: Germany
+
N: Markus Kuhn
E: mskuhn@cip.informatik.uni-erlangen.de
W: http://wwwcip.informatik.uni-erlangen.de/user/mskuhn
S: D-91080 Uttenreuth
S: Germany
-N: Gero Kuhlmann
-E: gero@gkminix.han.de
-D: mounting root via NFS
-S: Donarweg 4
-S: D-30657 Hannover
-S: Germany
-
N: Bas Laarhoven
E: bas@vimec.nl
D: Loadable modules and ftape driver
D: Keeper of the Jargon File and curator of the Retrocomputing Museum
D: Author, Emacs VC and GUD modes
-N: Bernhard Kaindl
-E: bartelt@computerhaus.at
-D: Author of a menu based configuration tool, kmenu, which
-D: is the predecessor of 'make menuconfig' and 'make xconfig'.
-S: Tallak 95
-S: 8103 Rein
-S: Austria
-
N: Stefan Reinauer
E: stepan@home.culture.mipt.ru
W: http://home.culture.mipt.ru/~stepan
S: 2135 CN Hoofddorp
S: The Netherlands
-N: Stephen D. Williams
-E: sdw@lig.net
-E: sdw@meaddata.com
-D: Consultant, entrepreneur, developer
-S: 2464 Rosina Drive
-S: Dayton, Ohio 45342-6430
-S: USA
-
N: G\"unter Windau
E: gunter@mbfys.kun.nl
D: Some bug fixes in the polling printer driver (lp.c)
In the latest 1.3.x kernel releases the /proc file system structure
was changed, so you need to upgrade the procps package to version
0.99a. In the very latest kernels, /proc has changed again. There's
-not yet an officially updated version of procps, so make due with
+not yet an officially updated version of procps, so make do with
0.99a; you might want to look for one of the patches floating around to
update 0.99a for use with 1.3.94 and later kernels.
Apart from the somewhat unstructured interfacing with software, the
actual execution of the commands is different for most of the
different drivers: e.g., some drivers close the tray if an $open()$ call
-occurs while the tray is unloaded, others not. Some drivers lock the
+occurs while the tray is unloaded, while others do not. Some drivers lock the
door upon opening the device, to prevent an incoherent file system,
but others don't, to allow software ejection. Undoubtedly, the
capabilities of the different drives vary, but even when two drives have
\subsection{$Disc_status(dev_t\ dev)$}
\label{disc status}
-As a complement to $drive_status()$, this functions can provide the
+As a complement to $drive_status()$, this function can provide the
general \cdrom-routines with information about the current disc that is
inserted in the drive represented by $dev$. The history of development
of the CD's use as a carrier medium for various digital information
CDS_XA_2_2& mixed data (XA), mode 2, form 1 (2324 user bytes)\cr
}
$$
-As far as I know, \cdrom's are always of type $CDS_DATA_1$. For
+As far as I know, \cdrom s are always of type $CDS_DATA_1$. For
some information concerning frame layout of the various disc types, see
a recent version of {\tt cdrom.h}.
a disc selection can be made by software. This function should perform
disc selection. It should return the number of the selected disc on
success, a negative value on error. Currently, none of the \linux\
-\cdrom\ drivers appear to support such functionality, but it defined
-here for future purpose.
+\cdrom\ drivers appears to support such functionality, but it is defined
+here for future purposes.
\subsection{$Get_last_session(dev_t\ dev, struct\ cdrom_multisession *
ms_info)$}
problem here could be the fact that audio-frames are 2352 bytes long,
so either the audio-file-system should ask for 75264 bytes at once
(the least common multiple of 512 and 2352), or the drivers should
-bend their backs to cope with this incoherence (to which I would
-oppose, this code then should be standardized in \cdromc).
+bend their backs to cope with this incoherence (to which I would be
+opposed). Once this question is resolved, this code should be standardized in
+\cdromc.
Because there are so many $ioctl$s that seem to be introduced to
satisfy certain drivers,\footnote{Is there software around that actually uses
-these? I 'd be interested!} any `non-standard' $ioctl$s are routed through
+these? I'd be interested!} any `non-standard' $ioctl$s are routed through
the call $dev_ioctl()$. In principle, `private' $ioctl$s should be
numbered after the device's major number, and not the general \cdrom\
$ioctl$ number, {\tt 0x53}. Currently the non-supported $ioctl$s are:
CDC_PLAY_AUDIO& can perform audio-functions (play, pause, etc)\cr
}
$$
-The capability flag is declared $const$, to prevent drivers to
-accidentally tamper with the contents. However, upon registration,
+The capability flag is declared $const$, to prevent drivers from
+accidentally tampering with the contents. However, upon registration,
some (claimed) capability flags may be cleared if the supporting
function has not been implemented (see $register_cdrom()$ in
\cdromc).
if\ (cdo\rightarrow capability \mathrel\& \mathord{\sim} cdo\rightarrow mask
\mathrel{\&} CDC_<capability>) \ldots
$$
-The $mask$ could be set in the low-level driver code do disable
+The $mask$ could be set in the low-level driver code to disable
certain capabilities for special brands of the device that can't
-perform the actions. However, there is not (yet) and $ioctl$ to set
+perform the actions. However, there is not (yet) an $ioctl$ to set
the mask\dots The reason is that I think it is better to control the
{\em behavior\/} rather than the {\em capabilities}.
\subsection{Options}
A final flag register controls the {\em behavior\/} of the \cdrom\
-drives, in order to satisfy the different users's wishes, hopefully
-independently of the ideas of the respectable author that happened to
+drives, in order to satisfy different users' wishes, hopefully
+independently of the ideas of the respective author who happened to
have made the drive's support available to the \linux\ community. The
current behavior options are:
$$
device in order to get a file handle which is needed for issuing
$ioctl$ commands, while data use wants to open for correct and
reliable data transfer. The only way user programs can indicate what
-their {\em purpose\/} of opening the device is, is trough the $flags$
+their {\em purpose\/} of opening the device is, is through the $flags$
parameter (see {\tt open(2)}). For \cdrom\ devices, these flags aren't
implemented (some drivers implement checking for write-related flags,
but this is not strictly necessary if the device file has correct
\cdrom\ devices: $O_CREAT$, $O_NOCTTY$, $O_TRUNC$, $O_APPEND$, and
$O_SYNC$ have no meaning to a \cdrom.
-We therefore propose to use the flag $O_NONBLOCK$ as an indication
+We therefore propose to use the flag $O_NONBLOCK$ to indicate
that the device is opened just for issuing $ioctl$
commands. Strictly, the meaning of $O_NONBLOCK$ is that opening and
subsequent calls to the device don't cause the calling process to
-wait. We could interpret this as ``don't wait until someone has been
+wait. We could interpret this as ``don't wait until someone has
inserted some valid data-\cdrom.'' Thus, our proposal of the
implementation for the $open()$ call for \cdrom s is:
\begin{itemize}
\subsection{And what about standards?}
-You might hesitate to accept this proposal as is comes from the
+You might hesitate to accept this proposal as it comes from the
\linux\ community, and not from some standardizing institute. What
about SUN, SGI, HP and all those other Unix and hardware vendors?
Well, these companies are in the lucky position that they generally
differences in behavior of the various drivers, and the need for an
$ioctl$ informing about media changes.}
-We believe that using $O_NONBLOCK$ as indication for opening a device
-for $ioctl$ commanding only, can be easily introduced in the \linux\
+We believe that using $O_NONBLOCK$ to indicate that a device is being opened
+for $ioctl$ commands only can be easily introduced in the \linux\
community. All the CD-player authors will have to be informed, we can
even send in our own patches to the programs. The use of $O_NONBLOCK$
has most likely no influence on the behavior of the CD-players on
\subsection{The preferred strategy of $open()$}
-The routines in \cdromc\ are designed in such way, that a run-time
+The routines in \cdromc\ are designed in such a way that a run-time
configuration of the behavior of \cdrom\ devices (of {\em any\/} type)
can be carried out, by the $CDROM_SET/CLEAR_OPTIONS$ $ioctls$. Thus, various
modes of operation can be set:
The following $ioctl$s have been introduced to allow user programs to
control the behavior of individual \cdrom\ devices. New $ioctl$
-commands an be identified by their underscores in the name.
+commands can be identified by the underscores in their names.
\begin{description}
\item[CDROM_SET_OPTIONS] Set options specified by $arg$. Returns the
option flag register after modification. Use $arg = \rm0$ for reading
\item[CDROM_DRIVE_STATUS] Returns the status of the drive by a call to
$drive_status()$. Return values are as defined in section~\ref{drive
status}. Note that this call doesn't return information on the
- current playing activity of the drive, this can be polled through an
+ current playing activity of the drive; this can be polled through an
$ioctl$ call to $CDROMSUBCHNL$.
\item[CDROM_DISC_STATUS] Returns the type of the disc currently in the
drive by a call to $disc_status()$. Return values are as defined in
and return values.
\item Rename your $<device>_ioctl()$ function to $audio_ioctl$ and
change the prototype a little. Remove entries listed in the first part
-in section~\ref{cdrom-ioctl}, if your code was OK, this are just calls
+in section~\ref{cdrom-ioctl}, if your code was OK, these are just calls
to the routines you adapted in the previous step.
\item You may remove all remaining memory checking code in the
-$audio_ioctl()$ function that deal with audio commands (these are
+$audio_ioctl()$ function that deals with audio commands (these are
listed in the second part of section~\ref{cdrom-ioctl}). There is no
need for memory allocation either, so most $case$s in the $switch$
statement look similar to:
Thanks to all the people involved. Thanks to Thomas Quinot, Jon Tombs,
Ken Pizzini, Eberhard M\"onkeberg and Andrew Kroll, the \linux\
-\cdrom\ device driver developers that were kind enough to give
-sugestions and criticisms during the writing. Finally of course, I
+\cdrom\ device driver developers who were kind enough to give
+suggestions and criticisms during the writing. Finally of course, I
want to thank Linus Torvalds for making this possible in the first
place.
Changes since version 0.99
--------------------------
- Interfacing to the kernel is routed though an extra interface layer,
- cdrom.c. This allows runtime-configurable `bahavior' of the cdrom-drive,
+ cdrom.c. This allows runtime-configurable `behavior' of the cdrom-drive,
independent of the driver.
Features since version 0.33
Since version 0.96, much of the functionality has been transferred to
a generic cdrom interface in the file cdrom.c. The module cm206.o
-depends on cdrom.o. If the latter is not compiled in in the kernel,
+depends on cdrom.o. If the latter is not compiled into the kernel,
you must explicitly load it before cm206.o:
insmod /usr/src/linux/modules/cdrom.o
insmod /usr/src/linux/modules/cm206.o cm206=0x300,11
-The order of base port and irq line don't matter; you may specify only
+The order of base port and irq line doesn't matter; you may specify only
one, the other will have the value of the compiled-in default. You
may also have to install the file-system module `iso9660.o', if you
didn't compile that into the kernel.
(c) 1995 David A. van Leeuwen
The driver is released under the conditions of the GNU general public
-license, that can be found in the file COPYING in the root of this
+license, which can be found in the file COPYING in the root of this
source tree.
--- /dev/null
+IDE-CD driver documentation
+10 May 1996
+scott snyder <snyder@fnald0.fnal.gov>
+
+1. Introduction
+---------------
+
+The ide-cd driver should work with all ATAPI 1.2 compliant cdrom
+drives which attach to an IDE interface. Note that some cdrom vendors
+(including Mitsumi, Sony, Creative, Aztech, and Goldstar) have made
+both ATAPI-compliant drives and drives which use a proprietary
+interface. If your drive uses one of those proprietary interfaces,
+this driver will not work with it (but one of the other cdrom drivers
+probably will). This driver will not work with `ATAPI' drives which
+attach to the parallel port. In addition, there is at least one drive
+(CyCDROM CR520ie) which attaches to the IDE port but is not ATAPI;
+this driver will not work with drives like that either (but see the
+aztcd driver).
+
+This driver provides the following features:
+
+ - Reading from data tracks, and mounting iso9660 filesystems.
+
+ - Playing audio tracks. Most of the cdrom player programs floating
+ around should work; i usually use Workman.
+
+ - Multisession support.
+
+ - On drives which support it, reading digital audio data directly
+ from audio tracks. The program cdda2wav can be used for this.
+ Note, however, that only a few drives actually support this
+ function; the only ones which i've heard of successes with are Sony
+ and Toshiba drives.
+
+ - There is now rudimentary support for cdrom changers which comply
+ with the ATAPI 2.6 draft standard (such as the NEC CDR-251). This
+ merely adds a function to switch between the slots of the changer
+ under control of an external program. A sample such program is
+ appended to the end of this file. I've heard that the Sanyo 3-disc
+ changer does not conform to this standard, so the changer functions
+ will probably not work with that drive.
+
+
+2. Installation
+---------------
+
+0. The ide-cd relies on the ide disk driver. See
+ drivers/block/README.ide for up-to-date information on the ide
+ driver.
+
+1. Make sure that the ide and ide-cd drivers are compiled into the
+ kernel you're using. When configuring the kernel, say `yes' to the
+ options
+
+ Enhanced IDE/MFM/RLL disk/cdrom/tape support
+ Include IDE/ATAPI CDROM support
+
+ and `no' to
+
+ Use old disk-only driver on primary interface
+
+ Depending on what type of IDE interface you have, you may need to
+ specify additional configuration options. See
+ drivers/block/README.ide.
+
+2. You should also ensure that the iso9660 filesystem is either
+ compiled into the kernel or available as a loadable module. You
+ can see if a filesystem is known to the kernel by cat'ing the file
+ /proc/filesystems.
+
+3. The cdrom drive should be connected to the host on an IDE
+ interface. Each interface on a system is defined by an I/O port
+ address and an IRQ number, the standard assignments being
+ 0x170 and 14 for the primary interface and 0x1f0 and 15 for the
+ secondary interface. Each interface can control up to two devices,
+ where each device can be either a hard drive, a cdrom drive, or a
+ tape drive. The two devices on an interface are called `master'
+ and `slave'; this is usually selectable via a jumper on the drive.
+
+ Linux names these devices as follows. The master and slave devices
+ on the primary IDE interface are called `hda' and `hdb',
+ respectively. The drives on the secondary interface are called
+ `hdc' and `hdd'. (Interfaces at other locations get other letters
+ in the third position; see drivers/block/README.ide.)
+
+ If you want your cdrom drive to be found automatically by the
+ driver, you should make sure your IDE interface uses either the
+ primary or secondary addresses mentioned above. In addition, if
+ the cdrom drive is the only device on the IDE interface, it should
+ be jumpered as `master'. (If for some reason you cannot configure
+ your system in this manner, you can probably still use the driver.
+ You may have to pass extra configuration information to the kernel
+ when you boot, however. See drivers/block/README.ide for more
+ information.)
+
+4. Boot the system. If the drive is recognized, you should see a
+ message which looks like
+
+ hdb: NEC CD-ROM DRIVE:260, ATAPI CDROM drive
+
+ If you do not see this, see section 5 below.
+
+5. You may want to create a symbolic link /dev/cdrom pointing to the
+ actual device. You can do this with the command
+
+ ln -s /dev/hdX /dev/cdrom
+
+ where X should be replaced by the letter indicating where your
+ drive is installed.
+
+6. You should be able to see any error messages from the driver with
+ the `dmesg' command.
+
+
+3. Basic usage
+--------------
+
+An iso9660 format cdrom can be mounted by putting the disc in the
+drive and typing (as root)
+
+ mount -t iso9660 /dev/cdrom /mnt/cdrom
+
+where it is assumed that /dev/cdrom is a link pointing to the actual
+device (as described in step 5 of the last section) and /mnt/cdrom is
+an empty directory. You should now be able to see the contents of the
+cdrom under the /mnt/cdrom directory. If you want to eject the cdrom,
+you must first dismount it with a command like
+
+ umount /mnt/cdrom
+
+Note that audio cds cannot be mounted.
+
+Some distributions set up /etc/fstab to always try to mount a cdrom
+filesystem on bootup. It is not required to mount the cdrom in this
+manner, though, and it may be a nuisance if you change cdroms often.
+You should feel free to remove the cdrom line from /etc/fstab and
+mount cdroms manually if that suits you better.
+
+Multisession and photocd discs should work with no special handling.
+The hpcdtoppm package (ftp.gwdg.de:/pub/linux/hpcdtoppm/) may be
+useful for reading photocds.
+
+To play an audio cd, you should first unmount and remove any data
+cdrom. Any of the cdrom player programs should then work (workman,
+workbone, cdplayer, etc.). Lacking anything else, you could use the
+cdtester program in Documentation/cdrom/sbpcd.
+
+On a few drives, you can read digital audio directly using a program
+such as cdda2wav. The only types of drive which i've heard support
+this are Sony and Toshiba drives. You will get errors if you try to
+use this function on a drive which does not support it.
+
+For supported changers, you can use the `cdload' program (appended to
+the end of this file) to switch between changer slots. Note that the
+drive should be unmounted before attempting this. The program takes
+two arguments: the cdrom device, and the slot number to which to change.
+If the slot number is -1, the drive is unloaded.
+
+
+4. Compilation options
+----------------------
+
+There are a few additional options which can be set when compiling the
+driver. Most people should not need to mess with any of these; they
+are listed here simply for completeness. A compilation option can be
+enabled by adding a line of the form `#define <option> 1' to the top
+of ide-cd.c. All these options are disabled by default.
+
+VERBOSE_IDE_CD_ERRORS
+ If this is set, ATAPI error codes will be translated into textual
+ descriptions. In addition, a dump is made of the command which
+ provoked the error. This is off by default to save the memory used
+ by the (somewhat long) table of error descriptions.
+
+STANDARD_ATAPI
+ If this is set, the code needed to deal with certain drives which do
+ not properly implement the ATAPI spec will be disabled. If you know
+ your drive implements ATAPI properly, you can turn this on to get a
+ slightly smaller kernel.
+
+NO_DOOR_LOCKING
+ If this is set, the driver will never attempt to lock the door of
+ the drive.
+
+TEST
+ This presently enables an additional ioctl which enables a user-mode
+ program to execute an arbitrary packet command. See the source for
+ details. This should be left off unless you know what you're doing.
+
+
+5. Common problems
+------------------
+
+This section discusses some common problems encountered when trying to
+use the driver, and some possible solutions. Note that if you are
+experiencing problems, you should probably also review
+drivers/block/README.ide for current information about the underlying
+IDE support code. Some of these items apply only to earlier versions
+of the driver, but are mentioned here for completeness.
+
+In most cases, you should probably check with `dmesg' for any errors
+from the driver.
+
+a. Drive is not detected during booting.
+
+ - Review the configuration instructions above and in
+ drivers/block/README.ide, and check how your hardware is
+ configured.
+
+ - If your drive is the only device on an IDE interface, it should
+ be jumpered as master, if at all possible.
+
+ - If your IDE interface is not at the standard addresses of 0x170
+ or 0x1f0, you'll need to explicitly inform the driver using a
+ lilo option. See drivers/block/README.ide. (This feature was
+ added around kernel version 1.3.30.)
+
+ - If the autoprobing is not finding your drive, you can tell the
+ driver to assume that one exists by using a lilo option of the
+ form `hdX=cdrom', where X is the drive letter corresponding to
+ where your drive is installed (see section 2). Note that if you
+ do this and you see a boot message like
+
+ hdX: ATAPI cdrom (?)
+
+ this does _not_ mean that the driver has successfully detected
+ the drive; rather, it means that the driver has not detected a
+ drive, but is assuming there's one there anyway because you told
+ it so. If you actually try to do I/O to a drive defined at a
+ nonexistent or nonresponding I/O address, you'll probably get
+ errors with a status value of 0xff.
+
+ - Some IDE adapters require a nonstandard initialization sequence
+ before they'll function properly. (If this is the case, there
+ will often be a separate MS-DOS driver just for the controller.)
+ IDE interfaces on sound cards often fall into this category.
+
+ Support for some interfaces needing extra initialization is
+ provided in later 1.3.x kernels. You may need to turn on
+ additional kernel configuration options to get them to work;
+ see drivers/block/README.ide.
+
+ Even if support is not available for your interface, you may be
+ able to get it to work with the following procedure. First boot
+ MS-DOS and load the appropriate drivers. Then warm-boot linux
+ (i.e., without powering off). If this works, it can be automated
+ by running loadlin from the MS-DOS autoexec.
+
+
+b. Timeout/IRQ errors.
+
+ - If you always get timeout errors, interrupts from the drive are
+ probably not making it to the host.
+
+ - IRQ problems may also be indicated by the message
+ `IRQ probe failed (<n>)' while booting. If <n> is zero, that
+ means that the system did not see an interrupt from the drive when
+ it was expecting one (on any feasible IRQ). If <n> is negative,
+ that means the system saw interrupts on multiple IRQ lines, when
+ it was expecting to receive just one from the cdrom drive.
+
+ - Double-check your hardware configuration to make sure that the IRQ
+ number of your IDE interface matches what the driver expects.
+ (The usual assignments are 14 for the primary (0x170) interface
+ and 15 for the secondary (0x1f0) interface.) Also be sure that
+ you don't have some other hardware which might be conflicting with
+ the IRQ you're using. Also check the BIOS setup for your system;
+ some have the ability to disable individual IRQ levels, and i've
+ had one report of a system which was shipped with IRQ 15 disabled
+ by default.
+
+ - Note that many MS-DOS cdrom drivers will still function even if
+ there are hardware problems with the interrupt setup; they
+ apparently don't use interrupts.
+
+
+c. System hangups.
+
+ - If the system locks up when you try to access the cdrom, the most
+ likely cause is that you have a buggy IDE adapter which doesn't
+ properly handle simultaneous transactions on multiple interfaces.
+ The most notorious of these is the CMD640B chip. This problem can
+ be worked around by specifying the `serialize' option when
+ booting. Recent kernels should be able to detect the need for
+ this automatically in most cases, but the detection is not
+ foolproof. See drivers/block/README.ide for more information
+ about the `serialize' option and the CMD640B.
+
+ - Note that many MS-DOS cdrom drivers will work with such buggy
+ hardware, apparently because they never attempt to overlap cdrom
+ operations with other disk activity.
+
+
+d. Can't mount a cdrom.
+
+ - If you get errors from mount, it may help to check `dmesg' to see
+ if there are any more specific errors from the driver or from the
+ filesystem.
+
+ - Make sure there's a cdrom loaded in the drive, and that's it's an
+ iso9660 format disc. You can't mount an audio cd.
+
+ - With the cdrom in the drive and unmounted, try something like
+
+ cat /dev/cdrom | od | more
+
+ If you see a dump, then the drive and driver are probably working
+ ok, and the problem is at the filesystem level (i.e., the cdrom is
+ not iso9660 format or has errors in the filesystem structure).
+
+ - If you see `not a block device' errors, check that the definitions
+ of the device special files are correct. They should be as
+ follows:
+
+ brw-rw---- 1 root disk 3, 0 Nov 11 18:48 /dev/hda
+ brw-rw---- 1 root disk 3, 64 Nov 11 18:48 /dev/hdb
+ brw-rw---- 1 root disk 22, 0 Nov 11 18:48 /dev/hdc
+ brw-rw---- 1 root disk 22, 64 Nov 11 18:48 /dev/hdd
+
+ Some early Slackware releases had these defined incorrectly. If
+ these are wrong, you can remake them by running the script
+ drivers/block/MAKEDEV.ide. (You may have to make it executable
+ with chmod first.)
+
+ If you have a /dev/cdrom symbolic link, check that it is pointing
+ to the correct device file.
+
+ If you hear people talking of the devices `hd1a' and `hd1b', these
+ were old names for what are now called hdc and hdd. Those names
+ should be considered obsolete.
+
+ - If mount is complaining that the iso9660 filesystem is not
+ available, but you know it is (check /proc/filesystems), you
+ probably need a newer version of mount. Early versions would not
+ always give meaningful error messages.
+
+
+e. Directory listings are unpredictably truncated, and `dmesg' shows
+ `buffer botch' error messages from the driver.
+
+ - There was a bug in the version of the driver in 1.2.x kernels
+ which could cause this. It was fixed in 1.3.0. If you can't
+ upgrade, you can probably work around the problem by specifying a
+ blocksize of 2048 when mounting. (Note that you won't be able to
+ directly execute binaries off the cdrom in that case.)
+
+ If you see this in kernels later than 1.3.0, please report it as a
+ bug.
+
+
+6. cdload.c
+-----------
+
+/*
+ * cdload.c <device> <slot>
+ *
+ * Load a cdrom from a specified slot in a changer. The drive should be
+ * unmounted before executing this.
+ *
+ * Based on code originally from Gerhard Zuber <zuber@berlin.snafu.de>.
+ */
+
+#include <stdlib.h>
+#include <errno.h>
+#include <string.h>
+#include <unistd.h>
+#include <stdio.h>
+#include <linux/cdrom.h>
+
+
+int
+main (int argc, char **argv)
+{
+ char *program;
+ char *device;
+ int x_slot;
+ int fd; /* file descriptor for CD-ROM device */
+ int status; /* return status for system calls */
+
+ program = argv[0];
+
+ if (argc != 3) {
+ fprintf (stderr, "usage: %s <device> <slot>\n", program);
+ exit (1);
+ }
+
+ device = argv[1];
+ x_slot = atoi (argv[2]);
+
+ /* open device */
+ fd = open (device, 0);
+ if (fd < 0) {
+ fprintf (stderr, "%s: open failed for `%s': %s\n",
+ program, device, strerror (errno));
+ exit (1);
+ }
+
+ /* load */
+ status = ioctl (fd, CDROMLOADFROMSLOT, x_slot);
+ if (status != 0) {
+ fprintf (stderr,
+ "%s: CDROMLOADFROMSLOT ioctl failed for `%s': %s\n",
+ program, device, strerror (errno));
+ exit (1);
+ }
+
+ /* close device */
+ status = close (fd);
+ if (status != 0) {
+ fprintf (stderr, "%s: close failed for `%s': %s\n",
+ program, device, strerror (errno));
+ exit (1);
+ }
+
+ exit (0);
+}
--- /dev/null
+ide.txt -- Information regarding the Enhanced IDE drive in Linux 2.0.x
+===============================================================================
+Supported by:
+ Mark Lord <mlord@pobox.com> -- disks, interfaces, probing
+ Gadi Oxman <gadio@netvision.net.il> -- tapes, disks, whatever
+ Scott Snyder <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.
+
+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 0x???; major=33; hde is minor=0; hdf is minor=64
+Quaternary: ide3, port 0x???; 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 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
W: http://www.advansys.com/linux
S: Maintained
+CREDITS FILE
+P: John A. Martin
+M: jam@acm.org
+S: Maintained
+
REST:
P: Linus Torvalds
S: Buried alive in email
VERSION = 1
PATCHLEVEL = 99
-SUBLEVEL = 1
+SUBLEVEL = 2
ARCH = i386
+++ /dev/null
-#!/bin/sh
-#
-# This script creates the proper /dev/ entries for IDE devices
-#
-makedev () {
- rm -f /dev/$1
- echo mknod /dev/$1 b $2 $3
- mknod /dev/$1 b $2 $3
- chown root:disk /dev/$1
- chmod 660 /dev/$1
-}
-
-makedevs () {
- rm -f /dev/$1*
- makedev $1 $2 $3
- for part in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
- do
- makedev $1$part $2 `expr $3 + $part`
- done
-}
-
-makedevs hda 3 0
-makedevs hdb 3 64
-makedevs hdc 22 0
-makedevs hdd 22 64
-makedevs hde 33 0
-makedevs hdf 33 64
-makedevs hdg 34 0
-makedevs hdh 34 64
-
-# Create the ide-tape rewinding character device.
-
-rm -f /dev/ht0
-echo mknod /dev/ht0 c 37 0
- mknod /dev/ht0 c 37 0
-chown root:disk /dev/ht0
-chmod 660 /dev/ht0
-
-# Create the ide-tape non rewinding character device.
-
-rm -f /dev/nht0
-echo mknod /dev/nht0 c 37 128
- mknod /dev/nht0 c 37 128
-chown root:disk /dev/nht0
-chmod 660 /dev/nht0
-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
/*
- * linux/drivers/block/ide.c Version 5.41 May 9, 1996
+ * linux/drivers/block/ide.c Version 5.42 May 12, 1996
*
* Copyright (C) 1994-1996 Linus Torvalds & authors (see below)
*/
#define _IDE_C /* needed by <linux/blk.h> */
/*
+ * Maintained by Mark Lord <mlord@pobox.com>
+ * and Gadi Oxman <gadio@netvision.net.il>
+ *
* 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 i/f: ide0: major=3; (hda) minor=0; (hdb) minor=64
- * Secondary i/f: ide1: major=22; (hdc or hd1a) minor=0; (hdd or hd1b) minor=64
- * Tertiary i/f: ide2: major=33; (hde) minor=0; (hdf) minor=64
- * Quaternary i/f: ide3: major=34; (hdg) minor=0; (hdh) minor=64
+ * 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 0x???; major=33; hde is minor=0; hdf is minor=64
+ * Quaternary: ide3, port 0x???; major=34; hdg is minor=0; hdh is minor=64
*
* It is easy to extend ide.c to handle more than four interfaces:
*
*
* Mark Lord (mlord@pobox.com) (IDE Perf.Pkg)
* Delman Lee (delman@mipg.upenn.edu) ("Mr. atdisk2")
- * Petri Mattila (ptjmatti@kruuna.helsinki.fi) (EIDE stuff)
* Scott Snyder (snyder@fnald0.fnal.gov) (ATAPI IDE cd-rom)
*
- * Maintained by Mark Lord (mlord@pobox.com): ide.c, ide.h, triton.c, hd.c, ..
- *
* This was a rewrite of just about everything from hd.c, though some original
* code is still sprinkled about. Think of it as a major evolution, with
* inspiration from lots of linux users, esp. hamish@zot.apana.org.au
* help sharing by masking device irq after probing
* Version 5.41 more fixes to irq sharing/serialize detection
* disable io_32bit by default on drive reset
+ * Version 5.42 simplify irq-masking after probe
+ * fix NULL pointer deref in save_match()
*
* Some additional driver compile-time options are in ide.h
*
} else
rc = 2; /* drive refused ID */
if (!HWIF(drive)->irq) {
+ OUT_BYTE(drive->ctl|2,IDE_CONTROL_REG); /* mask device irq */
+ udelay(5);
irqs = probe_irq_off(irqs); /* get our irq number */
if (irqs > 0) {
HWIF(drive)->irq = irqs; /* save it for later */
- irqs = probe_irq_on(); /* grab irqs, to ignore next edge */
- OUT_BYTE(drive->ctl|2,IDE_CONTROL_REG); /* mask device irq */
- (void) probe_irq_off(irqs); /* restore irqs again */
} else { /* Mmmm.. multiple IRQs.. don't know which was ours */
printk("%s: IRQ probe failed (%d)\n", drive->name, irqs);
#ifdef CONFIG_BLK_DEV_CMD640
return;
printk("%s: potential irq problem with %s and %s\n", hwif->name, new->name, m->name);
}
- if (m->irq != hwif->irq) /* don't undo a prior perfect match */
+ if (!m || m->irq != hwif->irq) /* don't undo a prior perfect match */
*match = new;
}
#endif /* MAX_HWIFS > 1 */
{ "QUANTUM LPS365A", 3 },
{ "QUANTUM LPS540A", 3 },
{ "QUANTUM LIGHTNING 540A", 3 },
+ { "QUANTUM LIGHTNING 730A", 3 },
{ "QUANTUM FIREBALL", 3 }, /* For models 540/640/1080/1280 */
/* 1080A works fine in mode4 with triton */
{ NULL, 0 }
#define ENOMEDIUM EAGAIN /* no medium in removable device */
-/* We use the open-option O_NONBLOCK as in indicator of that the
+/* We use the open-option O_NONBLOCK to indicate that the
* purpose of opening is only for subsequent ioctl() calls; no device
* integrity checks are performed.
*
* We hope that all cd-player programs will adopt this convention. It
- * is in their own advantage: device conotrol becomes a lot easier
+ * is in their own interest: device control becomes a lot easier
* this way.
*/
int open_for_data(struct cdrom_device_ops *, int);
/* All checking and format change makes this code really hard to read!
* So let's make some check and memory move macros. These macros are
- * a little inenficient when used both in the same piece of code, as
+ * a little inefficient when both used in the same piece of code, as
* verify_area is used twice, but who cares, as ioctl() calls
* shouldn't be in inner loops.
*/
* in parenthesis): CDROMREADMODE1 (2+ide), CDROMREADMODE2 (2+ide),
* CDROMREADAUDIO (2+ide), CDROMREADRAW (2), CDROMREADCOOKED (2),
* CDROMSEEK (2), CDROMPLAYBLK (scsi), CDROMREADALL (1). Read-audio,
- * OK (although i guess the record companies aren't too hapy with
- * this, most drives therefor refuse to transport audio data). But
+ * OK (although i guess the record companies aren't too happy with
+ * this, most drives therefore refuse to transport audio data). But
* why are there 5 different READs defined? For now, these functions
* are left over to the device-specific ioctl routine,
* cdo->dev_ioctl. Note that as a result of this, no
Upgrade to Linux kernel 1.3.78.
11 apr 1996 0.98 Upgrade to Linux kernel 1.3.85
- More uniformization stuff.
+ Made it more uniform.
*
* Parts of the code are based upon lmscd.c written by Kai Petzke,
* sbpcd.c written by Eberhard Moenkeberg, and mcd.c by Martin
* with `cm206' in it, as this stuff is too series-dependent.
*
* Currently, my limited knowledge is based on:
- * - The Linux Kernel Hacker's guide, v. 0.5, by Michael J. Johnson
+ * - The Linux Kernel Hacker's guide, v. 0.5, by Michael K. Johnson
* - Linux Kernel Programmierung, by Michael Beck and others
* - Philips/LMS cm206 and cm226 product specification
* - Philips/LMS cm260 product specification
uch intr_ur; /* uart receive buffer */
uch dsb, cc; /* drive status byte and condition (error) code */
uch fool;
- int command; /* command to be written to te uart */
+ int command; /* command to be written to the uart */
int openfiles;
ush sector[READ_AHEAD*RAW_SECTOR_SIZE/2]; /* buffered cd-sector */
int sector_first, sector_last; /* range of these sector */
stats(sync_error);
}
else if (cd->intr_ds & ds_toc_ready) {
- /* do something appropiate */
+ /* do something appropriate */
}
/* couldn't see why this interrupt, maybe due to init */
else {
}
}
-/* The new open. The real opeining strategy is defined in cdrom.c. */
+/* The new open. The real opening strategy is defined in cdrom.c. */
static int cm206_open(dev_t dev, int purpose)
{
cd->sector_last=cd->adapter_first; /* update the buffer sector */
}
-/* try_adapter. This function determines if the requested sector is is
+/* try_adapter. This function determines if the requested sector is
in adapter memory, or will appear there soon. Returns 0 upon
success */
int try_adapter(int sector)
/* Audio ioctl. Ioctl commands connected to audio are in such an
* idiosyncratic i/o format, that we leave these untouched. Return 0
* upon success. Memory checking has been done by cdrom_ioctl(), the
- * calling function, as well as LBA/MSF sanatization.
+ * calling function, as well as LBA/MSF sanitization.
*/
int cm206_audio_ioctl(dev_t dev, unsigned int cmd, void * arg)
{
case CDROMPLAYMSF:
play_from_to_msf((struct cdrom_msf *) arg);
return 0;
- case CDROMPLAYTRKIND: /* admittedly, not particulary beautiful */
+ case CDROMPLAYTRKIND: /* admittedly, not particularly beautiful */
play_from_to_track(((struct cdrom_ti *)arg)->cdti_trk0,
((struct cdrom_ti *)arg)->cdti_trk1);
return 0;
else return -EIO;
}
-/* The new generic cdrom support. Routines should be consice, most of
+/* The new generic cdrom support. Routines should be concise, most of
the logic should be in cdrom.c */
/* returns number of times device is in use */
if (gscdPresent == 0)
return -ENXIO; /* no hardware */
+ MOD_INC_USE_COUNT;
+
get_status ();
st = disk_state & (ST_NO_DISK | ST_DOOR_OPEN);
if ( st )
{
printk ( "GSCD: no disk or door open\n" );
+ MOD_DEC_USE_COUNT;
return -ENXIO;
}
return -EIO;
*/
- MOD_INC_USE_COUNT;
-
return 0;
}
ttytab = console_driver.table;
request_irq(KEYBOARD_IRQ, keyboard_interrupt, 0, "keyboard", NULL);
- request_region(0x60,16,"kbd");
+ request_region(0x60,16,"keyboard");
#ifdef INIT_KBD
initialize_kbd();
#endif
*
* -- Daniel M. Eischen, deischen@iworks.InterWorks.org, 04/03/95
*
- * $Id: aic7xxx.c,v 3.0 1996/04/16 09:11:53 deang Exp $
+ * $Id: aic7xxx.c,v 3.2 1996/05/12 17:28:23 deang Exp $
*-M*************************************************************************/
#ifdef MODULE
S_IFDIR | S_IRUGO | S_IXUGO, 2
};
-#define AIC7XXX_C_VERSION "$Revision: 3.0 $"
+#define AIC7XXX_C_VERSION "$Revision: 3.2 $"
#define NUMBER(arr) (sizeof(arr) / sizeof(arr[0]))
#define MIN(a,b) ((a < b) ? a : b)
*-F*************************************************************************/
static void
aic7xxx_scsirate(struct aic7xxx_host *p, unsigned char *scsirate,
- short period, unsigned char offset,
- int target, char channel)
+ short period, unsigned char offset, int target, char channel)
{
int i;
* Add this SCB to the head of the "waiting for selection" list.
*-F*************************************************************************/
static void
-aic7xxx_add_waiting_scb(u_long base,
- struct aic7xxx_scb *scb)
+aic7xxx_add_waiting_scb(u_long base, struct aic7xxx_scb *scb)
{
unsigned char next;
unsigned char curscb;
*-F*************************************************************************/
static unsigned char
aic7xxx_abort_waiting_scb(struct aic7xxx_host *p, struct aic7xxx_scb *scb,
- unsigned char prev, unsigned char timedout_scb)
+ unsigned char prev, unsigned char timedout_scb)
{
unsigned char curscb, next;
int target = (scb->target_channel_lun >> 4) & 0x0F;
*-F*************************************************************************/
static int
aic7xxx_reset_device(struct aic7xxx_host *p, int target, char channel,
- unsigned char timedout_scb)
+ unsigned char timedout_scb)
{
int base = p->base;
struct aic7xxx_scb *scb;
*-F*************************************************************************/
static int
aic7xxx_reset_channel(struct aic7xxx_host *p, char channel,
- unsigned char timedout_scb, int initiate_reset)
+ unsigned char timedout_scb, int initiate_reset)
{
int base = p->base;
unsigned char sblkctl;
{
aic7xxx_reset_current_bus(base);
}
- /* Ensure we don't get a RSTI interrupt from this. */
+
+ /*
+ * Ensure we don't get a RSTI interrupt from this.
+ */
outb(CLRSCSIRSTI | CLRSELTIMEO, CLRSINT1 + base);
outb(CLRSCSIINT, CLRINT + base);
outb(sblkctl, SBLKCTL + base);
{
aic7xxx_reset_current_bus(base);
}
- /* Ensure we don't get a RSTI interrupt from this. */
+ /*
+ * Ensure we don't get a RSTI interrupt from this.
+ */
outb(CLRSCSIRSTI | CLRSELTIMEO, CLRSINT1 + base);
outb(CLRSCSIINT, CLRINT + base);
*-F*************************************************************************/
static int
aic7xxx_register(Scsi_Host_Template *template,
- struct aic7xxx_host_config *config)
+ struct aic7xxx_host_config *config)
{
int i;
unsigned char sblkctl;
* so we default it to 100%.
*/
config->bus_speed = DFTHRSH_100;
- scsi_conf = config->scsi_id | DFTHRSH_100;
+ scsi_conf = config->scsi_id | config->bus_speed;
#if 0
if (config->parity == AIC_ENABLED)
{
}
#endif
outb(scsi_conf, SCSICONF + base);
- outb(DFTHRSH_100, DSPCISTATUS + base);
+ outb(config->bus_speed, DSPCISTATUS + base);
/*
* In case we are a wide card...
*/
-/*
- * Try the following:
- *
- * 1) outb(config->scsi_id, SCSICONF + base + 1);
- * 2) outb(scsiconf, SCSICONF + base + 1);
- *
- */
outb(config->scsi_id, SCSICONF + base + 1);
printk("aic7xxx: Extended translation %sabled.\n",
* 2s compliment of SCBCOUNT
*/
i = p->maxscb;
- outb(-i & 0xff, COMP_SCBCOUNT + base);
+ outb(-i & 0xFF, COMP_SCBCOUNT + base);
/*
* Set the QCNT (queue count) mask to deal with broken aic7850s that
udelay(1000);
outb(0, SCSISEQ + base);
- /* Ensure we don't get a RSTI interrupt from this. */
+ /*
+ * Ensure we don't get a RSTI interrupt from this.
+ */
outb(CLRSCSIRSTI, CLRSINT1 + base);
outb(CLRSCSIINT, CLRINT + base);
udelay(1000);
outb(0, SCSISEQ + base);
- /* Ensure we don't get a RSTI interrupt from this. */
+ /*
+ * Ensure we don't get a RSTI interrupt from this.
+ */
outb(CLRSCSIRSTI, CLRSINT1 + base);
outb(CLRSCSIINT, CLRINT + base);
case AIC_7872: /* 3940 */
case AIC_7882: /* 3940-Ultra */
- config.chan_num = number_of_39xxs & 0x1; /* Has 2 controllers */
+ config.chan_num = number_of_39xxs & 0x01; /* Has 2 controllers */
number_of_39xxs++;
if (number_of_39xxs == 2)
{
case AIC_7873: /* 3985 */
case AIC_7883: /* 3985-Ultra */
- config.chan_num = number_of_39xxs & 0x3; /* Has 3 controllers */
+ config.chan_num = number_of_39xxs & 0x03; /* Has 3 controllers */
number_of_39xxs++;
if (number_of_39xxs == 3)
{
*/
csize_lattime |= 8;
}
- if((csize_lattime & LATTIME) == 0)
+
+ if ((csize_lattime & LATTIME) == 0)
{
/*
* Default to 64 PCLKS (is this a good value?)
* The first bit of PCI_BASE_ADDRESS_0 is always set, so
* we mask it off.
*/
- base = io_port & 0xfffffffe;
+ base = io_port & 0xFFFFFFFE;
/*
* I don't think we need to bother with allowing
* Build a SCB.
*-F*************************************************************************/
static void
-aic7xxx_buildscb(struct aic7xxx_host *p,
- Scsi_Cmnd *cmd,
- struct aic7xxx_scb *scb)
+aic7xxx_buildscb(struct aic7xxx_host *p, Scsi_Cmnd *cmd,
+ struct aic7xxx_scb *scb)
{
void *addr;
unsigned short mask;
* the SCSI bus reset line.
*-F*************************************************************************/
int
-aic7xxx_reset(Scsi_Cmnd *cmd)
+aic7xxx_reset(Scsi_Cmnd *cmd, unsigned int resetFlags)
{
#ifdef AIC7XXX_DEBUG_ABORT
printk ("aic7xxx: (reset) target/channel %d/%d\n", cmd->target, cmd->channel);
sectors = 32;
cylinders = disk->capacity / (heads * sectors);
- if (p->extended && cylinders > 1024)
+ if (p->extended && (cylinders > 1024))
{
heads = 255;
sectors = 63;
- cylinders = disk->capacity / (255 * 63);
+ cylinders = disk->capacity / (heads * sectors);
}
geom[0] = heads;
* along with this program; see the file COPYING. If not, write to
* the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
*
- * $Id: aic7xxx.h,v 3.0 1996/04/16 09:11:53 deang Exp $
+ * $Id: aic7xxx.h,v 3.1 1996/05/12 17:25:20 deang Exp $
*-M*************************************************************************/
#ifndef _aic7xxx_h
#define _aic7xxx_h
-#define AIC7XXX_H_VERSION "$Revision: 3.0 $"
+#define AIC7XXX_H_VERSION "$Revision: 3.1 $"
/*
* Scsi_Host_Template (see hosts.h) for AIC-7xxx - some fields
extern int aic7xxx_detect(Scsi_Host_Template *);
extern int aic7xxx_command(Scsi_Cmnd *);
extern int aic7xxx_abort(Scsi_Cmnd *);
-extern int aic7xxx_reset(Scsi_Cmnd *);
+extern int aic7xxx_reset(Scsi_Cmnd *, unsigned int resetFlags);
extern const char *aic7xxx_info(struct Scsi_Host *);
/*+M*************************************************************************
* Adaptec AIC7xxx device driver proc support for Linux.
*
- * Copyright (c) 1995 Dean W. Gehnert
+ * Copyright (c) 1995, 1996 Dean W. Gehnert
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
*
* ----------------------------------------------------------------
- * o Modified from the EATA /proc support.
+ * o Modified from the EATA-DMA /proc support.
* o Additional support for device block statistics provided by
* Matthew Jacob.
*
- * Dean W. Gehnert, deang@teleport.com, 08/30/95
+ * Dean W. Gehnert, deang@teleport.com, 05/01/96
*
- * $Id: aic7xxx_proc.c,v 3.0 1996/04/16 08:52:23 deang Exp $
+ * $Id: aic7xxx_proc.c,v 3.1 1996/05/12 17:25:56 deang Exp $
*-M*************************************************************************/
#define BLS buffer + len + size
if (filp->private_data && filp->f_version == dir->i_version) {
i = (ULONG)filp->private_data;
j = 0;
- pd_debug("AFFS: readdir() left off=%lu\n",i);
+ pr_debug("AFFS: readdir() left off=%lu\n",i);
}
filp->f_version = dir->i_version;
- pd_debug("AFFS: hash_pos=%lu chain_pos=%lu\n", hash_pos, chain_pos);
+ pr_debug("AFFS: hash_pos=%lu chain_pos=%lu\n", hash_pos, chain_pos);
while (i) {
if (!(fh_bh = affs_bread(inode->i_dev,i,AFFS_I2BSIZE(inode)))) {
printk("AFFS: readdir: Can't get block %d\n",i);
#include <linux/binfmts.h>
#include <paths.h>
-#define _PATH_JAVA "/usr/local/java/bin/java"
-#define _PATH_APPLET "/usr/local/java/bin/appletviewer"
-#define _PATH_BASH "/bin/bash"
+#define _PATH_JAVA "/usr/bin/java"
+#define _PATH_APPLET "/usr/bin/appletviewer"
+#define _PATH_SH "/bin/sh"
static int do_load_script(struct linux_binprm *bprm,struct pt_regs *regs)
{
/*
* OK, we've set the interpreter name
- * Splice in (1) the interpreter's name for argv[0] (_PATH_BASH)
+ * Splice in (1) the interpreter's name for argv[0] (_PATH_SH)
* (2) the name of the java wrapper for argv[1] (_PATH_JAVA)
* (3) filename of Java class (replace argv[0])
* without leading path or trailing '.class'
bprm->p = copy_strings(1, &cp, bprm->page, bprm->p, 2);
bprm->argc++;
- strcpy (bprm->buf, _PATH_BASH);
+ strcpy (bprm->buf, _PATH_SH);
interp = bprm->buf;
if ((i_name = strrchr (bprm->buf, '/')) != NULL)
i_name++;
#endif
#define RO_IOCTLS(dev,where) \
- case BLKROSET: if (!suser()) return -EACCES; \
- set_device_ro((dev),get_fs_long((long *) (where))); return 0; \
+ case BLKROSET: { int __err; if (!suser()) return -EACCES; \
+ __err = verify_area(VERIFY_READ, (void *) (where), sizeof(long)); \
+ if (!__err) set_device_ro((dev),get_fs_long((long *) (where))); return __err; } \
case BLKROGET: { int __err = verify_area(VERIFY_WRITE, (void *) (where), sizeof(long)); \
if (!__err) put_fs_long(0!=is_read_only(dev),(long *) (where)); return __err; }
--- /dev/null
+#!/bin/sh
+#
+# This script creates the proper /dev/ entries for IDE devices
+# on the primary, secondary, tertiary, and quaternary interfaces.
+# See ../Documentation/ide.txt for more information.
+#
+makedev () {
+ rm -f /dev/$1
+ echo mknod /dev/$1 b $2 $3
+ mknod /dev/$1 b $2 $3
+ chown root:disk /dev/$1
+ chmod 660 /dev/$1
+}
+
+makedevs () {
+ rm -f /dev/$1*
+ makedev $1 $2 $3
+ for part in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+ do
+ makedev $1$part $2 `expr $3 + $part`
+ done
+}
+
+makedevs hda 3 0
+makedevs hdb 3 64
+makedevs hdc 22 0
+makedevs hdd 22 64
+makedevs hde 33 0
+makedevs hdf 33 64
+makedevs hdg 34 0
+makedevs hdh 34 64
+
+# Create the ide-tape rewinding character device.
+
+rm -f /dev/ht0
+echo mknod /dev/ht0 c 37 0
+ mknod /dev/ht0 c 37 0
+chown root:disk /dev/ht0
+chmod 660 /dev/ht0
+
+# Create the ide-tape non rewinding character device.
+
+rm -f /dev/nht0
+echo mknod /dev/nht0 c 37 128
+ mknod /dev/nht0 c 37 128
+chown root:disk /dev/nht0
+chmod 660 /dev/nht0
projects / history.git / commitdiff