LDP/LDP/howto/linuxdoc/BootPrompt-HOWTO.sgml

<!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.

TODO:

	I'm considering dropping device driver args since pretty
	much everybody uses modules, and the hackers that don't 
	will UTSL anyway.  Not to mention that an amalgamation
	of module args and boot args is in the works for 2.5.x.

-->


<article>

<title>The Linux BootPrompt-HowTo
<author>by Paul Gortmaker. 
<date>v1.3, Sept 4, 2001

<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. This includes all kernel and device parameters.
	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 a limited 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.

	However, if you just copy a kernel image directly to a floppy,
	(e.g. <tt> cp zImage /dev/fd0</tt>) then
	you are not given a chance to specify any arguments to that
	kernel. So most Linux users will use software like <em/LILO/
	or <em/loadlin/ that takes care of handing these arguments
	to the kernel, and then booting it.

	This present revision covers kernels up to and including v2.4.9.

	The BootPrompt-Howto is by:
<quote>
	Paul Gortmaker, <tt/p_gortmaker@yahoo.com/
</quote>

	This document is Copyright (c) 1995-2001 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 
	automatic detection is currently not available (e.g. some old ISA
	devices).

	<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>.
	

<sect1>Related Documentation
<p>
	The most up-to-date documentation will always be the kernel
	source itself. Hold on! Don't get scared. You don't need to
	know any programming to read the comments in the source files.
	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.

	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.
	(If you can't find the file in question, then make use of 
	the <tt/find/ and <tt/locate/ commands.)

	The next best thing will be any 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/).

	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>The Linux Newsgroups<label id="news">
<p>
	If you have questions about passing boot arguments to the
	kernel, please check this document first. If this and the
	related documentation mentioned above does not answer your
	question(s) then you can try the Linux newsgroups.
	General questions on how to configure your system
	should be directed to the comp.os.linux.setup newsgroup.
	We ask that you <em/please/ respect this general guideline
	for content, and don't cross-post your request to other groups.

	Of course you should try checking the group before blindly
	posting your question, as it may even be a Frequently Asked 
	Question (a FAQ).
	A quick browse of the Linux FAQ before posting is a <em/good/
	idea. You should be able to find the FAQ somewhere close to
	where you found this document.  If it is not a FAQ then
	use newsgroup archives, such as those 
	at <tt>http://www.dejanews.com</tt> to quickly search years
	worth of postings for your topic. Chances are someone
	else has already asked (and another person answered!) the question
	that you now have.

<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>General Notation
<p>
	When giving examples of boot arguments for device drivers
	you will commonly see the following given as parameters
	where numbers matching your particular system will need to be used.

	<tt/io/ or <tt/iobase/ -- the first I/O port that the device occupies.
	These are specified in hexidecimal notation, and usually lie
	in the range from <tt/0x200/ to <tt/0x3ff/ for ISA devices.
	Lower case is usually used in hex numbers with Linux.

	<tt/irq/ -- the hardware interrupt that the device is configured
	to use. Valid values will be dependent on the card in question,
	but will usually be 5, 7, 9, 10, 11, 12, and 15. The other
	values are usually used for common peripherals like IDE hard
	disks, floppies, serial ports, etc.

	<tt/dma/ -- the DMA (Direct Memory Access) channel that the
	card may use. Typically only applies to bus-mastering cards.
	PCI and VLB cards are native bus-masters, and do not require
	and ISA DMA channel. Some sound cards use two DMA channels,
	an 8 bit one and a 16 bit one.

<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&lsqb;=value_1&rsqb;&lsqb,value_2&rsqb;...&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 `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/.

<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=&lt;offset&gt;' 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=' 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.)

	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.

<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.

<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 `mem=' Argument
<p>
	This argument has two 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 second (and hardly used) purpose is to specify
	<tt/mem=nopentium/ which tells the Linux kernel to not use
	the 4MB page table performance feature.

	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.
	If you have more than 64MB of RAM installed, 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/".

