mirror of https://github.com/mkerrisk/man-pages
ffix
This commit is contained in:
parent
066cb3d698
commit
40dedbfef9
|
@ -63,7 +63,7 @@ tab(:);
|
|||
l l l.
|
||||
Name:Purpose:Man page
|
||||
T{
|
||||
.B "PF_UNIX,\ PF_LOCAL"
|
||||
.BR PF_UNIX ", " PF_LOCAL
|
||||
T}:T{
|
||||
Local communication
|
||||
T}:T{
|
||||
|
@ -331,7 +331,12 @@ However, some historical (BSD) implementations required this header
|
|||
file, and portable applications are probably wise to include it.
|
||||
|
||||
The manifest constants used under 4.x BSD for protocol families
|
||||
are PF_UNIX, PF_INET, etc., while AF_UNIX etc. are used for address
|
||||
are
|
||||
.BR PF_UNIX ,
|
||||
.BR PF_INET ,
|
||||
etc., while
|
||||
.B AF_UNIX
|
||||
etc. are used for address
|
||||
families.
|
||||
However, already the BSD man page promises: "The protocol
|
||||
family generally is the same as the address family", and subsequent
|
||||
|
|
257
man7/bootparam.7
257
man7/bootparam.7
|
@ -24,11 +24,11 @@
|
|||
.\" (dated v1.0.1, 15/08/95).
|
||||
.\" Major update, aeb, 970114.
|
||||
.\"
|
||||
.TH BOOTPARAM 7 2007-10-15 "Linux" "Linux Programmer's Manual"
|
||||
.TH BOOTPARAM 7 2007-12-16 "Linux" "Linux Programmer's Manual"
|
||||
.SH NAME
|
||||
bootparam \- Introduction to boot time parameters of the Linux kernel
|
||||
.SH DESCRIPTION
|
||||
The Linux kernel accepts certain `command line options' or `boot time
|
||||
The Linux kernel accepts certain 'command line options' or 'boot time
|
||||
parameters' at the moment it is started.
|
||||
In general this is used to
|
||||
supply the kernel with information about hardware parameters that
|
||||
|
@ -36,7 +36,7 @@ the kernel would not be able to determine on its own, or to avoid/override
|
|||
the values that the kernel would otherwise detect.
|
||||
|
||||
When the kernel is booted directly by the BIOS (say from a floppy to
|
||||
which you copied a kernel using `cp zImage /dev/fd0'),
|
||||
which you copied a kernel using 'cp zImage /dev/fd0'),
|
||||
you have no opportunity to specify any parameters.
|
||||
So, in order to take advantage of this possibility you have to
|
||||
use software that is able to pass parameters, like LILO or loadlin.
|
||||
|
@ -55,14 +55,14 @@ and
|
|||
.BR lilo.conf (5).)
|
||||
LILO can boot DOS, OS/2, Linux, FreeBSD, UnixWare, etc., and is quite flexible.
|
||||
|
||||
The other commonly used Linux loader is `LoadLin' which is a DOS
|
||||
The other commonly used Linux loader is 'LoadLin' which is a DOS
|
||||
program that has the capability to launch a Linux kernel from the DOS
|
||||
prompt (with boot-args) assuming that certain resources are available.
|
||||
This is good for people that want to launch Linux from DOS.
|
||||
|
||||
It is also very useful if you have certain hardware which relies on
|
||||
the supplied DOS driver to put the hardware into a known state.
|
||||
A common example is `SoundBlaster Compatible' sound cards that require
|
||||
A common example is 'SoundBlaster Compatible' sound cards that require
|
||||
the DOS driver to twiddle a few mystical registers to put the card
|
||||
into a SB compatible mode.
|
||||
Booting DOS with the supplied driver, and
|
||||
|
@ -75,7 +75,7 @@ Most of the boot args take the form of:
|
|||
.IP
|
||||
name[=value_1][,value_2]...[,value_10]
|
||||
.LP
|
||||
where `name' is a unique keyword that is used to identify what part of
|
||||
where 'name' is a unique keyword that is used to identify what part of
|
||||
the kernel the associated values (if any) are to be given to.
|
||||
Note the limit of 10 is real, as the present code only handles 10 comma
|
||||
separated parameters per keyword.
|
||||
|
@ -85,39 +85,39 @@ complicated situations, assuming the setup function supports it.)
|
|||
|
||||
Most of the sorting goes on in linux/init/main.c.
|
||||
First, the kernel
|
||||
checks to see if the argument is any of the special arguments `root=',
|
||||
`nfsroot=', `nfsaddrs=', `ro', `rw', `debug' or `init'.
|
||||
checks to see if the argument is any of the special arguments 'root=',
|
||||
'nfsroot=', 'nfsaddrs=', 'ro', 'rw', 'debug' or 'init'.
|
||||
The meaning of these special arguments is described below.
|
||||
|
||||
Then it walks a list of setup functions (contained in the bootsetups
|
||||
array) to see if the specified argument string (such as `foo') has
|
||||
been associated with a setup function (`foo_setup()') for a particular
|
||||
array) to see if the specified argument string (such as 'foo') has
|
||||
been associated with a setup function ('foo_setup()') for a particular
|
||||
device or part of the kernel.
|
||||
If you passed the kernel the line
|
||||
foo=3,4,5,6 then the kernel would search the bootsetups array to see
|
||||
if `foo' was registered.
|
||||
if 'foo' was registered.
|
||||
If it was, then it would call the setup
|
||||
function associated with `foo' (foo_setup()) and hand it the arguments
|
||||
function associated with 'foo' (foo_setup()) and hand it the arguments
|
||||
3, 4, 5 and 6 as given on the kernel command line.
|
||||
|
||||
Anything of the form `foo=bar' that is not accepted as a setup function
|
||||
Anything of the form 'foo=bar' that is not accepted as a setup function
|
||||
as described above is then interpreted as an environment variable to
|
||||
be set.
|
||||
A (useless?) example would be to use `TERM=vt100' as a boot
|
||||
A (useless?) example would be to use 'TERM=vt100' as a boot
|
||||
argument.
|
||||
|
||||
Any remaining arguments that were not picked up by the kernel and were
|
||||
not interpreted as environment variables are then passed onto process
|
||||
one, which is usually the init program.
|
||||
The most common argument that
|
||||
is passed to the init process is the word `single' which instructs init
|
||||
is passed to the init process is the word 'single' which instructs init
|
||||
to boot the computer in single user mode, and not launch all the usual
|
||||
daemons.
|
||||
Check the manual page for the version of init installed on
|
||||
your system to see what arguments it accepts.
|
||||
.SS "General Non-device Specific Boot Arguments"
|
||||
.TP
|
||||
.B "`init=...'"
|
||||
.B "'init=...'"
|
||||
This sets the initial command to be executed by the kernel.
|
||||
If this is not set, or cannot be found, the kernel will try
|
||||
.IR /sbin/init ,
|
||||
|
@ -129,40 +129,44 @@ then
|
|||
.I /bin/sh
|
||||
and panic if all of this fails.
|
||||
.TP
|
||||
.B "`nfsaddrs=...'"
|
||||
.B "'nfsaddrs=...'"
|
||||
This sets the nfs boot address to the given string.
|
||||
This boot address is used in case of a net boot.
|
||||
.TP
|
||||
.B "`nfsroot=...'"
|
||||
.B "'nfsroot=...'"
|
||||
This sets the nfs root name to the given string.
|
||||
If this string
|
||||
does not begin with '/' or ',' or a digit, then it is prefixed by
|
||||
`/tftpboot/'.
|
||||
'/tftpboot/'.
|
||||
This root name is used in case of a net boot.
|
||||
.TP
|
||||
.B "`no387'"
|
||||
(Only when CONFIG_BUGi386 is defined.)
|
||||
.B "'no387'"
|
||||
(Only when
|
||||
.B CONFIG_BUGi386
|
||||
is defined.)
|
||||
Some i387 coprocessor chips have bugs that show up when used in 32 bit
|
||||
protected mode.
|
||||
For example, some of the early ULSI-387 chips would
|
||||
cause solid lockups while performing floating point calculations.
|
||||
Using the `no387' boot arg causes Linux to ignore the maths
|
||||
Using the 'no387' boot arg causes Linux to ignore the maths
|
||||
coprocessor even if you have one.
|
||||
Of course you must then have your
|
||||
kernel compiled with math emulation support!
|
||||
.TP
|
||||
.B "`no-hlt'"
|
||||
(Only when CONFIG_BUGi386 is defined.)
|
||||
Some of the early i486DX-100 chips have a problem with the `hlt'
|
||||
.B "'no-hlt'"
|
||||
(Only when
|
||||
.B CONFIG_BUGi386
|
||||
is defined.)
|
||||
Some of the early i486DX-100 chips have a problem with the 'hlt'
|
||||
instruction, in that they can't reliably return to operating mode
|
||||
after this instruction is used.
|
||||
Using the `no-hlt' instruction tells
|
||||
Using the 'no-hlt' instruction tells
|
||||
Linux to just run an infinite loop when there is nothing else to do,
|
||||
and to not halt the CPU.
|
||||
This allows people with these broken chips
|
||||
to use Linux.
|
||||
.TP
|
||||
.B "`root=...'"
|
||||
.B "'root=...'"
|
||||
This argument tells the kernel what device is to be used as the root
|
||||
filesystem while booting.
|
||||
The default of this setting is determined
|
||||
|
@ -170,18 +174,18 @@ at compile time, and usually is the value of the root device of the
|
|||
system that the kernel was built on.
|
||||
To override this value, and
|
||||
select the second floppy drive as the root device, one would
|
||||
use `root=/dev/fd1'. (The root device can also be set using
|
||||
use 'root=/dev/fd1'. (The root device can also be set using
|
||||
.BR rdev (8).)
|
||||
|
||||
The root device can be specified symbolically or numerically.
|
||||
A symbolic specification has the form /dev/XXYN, where XX designates
|
||||
the device type (`hd' for ST-506 compatible hard disk, with Y in
|
||||
`a'-`d'; `sd' for SCSI compatible disk, with Y in `a'-`e';
|
||||
`ad' for Atari ACSI disk, with Y in `a'-`e',
|
||||
`ez' for a Syquest EZ135 parallel port removable drive, with Y=`a',
|
||||
`xd' for XT compatible disk, with Y either `a' or `b'; `fd' for
|
||||
the device type ('hd' for ST-506 compatible hard disk, with Y in
|
||||
'a'-'d'; 'sd' for SCSI compatible disk, with Y in 'a'-'e';
|
||||
'ad' for Atari ACSI disk, with Y in 'a'-'e',
|
||||
'ez' for a Syquest EZ135 parallel port removable drive, with Y='a',
|
||||
'xd' for XT compatible disk, with Y either 'a' or 'b'; 'fd' for
|
||||
floppy disk, with Y the floppy drive number \(em fd0 would be
|
||||
the DOS `A:' drive, and fd1 would be `B:'), Y the driver letter or
|
||||
the DOS 'A:' drive, and fd1 would be 'B:'), Y the driver letter or
|
||||
number, and N the number (in decimal) of the partition on this device
|
||||
(absent in the case of floppies).
|
||||
Recent kernels allow many other
|
||||
|
@ -191,30 +195,30 @@ gscd, sbpcd, sonycd, bpcd.
|
|||
|
||||
Note that this has nothing to do with the designation of these
|
||||
devices on your file system.
|
||||
The `/dev/' part is purely conventional.
|
||||
The '/dev/' part is purely conventional.
|
||||
|
||||
The more awkward and less portable numeric specification of the above
|
||||
possible root devices in major/minor format is also accepted.
|
||||
(E.g., /dev/sda3 is major 8, minor 3, so you could use `root=0x803' as an
|
||||
(E.g., /dev/sda3 is major 8, minor 3, so you could use 'root=0x803' as an
|
||||
alternative.)
|
||||
.TP
|
||||
.B "`ro' and `rw'"
|
||||
The `ro' option tells the kernel to mount the root filesystem
|
||||
as `readonly' so that filesystem consistency check programs (fsck)
|
||||
.BR 'ro' " and " 'rw'
|
||||
The 'ro' option tells the kernel to mount the root filesystem
|
||||
as 'readonly' so that filesystem consistency check programs (fsck)
|
||||
can do their work on a quiescent file system.
|
||||
No processes can
|
||||
write to files on the filesystem in question until it is `remounted'
|
||||
as read/write capable, for example, by `mount \-w \-n \-o remount /'.
|
||||
write to files on the filesystem in question until it is 'remounted'
|
||||
as read/write capable, for example, by 'mount \-w \-n \-o remount /'.
|
||||
(See also
|
||||
.BR mount (8).)
|
||||
|
||||
The `rw' option tells the kernel to mount the root filesystem read/write.
|
||||
The 'rw' option tells the kernel to mount the root filesystem read/write.
|
||||
This is the default.
|
||||
|
||||
The choice between read-only and read/write can also be set using
|
||||
.BR rdev (8).
|
||||
.TP
|
||||
.B "`reserve=...'"
|
||||
.B "'reserve=...'"
|
||||
This is used to protect I/O port regions from probes.
|
||||
The form of the command is:
|
||||
.IP
|
||||
|
@ -236,10 +240,10 @@ For example, the boot line
|
|||
.IP
|
||||
reserve=0x300,32 blah=0x300
|
||||
.IP
|
||||
keeps all device drivers except the driver for `blah' from probing
|
||||
keeps all device drivers except the driver for 'blah' from probing
|
||||
0x300-0x31f.
|
||||
.TP
|
||||
.B "`mem=...'"
|
||||
.B "'mem=...'"
|
||||
The BIOS call defined in the PC specification that returns
|
||||
the amount of installed memory was only designed to be able
|
||||
to report up to 64MB.
|
||||
|
@ -249,15 +253,15 @@ If you have more than 64MB of
|
|||
RAM installed, you can use this boot arg to tell Linux how much memory
|
||||
you have.
|
||||
The value is in decimal or hexadecimal (prefix 0x),
|
||||
and the suffixes `k' (times 1024) or `M' (times 1048576) can be used.
|
||||
Here is a quote from Linus on usage of the `mem=' parameter.
|
||||
and the suffixes 'k' (times 1024) or 'M' (times 1048576) can be used.
|
||||
Here is a quote from Linus on usage of the 'mem=' parameter.
|
||||
|
||||
.in +0.5i
|
||||
The kernel will accept any `mem=xx' parameter you give it, and if it
|
||||
The kernel will accept any 'mem=xx' parameter you give it, and if it
|
||||
turns out that you lied to it, it will crash horribly sooner or later.
|
||||
The parameter indicates the highest addressable RAM address, so
|
||||
\&`mem=0x1000000' means you have 16MB of memory, for example.
|
||||
For a 96MB machine this would be `mem=0x6000000'.
|
||||
\&'mem=0x1000000' means you have 16MB of memory, for example.
|
||||
For a 96MB machine this would be 'mem=0x6000000'.
|
||||
|
||||
NOTE NOTE NOTE: some machines might use the top of memory for BIOS
|
||||
caching or whatever, so you might not actually have up to the full
|
||||
|
@ -271,36 +275,38 @@ it actually does have, bad things will happen: maybe not at once, but
|
|||
surely eventually.
|
||||
.in
|
||||
|
||||
You can also use the boot argument `mem=nopentium' to turn off 4 MB
|
||||
You can also use the boot argument 'mem=nopentium' to turn off 4 MB
|
||||
page tables on kernels configured for IA32 systems with a pentium or newer
|
||||
CPU.
|
||||
.TP
|
||||
.B "`panic=N'"
|
||||
.B "'panic=N'"
|
||||
By default the kernel will not reboot after a panic, but this option
|
||||
will cause a kernel reboot after N seconds (if N > 0).
|
||||
This panic timeout can also be set by "echo N > /proc/sys/kernel/panic".
|
||||
.TP
|
||||
.B "`reboot=[warm|cold][,[bios|hard]]'"
|
||||
(Only when CONFIG_BUGi386 is defined.)
|
||||
.B "'reboot=[warm|cold][,[bios|hard]]'"
|
||||
(Only when
|
||||
.B CONFIG_BUGi386
|
||||
is defined.)
|
||||
Since 2.0.22 a reboot is by default a cold reboot.
|
||||
One asks for the old default with `reboot=warm'.
|
||||
One asks for the old default with 'reboot=warm'.
|
||||
(A cold reboot may be required to reset certain hardware,
|
||||
but might destroy not yet written data in a disk cache.
|
||||
A warm reboot may be faster.)
|
||||
By default a reboot is hard, by asking the keyboard controller
|
||||
to pulse the reset line low, but there is at least one type
|
||||
of motherboard where that doesn't work.
|
||||
The option `reboot=bios' will
|
||||
The option 'reboot=bios' will
|
||||
instead jump through the BIOS.
|
||||
.TP
|
||||
.B "`nosmp'" and "`maxcpus=N'"
|
||||
.BR 'nosmp' " and " 'maxcpus=N'
|
||||
(Only when __SMP__ is defined.)
|
||||
A command-line option of `nosmp' or `maxcpus=0' will disable SMP
|
||||
activation entirely; an option `maxcpus=N' limits the maximum number
|
||||
A command-line option of 'nosmp' or 'maxcpus=0' will disable SMP
|
||||
activation entirely; an option 'maxcpus=N' limits the maximum number
|
||||
of CPUs activated in SMP mode to N.
|
||||
.SS "Boot Arguments for Use by Kernel Developers"
|
||||
.TP
|
||||
.B "`debug'"
|
||||
.B "'debug'"
|
||||
Kernel messages are handed off to the kernel log daemon klogd so that they
|
||||
may be logged to disk.
|
||||
Messages with a priority above
|
||||
|
@ -316,18 +322,20 @@ to klogd.
|
|||
See
|
||||
.BR klogd (8).
|
||||
.TP
|
||||
.B "`profile=N'"
|
||||
.B "'profile=N'"
|
||||
It is possible to enable a kernel profiling function,
|
||||
if one wishes to find out where the kernel is spending its CPU cycles.
|
||||
Profiling is enabled by setting the variable
|
||||
.I prof_shift
|
||||
to a non-zero value.
|
||||
This is done either by specifying CONFIG_PROFILE at
|
||||
compile time, or by giving the `profile=' option.
|
||||
This is done either by specifying
|
||||
.B CONFIG_PROFILE
|
||||
at compile time, or by giving the 'profile=' option.
|
||||
Now the value that
|
||||
.I prof_shift
|
||||
gets will be N, when given, or CONFIG_PROFILE_SHIFT, when that is given,
|
||||
or 2, the default.
|
||||
gets will be N, when given, or
|
||||
.BR CONFIG_PROFILE_SHIFT ,
|
||||
when that is given, or 2, the default.
|
||||
The significance of this variable is that it
|
||||
gives the granularity of the profiling: each clock tick, if the
|
||||
system was executing kernel code, a counter is incremented:
|
||||
|
@ -341,19 +349,20 @@ Writing to
|
|||
.I /proc/profile
|
||||
will clear the counters.
|
||||
.TP
|
||||
.B "`swap=N1,N2,N3,N4,N5,N6,N7,N8'"
|
||||
.B "'swap=N1,N2,N3,N4,N5,N6,N7,N8'"
|
||||
Set the eight parameters max_page_age, page_advance, page_decline,
|
||||
page_initial_age, age_cluster_fract, age_cluster_min, pageout_weight,
|
||||
bufferout_weight that control the kernel swap algorithm.
|
||||
For kernel tuners only.
|
||||
.TP
|
||||
.B "`buff=N1,N2,N3,N4,N5,N6'"
|
||||
.B "'buff=N1,N2,N3,N4,N5,N6'"
|
||||
Set the six parameters max_buff_age, buff_advance, buff_decline,
|
||||
buff_initial_age, bufferout_weight, buffermem_grace that control
|
||||
kernel buffer memory management.
|
||||
For kernel tuners only.
|
||||
.SS "Boot Arguments for Ramdisk Use"
|
||||
(Only if the kernel was compiled with CONFIG_BLK_DEV_RAM.)
|
||||
(Only if the kernel was compiled with
|
||||
.BR CONFIG_BLK_DEV_RAM .)
|
||||
In general it is a bad idea to use a ramdisk under Linux \(em
|
||||
the system will use available memory more efficiently itself.
|
||||
But while booting (or while constructing boot floppies)
|
||||
|
@ -365,7 +374,7 @@ before the main disk can be accessed.
|
|||
|
||||
In Linux 1.3.48, ramdisk handling was changed drastically.
|
||||
Earlier, the memory was allocated statically, and there was
|
||||
a `ramdisk=N' parameter to tell its size.
|
||||
a 'ramdisk=N' parameter to tell its size.
|
||||
(This could also
|
||||
be set in the kernel image at compile time, or by use of
|
||||
.BR rdev (8).)
|
||||
|
@ -377,29 +386,31 @@ in conjunction with the new ramdisk setup), see
|
|||
|
||||
There are four parameters, two boolean and two integral.
|
||||
.TP
|
||||
.B "`load_ramdisk=N'"
|
||||
.B "'load_ramdisk=N'"
|
||||
If N=1, do load a ramdisk.
|
||||
If N=0, do not load a ramdisk.
|
||||
(This is the default.)
|
||||
.TP
|
||||
.B "`prompt_ramdisk=N'"
|
||||
.B "'prompt_ramdisk=N'"
|
||||
If N=1, do prompt for insertion of the floppy.
|
||||
(This is the default.)
|
||||
If N=0, do not prompt.
|
||||
(Thus, this parameter is never needed.)
|
||||
.TP
|
||||
.B "`ramdisk_size=N' or (obsolete) `ramdisk=N'"
|
||||
.BR 'ramdisk_size=N' " or (obsolete) " 'ramdisk=N'
|
||||
Set the maximal size of the ramdisk(s) to N kB.
|
||||
The default is 4096 (4 MB).
|
||||
.TP
|
||||
.B "`ramdisk_start=N'"
|
||||
.B "'ramdisk_start=N'"
|
||||
Sets the starting block number (the offset on the floppy where
|
||||
the ramdisk starts) to N.
|
||||
This is needed in case the ramdisk follows a kernel image.
|
||||
.TP
|
||||
.B "`noinitrd'"
|
||||
(Only if the kernel was compiled with CONFIG_BLK_DEV_RAM
|
||||
and CONFIG_BLK_DEV_INITRD.)
|
||||
.B "'noinitrd'"
|
||||
(Only if the kernel was compiled with
|
||||
.B CONFIG_BLK_DEV_RAM
|
||||
and
|
||||
.BR CONFIG_BLK_DEV_INITRD .)
|
||||
These days it is possible to compile the kernel to use initrd.
|
||||
When this feature is enabled, the boot process will load the kernel
|
||||
and an initial ramdisk; then the kernel converts initrd into
|
||||
|
@ -411,7 +422,7 @@ the usual boot sequence (e.g., invocation of /sbin/init) is performed.
|
|||
For a detailed description of the initrd feature, see
|
||||
.IR /usr/src/linux/Documentation/initrd.txt .
|
||||
|
||||
The `noinitrd' option tells the kernel that although it was compiled for
|
||||
The 'noinitrd' option tells the kernel that although it was compiled for
|
||||
operation with initrd, it should not go through the above steps, but
|
||||
leave the initrd data under
|
||||
.IR /dev/initrd .
|
||||
|
@ -450,13 +461,13 @@ and a zero disables parity checking.
|
|||
Again, not all adapters will support selection of parity
|
||||
behavior as a boot argument.
|
||||
.TP
|
||||
.B "`max_scsi_luns=...'"
|
||||
A SCSI device can have a number of `sub-devices' contained within
|
||||
.B "'max_scsi_luns=...'"
|
||||
A SCSI device can have a number of 'sub-devices' contained within
|
||||
itself.
|
||||
The most common example is one of the new SCSI CD-ROMs that
|
||||
handle more than one disk at a time.
|
||||
Each CD is addressed as a
|
||||
`Logical Unit Number' (LUN) of that particular device.
|
||||
'Logical Unit Number' (LUN) of that particular device.
|
||||
But most
|
||||
devices, such as hard disks, tape drives and such are only one device,
|
||||
and will be assigned to LUN zero.
|
||||
|
@ -464,11 +475,11 @@ and will be assigned to LUN zero.
|
|||
Some poorly designed SCSI devices cannot handle being probed for
|
||||
LUNs not equal to zero.
|
||||
Therefore, if the compile time flag
|
||||
CONFIG_SCSI_MULTI_LUN is not set, newer kernels will by default
|
||||
only probe LUN zero.
|
||||
.B CONFIG_SCSI_MULTI_LUN
|
||||
is not set, newer kernels will by default only probe LUN zero.
|
||||
|
||||
To specify the number of probed LUNs at boot, one enters
|
||||
`max_scsi_luns=n' as a boot arg, where n is a number between one and
|
||||
'max_scsi_luns=n' as a boot arg, where n is a number between one and
|
||||
eight.
|
||||
To avoid problems as described above, one would use n=1 to
|
||||
avoid upsetting such broken devices.
|
||||
|
@ -573,7 +584,7 @@ The
|
|||
value, if non-zero, tells the driver not to reset the SCSI bus when
|
||||
setting up the host adapter at boot.
|
||||
.TP
|
||||
.B "AdvanSys SCSI Hosts configuration (`advansys=')"
|
||||
.B "AdvanSys SCSI Hosts configuration ('advansys=')"
|
||||
The AdvanSys driver can accept up to four i/o addresses that will be
|
||||
probed for an AdvanSys SCSI card.
|
||||
Note that these values (if used) do
|
||||
|
@ -590,7 +601,7 @@ level of the debugging messages to any of 16 levels of verbosity.
|
|||
.IP
|
||||
.BI AM53C974= host-scsi-id,target-scsi-id,max-rate,max-offset
|
||||
.TP
|
||||
.B "BusLogic SCSI Hosts configuration (`BusLogic=')"
|
||||
.B "BusLogic SCSI Hosts configuration ('BusLogic=')"
|
||||
.IP
|
||||
.BI BusLogic= N1,N2,N3,N4,N5,S1,S2,...
|
||||
.IP
|
||||
|
@ -622,7 +633,7 @@ ER:None, ER:<Per-Target-Spec>), and over Host Adapter Probing
|
|||
.B "EATA/DMA configuration"
|
||||
The default list of i/o ports to be probed can be changed by
|
||||
.IP
|
||||
.BI eata= iobase,iobase,... .
|
||||
.BI eata= iobase,iobase,...\fP.
|
||||
.TP
|
||||
.B "Future Domain TMC-16x0 configuration"
|
||||
.IP
|
||||
|
@ -750,23 +761,23 @@ For details, see
|
|||
.B "IDE Disk/CD-ROM Driver Parameters"
|
||||
The IDE driver accepts a number of parameters, which range from disk
|
||||
geometry specifications, to support for broken controller chips.
|
||||
Drive specific options are specified by using `hdX=' with X in `a'-`h'.
|
||||
Drive specific options are specified by using 'hdX=' with X in 'a'-'h'.
|
||||
|
||||
Non-drive specific options are specified with the prefix `hd='.
|
||||
Non-drive specific options are specified with the prefix 'hd='.
|
||||
Note that using a drive specific prefix for a non-drive specific option
|
||||
will still work, and the option will just be applied as expected.
|
||||
|
||||
Also note that `hd=' can be used to refer to the next unspecified
|
||||
Also note that 'hd=' can be used to refer to the next unspecified
|
||||
drive in the (a, ..., h) sequence.
|
||||
For the following discussions,
|
||||
the `hd=' option will be cited for brevity.
|
||||
the 'hd=' option will be cited for brevity.
|
||||
See the file
|
||||
.I Documentation/ide.txt
|
||||
(or
|
||||
.I drivers/block/README.ide
|
||||
for older kernels) in the kernel source for more details.
|
||||
.TP
|
||||
.B "The `hd=cyls,heads,sects[,wpcom[,irq]]' options"
|
||||
.B "The 'hd=cyls,heads,sects[,wpcom[,irq]]' options"
|
||||
These options are used to specify the physical geometry of the disk.
|
||||
Only the first three values are required.
|
||||
The cylinder/head/sectors
|
||||
|
@ -777,7 +788,7 @@ The IRQ value specified will be the IRQ
|
|||
used for the interface that the drive resides on, and is not really a
|
||||
drive specific parameter.
|
||||
.TP
|
||||
.B "The `hd=serialize' option"
|
||||
.B "The 'hd=serialize' option"
|
||||
The dual IDE interface CMD-640 chip is broken as designed such that
|
||||
when drives on the secondary interface are used at the same time as
|
||||
drives on the primary interface, it will corrupt your data.
|
||||
|
@ -785,12 +796,12 @@ Using this
|
|||
option tells the driver to make sure that both interfaces are never
|
||||
used at the same time.
|
||||
.TP
|
||||
.B "The `hd=dtc2278' option"
|
||||
.B "The 'hd=dtc2278' option"
|
||||
This option tells the driver that you have a DTC-2278D IDE interface.
|
||||
The driver then tries to do DTC specific operations to enable the
|
||||
second interface and to enable faster transfer modes.
|
||||
.TP
|
||||
.B "The `hd=noprobe' option"
|
||||
.B "The 'hd=noprobe' option"
|
||||
Do not probe for this drive.
|
||||
For example,
|
||||
.IP
|
||||
|
@ -800,22 +811,24 @@ would disable the probe, but still specify the drive geometry so
|
|||
that it would be registered as a valid block device, and hence
|
||||
usable.
|
||||
.TP
|
||||
.B "The `hd=nowerr' option"
|
||||
Some drives apparently have the WRERR_STAT bit stuck on permanently.
|
||||
.B "The 'hd=nowerr' option"
|
||||
Some drives apparently have the
|
||||
.B WRERR_STAT
|
||||
bit stuck on permanently.
|
||||
This enables a work-around for these broken devices.
|
||||
.TP
|
||||
.B "The `hd=cdrom' option"
|
||||
.B "The 'hd=cdrom' option"
|
||||
This tells the IDE driver that there is an ATAPI compatible CD-ROM
|
||||
attached in place of a normal IDE hard disk.
|
||||
In most cases the CD-ROM
|
||||
is identified automatically, but if it isn't then this may help.
|
||||
.TP
|
||||
.B "Standard ST-506 Disk Driver Options (`hd=')"
|
||||
.B "Standard ST-506 Disk Driver Options ('hd=')"
|
||||
The standard disk driver can accept geometry arguments for the disks
|
||||
similar to the IDE driver.
|
||||
Note however that it only expects three
|
||||
values (C/H/S); any more or any less and it will silently ignore you.
|
||||
Also, it only accepts `hd=' as an argument, that is, `hda='
|
||||
Also, it only accepts 'hd=' as an argument, that is, 'hda='
|
||||
and so on are not valid here.
|
||||
The format is as follows:
|
||||
.IP
|
||||
|
@ -824,7 +837,7 @@ hd=cyls,heads,sects
|
|||
If there are two disks installed, the above is repeated with the
|
||||
geometry parameters of the second disk.
|
||||
.TP
|
||||
.B "XT Disk Driver Options (`xd=')"
|
||||
.B "XT Disk Driver Options ('xd=')"
|
||||
If you are unfortunate enough to be using one of these old 8 bit cards
|
||||
that move data at a whopping 125kB/s then here is the scoop.
|
||||
If the card is not recognized, you will have to use a boot arg of the form:
|
||||
|
@ -852,7 +865,7 @@ that you entered all four values.
|
|||
Don't disappoint it.
|
||||
Here is an
|
||||
example usage for a WD1002 controller with the BIOS disabled/removed,
|
||||
using the `default' XT controller parameters:
|
||||
using the 'default' XT controller parameters:
|
||||
.IP
|
||||
xd=2,5,0x320,3
|
||||
.TP
|
||||
|
@ -895,11 +908,11 @@ pcd.driveN=prt,pro,uni,mod,slv,dly
|
|||
.br
|
||||
pcd.nice=nice
|
||||
.IP
|
||||
where `port' is the base address, `pro' is the protocol number, `uni'
|
||||
is the unit selector (for chained devices), `mod' is the mode (or \-1
|
||||
to choose the best automatically), `slv' is 1 if it should be a slave,
|
||||
and `dly' is a small integer for slowing down port accesses.
|
||||
The `nice' parameter controls the driver's use of idle CPU time, at the
|
||||
where 'port' is the base address, 'pro' is the protocol number, 'uni'
|
||||
is the unit selector (for chained devices), 'mod' is the mode (or \-1
|
||||
to choose the best automatically), 'slv' is 1 if it should be a slave,
|
||||
and 'dly' is a small integer for slowing down port accesses.
|
||||
The 'nice' parameter controls the driver's use of idle CPU time, at the
|
||||
expense of some speed.
|
||||
.TP
|
||||
.B "The CDU-31A and CDU-33A Sony Interface"
|
||||
|
@ -917,7 +930,7 @@ usage of the driver.
|
|||
|
||||
The
|
||||
.I is_pas_card
|
||||
should be entered as `PAS' if using a Pro Audio Spectrum card,
|
||||
should be entered as 'PAS' if using a Pro Audio Spectrum card,
|
||||
and otherwise it should not be specified at all.
|
||||
.TP
|
||||
.B "The CDU-535 Sony Interface"
|
||||
|
@ -925,7 +938,7 @@ The syntax for this CD-ROM interface is:
|
|||
.IP
|
||||
sonycd535=iobase[,irq]
|
||||
.IP
|
||||
A zero can be used for the I/O base as a `placeholder' if one wishes
|
||||
A zero can be used for the I/O base as a 'placeholder' if one wishes
|
||||
to specify an IRQ value.
|
||||
.TP
|
||||
.B "The GoldStar Interface"
|
||||
|
@ -939,10 +952,10 @@ Syntax:
|
|||
isp16=[iobase[,irq[,dma[,type]]]]
|
||||
.IP
|
||||
(three integers and a string).
|
||||
If the type is given as `noisp16',
|
||||
If the type is given as 'noisp16',
|
||||
the interface will not be configured.
|
||||
Other recognized types
|
||||
are: `Sanyo", `Sony', `Panasonic' and `Mitsumi'.
|
||||
are: 'Sanyo", 'Sony', 'Panasonic' and 'Mitsumi'.
|
||||
.TP
|
||||
.B "The Mitsumi Standard Interface"
|
||||
The syntax for this CD-ROM interface is:
|
||||
|
@ -976,7 +989,7 @@ cm206=[iobase][,irq]
|
|||
The driver assumes numbers between 3 and 11 are IRQ values, and
|
||||
numbers between 0x300 and 0x370 are I/O ports, so you can specify one,
|
||||
or both numbers, in any order.
|
||||
It also accepts `cm206=auto' to enable
|
||||
It also accepts 'cm206=auto' to enable
|
||||
autoprobing.
|
||||
.TP
|
||||
.B "The Sanyo Interface"
|
||||
|
@ -990,7 +1003,7 @@ The syntax for this type of card is:
|
|||
sbpcd=iobase,type
|
||||
.IP
|
||||
where type is one of the following (case sensitive) strings:
|
||||
`SoundBlaster', `LaserMate', or `SPEA'.
|
||||
'SoundBlaster', 'LaserMate', or 'SPEA'.
|
||||
The I/O base is that of the
|
||||
CD-ROM interface, and not that of the sound portion of the card.
|
||||
.SS "Ethernet Devices"
|
||||
|
@ -1062,7 +1075,7 @@ with caution.
|
|||
.B "floppy=one_fdc"
|
||||
Tells the floppy driver that you have only floppy controller (default)
|
||||
.TP
|
||||
.B "floppy=two_fdc or floppy=address,two_fdc"
|
||||
.BR floppy=two_fdc " or " floppy=address,two_fdc
|
||||
Tells the floppy driver that you have two floppy controllers.
|
||||
The second floppy controller is assumed to be at address.
|
||||
If address is
|
||||
|
@ -1091,7 +1104,7 @@ cmos for those drives.
|
|||
Print a warning message when an unexpected interrupt is received
|
||||
(default behavior)
|
||||
.TP
|
||||
.B "floppy=no_unexpected_interrupts or floppy=L40SX"
|
||||
.BR floppy=no_unexpected_interrupts " or " floppy=L40SX
|
||||
Don't print a message when an unexpected interrupt is received.
|
||||
This is needed on IBM L40SX laptops in certain video modes.
|
||||
(There seems to
|
||||
|
@ -1123,7 +1136,7 @@ d \- DMA channel.
|
|||
As you can see it gets pretty messy, and you are better off to compile
|
||||
in your own personal values as recommended.
|
||||
Using a boot arg of
|
||||
`sound=0' will disable the sound driver entirely.
|
||||
'sound=0' will disable the sound driver entirely.
|
||||
.SS "ISDN Drivers"
|
||||
.TP
|
||||
.B "The ICN ISDN driver"
|
||||
|
@ -1154,7 +1167,7 @@ shared memory base address of the card, irq is the interrupt channel
|
|||
the card uses, and teles_id is the unique ASCII string identifier.
|
||||
.SS "Serial Port Drivers"
|
||||
.TP
|
||||
.B "The RISCom/8 Multiport Serial Driver (`riscom8=')"
|
||||
.B "The RISCom/8 Multiport Serial Driver ('riscom8=')"
|
||||
Syntax:
|
||||
.IP
|
||||
riscom=iobase1[,iobase2[,iobase3[,iobase4]]]
|
||||
|
@ -1162,7 +1175,7 @@ riscom=iobase1[,iobase2[,iobase3[,iobase4]]]
|
|||
More details can be found in
|
||||
.IR /usr/src/linux/Documentation/riscom8.txt .
|
||||
.TP
|
||||
.B "The DigiBoard Driver (`digi=')"
|
||||
.B "The DigiBoard Driver ('digi=')"
|
||||
If this option is used, it should have precisely six parameters.
|
||||
Syntax:
|
||||
.IP
|
||||
|
@ -1193,7 +1206,7 @@ Syntax:
|
|||
baycom=iobase,irq,modem
|
||||
.IP
|
||||
There are precisely 3 parameters; for several cards, give
|
||||
several `baycom=' commands.
|
||||
several 'baycom=' commands.
|
||||
The modem parameter is a string
|
||||
that can take one of the values ser12, ser12*, par96, par96*.
|
||||
Here the * denotes that software DCD is to be used, and
|
||||
|
@ -1216,7 +1229,7 @@ where hw is one of sbc, wss, wssfdx and modem is one of
|
|||
afsk1200, fsk9600.
|
||||
.SS "The Line Printer Driver"
|
||||
.TP
|
||||
.B "`lp='"
|
||||
.B "'lp='"
|
||||
Syntax:
|
||||
.IP
|
||||
lp=0
|
||||
|
@ -1246,11 +1259,11 @@ Syntax:
|
|||
wdt=io,irq
|
||||
.SS "Mouse Drivers"
|
||||
.TP
|
||||
.B "`bmouse=irq'"
|
||||
.B "'bmouse=irq'"
|
||||
The busmouse driver only accepts one parameter, that being the
|
||||
hardware IRQ value to be used.
|
||||
.TP
|
||||
.B "`msmouse=irq'"
|
||||
.B "'msmouse=irq'"
|
||||
And precisely the same is true for the msmouse driver.
|
||||
.TP
|
||||
.B "ATARI mouse setup"
|
||||
|
@ -1264,7 +1277,7 @@ is the x-threshold, and the second the y-threshold.
|
|||
These values must lie between 1 and 20 (inclusive); the default is 2.
|
||||
.SS "Video Hardware"
|
||||
.TP
|
||||
.B "`no-scroll'"
|
||||
.B "'no-scroll'"
|
||||
This option tells the console driver not to use hardware scroll
|
||||
(where a scroll is effected by moving the screen origin in video
|
||||
memory, instead of moving the data).
|
||||
|
|
Loading…
Reference in New Issue