mirror of https://github.com/tLDP/LDP
1980 lines
74 KiB
Plaintext
1980 lines
74 KiB
Plaintext
<!doctype linuxdoc system>
|
|
<!--
|
|
|
|
The SGML source of the BootPrompt-Howto
|
|
=====================================
|
|
|
|
Maintained by Paul Gortmaker.
|
|
|
|
Modification Date: Sept. 04, 2001
|
|
|
|
(Don't forget to update the reference to the current kernel version
|
|
in the Introduction section, and the date/version in the abstract!)
|
|
|
|
History:
|
|
|
|
1) August 1995 - Still no comprehensive list of kernel arguments
|
|
for users to look up existence/usage info. So I hacked this up,
|
|
having experience with the linuxdoc-sgml stuff from the
|
|
Ethernet-HowTo. (Of course the most up-to-date list is the kernel
|
|
itself, but that does not lend itself well to beginners.)
|
|
|
|
2) July 1996 - Update to the v2.0 kernel, and add in all the
|
|
things I left out in the 1st version, nearly a year(!) ago.
|
|
Make copying conditions GPL (it was before, as I swiped the
|
|
the copying conditions from the GNU Make manual, but it didn't
|
|
explicitly say GPL).
|
|
|
|
3) December 1996 - More minor updates up to and incl. v2.0.27
|
|
kernel. Should be good for a while now... (ha!)
|
|
|
|
4) November 1997 - Add in a few minor updates for v2.0.31 to
|
|
coincide with the new printing of LSL's book.
|
|
|
|
5) Feb 1998 - Some more minor fixes (2.0.33).
|
|
|
|
6) May 1998 - as above, 2.0.34 still isn't officially released.
|
|
|
|
7) May 1999 - 2.2 (and 2.3) are released, time for an update!
|
|
Cite documentation files that come with the kernel instead
|
|
of taking info from them - makes maintenance easier. Also
|
|
put copying conditions as LDP or GPL (I don't really care
|
|
either way - as long as people get access to the info within.)
|
|
|
|
8) Sep 2001 - Add some new 2.4 entries. 2.5 isn't out yet.
|
|
|
|
9) Mar 2003 - (gasp!) current is 2.4.20, and 2.5.64. More of
|
|
change 7 above - deleted SCSI, CD, and sound low level
|
|
driver info.
|
|
|
|
TODO:
|
|
|
|
I'm considering the option of improving kernel-parameters.txt
|
|
that comes with the kernel source, and dropping this HowTo
|
|
altogether... Something worth considering.
|
|
|
|
-->
|
|
|
|
|
|
<article>
|
|
|
|
<title>The Linux BootPrompt-HowTo
|
|
<author>by Paul Gortmaker.
|
|
<date>v1.4, Mar 21, 2003
|
|
|
|
<abstract>
|
|
This is the BootPrompt-Howto, which is a compilation of all the
|
|
possible boot time arguments that can be passed to the Linux
|
|
kernel at boot time.
|
|
A discussion of how the kernel sorts boot time arguments, along
|
|
with an overview of some of the popular software used to boot Linux
|
|
kernels is also included.
|
|
</abstract>
|
|
|
|
<toc>
|
|
|
|
<sect>Introduction<label id="main-intro">
|
|
<p>
|
|
|
|
The kernel has the capability to accept information at
|
|
boot in the form of a `command line', similar to an argument
|
|
list you would give to a program. In general this is used to
|
|
supply the kernel with information about hardware parameters
|
|
that the kernel would not be able to determine on its own, or
|
|
to avoid/override the values that the kernel would otherwise
|
|
detect.
|
|
|
|
It is the job of the boot loader (e.g. LILO, loadlin or Grub) to
|
|
take this information from the user and put it in a previously
|
|
agreed upon place where the kernel can find it once it starts.
|
|
|
|
This present revision covers kernels up to and including v2.4.20.
|
|
and v2.5.63
|
|
|
|
The BootPrompt-Howto is by:
|
|
<quote>
|
|
Paul Gortmaker, <tt/p_gortmaker @ yahoo.com/
|
|
</quote>
|
|
|
|
This document is Copyright (c) 1995-2003 by Paul Gortmaker.
|
|
Please see the Disclaimer and Copying information at the end
|
|
of this document (<ref id="copyright" name="copyright">)
|
|
for information about redistribution of
|
|
this document and the usual `we are not responsible for what
|
|
you manage to break...' type legal stuff.
|
|
|
|
<sect1>Intended Audience and Applicability
|
|
<p>
|
|
Most Linux users should never have to even look at this document.
|
|
Linux does an exceptionally good job at detecting most hardware and
|
|
picking reasonable default settings for most parameters.
|
|
The information in this document is aimed at users who might want
|
|
to change some of the default settings to optimize the kernel to
|
|
their particular machine, or to a user who has `rolled their own'
|
|
kernel to support a not so common piece of hardware for which
|
|
the automatic defaults are not optimal.
|
|
|
|
For the sake of this document it is best to break the
|
|
boot arguments into two general categories; (a)ones
|
|
handled by the kernel and (b)those being handled by a device driver.
|
|
Examples would be <tt/init=/ which tells the kernel what the
|
|
first program to run should be, versus <tt/aha154x=/ which
|
|
tells a device driver for a SCSI card what hardware resources it
|
|
should use are. This document concentrates on giving detailed
|
|
information on those in (a) for reasons outlined below.
|
|
|
|
<em/IMPORTANT NOTE:/ Driver related boot prompt arguments
|
|
only apply to hardware drivers that are compiled directly into the
|
|
kernel. They have <em/no effect/ on drivers that are loaded
|
|
as modules. Most Linux distributions come with a basic `bare-bones'
|
|
kernel, and the drivers are small modules that are loaded after
|
|
the kernel has initialized.
|
|
If you are unsure if you are using modules then try <tt>lsmod</tt>,
|
|
look at <tt/man depmod/ and <tt/man modprobe/ along with the
|
|
contents of your <tt>/etc/modules.conf</tt>.
|
|
|
|
In light of this, device driver boot prompt arguments are
|
|
only really used by a few people who are building their own
|
|
kernels, and thus have the kernel source at hand. These people
|
|
are usually going to check the source for the options and
|
|
syntax required by that driver to get the most up to date info.
|
|
|
|
For example, if you were looking for what arguments could be
|
|
passed to the AHA1542 SCSI driver, then you would go to the
|
|
<tt>linux/drivers/scsi</tt> directory, and look in the
|
|
file <tt/aha1542.c/ for <tt>__setup(... , ...)</tt>. The
|
|
first thing in brackets is the argument you provide at boot,
|
|
and the second thing is the name of the function that processes your
|
|
argument. Usually near the top of this function or at the
|
|
top of the source file you will find a description of the boot
|
|
time arguments that the driver accepts.
|
|
|
|
|
|
<sect1>Related Documentation
|
|
<p>
|
|
|
|
For a while now, the kernel source has come with the file
|
|
<tt>linux/Documentation/kernel-parameters.txt</tt>. This
|
|
file contains a brief listing of all the boot time arguments
|
|
that you can provide, along with quick pointers to where in
|
|
the source you can find where the arguments are parsed.
|
|
The idea is that this file gives developers a quick and
|
|
easy place to add in a brief description of any new arguments
|
|
that they add while working on the source. As such, it
|
|
will probably always be more up to date than this document.
|
|
Actually, I'm considering discontinuing this document in light
|
|
of the existence of <tt/kernel-parameters.txt/. (Opinions?)
|
|
|
|
The <tt/linux/ directory is usually found in <tt>/usr/src/</tt>
|
|
for most distributions. All references in this document
|
|
to files that come with the kernel will have their pathname
|
|
abbreviated to start with <tt/linux/ - you will have to add the
|
|
<tt>/usr/src/</tt> or whatever is appropriate for your system.
|
|
Some distributions may not install the full kernel source by
|
|
default, and only put in the <tt>linux/include</tt> directory.
|
|
If you can't find the file in question, then install the kernel
|
|
source and/or make use of the <tt/find/ and <tt/locate/ commands.
|
|
If you can't find the kernel source package in your distribution
|
|
then the kernel source is available at:
|
|
|
|
<url url="http://www.kernel.org"
|
|
name="Kernel Source Home">
|
|
|
|
The next best thing to reading the kernel C source itself, will
|
|
be any of the other documentation files that are
|
|
distributed with the kernel itself. There are now quite a
|
|
few of these, and most of them can be found in the directory
|
|
<tt>linux/Documentation</tt> and subdirectories from there.
|
|
Sometimes there will be <tt/README.foo/ files that can be found
|
|
in the related driver directory (e.g. <tt>linux/drivers/???/</tt>,
|
|
where examples of <tt/???/ could be <tt/scsi/, <tt/char/, or <tt/net/).
|
|
The general trend is to move these files into the Documentation
|
|
directory, so if a file mentioned in this document is no longer
|
|
there, chances are it has been moved.
|
|
|
|
If you have figured out what boot-args you intend to use, and
|
|
now want to know how to get that information to the kernel, then
|
|
look at the documentation that comes with the software that you
|
|
use to boot the kernel (e.g. LILO or loadlin). A brief overview
|
|
is given below, but it is no substitute for the documentation
|
|
that comes with the booting software.
|
|
|
|
<sect1>New Versions of this Document<label id="new-doc">
|
|
<p>
|
|
New versions of this document can be retrieved via anonymous
|
|
FTP from most Linux FTP sites in the directory
|
|
<tt>/pub/Linux/docs/HOWTO/</tt>. Updates will be made as new
|
|
information and/or drivers becomes available. If this copy that
|
|
you are presently reading is more than six months old, then
|
|
you should probably check to see if a newer copy exists.
|
|
I would recommend viewing this via a WWW browser or in the
|
|
Postscript/dvi format. Both of these contain cross-references
|
|
that are lost in a simple plain text version.
|
|
|
|
If you want to get the official copy, here is URL.
|
|
|
|
<url url="http://metalab.unc.edu/mdw/HOWTO/BootPrompt-HOWTO.html"
|
|
name="BootPrompt-HOWTO">
|
|
|
|
<sect>Overview of Boot Prompt Arguments<label id="oview">
|
|
<p>
|
|
|
|
This section gives some examples of software that can be used
|
|
to pass kernel boot-time arguments to the kernel itself.
|
|
It also gives you an idea of how the arguments are processed,
|
|
what limitations there are on the boot args, and how they filter
|
|
down to each appropriate device that they are intended for.
|
|
|
|
It is <em/important/ to note that spaces should <em/not/ be
|
|
used in a boot argument, but only between separate arguments.
|
|
A list of values that are for a single argument are to be
|
|
separated with a comma between the values, and again without
|
|
any spaces. See the following examples below.
|
|
|
|
<code>
|
|
ether=9,0x300,0xd0000,0xd4000,eth0 root=/dev/hda1 *RIGHT*
|
|
ether = 9, 0x300, 0xd0000, 0xd4000, eth0 root = /dev/hda1 *WRONG*
|
|
</code>
|
|
|
|
Once the Linux kernel is up and running, one can view the command
|
|
line arguments that were in place at boot by simply typing
|
|
<tt>cat /proc/cmdline</tt> at a shell prompt.
|
|
|
|
<sect1>LILO (LInux LOader)<label id="lilo">
|
|
<p>
|
|
The LILO program (LInux LOader) written by Werner Almesberger
|
|
is the most commonly used. It has the ability to boot
|
|
various kernels, and stores the configuration information
|
|
in a plain text file. Most distributions ship with LILO
|
|
as the default boot-loader. LILO can boot DOS, OS/2, Linux,
|
|
FreeBSD, etc. without any difficulties, and is quite flexible.
|
|
|
|
A typical configuration will have LILO stop and print <tt/LILO:/
|
|
shortly after you turn on your computer. It will then wait for
|
|
a few seconds for any optional input from the user, and failing
|
|
that it will then boot the default system. Typical system labels
|
|
that people use in the LILO configuration files are <tt/linux/
|
|
and <tt/backup/ and <tt/msdos/. If you want to type in a boot
|
|
argument, you type it in here, after typing in the system label
|
|
that you want LILO to boot from, as shown in the example below.
|
|
|
|
<code>
|
|
LILO: linux root=/dev/hda1
|
|
</code>
|
|
|
|
LILO comes with excellent documentation, and for the purposes
|
|
of boot args discussed here, the LILO <tt/append=/ command
|
|
is of significant importance when one wants to add a boot time
|
|
argument as a permanent addition to the LILO config file.
|
|
You simply add something like <tt/append = "foo=bar"/ to the
|
|
<tt>/etc/lilo.conf</tt> file. It can either be added at the top
|
|
of the config file, making it apply to all sections, or to a
|
|
single system section by adding it inside an <tt/image=/ section.
|
|
Please see the LILO documentation for a more complete description.
|
|
|
|
<sect1>LoadLin<label id="loadlin">
|
|
<p>
|
|
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 use DOS and want to launch into 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 the DOS driver to set a few proprietary
|
|
registers to put the card into a SB compatible mode. Booting
|
|
DOS with the supplied driver, and then loading Linux from
|
|
the DOS prompt with <tt>LOADLIN.EXE</tt> avoids the reset of
|
|
the card that
|
|
happens if one rebooted instead. Thus the card is left in a
|
|
SB compatible mode and hence is useable under Linux.
|
|
|
|
There are also other programs that can be used to boot Linux.
|
|
For a complete list, please look at the programs available
|
|
on your local Linux ftp mirror, under <tt>system/Linux-boot/</tt>.
|
|
|
|
<sect1>The ``rdev'' utility<label id="rdev">
|
|
<p>
|
|
There are a few of the kernel boot parameters that have their
|
|
default values stored in various bytes in the kernel image itself.
|
|
There is a utility called <tt/rdev/ that is installed on most
|
|
systems that knows where these values are, and how to change them.
|
|
It can also change things that have no kernel boot argument
|
|
equivalent, such as the default video mode used.
|
|
|
|
The rdev utility is usually also aliased to swapdev, ramsize,
|
|
vidmode and rootflags. These are the five things that rdev
|
|
can change, those being the root device, the swap device,
|
|
the RAM disk parameters, the default video mode, and the
|
|
readonly/readwrite setting of root device.
|
|
|
|
More information on <tt/rdev/ can be found by typing
|
|
<tt/rdev -h/ or by reading the supplied man page (<tt/man rdev/).
|
|
|
|
<sect1>How the Kernel Sorts the Arguments
|
|
<p>
|
|
Most of the boot args take the form of:
|
|
<code>
|
|
name[=value_1]&lsqb,value_2]...&lsqb,value_11&rsqb
|
|
</code>
|
|
|
|
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. Multiple boot args are just a space separated list
|
|
of the above format. Note the limit of 11 is real, as the
|
|
present code only handles 11 comma separated parameters per
|
|
keyword. (However, you can re-use the same keyword with
|
|
up to an additional 11 parameters in unusually complicated
|
|
situations, assuming the setup function supports it.)
|
|
Also note that the kernel splits the list into a maximum of
|
|
ten integer arguments, and a following string, so you
|
|
can't really supply 11 integers unless you convert the
|
|
11th arg from a string to an int in the driver itself.
|
|
|
|
Most of the sorting goes on in <tt>linux/init/main.c</tt>.
|
|
First, the kernel checks to see if the argument is any of
|
|
the special arguments `root=', `ro', `rw', or `debug'.
|
|
The meaning of these special arguments is described further
|
|
on in the document.
|
|
|
|
Then it walks a list of setup functions (contained in the
|
|
<tt/bootsetups/ array) to see if the specified
|
|
argument string (such as `foo') has been associated with a
|
|
setup function (<tt/foo_setup()/) for a particular
|
|
device or part of the kernel. If you
|
|
passed the kernel the line <tt>foo=3,4,5,6,bar</tt> then the
|
|
kernel would search the <tt/bootsetups/ array to see if
|
|
`foo' was registered. If it was, then it would call the
|
|
setup function associated with `foo' (<tt/foo_setup()/)
|
|
and hand it the integer arguments
|
|
3, 4, 5 and 6 as given on the kernel command line, and
|
|
also hand it the string argument <tt/bar/.
|
|
|
|
<sect1>Setting Environment Variables.
|
|
<p>
|
|
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. An example would
|
|
be to use <tt/TERM=vt100/ or <tt/BOOT_IMAGE=vmlinuz.bak/
|
|
as a boot argument. These environment
|
|
variables are typically tested for in the initialization
|
|
scripts to enable or disable a wide range of things.
|
|
|
|
<sect1>Passing Arguments to the `init' program
|
|
<p>
|
|
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
|
|
<tt/init/ program. The most common argument that is passed to
|
|
the <tt/init/ process is the word <em/single/ which instructs
|
|
<tt/init/ to boot the computer in single user mode, and not
|
|
launch all the usual daemons. Check the manual page for the
|
|
version of <tt/init/ installed on your system to see what
|
|
arguments it accepts.
|
|
|
|
<sect>General Non-Device Specific Boot Args<label id="general">
|
|
<p>
|
|
These are the boot arguments that are not related to any
|
|
specific device or peripheral. They are instead related to
|
|
certain internal kernel parameters, such as memory handling,
|
|
ramdisk handling, root file system handling and others.
|
|
|
|
<sect1> Root Filesystem options
|
|
<p>
|
|
The following options all pertain to how the kernel selects
|
|
and handles the root filesystem.
|
|
|
|
<sect2>The `root=' Argument
|
|
<p>
|
|
This argument tells the kernel what device is to be used as
|
|
the root filesystem while booting. The default of this setting
|
|
is the value of the root device of the system that
|
|
the kernel was built on.
|
|
For example, if the kernel in question was built on a system
|
|
that used `/dev/hda1' as the root partition, then the default
|
|
root device would be `/dev/hda1'. To override this default
|
|
value, and select the second floppy drive as the root device,
|
|
one would use `root=/dev/fd1'.
|
|
|
|
Valid root devices are any of the following devices:
|
|
|
|
(1) /dev/hdaN to /dev/hddN, which is partition N on ST-506
|
|
compatible disk `a to d'.
|
|
|
|
(2) /dev/sdaN to /dev/sdeN, which is partition N on SCSI
|
|
compatible disk `a to e'.
|
|
|
|
(3) /dev/xdaN to /dev/xdbN, which is partition N on XT
|
|
compatible disk `a to b'.
|
|
|
|
(4) /dev/fdN, which is floppy disk drive number N. Having
|
|
N=0 would be the DOS `A:' drive, and N=1 would be `B:'.
|
|
|
|
(5) /dev/nfs, which is not really a device, but rather a
|
|
flag to tell the kernel to get the root fs via the network.
|
|
|
|
(6) /dev/ram, which is the RAM disk.
|
|
|
|
The more awkward and less portable numeric specification
|
|
of the above possible disk devices in major/minor format is
|
|
also accepted. (e.g. /dev/sda3 is major 8, minor 3, so you
|
|
could use <tt/root=0x803/ as an alternative.)
|
|
|
|
This is one of the few kernel boot arguments that has its
|
|
default stored in the kernel image, and which can thus
|
|
be altered with the <tt/rdev/ utility.
|
|
|
|
|
|
<sect2>The `rootflags=' Argument
|
|
<p>
|
|
This option allows you to give options pertaining to the
|
|
mounting of the root filesystem just as you would to the
|
|
<tt/mount/ program. An example could be giving the
|
|
<tt/noatime/ option to an ext2 fs.
|
|
|
|
<sect2>The `rootfstype=' Argument
|
|
<p>
|
|
This option allows you to give a comma separated list of
|
|
fs types that will be tried for a match when trying to
|
|
mount the root filesystem. This list will be used instead
|
|
of the internal default which usually starts with ext2,
|
|
minix and the like.
|
|
|
|
<sect2>The `ro' Argument
|
|
<p>
|
|
When the kernel boots, it needs a root filesystem to read
|
|
basic things off of. This is the root filesystem that is
|
|
mounted at boot. However, if the root filesystem is mounted
|
|
with write access, you can not reliably check the filesystem
|
|
integrity with half-written files in progress. The `ro'
|
|
option tells the kernel to mount the root filesystem as
|
|
`readonly' so that any filesystem consistency check programs
|
|
(fsck) can safely assume that there are no half-written
|
|
files in progress while performing the check. No programs
|
|
or processes can write to files on the filesystem in
|
|
question until it is `remounted' as read/write capable.
|
|
|
|
This is one of the few kernel boot arguments that has its
|
|
default stored in the kernel image, and which can thus
|
|
be altered with the <tt/rdev/ utility.
|
|
|
|
<sect2>The `rw' Argument
|
|
<p>
|
|
This is the exact opposite of the above, in that it tells the
|
|
kernel to mount the root filesystem as read/write. The default
|
|
is to mount the root filesystem as read only. Do not
|
|
run any `fsck' type programs on a filesystem that is mounted
|
|
read/write.
|
|
|
|
The same value stored in the image file mentioned above is
|
|
also used for this parameter, accessible via <tt/rdev/.
|
|
|
|
<sect2>The `nfsroot=' Argument
|
|
<p>
|
|
This argument tells the kernel which machine, what directory
|
|
and what NFS options to use for the root filesystem.
|
|
Also note that
|
|
the argument <tt>root=/dev/nfs</tt> is required. Detailed
|
|
information on using an NFS root fs is in the file
|
|
<tt>linux/Documentation/nfsroot.txt</tt>.
|
|
|
|
|
|
<sect2>The `ip=' or `nfsaddrs=' Argument
|
|
<p>
|
|
If you are using NFS as a root filesystem, then there is no
|
|
programs like <tt/ifconfig/ and <tt/route/ present until
|
|
the root fs is mounted, and so the
|
|
kernel has to configure the network interfaces directly.
|
|
This boot argument sets up the various network interface addresses
|
|
that are required to communicate over the network. If this argument
|
|
is not given, then the kernel tries to use RARP and/or BOOTP to
|
|
figure out these parameters.
|
|
|
|
<sect1>Options Relating to RAM Disk Management
|
|
<p>
|
|
The following options all relate to how the kernel handles
|
|
the RAM disk device, which is usually used for bootstrapping
|
|
machines during the install phase, or for machines with
|
|
modular drivers that need to be installed to access the
|
|
root filesystem.
|
|
|
|
|
|
<sect2>The `ramdisk_start=' Argument
|
|
<p>
|
|
To allow a kernel image to reside on a floppy disk along with a
|
|
compressed ramdisk image, the `ramdisk_start=<offset>' command
|
|
was added. The kernel can't be included into the compressed ramdisk
|
|
filesystem image, because it needs to be stored starting at block
|
|
zero so that the BIOS can load the bootsector and then the kernel
|
|
can bootstrap itself to get going.
|
|
|
|
Note: If you are using an uncompressed ramdisk image, then the kernel
|
|
can be a part of the filesystem image that is being loaded into the
|
|
ramdisk, and the floppy can be booted with LILO, or the two can be
|
|
separate as is done for the compressed images.
|
|
|
|
If you are using a two-disk boot/root setup (kernel on disk 1,
|
|
ramdisk image on disk 2) then the ramdisk would start at block zero,
|
|
and an offset of zero would be used. Since this is the default value,
|
|
you would not need to actually use the command at all.
|
|
|
|
<sect2>The `load_ramdisk=' Argument
|
|
<p>
|
|
This parameter tells the kernel whether it is to try to load a
|
|
ramdisk image or not. Specifying `load_ramdisk=1' will tell the
|
|
kernel to load a floppy into the ramdisk. The default value is
|
|
zero, meaning that the kernel should not try to load a ramdisk.
|
|
|
|
Please see the file <tt>linux/Documentation/ramdisk.txt</tt>
|
|
for a complete description of the new boot time arguments, and
|
|
how to use them. A description of how this parameter can be set
|
|
and stored in the kernel image via `rdev' is also described.
|
|
|
|
<sect2>The `prompt_ramdisk=' Argument
|
|
<p>
|
|
This parameter tells the kernel whether or not to give you a prompt
|
|
asking you to insert the floppy containing the ramdisk image. In
|
|
a single floppy configuration the ramdisk image is on the same floppy
|
|
as the kernel that just finished loading/booting and so a prompt
|
|
is not needed. In this case one can use `prompt_ramdisk=0'. In a
|
|
two floppy configuration, you will need the chance to switch disks,
|
|
and thus `prompt_ramdisk=1' can be used. Since this is the default
|
|
value, it doesn't really need to be specified. (
|
|
(Historical note: Sneaky people used to use the `vga=ask' LILO
|
|
option to temporarily pause the boot process and allow a chance to
|
|
switch from boot to root floppy.)
|
|
|
|
Please see the file <tt>linux/Documentation/ramdisk.txt</tt>
|
|
for a complete description of the new boot time arguments, and
|
|
how to use them. A description of how this parameter can be set
|
|
and stored in the kernel image via `rdev' is also described.
|
|
|
|
<sect2>The `ramdisk_size=' Argument
|
|
<p>
|
|
While it is true that the ramdisk grows dynamically as required,
|
|
there is an upper bound on its size so that it doesn't consume
|
|
all available RAM and leave you in a mess. The default is 4096
|
|
(i.e. 4MB) which should be large enough for most needs. You
|
|
can override the default to a bigger or smaller size with this
|
|
boot argument.
|
|
|
|
Please see the file <tt>linux/Documentation/ramdisk.txt</tt>
|
|
for a complete description of the new boot time arguments, and
|
|
how to use them. A description of how this parameter can be set
|
|
and stored in the kernel image via `rdev' is also described.
|
|
|
|
<sect2>The `ramdisk_blocksize=' Argument
|
|
<p>
|
|
This can be tuned for better memory management behaviour.
|
|
Quoting from the ramdisk driver <tt/rd.c/:
|
|
|
|
It would be very desirable to have a soft-blocksize (that in
|
|
the case of the ramdisk driver is also the hardblocksize ;) of
|
|
PAGE_SIZE because doing that we'll achieve a far better MM
|
|
footprint. Using a rd_blocksize of BLOCK_SIZE in the worst case
|
|
we'll make PAGE_SIZE/BLOCK_SIZE buffer-pages unfreeable. With a
|
|
rd_blocksize of PAGE_SIZE instead we are sure that only 1 page
|
|
will be protected. Depending on the size of the ramdisk you may
|
|
want to change the ramdisk blocksize to achieve a better or worse
|
|
MM behaviour. The default is still BLOCK_SIZE (needed by
|
|
rd_load_image that supposes the filesystem in the image uses
|
|
a BLOCK_SIZE blocksize)
|
|
|
|
<sect2>The `ramdisk=' Argument (obsolete)
|
|
<p>
|
|
(NOTE: This argument is obsolete, and should not be used except
|
|
on kernels v1.3.47 and older. The commands that should be used
|
|
for the ramdisk device are documented above. Newer kernels
|
|
may accept this as an alias for <tt/ramdisk_size/.)
|
|
|
|
This specifies the size in kB of the RAM disk device.
|
|
For example, if one wished to have a root filesystem on a 1.44MB
|
|
floppy loaded into the RAM disk device, they would use:
|
|
|
|
<code>
|
|
ramdisk=1440
|
|
</code>
|
|
|
|
This is one of the few kernel boot arguments that has its
|
|
default stored in the kernel image, and which can thus
|
|
be altered with the <tt/rdev/ utility.
|
|
|
|
|
|
<sect2>The `noinitrd' (initial RAM disk) Argument
|
|
<p>
|
|
The v2.x and newer kernels have a feature where the root filesystem
|
|
can be initially a RAM disk, and the kernel executes <tt>/linuxrc</tt>
|
|
on that RAM image. This feature is typically used to allow loading
|
|
of modules needed to mount the real root filesystem (e.g. load
|
|
the SCSI driver modules stored in the RAM disk image, and then
|
|
mount the real root filesystem on a SCSI disk.)
|
|
|
|
The actual `noinitrd' argument determines what happens to the
|
|
initrd data after the kernel has booted. When
|
|
specified, instead of converting it to a RAM disk, it
|
|
is accessible via <tt>/dev/initrd</tt>, which can be read once
|
|
before the RAM is released back to the system. For full details
|
|
on using the initial RAM disk, please consult
|
|
<tt>linux/Documentation/initrd.txt</tt>. In addition, the most
|
|
recent versions of <tt/LILO/ and <tt/LOADLIN/ should have additional
|
|
useful information.
|
|
|
|
|
|
<sect1>Boot Arguments Related to Memory Handling
|
|
<p>
|
|
The following arguments alter how Linux detects or handles
|
|
the physical and virtual memory of your system.
|
|
|
|
<sect2>The `cachesize=' Argument
|
|
<p>
|
|
Override level 2 CPU cache size detection (in kB). Sometimes
|
|
CPU hardware bugs make them report the cache size incorrectly.
|
|
The kernel will attempt work arounds to fix known problems, but
|
|
for some CPUs it is not possible to determine what the correct
|
|
size should be. This option provides an override for these
|
|
situations.
|
|
|
|
<sect2>The `mem=' Argument
|
|
<p>
|
|
This argument has several purposes: The original purpose was to
|
|
specify the amount of installed memory (or a value less than
|
|
that if you wanted to limit the amount of memory available to
|
|
linux).
|
|
|
|
The next (and hardly used) purpose is to specify
|
|
<tt/mem=nopentium/ which tells the Linux kernel to not use
|
|
the 4MB page table performance feature. If you want to use
|
|
it for both purposes, use a separate <tt/mem=/ for each one.
|
|
|
|
The original 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. (Yes, another lack of foresight,
|
|
just like the 1024 cylinder disks... sigh.) Linux uses this
|
|
BIOS call at boot to determine how much memory is installed.
|
|
A newer specification (e820) allows the BIOS to get this right
|
|
on most machines nowadays. If you have more than 64MB of RAM
|
|
installed on an older machine, you can use this
|
|
boot argument to tell Linux how much memory you have.
|
|
Here is a quote from Linus on the usage of the <tt/mem=/ parameter.
|
|
|
|
``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'.
|
|
If you tell Linux that it has more memory
|
|
than it actually does have, bad things will happen: maybe not at
|
|
once, but surely eventually.''
|
|
|
|
Note that the argument does not have to be in hex, and the
|
|
suffixes `k' and `M' (case insensitive) can be used to specify
|
|
kilobytes and Megabytes, respectively. (A `k' will cause a 10 bit
|
|
shift on your value, and a `M' will cause a 20 bit shift.)
|
|
A typical example for a 128MB machine would be "<tt/mem=128m/".
|
|
|
|
In some cases, the memory reported via e820 can also be wrong,
|
|
and so the <tt/mem=exactmap/ was added. You use this in
|
|
conjunction with specifying an exact memory map, such as:
|
|
|
|
<code>
|
|
mem=exactmap mem=640K@0 mem=1023M@1M
|
|
</code>
|
|
|
|
for a 1GB machine with the usual 384k of ISA memory mapped
|
|
I/O space excluded from use.
|
|
|
|
|
|
<sect2>The `memfrac=' Argument
|
|
<p>
|
|
Memory is broken down into zones; on i386 these zones
|
|
correspond to `DMA' (for legacy ISA devices that can only address
|
|
up to 16MB via DMA); `Normal' for memory from 16MB up to 1GB,
|
|
and `HighMem' for memory beyond 1GB (assuming your kernel
|
|
was built with high mem support enabled). The two (or three)
|
|
integers supplied here determine how much memory in each zone
|
|
should be kept free - with the size of the zone divided by the
|
|
number supplied being used as the minimum (so smaller numbers
|
|
mean keep more free in the zone). The defaults are currently
|
|
<tt>memfrac=32,128,128</tt>.
|
|
|
|
<sect2>The `swap=' Argument
|
|
<p>
|
|
This allows the user to tune some of the virtual memory (VM)
|
|
parameters that are related to swapping to disk. It accepts
|
|
the following eight parameters:
|
|
|
|
<code>
|
|
MAX_PAGE_AGE
|
|
PAGE_ADVANCE
|
|
PAGE_DECLINE
|
|
PAGE_INITIAL_AGE
|
|
AGE_CLUSTER_FRACT
|
|
AGE_CLUSTER_MIN
|
|
PAGEOUT_WEIGHT
|
|
BUFFEROUT_WEIGHT
|
|
</code>
|
|
|
|
Interested hackers are advised to have a read of
|
|
<tt>linux/mm/swap.c</tt> and also make note of the goodies in
|
|
<tt>/proc/sys/vm</tt>. Kernels come with some
|
|
useful documentation on this in the
|
|
<tt>linux/Documentation/vm/</tt> directory.
|
|
|
|
<sect2>The `buff=' Argument
|
|
<p>
|
|
Similar to the `swap=' argument, this allows the user to
|
|
tune some of the parameters related to buffer memory management.
|
|
It accepts the following six parameters:
|
|
|
|
<code>
|
|
MAX_BUFF_AGE
|
|
BUFF_ADVANCE
|
|
BUFF_DECLINE
|
|
BUFF_INITIAL_AGE
|
|
BUFFEROUT_WEIGHT
|
|
BUFFERMEM_GRACE
|
|
</code>
|
|
|
|
Interested hackers are advised to have a read of
|
|
<tt>linux/mm/swap.c</tt> and also make note of the goodies
|
|
in <tt>/proc/sys/vm</tt>. Kernels come with some
|
|
useful documentation on this in the
|
|
<tt>linux/Documentation/vm/</tt> directory.
|
|
|
|
<sect1>Other Misc. Kernel Boot Arguments
|
|
<p>
|
|
These various boot arguments let the user tune certain
|
|
internal kernel parameters.
|
|
|
|
<sect2>The `acpi=' Argument
|
|
<p>
|
|
Currently this only accepts `off' to disable the ACPI subsystem.
|
|
|
|
<sect2>The `console=' Argument
|
|
<p>
|
|
Usually the console is the 1st virtual terminal, and so boot
|
|
messages appear on your VGA screen. Sometimes it is nice to
|
|
be able to use another device like a serial port (or even a
|
|
printer!) to be the console when no video device is present.
|
|
It is also useful to capture boot time messages if a problem
|
|
stops progress before they can be logged to disk.
|
|
An example would be to use
|
|
<tt>console=ttyS1,9600</tt> for selecting the 2nd serial port
|
|
at 9600 baud to be the console.
|
|
More information can be found in
|
|
<tt>linux/Documentation/serial-console.txt</tt>.
|
|
|
|
<sect2>The `debug' Argument
|
|
<p>
|
|
The kernel communicates important (and not-so important)
|
|
messages to the operator via the <tt/printk()/ function.
|
|
If the message is considered important, the <tt/printk()/
|
|
function will put a copy on the present console as well
|
|
as handing it off to the <tt/klogd()/ facility so that it
|
|
gets logged to disk. The reason for printing important
|
|
messages to the console as well as logging them to disk is
|
|
because under unfortunate circumstances (e.g. a disk failure)
|
|
the message won't make it to disk and will be lost.
|
|
|
|
The threshold for what is and what isn't considered important
|
|
is set by the <tt/console_loglevel/ variable. The default is
|
|
to log anything more important than <tt/DEBUG/ (level 7) to
|
|
the console. (These levels are defined in the include file
|
|
<tt/kernel.h/) Specifying <tt/debug/ as a boot argument will
|
|
set the console loglevel to 10, so that <em/all/ kernel
|
|
messages appear on the console.
|
|
|
|
The console loglevel can usually also be set at run time via
|
|
an option to the <tt/klogd()/ program. Check the man page
|
|
for the version installed on your system to see how to do this.
|
|
|
|
<sect2>The `decnet=' Argument
|
|
<p>
|
|
If you are using DECnet, you can supply two comma separated
|
|
integers here to give your area and node respectively.
|
|
|
|
<sect2>The `devfs=' Argument
|
|
<p>
|
|
If you are using devfs, instead of the standard static
|
|
devices in <tt>/dev/</tt> then you can supply the words
|
|
<tt>only</tt> or <tt>mount</tt> with this argument.
|
|
There are also additional debug arguments that are listed
|
|
in the source.
|
|
|
|
<sect2>The `gpt' Argument
|
|
<p>
|
|
If you are using EFI GUID Partition Table handling, you can
|
|
use this to override problems associated with an invalid PMBR.
|
|
|
|
<sect2>The `idle=' Argument
|
|
<p>
|
|
Setting this to `poll' causes the idle loop in the kernel
|
|
to poll on the need reschedule flag instead of waiting
|
|
for an interrupt to happen. This can result in an improvement
|
|
in performance on SMP systems (albeit at the cost of an
|
|
increase in power consumption).
|
|
|
|
<sect2>The `init=' Argument
|
|
<p>
|
|
The kernel defaults to starting the `init' program at boot,
|
|
which then takes care of setting up the computer for users
|
|
via launching getty programs, running `rc' scripts and the like.
|
|
The kernel first looks for <tt>/sbin/init</tt>, then
|
|
<tt>/etc/init</tt> (depreciated), and as a last resort, it
|
|
will try to use <tt>/bin/sh</tt> (possibly on <tt>/etc/rc</tt>).
|
|
If for example, your init program got corrupted and thus stopped
|
|
you from being able to boot, you could simply use the boot prompt
|
|
<tt>init=/bin/sh</tt> which would drop you directly into a
|
|
shell at boot, allowing you to replace the corrupted program.
|
|
|
|
<sect2>The `isapnp=' Argument
|
|
<p>
|
|
This takes the form of:
|
|
<tt>isapnp=read_port,reset,skip_pci_scan,verbose</tt>
|
|
|
|
<sect2>The `isapnp_reserve_dma=' Argument
|
|
<p>
|
|
This takes the form of:
|
|
<tt>isapnp_reserve_dma=n1,n2,n3,...nN</tt>
|
|
where n1 ... nN are the DMA channel numbers to not use for PnP.
|
|
|
|
<sect2>The `isapnp_reserve_io=' Argument
|
|
<p>
|
|
This takes the form of:
|
|
<tt>isapnp_reserve_irq=io1,size1,io2,size2,...ioN,sizeN</tt>
|
|
where ioX,sizeX are I/O start and length pairs of regions
|
|
in I/O space that are not to be used by PnP.
|
|
|
|
<sect2>The `isapnp_reserve_irq=' Argument
|
|
<p>
|
|
This takes the form of:
|
|
<tt>isapnp_reserve_irq=n1,n2,n3,...nN</tt>
|
|
where n1 ... nN are the interrupt numbers to not use for PnP.
|
|
|
|
<sect2>The `isapnp_reserve_mem=' Argument
|
|
<p>
|
|
This takes the form of:
|
|
<tt>isapnp_reserve_mem=mem1,size1,mem2,size2,...memN,sizeN</tt>
|
|
where ioX,sizeX are I/O start and length pairs of regions
|
|
in memory space that are not to be used by PnP.
|
|
|
|
<sect2>The `kbd-reset' Argument
|
|
<p>
|
|
Normally on i386 based machines, the Linux kernel does not
|
|
reset the keyboard controller at boot, since the BIOS is
|
|
supposed to do this. But as usual, not all machines do what
|
|
they should. Supplying this option may help if you are having
|
|
problems with your keyboard behaviour. It simply forces a
|
|
reset at initialization time. (Some have argued that this should
|
|
be the default behaviour anyways).
|
|
|
|
<sect2>The `lockd.udpport=' and `lockd.tcpport' Argument
|
|
<p>
|
|
These tell the kernel to use the given port numbers for
|
|
NFS lockd operation (for either UDP or TCP operation).
|
|
|
|
<sect2>The `maxcpus=' Argument
|
|
<p>
|
|
The number given with this argument limits the maximum
|
|
number of CPUs activated in SMP mode. Using a value of
|
|
0 is equivalent to the <tt/nosmp/ option.
|
|
|
|
<sect2>The `mca-pentium' Argument
|
|
<p>
|
|
The IBM model 95 Microchannel machines seem to lock up on the
|
|
test that Linux usually does to detect the type of math chip
|
|
coupling. Since all Pentium chips have a built in math processor,
|
|
this test (and the lock up problem) can be avoided by using
|
|
this boot option.
|
|
|
|
<sect2>The `md=' Argument
|
|
<p>
|
|
If your root filesystem is on a Multiple Device then you can
|
|
use this (assuming you compiled in boot support) to tell the
|
|
kernel the multiple device layout. The format (from the
|
|
file <tt>linux/Documentation/md.txt</tt>) is:
|
|
|
|
<tt>md=md_device_num,raid_level,chunk_size_factor,fault_level,dev0,dev1,...,devN</tt>
|
|
|
|
Where <tt/md_device_num/ is the number of the md device,
|
|
i.e. 0 means md0, 1 means md1, etc.
|
|
For <tt/raid_level/, use -1 for linear mode and 0 for striped mode.
|
|
Other modes are currently unsupported.
|
|
The <tt/chunk_size_factor/ is for raid-0 and raid-1 only and
|
|
sets the chunk size as PAGE_SIZE shifted left the specified
|
|
amount. The <tt/fault_level/ is only for raid-1
|
|
and sets the maximum fault number to the specified number.
|
|
(Currently unsupported due to lack of boot support for raid1.)
|
|
The <tt/dev0-devN/ are a comma separated list of the devices that
|
|
make up the individual md device:
|
|
e.g. <tt>/dev/hda1,/dev/hdc1,/dev/sda1</tt>
|
|
|
|
See also <tt/raid=/.
|
|
|
|
<sect2>The `nmi_watchdog=' Argument
|
|
<p>
|
|
Supplying a non-zero integer will enable the non maskable
|
|
interrupt watchdog (assuming IO APIC support is compiled in).
|
|
This checks to see if the interrupt count is increasing
|
|
(indicating normal system activity) and if it is not then
|
|
it assumes that a processor is stuck and forces an error
|
|
dump of diagnostic information.
|
|
|
|
<sect2>The `no387' Argument
|
|
<p>
|
|
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, apparently due to
|
|
a bug in the FRSAV/FRRESTOR instructions. Using the `no387'
|
|
boot argument causes Linux to ignore the math coprocessor
|
|
even if you have one. Of course you must then have your
|
|
kernel compiled with math emulation support! This may also
|
|
be useful if you have one of those <em/really/ old 386 machines
|
|
that could use an 80287 FPU, as Linux can't use an 80287.
|
|
|
|
<sect2>The `no-hlt' Argument
|
|
<p>
|
|
The i386 (and successors thereof) family of CPUs have a
|
|
`hlt' instruction which tells the CPU that nothing is
|
|
going to happen until an external device (keyboard, modem,
|
|
disk, etc.) calls upon the CPU to do a task. This allows the
|
|
CPU to enter a `low-power' mode where it sits like a zombie
|
|
until an external device wakes it up (usually via an interrupt).
|
|
Some of the early i486DX-100 chips had a problem with the
|
|
`hlt' instruction, in that they couldn't reliably return to
|
|
operating mode after this instruction was used. Using the
|
|
`no-hlt' instruction tells Linux to just run an infinite loop
|
|
when there is nothing else to do, and to <em/not/ halt your
|
|
CPU when there is no activity. This allows people with these
|
|
broken chips to use Linux, although they would be well advised
|
|
to seek a replacement through a warranty where possible.
|
|
|
|
<sect2>The `no-scroll' Argument
|
|
<p>
|
|
Using this argument at boot disables scrolling features that
|
|
make it difficult to use Braille terminals.
|
|
|
|
<sect2>The `noapic' Argument
|
|
<p>
|
|
Using this option tells a SMP kernel to not use some of the
|
|
advanced features of the interrupt controller on multi processor
|
|
machines. Use of this option may be required when a device
|
|
(such as those using ne2k-pci or 3c59xi drivers) stops generating
|
|
interrupts (i.e. <tt>cat /proc/interrupts</tt> shows the same
|
|
interrupt count.)
|
|
See <tt>linux/Documentation/IO-APIC.txt</tt> for more information.
|
|
|
|
<sect2>The `noht' Argument
|
|
<p>
|
|
This will disable hyper-threading on intel processors that
|
|
have this feature.
|
|
|
|
<sect2>The `noisapnp' Argument
|
|
<p>
|
|
If ISA PnP is built into the kernel, this will disable it.
|
|
|
|
<sect2>The `nomce' Argument
|
|
<p>
|
|
Some newer processors have the ability to self-monitor and
|
|
detect inconsistencies that should not regularly happen.
|
|
If an inconsistency is detected, a Machine Check Exception
|
|
will take place and the system will be halted (rather than
|
|
plundering forward and corrupting your data). You can use
|
|
this argument to disable this feature, but be sure to check
|
|
that your CPU is not overheating or otherwise faulty first.
|
|
|
|
<sect2>The `nosmp' Argument
|
|
<p>
|
|
Use of this option will tell a SMP kernel on a SMP machine to
|
|
operate single processor. Typically only used for debugging
|
|
and determining if a particular problem is SMP related.
|
|
|
|
<sect2>The `noresume' Argument
|
|
<p>
|
|
If software suspend is enabled, and a suspend to disk file
|
|
has been specified, using this argument will give a normal
|
|
boot and the suspend data will be ignored.
|
|
|
|
<sect2>The `notsc' Argument
|
|
<p>
|
|
Use of this option will tell the kernel to not use the
|
|
Time Stamp Counter for anything, even if the CPU has one.
|
|
|
|
<sect2>The `nofxsr" Argument
|
|
<p>
|
|
Use of this option will tell the kernel to not use
|
|
any speed-up tricks involving the floating point unit,
|
|
even if the processor supports them.
|
|
|
|
<sect2>The `panic=' Argument
|
|
<p>
|
|
In the unlikely event of a kernel panic (i.e. an internal error
|
|
that has been detected by the kernel, and which the kernel decides
|
|
is serious enough to moan loudly and then halt everything), the
|
|
default behaviour is to just sit there until someone comes along
|
|
and notices the panic message on the screen and reboots the machine.
|
|
However if a machine is running unattended in an isolated location
|
|
it may be desirable for it to automatically reset itself so that
|
|
the machine comes back on line. For example, using <tt/panic=30/ at
|
|
boot would cause the kernel to try and reboot itself 30 seconds
|
|
after the kernel panic happened. A value of zero gives the default
|
|
behaviour, which is to wait forever.
|
|
|
|
Note that this timeout value can also be read and set via the
|
|
<tt>/proc/sys/kernel/panic</tt> sysctl interface.
|
|
|
|
<sect2>The `pirq=' Argument
|
|
<p>
|
|
Using this option tells a SMP kernel information on the PCI
|
|
slot versus IRQ settings for SMP motherboards which are
|
|
unknown (or known to be blacklisted).
|
|
See <tt>linux/Documentation/IO-APIC.txt</tt> for more
|
|
information.
|
|
|
|
<sect2>The `profile=' Argument
|
|
<p>
|
|
Kernel developers can
|
|
profile how and where the kernel is spending its CPU cycles
|
|
in an effort to maximize efficiency and performance. This
|
|
option lets you set the profile shift count at boot. Typically
|
|
it is set to two. You need a tool such as
|
|
<tt/readprofile.c/ that can make use of the <tt>/proc/profile</tt>
|
|
output.
|
|
|
|
<sect2>The `quiet' Argument
|
|
<p>
|
|
This is pretty much the opposite of the `debug' argument.
|
|
When this is given, only important and system critical
|
|
kernel messages are printed to the console. Normal messages
|
|
about hardware detection at boot are suppressed.
|
|
|
|
<sect2>The `raid=' Argument
|
|
<p>
|
|
Accepts <tt/noautodetect/ at the moment. See also <tt/md=/.
|
|
|
|
<sect2>The `reboot=' Argument
|
|
<p>
|
|
This option controls the type of reboot that Linux will do
|
|
when it resets the computer (typically via <tt>/sbin/init</tt>
|
|
handling a Control-Alt-Delete). The default as of v2.0
|
|
kernels is to do a `cold' reboot (i.e. full reset, BIOS does
|
|
memory check, etc.) instead of a `warm' reboot (i.e. no full
|
|
reset, no memory check). It was changed to be cold by default
|
|
since that tends to work on cheap/broken hardware that fails
|
|
to reboot when a warm reboot is requested. To get the old
|
|
behaviour (i.e. warm reboots) use <tt/reboot=w/ or in fact
|
|
any word that starts with <tt/w/ will work.
|
|
|
|
Other accepted options are `c', `b', `h', and `s', for cold,
|
|
bios, hard, and SMP respectively. The `s' takes an optional
|
|
digit to specify which CPU should handle the reboot. Options
|
|
can be combined where it makes sense, i.e. <tt/reboot=b,s2/
|
|
|
|
<sect2>The `reserve=' Argument
|
|
<p>
|
|
This is used to <em/protect/ I/O port regions from probes.
|
|
The form of the command is:
|
|
|
|
<tscreen>
|
|
reserve=iobase,extent[,iobase,extent]...
|
|
</tscreen>
|
|
|
|
In some machines it may be necessary to prevent device drivers from
|
|
checking for devices (auto-probing) in a specific region. This may be
|
|
because of poorly designed hardware that causes the boot to <em/freeze/
|
|
(such as some ethercards), hardware that is mistakenly identified,
|
|
hardware whose state is changed by an earlier probe, or merely
|
|
hardware you don't want the kernel to initialize.
|
|
|
|
The <tt/reserve/ boot-time argument addresses this problem by specifying
|
|
an I/O port region that shouldn't be probed. That region is reserved
|
|
in the kernel's port registration table as if a device has already
|
|
been found in that region (with the name <tt/reserved/).
|
|
Note that this mechanism shouldn't be necessary on most machines.
|
|
Only when there is a problem or special case would it be necessary
|
|
to use this.
|
|
|
|
The I/O ports in the specified region are protected against
|
|
device probes that do a <tt/check_region()/ prior to probing
|
|
blindly into a region of I/O space. This was put in to be used
|
|
when some driver was hanging on a NE2000, or misidentifying
|
|
some other device as its own. A correct device driver shouldn't
|
|
probe a reserved region, unless another boot argument explicitly
|
|
specifies that it do so. This implies that <tt/reserve/ will
|
|
most often be used with some other boot argument. Hence if you
|
|
specify a <tt/reserve/ region to protect a specific device, you
|
|
must generally specify an explicit probe for that device. Most
|
|
drivers ignore the port registration table if they are given an
|
|
explicit address.
|
|
|
|
For example, the boot line
|
|
|
|
<code>
|
|
reserve=0x300,32 blah=0x300
|
|
</code>
|
|
|
|
keeps all device drivers except the driver for `blah' from
|
|
probing <tt>0x300-0x31f</tt>.
|
|
|
|
As usual with boot-time specifiers there is an 11 parameter limit,
|
|
thus you can only specify 5 reserved regions per <tt/reserve/ keyword.
|
|
Multiple <tt/reserve/ specifiers will work if you have an unusually
|
|
complicated request.
|
|
|
|
<sect2> The `resume=' Argument
|
|
<p>
|
|
If you are using software suspend, then this will allow you to
|
|
specify the file name of the suspend to disk data that you
|
|
want the machine to resume from.
|
|
|
|
<sect2> The `vga=' Argument
|
|
<p>
|
|
Note that this is not really a boot argument. It is an option
|
|
that is interpreted by LILO and not by the kernel like all the
|
|
other boot arguments are. However its use has become so common
|
|
that it deserves a mention here. It can also be set via using
|
|
<tt/rdev -v/ or equivalently <tt/vidmode/ on the vmlinuz file.
|
|
This allows the setup code to use the video BIOS to change
|
|
the default display mode before actually booting the Linux
|
|
kernel. Typical modes are 80x50, 132x44 and so on. The best
|
|
way to use this option is to start with <tt/vga=ask/ which
|
|
will prompt you with a list of various modes that you can use
|
|
with your video adapter before booting the kernel. Once you
|
|
have the number from the above list that you want to use, you
|
|
can later put it in place of the `ask'. For more information,
|
|
please see the file <tt>linux/Documentation/svga.txt</tt>
|
|
that comes with all recent kernel versions.
|
|
|
|
Note that newer kernels (v2.1 and up) have the setup code that
|
|
changes the video mode as an option, listed as
|
|
<tt/Video mode selection support/ so you need to enable this
|
|
option if you want to use this feature.
|
|
|
|
<sect>Boot Arguments to Control PCI Bus Behaviour (`pci=')
|
|
<p>
|
|
The `pci=' argument (not avail. in v2.0 kernels)
|
|
can be used to change the behaviour of PCI bus device
|
|
probing and device behaviour. Firstly the file
|
|
<tt>linux/drivers/pci/pci.c</tt> checks for
|
|
architecture independent <tt/pci=/ options.
|
|
The remaining allowed arguments are handled
|
|
in <tt>linux/arch/???/kernel/bios32.c</tt> and are
|
|
listed below for ???=i386.
|
|
|
|
<sect1>The `pci=assign-busses' Argument
|
|
<p>
|
|
This tells the kernel to always assign all PCI bus numbers,
|
|
overriding whatever the firmware may have done.
|
|
|
|
<sect1>The `pci=bios' and `pci=nobios' Arguments
|
|
<p>
|
|
These are used to set/clear the flag indicating that the
|
|
PCI probing is to take place via the PCI BIOS. The default
|
|
is to use the BIOS.
|
|
|
|
<sect1>The `pci=conf1' and `pci=conf2' Arguments
|
|
<p>
|
|
If PCI direct mode is enabled, the use of these enables
|
|
either configuration Type 1 or Type 2. These implicitly
|
|
clear the PCI BIOS probe flag (i.e. `pci=nobios') too.
|
|
|
|
<sect1>The `pci=irqmask=' Argument
|
|
<p>
|
|
This allows the user to supply an IRQ mask value, which
|
|
is converted using strtol(). It will set a bit mask of IRQs
|
|
allowed to be assigned automatically to PCI devices. You
|
|
can make the kernel exclude IRQs of your ISA cards this way.
|
|
|
|
<sect1>The `pci=lastbus=' Argument
|
|
<p>
|
|
This allows the user to supply a lastbus value, which
|
|
is converted using strtol(). It will scan all buses till bus N.
|
|
Can be useful if the kernel is unable to find your secondary buses
|
|
and you want to tell it explicitly which ones they are.
|
|
|
|
<sect1>The `pci=noacpi' Argument
|
|
<p>
|
|
|
|
This disables the use of ACPI routing information during
|
|
the PCI configuration stages.
|
|
|
|
<sect1>The `pci=nopeer' Argument
|
|
<p>
|
|
This disables the default peer bridge fixup, which according
|
|
to the source does the following:
|
|
|
|
``In case there are peer host bridges, scan bus behind each of
|
|
them. Although several sources claim that the host bridges should
|
|
have header type 1 and be assigned a bus number as for PCI2PCI
|
|
bridges, the reality doesn't pass this test and the bus number
|
|
is usually set by BIOS to the first free value.''
|
|
|
|
<sect1>The `pci=nosort' Argument
|
|
<p>
|
|
Using this argument instructs the kernel to not sort the
|
|
PCI devices during the probing phase.
|
|
|
|
<sect1>The `pci=off' Argument
|
|
<p>
|
|
Using this option disables all PCI bus probing. Any
|
|
device drivers that make use of PCI functions to find
|
|
and initialize hardware will most likely fail to work.
|
|
|
|
<sect1>The `pci=usepirqmask' Argument
|
|
<p>
|
|
This sets the USE_PIRQ_MASK flag during PCI init.
|
|
The kernel will honour the possible IRQ mask
|
|
stored in the BIOS PIR table. This is needed on some systems
|
|
with broken BIOSes, notably some HP Pavilion N5400
|
|
and Omnibook XE3 notebooks. This will have no effect if
|
|
ACPI IRQ routing is enabled.
|
|
|
|
<sect1>The `pci=rom' Argument
|
|
<p>
|
|
This sets the ASSIGN_ROM flag during the probing phase.
|
|
The kernel will assign address space to expansion ROMs.
|
|
Use with caution as certain devices share address
|
|
decoders between ROMs and other resources.
|
|
|
|
|
|
<sect>Boot Arguments for Video Frame Buffer Drivers
|
|
<p>
|
|
The `video=' argument (not avail. in v2.0 kernels)
|
|
is used when the frame buffer device abstraction layer
|
|
is built into the kernel. If that sounds complicated,
|
|
well it isn't really too bad. It basically means that
|
|
instead of having a different
|
|
video program (the X11R6 server) for each brand of video
|
|
card (e.g. XF86_S3, XF86_SVGA, ...), the kernel would have
|
|
a built in driver available for each video card and export
|
|
a single interface for the video program so that only one
|
|
X11R6 server (XF86_FBDev) would be required. This is similar
|
|
to how networking is now - the kernel has drivers available for
|
|
each brand of network card and exports a single network
|
|
interface so that just one version of a network program
|
|
(like Netscape) will work for all systems, regardless of the
|
|
underlying brand of network card.
|
|
|
|
The typical format of this argument is
|
|
<tt>video=name:option1,option2,...</tt>
|
|
where <tt/name/ is the name of a generic option or of a
|
|
frame buffer driver.
|
|
The <tt/video=/ option is passed from <tt>linux/init/main.c</tt>
|
|
into <tt>linux/drivers/video/fbmem.c</tt> for further processing.
|
|
Here it is checked for some generic options before trying to
|
|
match to a known driver name. Once a driver name match is made,
|
|
the comma separated option list is then passed into that particular
|
|
driver for final processing. The list of valid driver names
|
|
can be found by reading down the <tt/fb_drivers/ array in the
|
|
file <tt/fbmem.c/ mentioned above.
|
|
|
|
Information on the options that each driver supports will
|
|
eventually be found in <tt>linux/Documentation/fb/</tt> but
|
|
currently (v2.2) only a few are described there.
|
|
Unfortunately the number
|
|
of video drivers and the number of options for each one
|
|
is content for another document itself and hence
|
|
too much to list here.
|
|
|
|
If there is no Documentation file for your card, you
|
|
will have to get
|
|
the option information directly from the driver. Go to
|
|
<tt>linux/drivers/video/</tt> and look in the appropriate
|
|
<tt/???fb.c/ file (the ??? will be based on the card name).
|
|
In there, search for a function with <tt/_setup/ in its name
|
|
and you should see what options the driver tries to match,
|
|
such as <tt/font/ or <tt/mode/ or...
|
|
|
|
<sect1>The `video=map:...' Argument
|
|
<p>
|
|
This option is used to set/override the console to frame buffer
|
|
device mapping. A comma separated list of numbers sets the mapping,
|
|
with the value of option N taken to be the frame buffer device
|
|
number for console N.
|
|
|
|
<sect1>The `video=scrollback:...' Argument
|
|
<p>
|
|
A number after the colon will set the size of memory allocated
|
|
for the scrollback buffer. (Use Shift and Page Up or Page Down
|
|
keys to scroll.) A suffix of `k' or `K' after the number will
|
|
indicate that the number is to be interpreted as kilobytes
|
|
instead of bytes.
|
|
|
|
<sect1>The `video=vc:...' Argument
|
|
<p>
|
|
|
|
A number, or a range of numbers (e.g. <tt/video=vc:2-5/)
|
|
will specify the first, or the first and last frame
|
|
buffer virtual console(s). The use of this option also
|
|
has the effect of setting the frame buffer console to
|
|
<em/not/ be the default console.
|
|
|
|
<sect>Boot Arguments for SCSI Peripherals.
|
|
<p>
|
|
This section contains the descriptions of the boot args that
|
|
are used for passing information about the installed SCSI
|
|
host adapters, and SCSI devices.
|
|
|
|
<sect1>Arguments for Upper and Mid-level Drivers
|
|
<p>
|
|
The upper level drivers handle all things SCSI, regardless
|
|
of whether they be disk, tape, or CD-ROM.
|
|
The mid level drivers handle things like disks, CD-ROMs and
|
|
tapes without getting into low level host adapter
|
|
device driver specifics.
|
|
|
|
<sect2>Maximum Probed LUNs (`max_scsi_luns=')
|
|
<p>
|
|
Each SCSI device can have a number of `sub-devices' contained
|
|
within itself. The most common example is any of the
|
|
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. But most devices, such as hard disks,
|
|
tape drives and such are only one device, and will be
|
|
assigned to LUN zero.
|
|
|
|
The problem arises with single LUN devices with bad firmware.
|
|
Some poorly designed SCSI devices (old and unfortunately new)
|
|
can not handle being probed for LUNs not equal to zero. They
|
|
will respond by locking up, and possibly taking the whole
|
|
SCSI bus down with them.
|
|
|
|
The kernel has a configuration option that allows you
|
|
to set the maximum number of probed LUNs. The default is to
|
|
only probe LUN zero, to avoid the problem described above.
|
|
|
|
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 eight. To avoid problems as described above, one would
|
|
use n=1 to avoid upsetting such broken devices
|
|
|
|
<sect2>SCSI Logging (`scsi_logging=')
|
|
<p>
|
|
Supplying a non-zero value to this boot argument turns on
|
|
logging of all SCSI events (error, scan, mlqueue, mlcomplete,
|
|
llqueue, llcomplete, hlqueue, hlcomplete). Note that
|
|
better control of which events are logged can be obtained
|
|
via the <tt>/proc/scsi/scsi</tt> interface if you aren't
|
|
interested in the events that take place at boot before
|
|
the <tt>/proc/</tt> filesystem is accessible.
|
|
|
|
<sect2>Parameters for the SCSI Tape Driver (`st=')
|
|
<p>
|
|
Some boot time configuration of the SCSI tape driver can
|
|
be achieved by using the following:
|
|
|
|
<code>
|
|
st=buf_size[,write_threshold[,max_bufs]]
|
|
</code>
|
|
|
|
The first two numbers are specified in units of kB.
|
|
The default <tt/buf_size/ is 32kB, and the maximum size
|
|
that can be specified is a ridiculous 16384kB.
|
|
The <tt/write_threshold/ is the value at which the buffer is
|
|
committed to tape, with a default value of 30kB.
|
|
The maximum number of buffers varies with the number of drives
|
|
detected, and has a default of two. An example usage would be:
|
|
|
|
<code>
|
|
st=32,30,2
|
|
</code>
|
|
|
|
Full details can be found in the <tt/README.st/ file that is
|
|
in the <tt/scsi/ directory of the kernel source tree.
|
|
|
|
<sect1>Arguments for SCSI Host Adapter Drivers
|
|
<p>
|
|
|
|
These are arguments for low level SCSI host device drivers,
|
|
and as such are typically only used by those that compile
|
|
their own kernel with the SCSI driver built in. These
|
|
people are advised to check the source for the latest
|
|
list of options that can be supplied to their driver.
|
|
|
|
<tt/aha152x=/ Adaptec aha151x, aha152x, aic6260, aic6360, SB16-SCSI
|
|
|
|
<tt/aha1542=/ Adaptec aha1540, aha1542
|
|
|
|
<tt/aic7xxx=/ Adaptec aha274x, aha284x, aic7xxx
|
|
|
|
<tt/advansys=/ AdvanSys SCSI Host Adaptors
|
|
|
|
<tt/in2000=/ Always IN2000 Host Adaptor
|
|
|
|
<tt/AM53C974=/ AMD AM53C974 based hardware
|
|
|
|
<tt/BusLogic=/ ISA/PCI/EISA BusLogic SCSI Hosts
|
|
|
|
<tt/eata=/ EATA SCSI Cards
|
|
|
|
<tt/tmc8xx=/ Future Domain TMC-8xx, TMC-950
|
|
|
|
<tt/fdomain=/ Future Domain TMC-16xx, TMC-3260, AHA-2920
|
|
|
|
<tt/ppa=/ IOMEGA Parallel Port / ZIP drive
|
|
|
|
<tt/ncr5380=/ NCR5380 based controllers
|
|
|
|
<tt/ncr53c400=/ NCR53c400 based controllers
|
|
|
|
<tt/ncr53c406a=/ NCR53c406a based controllers
|
|
|
|
<tt/pas16=/ Pro Audio Spectrum
|
|
|
|
<tt/st0x=/ Seagate ST-0x
|
|
|
|
<tt/t128=/ Trantor T128
|
|
|
|
<tt/u14-34f=/ Ultrastor SCSI cards
|
|
|
|
<tt/wd7000=/ Western Digital WD7000 cards
|
|
|
|
|
|
<sect>Hard Disks
|
|
<p>
|
|
This section lists all the boot args associated with standard
|
|
MFM/RLL, ST-506, XT, and IDE disk drive devices.
|
|
Note that both the IDE and the generic ST-506 HD driver
|
|
both accept the `hd=' option.
|
|
|
|
<sect1>IDE Disk/CD-ROM Driver Parameters
|
|
<p>
|
|
The IDE driver accepts a number of parameters, which range
|
|
from disk geometry specifications, to support for advanced or
|
|
broken controller chips. The following is a summary of
|
|
some of the more common boot arguments. For full details, you
|
|
<em/really/ should consult the file <tt/ide.txt/ in the
|
|
<tt>linux/Documentation</tt> directory, from which this
|
|
summary was extracted.
|
|
|
|
<code>
|
|
|
|
"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)
|
|
|
|
</code>
|
|
|
|
The following are valid ONLY on ide0,
|
|
and the defaults for the base,ctl ports must not be altered.
|
|
|
|
<code>
|
|
|
|
"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
|
|
|
|
</code>
|
|
|
|
During the install of some PCMCIA systems, you may be able
|
|
to get detection of your CD-ROM by using:
|
|
<code>
|
|
|
|
"ide2=0x180,0x386" : probe typical PCMCIA IDE interface location
|
|
|
|
</code>
|
|
|
|
Everything else is rejected with a "BAD OPTION" message.
|
|
Also note that there is an implied <tt/ide0=0x1f0 ide1=0x170/
|
|
in the absence of any other ide boot args.
|
|
|
|
<sect1>Old MFM/RLL/Standard ST-506 Disk Driver Options (`hd=')
|
|
<p>
|
|
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, i.e. `hda=', `hdb=' and so on are
|
|
not valid here. The format is as follows:
|
|
|
|
<code>
|
|
hd=cyls,heads,sects
|
|
</code>
|
|
|
|
If there are two disks installed, the above is repeated
|
|
with the geometry parameters of the second disk.
|
|
|
|
<sect1>XT Disk Driver Options (`xd=', `xd_geo=')
|
|
<p>
|
|
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. The probe code for these cards looks for an installed
|
|
BIOS, and if none is present, the probe will not find your card. Or,
|
|
if the signature string of your BIOS is not recognized then it
|
|
will also not be found. In either case, you will then have to use a
|
|
boot argument of the form:
|
|
|
|
<code>
|
|
xd=type,irq,iobase,dma_chan
|
|
</code>
|
|
|
|
The <tt/type/ value specifies the particular manufacturer of the
|
|
card, and are as follows: 0=generic; 1=DTC; 2,3,4=Western Digital,
|
|
5,6,7=Seagate; 8=OMTI. The only difference between multiple types
|
|
from the same manufacturer is the BIOS string used for detection,
|
|
which is not used if the type is specified.
|
|
|
|
The <tt/xd_setup()/ function does no checking on the values, and
|
|
assumes 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:
|
|
|
|
<code>
|
|
xd=2,5,0x320,3
|
|
</code>
|
|
|
|
If the disk geometry that the kernel prints out comes out all
|
|
wrong to what you know the disk is set up as, you can override
|
|
that as well, with:
|
|
|
|
<code>
|
|
xd_geo=cyl_xda,head_xda,sec_xda
|
|
</code>
|
|
|
|
Add another comma and another three CHS values if you are
|
|
silly enough to have two disks on the old hunk of scrap...
|
|
|
|
<sect>The Sound Drivers
|
|
<p>
|
|
|
|
Note that there was a rewrite of a lot of the sound
|
|
core and related drivers. The older stuff is generally
|
|
called `OSS' and the newer is called `ALSA'. The intention
|
|
is to drop the OSS stuff eventually. To avoid name conflict,
|
|
the ALSA stuff generally has `snd-' as a prefix to all
|
|
the boot parameters.
|
|
|
|
Note that each driver has its own
|
|
individual boot argument (very old kernels used a shared
|
|
<tt/sound=/). Also, generally no defaults are set at
|
|
compile time (i.e. you <em>must</em> supply a boot
|
|
argument for older non-PNP ISA cards to be detected.)
|
|
Your best source of information for your card is the files
|
|
in <tt>linux/Documentation/sound/</tt>.
|
|
|
|
<sect1>Individual Sound Device Driver Arguments
|
|
<p>
|
|
|
|
<sect2>ALSA ISA drivers
|
|
<p>
|
|
<tt/snd-dummy=/ Dummy soundcard
|
|
|
|
<tt/snd-mpu401=/ mpu401 UART
|
|
|
|
<tt/snd-mtpav=/ MOTU Midi Timepiece
|
|
|
|
<tt/snd-serial=/ Serial UART 16450/16550 MIDI
|
|
|
|
<tt/snd-virmidi=/ Dummy soundcard for virtual rawmidi devices
|
|
|
|
<tt/snd-ad1816a=/ ADI SoundPort AD1816A
|
|
|
|
<tt/snd-ad1848=/ Generic driver for AD1848/AD1847/CS4248
|
|
|
|
<tt/snd-als100=/ Avance Logic ALS100
|
|
|
|
<tt/snd-azt2320=/ Aztech Systems AZT2320 (and 2316)
|
|
|
|
<tt/snd-cmi8330=/ C-Media's CMI8330
|
|
|
|
<tt/snd-cs4231=/ Generic driver for CS4231 chips
|
|
|
|
<tt/snd-cs4232=/ Generic driver for CS4232 chips
|
|
|
|
<tt/snd-cs4236=/ Generic driver for CS4235/6/7/8/9 chips
|
|
|
|
<tt/snd-dt019x=/ Diamond Technologies DT-019x
|
|
|
|
<tt/snd-es1688=/ Generic ESS AudioDrive ESx688
|
|
|
|
<tt/snd-es18xx=/ Generic ESS AudioDrive ES18xx
|
|
|
|
<tt/snd-gusclassic=/ Gus classic
|
|
|
|
<tt/snd-gusextreme=/ Gus extreme
|
|
|
|
<tt/snd-gusmax=/ Gus Max
|
|
|
|
<tt/snd-interwave=/ Interwave
|
|
|
|
<tt/snd-interwave-stb=/ Interwave
|
|
|
|
<tt/snd-opl3sa2=/ Yamaha OPL3SA2
|
|
|
|
<tt/snd-opti93x=/ OPTi 82c93x based cards
|
|
|
|
<tt/snd-opti92x-cs4231=/ OPTi 82c92x/CS4231
|
|
|
|
<tt/snd-opti92x-ad1848=/ OPTi 82c92x/AD1848
|
|
|
|
<tt/snd-es968=/ ESS AudioDrive ES968
|
|
|
|
<tt/snd-sb16=/ SoundBlaster 16
|
|
|
|
<tt/snd-sbawe=/ SoundBlaster 16 AWE
|
|
|
|
<tt/snd-sb8=/ Old 8 bit SoundBlaster (1.0, 2.0, Pro)
|
|
|
|
<tt/snd-sgalaxy=/ Sound galaxy
|
|
|
|
<tt/snd-wavefront=/ Wavefront
|
|
|
|
<sect2>OSS drivers
|
|
<p>
|
|
|
|
<tt/ad1848=/ AD1848
|
|
|
|
<tt/adlib=/ Adlib
|
|
|
|
<tt/mad16=/ MAD16
|
|
|
|
<tt/pas2=/ ProAudioSpectrum PAS16
|
|
|
|
<tt/sb=/ SoundBlaster
|
|
|
|
<tt/uart401=/ UART 401 (on card chip)
|
|
|
|
<tt/uart6850=/ UART 6850 (on card chip)
|
|
|
|
<tt/opl3=/ Yamaha OPL2/OPL3/OPL4 FM Synthesizer (on card chip)
|
|
|
|
<tt/opl3sa=/ Yamaha OPL3-SA FM Synthesizer (on card chip)
|
|
|
|
<tt/opl3sa2=/ Yamaha OPL3-SA2/SA3 FM Synthesizer (on card chip)
|
|
|
|
<sect2>ALSA PCI Drivers
|
|
<p>
|
|
|
|
<tt/snd-ali5451=/ ALi PCI audio M5451
|
|
|
|
<tt/snd-als4000=/ Avance Logic ALS4000
|
|
|
|
<tt/snd-cmipci=/ C-Media CMI8338 and 8738
|
|
|
|
<tt/snd-cs4281=/ Cirrus Logic CS4281
|
|
|
|
<tt/snd-cs46xx=/ Cirrus Logic Sound Fusion CS46XX
|
|
|
|
<tt/snd-emu10k1=/ EMU10K1 (SB Live!)
|
|
|
|
<tt/snd-ens1370=/ Ensoniq ES1370 AudioPCI
|
|
|
|
<tt/snd-ens1371=/ Ensoniq ES1371 AudioPCI
|
|
|
|
<tt/snd-es1938=/ ESS Solo-1 (ES1938, ES1946, ES1969)
|
|
|
|
<tt/snd-es1968=/ ESS Maestro 1/2/2E
|
|
|
|
<tt/snd-fm801=/ ForteMedia FM801
|
|
|
|
<tt/snd-intel8x0=/ Intel ICH (i8x0) chipsets
|
|
|
|
<tt/snd-maestro3=/ ESS Maestro3/Allegro (ES1988)
|
|
|
|
<tt/snd-korg1212=/ Korg 1212 IO
|
|
|
|
<tt/snd-rme32=/ RME Digi32, Digi32/8 and Digi32 PRO
|
|
|
|
<tt/snd-nm256=/ NeoMagic 256AV and 256ZX
|
|
|
|
<tt/snd-rme96=/ RME Digi96, Digi96/8 and Digi96/8 PRO/PAD/PST
|
|
|
|
<tt/snd-rme9652=/ RME Digi9652 audio interface
|
|
|
|
<tt/snd-hdsp=/ RME Hammerfall DSP
|
|
|
|
<tt/snd-sonicvibes=/ S3 SonicVibes
|
|
|
|
<tt/snd-trident=/ Trident 4DWave DX/NX & SiS SI7018
|
|
|
|
<tt/snd-via82xx=/ VIA South Bridge VT82C686A/B/C, VT8233A/C, VT8235
|
|
|
|
<tt/snd-ymfpci=/ Yamaha DS1/DS1E
|
|
|
|
<tt/snd-ice1712=/ ICEnsemble ICE1712 (Envy24)
|
|
|
|
|
|
<sect>CD-ROMs (Non-SCSI/ATAPI/IDE)
|
|
<p>
|
|
This section lists all the possible boot args pertaining to
|
|
these older CD-ROM devices on proprietary interface cards.
|
|
Note that this does not include SCSI or
|
|
IDE/ATAPI CD-ROMs. See the appropriate section(s) for those
|
|
types of CD-ROMs.
|
|
|
|
Note that most of these CD-ROMs have documentation files that you
|
|
<em/should/ read, and they are all in one handy place:
|
|
<tt>linux/Documentation/cdrom</tt>.
|
|
|
|
<sect1>Old CD-ROM Driver Arguments
|
|
<p>
|
|
|
|
<tt/aztcd=/ Aztech Interface
|
|
|
|
<tt/cdu31a=/ CDU-31A and CDU-33A Sony Interface (Also Old PAS)
|
|
|
|
<tt/sonycd535=/ CDU-535 Sony Interface
|
|
|
|
<tt/gscd=/ GoldStar Interface
|
|
|
|
<tt/isp16=/ ISP16 Interface
|
|
|
|
<tt/mcd=/ Mitsumi Standard Interface
|
|
|
|
<tt/mcdx=/ Mitsumi XA/MultiSession Interface
|
|
|
|
<tt/optcd=/ Optics Storage Interface
|
|
|
|
<tt/cm206=/ Phillips CM206 Interface
|
|
|
|
<tt/sjcd=/ Sanyo Interface
|
|
|
|
<tt/sbpcd=/ SoundBlaster Pro Interface
|
|
|
|
<sect>Serial and ISDN Drivers
|
|
<p>
|
|
|
|
<sect1>The ISDN drivers
|
|
<p>
|
|
|
|
Please see <tt>linux/Documentation/isdn/</tt> for the full
|
|
details of all the options the following ISDN drivers accept.
|
|
|
|
<tt/icn=/ ICN ISDN driver
|
|
|
|
<tt/pcbit=/ PCBIT ISDN driver
|
|
|
|
<tt/teles=/ Teles ISDN driver
|
|
|
|
<sect1>The Serial drivers
|
|
<p>
|
|
Please see <tt>linux/Documentation/</tt> and/or the <tt/README/
|
|
files in <tt>linux/drivers/char</tt> for the full details of
|
|
all the options that the following support.
|
|
|
|
<tt/digi=/ DigiBoard Driver
|
|
|
|
<tt/riscom8=/ RISCom/8 Multiport Serial Driver
|
|
|
|
<tt/baycom=/ Baycom Serial/Parallel Radio Modem
|
|
|
|
<sect>Other Hardware Devices
|
|
<p>
|
|
Any other devices that didn't fit into any of the above categories
|
|
got lumped together here.
|
|
|
|
<sect1>Ethernet Devices (`ether=', `netdev=')
|
|
<p>
|
|
Different drivers make use of different parameters, but they all
|
|
at least share having an IRQ, an I/O port base value, and
|
|
a name. In its most generic form, it looks something like this:
|
|
|
|
<code>
|
|
ether=irq,iobase[,param_1[,param_2,...param_8]]],name
|
|
</code>
|
|
|
|
The first non-numeric argument is taken as the name.
|
|
The <tt/param_n/ values (if applicable) usually have
|
|
different meanings for each different card/driver.
|
|
Typical <tt/param_n/ values are used to specify things
|
|
like shared memory address, interface selection, DMA
|
|
channel and the like.
|
|
|
|
The most common use of this parameter is to force probing
|
|
for a second ethercard, as the default is to only probe
|
|
for one (with 2.4 and older kernels). This can be accomplished
|
|
with a simple:
|
|
|
|
<code>
|
|
ether=0,0,eth1
|
|
</code>
|
|
|
|
Note that the values of zero for the IRQ and I/O base in the
|
|
above example tell the driver(s) to autoprobe.
|
|
|
|
IMPORTANT NOTE TO MODULE USERS: The above will <em/not/ force a
|
|
probe for a second card if you are using the driver(s) as run time
|
|
loadable modules (instead of having them complied into the kernel).
|
|
Most Linux distributions use a bare bones kernel combined with a
|
|
large selection of modular drivers. The <tt/ether=/ only applies
|
|
to drivers compiled directly into the kernel.
|
|
|
|
The Ethernet-HowTo has complete and extensive
|
|
documentation on using multiple cards and on the card/driver
|
|
specific implementation of the <tt/param_n/ values where used.
|
|
Interested readers should refer to the section in that document
|
|
on their particular card for more complete information.
|
|
<url url="http://metalab.unc.edu/mdw/HOWTO/Ethernet-HOWTO.html"
|
|
name="Ethernet-HowTo">
|
|
|
|
<sect1>The Floppy Disk Driver (`floppy=')
|
|
<p>
|
|
There are many floppy driver options, and they are all listed in
|
|
<tt/floppy.txt/ in <tt>linux/Documentation</tt>. There are too
|
|
many options in that file to list here. Instead, only those
|
|
options that may be required to get a Linux install to proceed
|
|
on less than normal hardware are reprinted here.
|
|
|
|
<tt/floppy=0,daring/
|
|
Tells the floppy driver that your floppy controller should be used
|
|
with caution (disables all daring operations).
|
|
|
|
<tt/floppy=thinkpad/
|
|
Tells the floppy driver that you have a Thinkpad. Thinkpads use an
|
|
inverted convention for the disk change line.
|
|
|
|
<tt/floppy=nodma/
|
|
Tells the floppy driver not to use DMA for data transfers.
|
|
This is needed on HP Omnibooks, which don't have a workable
|
|
DMA channel for the floppy driver. This option is also useful
|
|
if you frequently get `Unable to allocate DMA memory' messages.
|
|
Use of `nodma' is not recommended if
|
|
you have a FDC without a FIFO (8272A or 82072). 82072A and
|
|
later are OK). The FDC model is reported at boot.
|
|
You also need at least a 486 to use nodma.
|
|
|
|
<tt/floppy=nofifo/
|
|
Disables the FIFO entirely. This is needed if you get `Bus
|
|
master arbitration error' messages from your Ethernet card (or
|
|
from other devices) while accessing the floppy.
|
|
|
|
<tt/floppy=broken_dcl/
|
|
Don't use the disk change line, but assume that the disk was
|
|
changed whenever the device node is reopened. Needed on some
|
|
boxes where the disk change line is broken or unsupported.
|
|
This should be regarded as a stopgap measure, indeed it makes
|
|
floppy operation less efficient due to unneeded cache
|
|
flushings, and slightly more unreliable. Please verify your
|
|
cable connection and jumper settings if you have any DCL
|
|
problems. However, some older drives, and also some Laptops
|
|
are known not to have a DCL.
|
|
|
|
<tt/floppy=debug/
|
|
Print (additional) debugging messages.
|
|
|
|
<tt/floppy=messages/
|
|
Print informational messages for some operations (disk change
|
|
notifications, warnings about over and underruns, and about
|
|
autodetection).
|
|
|
|
<sect1>The Bus Mouse Driver (`bmouse=')
|
|
<p>
|
|
The busmouse driver only accepts one parameter, that being
|
|
the hardware IRQ value to be used.
|
|
|
|
<sect1>The MS Bus Mouse Driver (`msmouse=')
|
|
<p>
|
|
The MS mouse driver only accepts one parameter, that being
|
|
the hardware IRQ value to be used.
|
|
|
|
<sect1>The Printer Driver (`lp=')
|
|
<p>
|
|
With this boot argument you can tell the printer driver
|
|
what ports to use and what ports <em/not/ to use. The latter comes
|
|
in handy if you don't want the printer driver to claim all available
|
|
parallel ports, so that other drivers (e.g. PLIP, PPA) can use
|
|
them instead.
|
|
|
|
The format of the argument is multiple i/o, IRQ pairs. For example,
|
|
<tt/lp=0x3bc,0,0x378,7/ would use the port at <tt/0x3bc/ in IRQ-less
|
|
(polling) mode, and use IRQ 7 for the port at <tt/0x378/. The port
|
|
at <tt/0x278/ (if any) would not be probed, since autoprobing only
|
|
takes place in the absence of a <tt/lp=/ argument. To disable the
|
|
printer driver entirely, one can use <tt/lp=0/.
|
|
|
|
<sect1>The Parallel port IP driver (`plip=')
|
|
<p>
|
|
|
|
Using <tt>plip=timid</tt> will tell the plip driver to avoid
|
|
any ports that appear to be in use by other parallel port
|
|
devices. Otherwise you can use <tt>plip=parportN</tt> where
|
|
<tt>N</tt> is a non-zero integer indicating the parallel
|
|
port to use. (Using <tt>N</tt>=0 will disable the plip driver.)
|
|
|
|
<sect>Copying, Translations, Closing, etc.
|
|
<p>
|
|
Hey, you made it to the end! (Phew...) Now just the legal stuff.
|
|
|
|
<sect1>Copyright and Disclaimer<label id="copyright">
|
|
<p>
|
|
This document is Copyright (c) 1995-1999 by Paul Gortmaker.
|
|
Copying and redistribution is allowed under the conditions as
|
|
outlined in the Linux Documentation Project Copyright, available
|
|
from where you obtained this document, OR as outlined in the
|
|
GNU General Public License, version 2 (see linux/COPYING).
|
|
|
|
This document is <em/not/ gospel. However, it is probably the most
|
|
up to date info that you will be able to find. Nobody is responsible
|
|
for what happens to your hardware but yourself. If your stuff
|
|
goes up in smoke, or anything else bad happens,
|
|
we take no responsibility. ie. THE AUTHOR IS NOT RESPONSIBLE
|
|
FOR ANY DAMAGES INCURRED DUE TO ACTIONS TAKEN BASED ON THE
|
|
INFORMATION INCLUDED IN THIS DOCUMENT.
|
|
|
|
A hint to people considering doing a translation. First,
|
|
translate the SGML source (available via FTP from the HowTo
|
|
main site) so that you can then generate other output formats.
|
|
Be sure to keep a copy of the original English SGML source that
|
|
you translated from! When an updated HowTo is released,
|
|
get the new SGML source for that version, and then a simple
|
|
<tt/diff -u old.sgml new.sgml/ will show you exactly what has
|
|
changed so that you can easily incorporate those changes into
|
|
your translated SMGL source without having to re-read or
|
|
re-translate everything.
|
|
|
|
If you are intending to incorporate this document into a
|
|
published work, please make contact (via e-mail) so that
|
|
you can be supplied with the most up to date information
|
|
available. In the past, out of date versions of the Linux
|
|
HowTo documents have been published, which caused the developers
|
|
undue grief from being plagued with questions that were already
|
|
answered in the up to date versions.
|
|
|
|
<sect1>Closing
|
|
<p>
|
|
If you have found any glaring typos, or outdated info in this
|
|
document, please let me know. It is easy to overlook stuff,
|
|
as the kernel (and the number of drivers) is huge compared
|
|
to what it was when I started this.
|
|
|
|
Thanks,
|
|
|
|
Paul Gortmaker, <tt/p_gortmaker @ yahoo.com/
|
|
|
|
</article>
|