<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>Boot Arguments for Network Settings with NFS Root Filesystem
<p>
	Linux supports systems such as diskless workstations via
	having their root filesystem as NFS (Network FileSystem).
	These arguments are used to tell the diskless workstation
	which machine it is to get its system from. 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 `nfsroot=' Argument
<p>
	This argument tells the kernel which machine, what directory
	and what NFS options to use for the root filesystem. The form
	of the argument is as follows:

<code>
	nfsroot=&lsqb;<server-ip>:&rsqb;<root-dir>&lsqb;,<nfs-options>&rsqb;
</code>

  If the nfsroot parameter is not given on the command line, the default
  `/tftpboot/&percnt;s' will be used. The other options are as follows:

	&lt;server-ip&gt; --
		Specifies the IP address of the NFS server. If this field
		is not given, the default address as determined by the
		nfsaddrs variable (see below) is used. One use of this
		parameter is for example to allow using different servers
		for RARP and NFS. Usually you can leave this blank.

	&lt;root-dir&gt; --
		Name of the directory on the server to mount as root. If
		there is a `&percnt;s' token in the string, the token will be
		replaced by the ASCII-representation of the client's IP
		address.

	&lt;nfs-options&gt; --
		Standard NFS options. All options are separated by commas.
		If the options field is not given, the following defaults
		will be used:

<verb>
        port            = as given by server portmap daemon
        rsize           = 1024
        wsize           = 1024
        timeo           = 7
        retrans         = 3
        acregmin        = 3
        acregmax        = 60
        acdirmin        = 30
        acdirmax        = 60
        flags           = hard, nointr, noposix, cto, ac
</verb>

<sect2>The `ip=' or `nfsaddrs=' Argument
<p>
	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. The form is as follows:

<code>
	nfsaddrs=<my-ip>:<serv-ip>:<gw-ip>:<netmask>:<name>:<dev>:<auto>
</code>

	&lt;my-ip&gt; --
		IP address of the client. If empty, the address will either
                be determined by RARP or BOOTP. What protocol is used de-
                pends on what has been enabled during kernel configuration
                and on the &lt;auto&gt; parameter. If this parameter is not
                empty, neither RARP nor BOOTP will be used.

	&lt;serv-ip&gt; --
		IP address of the NFS server. If RARP is used to determine
		the client address and this parameter is NOT empty only
		replies from the specified server are accepted. To use
		different RARP and NFS server, specify your RARP server
		here (or leave it blank), and specify your NFS server in
		the nfsroot parameter (see above). If this entry is blank
		the address of the server is used which answered the RARP
		or BOOTP request.

	&lt;gw-ip&gt; --
		IP address of a gateway if the server in on a different
		subnet. If this entry is empty no gateway is used and the
		server is assumed to be on the local network, unless a
		value has been received by BOOTP.

	&lt;netmask&gt; --
		Netmask for local network interface. If this is empty,
		the netmask is derived from the client IP address,
		unless a value has been received by BOOTP.

	&lt;name&gt; --
		Name of the client. If empty, the client IP address is
		used in ASCII-notation, or the value received by BOOTP.

	&lt;dev&gt; --
		Name of network device to use. If this is empty, all
		devices are used for RARP requests, and the first one
		found for BOOTP. For NFS the device is used on which
		either RARP or BOOTP replies have been received. If
		you only have one device you can safely leave this blank.

	&lt;auto&gt; --
		Method to use for autoconfiguration. If this is either
		`rarp' or `bootp' or `dhcp' the specified protocol 
		is being used.
		If the value is `both' or empty, both RARP and BOOTP
		protocols are used
		so far as they have been enabled during kernel configuration
		Using 'none' means no autoconfiguration. In this case you
		have to specify all necessary values in the fields before.

	The &lt;auto&gt; parameter can appear alone as the value to the
	nfsaddrs parameter (without all the `:' characters before) in which
	case autoconfiguration is used. However, the `none' value is not
	available in that case.
	
<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 `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 `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>

<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 `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 `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 `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.

	Why would you bother? Some disk controllers with cache memory
	on board can sense a warm reboot, and flush any cached data
	to disk. Upon a cold boot, the card may be reset and the 
	write-back data in your cache card's memory is lost. Others have
	reported systems that take a long time to go through the 
	memory check, and/or SCSI BIOSes that take longer to initialize
	on a cold boot as a good reason to use warm reboots.

