Skip to content

L
linux
Commit 18a8b1c2 authored by Linus Torvalds's avatar Linus Torvalds
Browse files
Options

Import pre2.0.2

parent 0351166f
Hide whitespace changes
Inline Side-by-side
Showing with 1017 additions and 697 deletions
CREDITS
View file @ 18a8b1c2
......@@ -123,6 +123,10 @@ E: hennus@sky.ow.nl [My uucp-fed Linux box at home]
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
......@@ -131,10 +135,6 @@ S: Baumgartenweg 5
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
......@@ -320,6 +320,16 @@ S: 2255 Spruce
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/
......@@ -583,6 +593,14 @@ S: 201 Howell Street, Apartment 1C
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
......@@ -633,6 +651,13 @@ N: Rudolf Koenig
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
......@@ -641,13 +666,6 @@ S: Schlehenweg 9
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
......@@ -986,14 +1004,6 @@ D: Instigator, FHS standard
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
......@@ -1315,14 +1325,6 @@ S: Breeburgsingel 12
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)
......
Documentation/Changes
View file @ 18a8b1c2
......@@ -89,7 +89,7 @@ Procps utilities
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.
......
Documentation/cdrom/cdrom-standard.tex
View file @ 18a8b1c2
......@@ -53,7 +53,7 @@ underlying hardware. Any structure is lost.
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
......@@ -272,7 +272,7 @@ $$
\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
......@@ -288,7 +288,7 @@ CDS_XA_2_1& mixed data (XA), mode 2, form 1 (2048 user bytes)\cr
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}.
......@@ -347,8 +347,8 @@ If the drive can store multiple discs (a juke-box), it is likely that
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)$}
......@@ -418,12 +418,13 @@ supported, it should be done through the VFS and not via $ioctl$s. A
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:
......@@ -450,8 +451,8 @@ CDC_MEDIA_CHANGED& can report if disc has changed\cr
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).
......@@ -464,17 +465,17 @@ $$\it
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:
$$
......@@ -537,7 +538,7 @@ behavior of the $open()$ call. Audio use simply wants to open the
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
......@@ -545,11 +546,11 @@ permission flags). Most option flags simply don't make sense to
\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}
......@@ -564,7 +565,7 @@ no actions whatsoever.
\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
......@@ -583,8 +584,8 @@ implement such a user-program for \linux, I came across the
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
......@@ -594,7 +595,7 @@ CDO_USE_FFLAGS)$.
\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:
......@@ -734,7 +735,7 @@ cdrom_volctrl *{}$.
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
......@@ -757,7 +758,7 @@ the current flags.
\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
......@@ -802,10 +803,10 @@ the code in a large part, and you may just have to adapt the prototype
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:
......@@ -828,8 +829,8 @@ way.
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.
......
Documentation/cdrom/cm206
View file @ 18a8b1c2
......@@ -6,7 +6,7 @@ cm206 in combination with the cm260 host adapter card.
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
......@@ -70,7 +70,7 @@ the module when you upgrade the kernel to a new version.
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
......@@ -84,7 +84,7 @@ line to be used, e.g.
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.
......@@ -181,5 +181,5 @@ The copyright of the cm206 driver for Linux is
(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.
Documentation/cdrom/ide-cd 0 → 100644
View file @ 18a8b1c2
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);
}
Documentation/ide.txt 0 → 100644
View file @ 18a8b1c2
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
MAINTAINERS
View file @ 18a8b1c2
......@@ -311,6 +311,11 @@ M: Bob Frey <bobf@advansys.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
Makefile
View file @ 18a8b1c2
VERSION = 1
PATCHLEVEL = 99
SUBLEVEL = 1
SUBLEVEL = 2
ARCH = i386
......
drivers/block/README.ide
View file @ 18a8b1c2
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
drivers/block/ide.c
View file @ 18a8b1c2
/*
* 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:
*
......@@ -51,11 +54,8 @@
*
* 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
......@@ -235,6 +235,8 @@
* 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
*
......@@ -2419,12 +2421,11 @@ static int try_to_identify (ide_drive_t *drive, byte cmd)
} 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
......@@ -3032,7 +3033,7 @@ static void save_match (ide_hwif_t *hwif, ide_hwif_t *new, ide_hwif_t **match)
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 */
......
drivers/block/ide_modes.h
View file @ 18a8b1c2
......@@ -87,6 +87,7 @@ static struct ide_pio_info {
{ "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 }
......
drivers/cdrom/cdrom.c
View file @ 18a8b1c2
......@@ -99,12 +99,12 @@ int unregister_cdrom(int major, char *name)
#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);
......@@ -261,7 +261,7 @@ void sanitize_format(union cdrom_addr *addr,
/* 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.
*/
......@@ -280,8 +280,8 @@ void sanitize_format(union cdrom_addr *addr,
* 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
......
drivers/cdrom/cm206.c
View file @ 18a8b1c2
......@@ -77,7 +77,7 @@
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
......@@ -92,7 +92,7 @@
* 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
......@@ -176,7 +176,7 @@ struct cm206_struct {
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 */
......@@ -296,7 +296,7 @@ static void cm206_interrupt(int sig, void *dev_id, struct pt_regs * regs)
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 {
......@@ -578,7 +578,7 @@ void get_disc_status(void)
}
}
/* 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)
{
......@@ -622,7 +622,7 @@ void empty_buffer(int sectors)
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)
......@@ -883,7 +883,7 @@ void get_toc_entry(struct cdrom_tocentry * ep)
/* 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)
{
......@@ -896,7 +896,7 @@ 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;
......@@ -959,7 +959,7 @@ int cm206_media_changed(dev_t dev)
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 */
......
drivers/cdrom/gscd.c
View file @ 18a8b1c2
......@@ -370,11 +370,14 @@ printk ( "GSCD: open\n" );
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;
}
......@@ -382,8 +385,6 @@ printk ( "GSCD: open\n" );
return -EIO;
*/
MOD_INC_USE_COUNT;
return 0;
}
......
drivers/char/keyboard.c
View file @ 18a8b1c2
......@@ -1201,7 +1201,7 @@ int kbd_init(void)
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
......
drivers/scsi/aic7xxx.c
View file @ 18a8b1c2
......@@ -41,7 +41,7 @@
*
* -- 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
......@@ -74,7 +74,7 @@ struct proc_dir_entry proc_scsi_aic7xxx = {
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)
......@@ -1069,8 +1069,7 @@ aic7xxx_length(Scsi_Cmnd *cmd, int sg_last)
*-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;
......@@ -1367,8 +1366,7 @@ aic7xxx_done_aborted_scbs (struct aic7xxx_host *p)
* 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;
......@@ -1393,7 +1391,7 @@ aic7xxx_add_waiting_scb(u_long base,
*-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;
......@@ -1457,7 +1455,7 @@ aic7xxx_abort_waiting_scb(struct aic7xxx_host *p, struct aic7xxx_scb *scb,
*-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;
......@@ -1602,7 +1600,7 @@ aic7xxx_reset_current_bus(int base)
*-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;
......@@ -1686,7 +1684,10 @@ aic7xxx_reset_channel(struct aic7xxx_host *p, char channel,
{
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);
......@@ -1706,7 +1707,9 @@ aic7xxx_reset_channel(struct aic7xxx_host *p, char channel,
{
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);
......@@ -3121,7 +3124,7 @@ detect_maxscb(struct aic7xxx_host_config *config)
*-F*************************************************************************/
static int
aic7xxx_register(Scsi_Host_Template *template,
struct aic7xxx_host_config *config)
struct aic7xxx_host_config *config)
{
int i;
unsigned char sblkctl;
......@@ -3327,7 +3330,7 @@ aic7xxx_register(Scsi_Host_Template *template,
* 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)
{
......@@ -3335,18 +3338,11 @@ aic7xxx_register(Scsi_Host_Template *template,
}
#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",
......@@ -3737,7 +3733,7 @@ aic7xxx_register(Scsi_Host_Template *template,
* 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
......@@ -3788,7 +3784,9 @@ aic7xxx_register(Scsi_Host_Template *template,
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);
......@@ -3802,7 +3800,9 @@ aic7xxx_register(Scsi_Host_Template *template,
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);
......@@ -3970,7 +3970,7 @@ aic7xxx_detect(Scsi_Host_Template *template)
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)
{
......@@ -3980,7 +3980,7 @@ aic7xxx_detect(Scsi_Host_Template *template)
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)
{
......@@ -4013,7 +4013,8 @@ aic7xxx_detect(Scsi_Host_Template *template)
*/
csize_lattime |= 8;
}
if((csize_lattime & LATTIME) == 0)
if ((csize_lattime & LATTIME) == 0)
{
/*
* Default to 64 PCLKS (is this a good value?)
......@@ -4049,7 +4050,7 @@ aic7xxx_detect(Scsi_Host_Template *template)
* 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
......@@ -4115,9 +4116,8 @@ aic7xxx_detect(Scsi_Host_Template *template)
* 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;
......@@ -4638,7 +4638,7 @@ aic7xxx_abort(Scsi_Cmnd *cmd)
* 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);
......@@ -4683,11 +4683,11 @@ aic7xxx_biosparam(Disk *disk, kdev_t dev, int geom[])
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;
......
drivers/scsi/aic7xxx.h
View file @ 18a8b1c2
......@@ -18,12 +18,12 @@
* 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
......@@ -58,7 +58,7 @@ extern int aic7xxx_biosparam(Disk *, kdev_t, int[]);
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 *);
......
drivers/scsi/aic7xxx_proc.c
View file @ 18a8b1c2
/*+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
......@@ -18,13 +18,13 @@
* 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
......
fs/affs/dir.c
View file @ 18a8b1c2
......@@ -144,10 +144,10 @@ affs_readdir(struct inode *inode, struct file *filp, void *dirent, filldir_t fil
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);
......
fs/binfmt_java.c
View file @ 18a8b1c2
......@@ -12,9 +12,9 @@
#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)
{
......@@ -29,7 +29,7 @@ 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'
......@@ -52,7 +52,7 @@ static int do_load_script(struct linux_binprm *bprm,struct pt_regs *regs)
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++;
......
include/linux/blk.h
View file @ 18a8b1c2
......@@ -107,8 +107,9 @@ void initrd_init(void);
#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; }
......
drivers/block/MAKEDEV.ide → scripts/MAKEDEV.ide
View file @ 18a8b1c2
#!/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
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7