<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&lsqb;,iobase,extent&rsqb;...
</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 `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=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=io=' Argument
<p>
	If you get a message like <tt/PCI: Unassigned I/O space for.../
	then you may need to supply an I/O value with this option. 
	From the source:

	``Several BIOS'es forget to assign addresses to I/O ranges.
 	We try to fix it here, expecting there are free addresses
	starting with <tt/0x5800/. Ugly, but until we come with better
	resource management, it's the only simple solution.''

<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=reverse' Argument
<p>
	This option will reverse the ordering of the PCI devices 
	on that PCI bus.

<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 Mid-level Drivers
<p>
	The mid level drivers handle things like disks, CD-ROMs and
	tapes without getting into host adapter 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&lsqb;,write_threshold&lsqb;,max_bufs&rsqb;&rsqb;
</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>
	General notation for this section:

	<tt/scsi-id/ -- the ID that the host adapter uses to identify
	itself on the SCSI bus. Only some host adapters allow you to
	change this value, as most have it permanently specified
	internally. The usual default value is seven, but the Seagate
	and Future Domain TMC-950 boards use six.

	<tt/parity/ -- whether the SCSI host adapter expects the attached
	devices to supply a parity value with all information exchanges.
	Specifying a one indicates parity checking is enabled, and a
	zero disables parity checking. Again, not all adapters will
	support selection of parity behaviour as a boot argument.

<sect2>Adaptec aha151x, aha152x, aic6260, aic6360, SB16-SCSI (`aha152x=')
<p>
	The aha numbers refer to cards and the aic numbers refer to
	the actual SCSI chip on these type of cards, including the
	Soundblaster-16 SCSI.

	The probe code for these SCSI hosts looks for an installed BIOS,
	and if none is present, the probe will not find your card. Then
	you will have to use a boot argument of the form:

	<tt>aha152x=iobase,irq,scsi-id,reconnect,parity</tt>

	Note that if the driver was compiled with debugging enabled,
	a sixth value can be specified to set the debug level.
	The second to fifth values are also optional.

	All the parameters are as described at the top of this section,
	and the <tt/reconnect/ value will allow device disconnect/reconnect
	if a non-zero value is used.
	Note that the parameters must be specified in order, meaning that
	if you want to specify a parity setting, then you will have to
	specify an iobase, irq, scsi-id and reconnect value as well.

<sect2>Adaptec aha154x (`aha1542=')
<p>
	These are the aha154x series cards. The aha1542 series cards
	have an i82077 floppy controller onboard, while the aha1540
	series cards do not. These are busmastering cards, and have
	parameters to set the ``fairness'' that is used to share the
	bus with other devices. The boot argument looks like the following.

<code>
	aha1542=iobase&lsqb;,buson,busoff&lsqb;,dmaspeed&rsqb;&rsqb;
</code>

	Valid <tt/iobase/ values are usually one of:
	<tt/0x130, 0x134, 0x230, 0x234, 0x330, 0x334/.
	Clone cards may permit other values.

	The <tt/buson, busoff/ values refer to the number of microseconds
	that the card dominates the ISA bus. The defaults are 11us on, and
	4us off, so that other cards (such as an ISA LANCE Ethernet card)
	have a chance to get access to the ISA bus.

	The <tt/dmaspeed/ value refers to the rate (in MB/s) at which the
	DMA (Direct Memory Access) transfers proceed at. The default is
	5MB/s. Newer revision cards allow you to select this value as part
	of the soft-configuration, older cards use jumpers. You can use
	values up to 10MB/s assuming that your motherboard is capable of
	handling it. Experiment with caution if using values over 5MB/s.

<sect2>Adaptec aha274x, aha284x, aic7xxx (`aic7xxx=')
<p>
	These boards can accept an argument of the form:

<code>
	aic7xxx=extended,no_reset
</code>

	The <tt/extended/ value, if non-zero, indicates that extended
	translation for large disks is enabled. The <tt/no_reset/
	value, if non-zero, tells the driver not to reset the SCSI bus
	when setting up the host adaptor at boot.

<sect2>AdvanSys SCSI Host Adaptors (`advansys=')
<p>
	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 not effect EISA or PCI probing in any way.
	They are only used for probing ISA and VLB cards.
	In addition, if the driver has been compiled with debugging
	enabled, the level of debugging output can be set by
	adding an <tt/0xdeb&lsqb;0-f&rsqb;/ parameter. The <tt/0-f/
	allows setting the level of the debugging messages to any
	of 16 levels of verbosity.

<sect2>Always IN2000 Host Adaptor (`in2000=')
<p>
	Unlike other SCSI host boot arguments, the IN2000 driver uses
	ASCII string prefixes for most of its integer arguments. Here
	is a list of the supported arguments:

	ioport:addr --
		Where addr is IO address of a (usually ROM-less) card.

	noreset --
		No optional args. Prevents SCSI bus reset at boot time.

	nosync:x --
		x is a bitmask where the 1st 7 bits correspond with
		the 7 possible SCSI devices (bit 0 for device &num;0, etc).
		Set a bit to PREVENT sync negotiation on that device.
		The driver default is sync DISABLED on all devices.

	period:ns --
		ns is the minimum &num; of nanoseconds in a SCSI data transfer
		period. Default is 500; acceptable values are 250 to 1000.

	disconnect:x --
		x = 0 to never allow disconnects, 2 to always allow them.
		x = 1 does 'adaptive' disconnects, which is the default
		and generally the best choice.

	debug:x
		If `DEBUGGING_ON' is defined, x is a bitmask that causes
		various types of debug output to printed - see the DB_xxx
		defines in in2000.h

	proc:x --
		If `PROC_INTERFACE' is defined, x is a bitmask that
		determines how the /proc interface works and what it
		does - see the PR_xxx defines in in2000.h


	Some example usages are listed below:

<code>
	in2000=ioport:0x220,noreset
	in2000=period:250,disconnect:2,nosync:0x03
	in2000=debug:0x1e
	in2000=proc:3
</code>


<sect2>AMD AM53C974 based hardware (`AM53C974=')
<p>
	Unlike other drivers, this one does not use boot parameters
	to communicate i/o, IRQ or DMA channels. (Since the AM53C974
	is a PCI device, there shouldn't be a need to do so.)
	Instead, the parameters are used to communicate the transfer
	modes and rates that are to be used between the host and
	the target device. This is best described with an example:

<code>
	AM53C974=7,2,8,15
</code>

	This would be interpreted as follows: `For communication between
	the controller with SCSI-ID 7 and the device with SCSI-ID 2, a
	transfer rate of 8MHz in synchronous mode with max. 15 bytes
	offset should be negotiated.' More details can be found in
	the file <tt>linux/drivers/scsi/README.AM53C974</tt>
	
<sect2>BusLogic SCSI Hosts (`BusLogic=')
<p>
	With v2.x kernels, the BusLogic driver accepts many parameters.
	(Note the case in the above; upper case B and L!!!).
	There are simply too many to list here.  A complete description
	is tucked away in the middle of the driver
	<tt>linux/drivers/scsi/BusLogic.c</tt> and searching for the
	string <tt/BusLogic=/ will put you right on it.

<sect2>EATA SCSI Cards (`eata=')
<p>
	As of late v2.0 kernels, the EATA drivers will accept a boot
	argument to specify the i/o base(s) to be probed. It is of the
	form:

<code>
	eata=iobase1&lsqb;,iobase2&rsqb;&lsqb;,iobase3&rsqb;...&lsqb;,iobaseN&rsqb;
</code>

	The driver will probe the addresses in the order that they are
	listed.


<sect2>Future Domain TMC-8xx, TMC-950 (`tmc8xx=')
<p>
	The probe code for these SCSI hosts 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>
	tmc8xx=mem_base,irq
</code>

	The <tt/mem_base/ value is the value of the memory mapped
	I/O region that the card uses. This will usually be one of
	the following values:
        <tt/0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000, 0xde000/.

<sect2>Future Domain TMC-16xx, TMC-3260, AHA-2920 (`fdomain=')
<p>
	The driver detects these cards according to a list of known
	BIOS ROM signatures. For a full list of known BIOS revisions,
	please see <tt>linux/drivers/scsi/fdomain.c</tt> as it has a
	lot of information at the top of that file. If your BIOS is not
	known to the driver, you can use an override of the form:

<code>
	fdomain=iobase,irq&lsqb;,scsi_id&rsqb;
</code>
	
<sect2>IOMEGA Parallel Port / ZIP drive (`ppa=')
<p>
	This driver is for the IOMEGA Parallel Port SCSI adapter
	which is embedded into the IOMEGA ZIP drives. It may also
	work with the original IOMEGA PPA3 device. The boot argument
	for this driver is of the form:

<code>
	ppa=iobase,speed_high,speed_low,nybble
</code>

	with all but iobase being optionally specified values. If you
	wish to alter any of the three optional parameters, you
	are advised to read <tt>linux/drivers/scsi/README.ppa</tt>
	for details of what they control.

<sect2>NCR5380 based controllers (`ncr5380=')
<p>
	Depending on your board, the 5380 can be either i/o mapped
	or memory mapped. (An address below 0x400 usually implies
	i/o mapping, but PCI and EISA hardware use i/o addresses
	above 0x3ff.) In either case, you specify the address, the
	IRQ value and the DMA channel value. An example for an i/o
	mapped card would be: <tt/ncr5380=0x350,5,3/. If the card
	doesn't use interrupts, then an IRQ value of 255 (<tt/0xff/)
	will disable interrupts. An IRQ value of 254 means to
	autoprobe. More details can be found in the file
	<tt>linux/drivers/scsi/README.g_NCR5380</tt>

<sect2>NCR53c400 based controllers (`ncr53c400=')
<p>
	The generic 53c400 support is done with the same driver as
	the generic 5380 support mentioned above. The boot argument is
	identical to the above with the exception that no DMA channel
	is used by the 53c400.

<sect2>NCR53c406a based controllers (`ncr53c406a=')
<p>
	This driver uses a boot argument of the form:

<code>
	ncr53c406a=PORTBASE,IRQ,FASTPIO
</code>

	where the IRQ and FASTPIO parameters are optional. An interrupt
	value of zero disables the use of interrupts. Using a value of
	one for the FASTPIO parameter enables the use of <tt/insl/ and
	<tt/outsl/ instructions instead of the single-byte <tt/inb/
	and <tt/outb/ instructions. The driver can also use DMA as
	a compile-time option.

<sect2>Pro Audio Spectrum (`pas16=')
<p>
	The PAS16 uses a NCR5380 SCSI chip, and newer models support
	jumper-less configuration. The boot argument is of the form:

<code>
	pas16=iobase,irq
</code>

	The only difference is that you can specify an IRQ value of
	255, which will tell the driver to work without using interrupts,
	albeit at a performance loss. The <tt/iobase/ is usually <tt/0x388/.

<sect2>Seagate ST-0x (`st0x=')
<p>
	The probe code for these SCSI hosts 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>
	st0x=mem_base,irq
</code>

	The <tt/mem_base/ value is the value of the memory mapped
	I/O region that the card uses. This will usually be one of
	the following values:
        <tt/0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000, 0xde000/.

<sect2>Trantor T128 (`t128=')
<p>
	These cards are also based on the NCR5380 chip, and accept
	the following options:

<code>
	t128=mem_base,irq
</code>

	The valid values for <tt/mem_base/ are as follows:
	<tt/0xcc000, 0xc8000, 0xdc000, 0xd8000/.

<sect2>Ultrastor SCSI cards (`u14-34f=')
<p>
	Note that there appears to be two independent drivers
	for this card, namely <tt/CONFIG_SCSI_U14_34F/ that uses
	<tt/u14-34f.c/ and <tt/CONFIG_SCSI_ULTRASTOR/ that uses
	<tt/ultrastor.c/. It is the u14-34f one that (as of late 
	v2.0 kernels) accepts a boot argument of the form:

<code>
	u14-34f=iobase1&lsqb;,iobase2&rsqb;&lsqb;,iobase3&rsqb;...&lsqb;,iobaseN&rsqb;
</code>

	The driver will probe the addresses in the order that they are
	listed.

<sect2>Western Digital WD7000 cards (`wd7000=')
<p>
	The driver probe for the wd7000 looks for a known BIOS ROM
	string and knows about a few standard configuration settings.
	If it doesn't come up with the correct values for your card,
	or you have an unrecognized BIOS version, you can use
	a boot argument of the form:

<code>
	wd7000=irq,dma,iobase
</code>
	

<sect1>SCSI Host Adapters that don't Accept Boot Args
<p>
	At present, the following SCSI cards do not make use of any
	boot-time parameters. In some cases, you can <em/hard-wire/
	values by directly editing the driver itself, if required.

<verb>
	Adaptec aha1740 (EISA probing),
	NCR53c7xx,8xx (PCI, both drivers)
	Qlogic Fast (0x230, 0x330)
	Qlogic ISP (PCI)
</verb>

<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
	all the possible 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>

	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>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=')
<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>

<sect>The Sound Drivers 
<p>

	With the sound driver(s) compiled into older kernels, 
	it was virtually impossible to change the parameters that
	were selected at compile time. Now, each driver has an 
	individual boot argument, and 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.)
	If information on your card is not here then check the files
	in <tt>linux/Documentation/sound/</tt>.  
	You can typically use -1 for unused parameters
	or to disable various things like the 16 bit DMA channel(s).

<sect1>The AD1848 (`ad1848=')
<p>
	This takes an argument of the form:

	<tt>ad1848=io,irq,dma,dma2,type</tt>

<sect1>The Adlib (`adlib=')
<p>
	This takes an argument of the form:

	<tt>adlib=io</tt>

<sect1>The MAD16 (`mad16=')
<p>
	This takes an argument of the form:

	<tt>mad16=io,irq,dma,dma16,mpu_io,mpu_irq</tt>.


<sect1>The ProAudioSpectrum PAS16 (`pas2=')
<p>
	This takes an argument of the form:

	<tt>pas2=io,irq,dma,dma2,sbio,sbirq,sbdma,sbdma16</tt>

	where the <tt>sb</tt> prefixed values are for the SoundBlaster
	emulation that the PAS16 provides. 
	You should also use the <tt>sb=</tt> argument with the
	same values given for the SoundBlaster emulation.

<sect1>The SoundBlaster (`sb=')
<p>
	This takes an argument of the form:

        <tt>sb=io,irq,dma,dma2</tt>.

<sect1>The UART 401 (`uart401=')
<p>
	This takes an argument of the form:

	<tt>uart401=io,irq</tt>.

<sect1>The UART 6850 (`uart6850=')
<p>
	This takes an argument of the form:

	<tt>uart6850=io,irq</tt>.

<sect1>The Yamaha OPL2/OPL3/OPL4 FM Synthesizer (`opl3=')
<p>
	This argument expects an I/O address only, and the most
	common one (for ISA cards) is <tt>opl3=0x388</tt>.
	
<sect1>The Yamaha OPL3-SA FM Synthesizer (`opl3sa=')
<p>
	This takes an argument of the form:

	<tt>opl3sa=io,irq,dma,dma2,mpu_io,mpu_irq</tt>.

<sect1>The Yamaha OPL3-SA2/SA3 FM Synthesizer (`opl3sa2=')
<p>
	This takes an argument of the form:

	<tt>opl3sa2=io,irq,dma,dma2,mss_io,mpu_io,ymode,loopback,isapnp,multiple</tt>

<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>The Aztech Interface (`aztcd=')
<p>
	The syntax for this type of card is:

<code>
	aztcd=iobase&lsqb;,magic_number&rsqb;
</code>

	If you set the <tt/magic_number/ to <tt/0x79/ then the driver
	will try and run anyway in the event of an unknown firmware
	version. All other values are ignored.

<sect1>The CDU-31A and CDU-33A Sony Interface (`cdu31a=')
<p>
	This CD-ROM interface is found on some of the Pro Audio
	Spectrum sound cards, and other Sony supplied interface cards.
	The syntax is as follows:

<code>
	cdu31a=iobase,&lsqb;irq&lsqb;,is_pas_card&rsqb;&rsqb;
</code>

	Specifying an IRQ value of zero tells the driver that hardware
	interrupts aren't supported (as on some PAS cards). If your
	card supports interrupts, you should use them as it cuts down
	on the CPU usage of the driver.

	The `is_pas_card' should be entered as `PAS' if using a
	Pro Audio Spectrum card, and otherwise it should not be
	specified at all.

<sect1>The CDU-535 Sony Interface (`sonycd535=')
<p>
	The syntax for this CD-ROM interface is:

<code>
	sonycd535=iobase&lsqb;,irq&rsqb;
</code>

	A zero can be used for the I/O base as a `placeholder'
	if one wishes to specify an IRQ value.

<sect1>The GoldStar Interface (`gscd=')
<p>
	The syntax for this CD-ROM interface is:

<code>
	gscd=iobase
</code>

<sect1>The ISP16 Interface (`isp16=')
<p>
	The syntax for this CD-ROM interface is:

<code>
	isp16=&lsqb;port&lsqb;,irq&lsqb;,dma&rsqb;&rsqb;&rsqb;&lsqb;&lsqb;,&rsqb;drive_type&rsqb;
</code>

	Using a zero for <tt/irq/ or <tt/dma/ means that they are not
	used. The allowable values for <tt/drive_type/ are
	<tt/noisp16, Sanyo, Panasonic, Sony,/ and <tt/Mitsumi/.
	Using <tt/noisp16/ disables the driver altogether.

<sect1>The Mitsumi Standard Interface (`mcd=')
<p>
	The syntax for this CD-ROM interface is:

<code>
	mcd=iobase,&lsqb;irq&lsqb;,wait_value&rsqb;&rsqb;
</code>

	The <tt/wait_value/ is used as an internal timeout value
	for people who are having problems with their drive, and
	may or may not be implemented depending on a compile time
	<tt/DEFINE/.

<sect1>The Mitsumi XA/MultiSession Interface (`mcdx=')
<p>
	At present this `experimental' driver has a setup function,
	but no parameters are implemented yet (as of 1.3.15).
	This is for the same hardware as above, but the driver
	has extended features.

<sect1>The Optics Storage Interface (`optcd=')
<p>
	The syntax for this type of card is:

<code>
	optcd=iobase
</code>

<sect1>The Phillips CM206 Interface (`cm206=')
<p>
	The syntax for this type of card is:

<code>
	cm206=&lsqb;iobase&rsqb;&lsqb;,irq&rsqb;
</code>

	The driver assumes numbers between 3 and 11 are IRQ values,
	and numbers between <tt/0x300/ and <tt/0x370/ are I/O ports,
	so you can specify one, or both numbers, in any order.
	It also accepts `cm206=auto' to enable autoprobing.
	
<sect1>The Sanyo Interface (`sjcd=')
<p>
	The syntax for this type of card is:

<code>
	sjcd=iobase&lsqb;,irq&lsqb;,dma_channel&rsqb;&rsqb;
</code>

<sect1>The SoundBlaster Pro Interface (`sbpcd=')
<p>
	The syntax for this type of card is:

<code>
	sbpcd=iobase,type
</code>

	where <tt/type/ is one of the following (case sensitive)
	strings: `SoundBlaster', `LaserMate', or `SPEA'.
	The I/O base is that of the CD-ROM interface, and <em/not/
	that of the sound portion of the card.

<sect>Serial and ISDN Drivers

<sect1>The ICN ISDN driver (`icn=')
<p>
	This ISDN driver expects a boot argument of the form:

<code>
	icn=iobase,membase,icn_id1,icn_id2
</code>

	where <tt/iobase/ is the i/o port address of the card, <tt/membase/
	is the shared memory base address of the card, and the two
	<tt/icn_id/ are unique ASCII string identifiers.  You only need
	the second identifier when using a 4B double card.

<sect1>The PCBIT ISDN driver (`pcbit=')
<p>
	This boot argument takes integer pair arguments of the form:

<code>
	pcbit=membase1,irq1&lsqb;,membase2,irq2&rsqb;
</code>

	where <tt/membaseN/ is the shared memory base of the N'th card,
	and <tt/irqN/ is the interrupt setting of the N'th card. The
	default is IRQ 5 and membase <tt/0xD0000/.

<sect1>The Teles ISDN driver (`teles=')
<p>
	This ISDN driver expects a boot argument of the form:

<code>
	teles=iobase,irq,membase,protocol,teles_id
</code>

	where <tt/iobase/ is the i/o port address of the card, <tt/membase/
	is the shared memory base address of the card, <tt/irq/ is the
	interrupt channel the card uses, and <tt/teles_id/ is the
	unique ASCII string identifier.

<sect1>The DigiBoard Driver (`digi=')
<p>
	The DigiBoard driver accepts a string of six comma separated
	identifiers or integers.  The 6 values in order are:

<verb>
	Enable/Disable this card
	Type of card: PC/Xi(0), PC/Xe(1), PC/Xeve(2), PC/Xem(3)
	Enable/Disable alternate pin arrangement
	Number of ports on this card
	I/O Port where card is configured (in HEX if using string identifiers)
	Base of memory window (in HEX if using string identifiers)
</verb>

	An example of a correct boot prompt argument (in both
	identifier and integer form) is:

<code>
	digi=E,PC/Xi,D,16,200,D0000
	digi=1,0,0,16,512,851968
</code>

	Note that the driver defaults to an i/o of <tt/0x200/ and 
	a shared memory base of <tt/0xD0000/
	in the absence of a <tt/digi=/ boot argument.  There is no
	autoprobing performed. More details can be found in the file
	<tt>linux/Documentation/digiboard.txt</tt>.

<sect1>The RISCom/8 Multiport Serial Driver (`riscom8=')
<p>
	Up to four boards can be supported by supplying four
	unique i/o port values for each individual board installed.
	Other details can be found in the file
	<tt>linux/Documentation/riscom8.txt</tt>.

<sect1>The Baycom Serial/Parallel Radio Modem (`baycom=')
<p>
	The format of the boot argument for these devices is:

<code>
	baycom=modem,io,irq,options&lsqb;,modem,io,irq,options&rsqb;
</code>

	Using modem=1 means you have the ser12 device, modem=2 means
	you have the par96 device. Using options=0 means use hardware DCD,
	and options=1 means use software DCD. The <tt/io/ and <tt/irq/
	are the i/o port base and interrupt settings as usual.
	There is more details in the file <tt/README.baycom/ which
	is currently in the <tt>/linux/drivers/char/</tt> directory.

<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&lsqb;,param_1&lsqb;,param_2,...param_8&rsqb;&rsqb;&rsqb;,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. 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/README.fd/ in <tt>linux/drivers/block</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>