ch09.xml

<!--<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">-->
<chapter id="LKN-command-line">

<!--

  AO: Some of the options that fix bugs may be obscure. I don't know
  how common the hardware is that requires these options. I'll trust
  you; if you think a lot of readers will benefit by having these
  options, leave them in.

  Production will probably want to alphabetize the options under each
  sect1, and I think that would be a good idea to make them easier to
  find, but we can leave it up to production staff.

-->

<title>Kernel boot command-line parameter reference
<!-- don't put a footnote in a title normally... -->
<footnote>
<para>
The majority of this chapter is based on the in-kernel documentation for the
different kernel boot command line reference options, which were written by the
kernel developers and released under the GPL.
</para>
</footnote>
</title>

<!--

  AO: I thought the lead-in could be better. I just wrote up the
  following as an experiment.

  gkh: looks good, I made a minor edit about the proc stuff, adding sysfs
  to it too.

-->

<para>

There are three ways to pass options to the kernel and thus control
its behavior:

</para>

<orderedlist>

<listitem><para>

When building the kernel. Most of this book discusses these options.

</para></listitem>
<listitem><para>

When starting the kernel. Usually, parameters are passed to the kernel
when it is invoked from a boot file such as the GRUB or LILO
configuration file.

</para></listitem>
<listitem><para>

At run-time, by writing to files in the <filename>/proc</filename> and
<filename>/sys</filename> directories.

</para></listitem>

</orderedlist>

<para>

This chapter describes the second method of passing options. The
chapter breaks the boot-time options into different logical sections.
A number of architecture-specific and individual driver options are
not listed here. For a complete list of all known options, please see
the file <filename>Documentation/kernel-parameters.txt</filename> in
the kernel source tree and the individual architecture-specific
documentation files.

</para>

<!--
<para>
The kernel has a wide variety of different command line options that are
able to control lots of different actions. This chapter documents the
majority of them, breaking them down into different logical sections. A
number of architecture specific and individual driver options are not
listed here. For a complete list of all known options, please see the
kernel file, <filename>Documentation/kernel-parameters.txt</filename>
and the individual architecture specific documentation files.
</para>
-->

<!--

  AO: I assume the following applies to all boot parameters, not just
  module parameters.

  gkh: Yes, you are correct.

-->

<para>
Not all of the listed options are always available. Most are
associated with subsystems, and work only if the kernel is configured
with those subsystems built in. They also depend on the presence of
the hardware with which they are associated.
</para>

<para>
All of these parameters are case-sensitive.
</para>

<!--

  AO: I thought the module behavior deserves its own section. I think
  it would go well at the end of the chapter, but maybe it's important
  enough to put up here at the front.

  gkh:  Yes, a different section is fine.  And yes, I think it is important
  enough to put here.

-->

<sect1>
<title>Module-specific options</title>

<para>
In addition to the options listed in this chapter, parameters for
modules that are built in to the kernel
can also be passed on the command line. (Dynamically loaded modules,
of course, are not in memory when the kernel boots and therefore
cannot be passed parameters at boot time.)
The syntax for passing parameters consisting of
the module name followed by a dot (<literal>.</literal>) and the
parameter.
</para>

<para>

For example, the
<literal>usbcore</literal> module accepts the parameter
<literal>blinkenlights</literal> to display flashing lights
on all supported USB 2.0 hubs (don't ever say the kernel developers
don't have a sense of humor). To set
this parameter when loading the module dynamically, you would enter:
<screen>
$ <userinput>modprobe usbcore blinkenlights=1</userinput>
</screen>
But if the <literal>usbcore</literal> module is built into the kernel,
you achieve the same effect by invoking the kernel with the following
option:
<screen>
usbcore.blinkenlights=1
</screen>
</para>

<para>
Most module options for modules that are built into the kernel can also be
changed at run time by writing to files in the subdirectory named after the
module under the <filename>/sys/module/</filename> directory. Thus, the
<literal>blinkenlights</literal> option is represented by the file
<filename>/sys/module/usbcore/blinkenlights</filename>.
desired.
</para>

</sect1>

<sect1>
<title>Console options</title>

<para>
These options deal with the console or kernel log, where kernel
debugging and error information are displayed.
</para>

<refentry>
  <refnamediv>
    <refname>console</refname>
<!--

  AO: Do you like having periods at the end of the refpurpose
  sentences? Most seem to be sentences, so I put in the periods. We
  could easily remove them if you prefer.

  gkh: I don't really care either way.  I'll leave your changes in.

-->
    <refpurpose>Output console device and options.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para><literal>console=</literal></para>
  </refsynopsisdiv>
  <refsect1>
    <title>Options</title> <!-- Description or Options ?  I like
    options...
AO: Yes, I think "options" is best. -->
    <variablelist>
      <varlistentry>
        <term><literal>tty<replaceable>n</replaceable></literal></term>
        <listitem><para>Use the virtual console device <replaceable>n</replaceable>.</para></listitem>
      </varlistentry>
      <varlistentry>
        <term><literal>ttyS<replaceable>n</replaceable>[,<replaceable>options</replaceable>]</literal></term>
        <term><literal>ttyUSB0[,<replaceable>options</replaceable>]</literal></term> <!-- can have two, hooray -->
        <listitem>
          <para>
	  Use the specified serial port. The options are of the form
	  <replaceable>bbbbpnf</replaceable>, where <replaceable>bbbb</replaceable> is the baud rate, <replaceable>p</replaceable> is parity (<literal>n</literal>,
	  <literal>o</literal>, or <literal>e</literal>), <replaceable>n</replaceable> is number of bits, and <replaceable>f</replaceable> is flow control (<literal>r</literal>
	  for RTS or omitted). Default is <literal>9600n8</literal>.
	  </para>

	  <para>
	  See the file
	  <filename>Documentation/serial-console.txt</filename> for more
	  information on how to use a serial console. If you wish to have
	  access to the kernel console information and do not have a serial
	  port, see the <literal>netconsole</literal> command-line option.
	  </para>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><literal>uart,io,<replaceable>addr</replaceable>[,<replaceable>options</replaceable>]</literal></term>
        <term><literal>uart,mmio,<replaceable>addr</replaceable>[,<replaceable>options</replaceable>]</literal></term>
        <listitem>
          <para>
	  Start an early, polled-mode console on the 8250/16550 UART at the
	  specified I/O port or MMIO address, switching to the specified
	  ttyS device later. The options are the same as for ttyS
	  shown earlier.
<!--

  AO: Do you also have to specify a ttyS option, or does the kernel
  now how to find it automatically?

  gkh: you also have to specify one.  I've edited it to show this.
-->

	  </para>
        </listitem>
      </varlistentry>
    </variablelist>
  </refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>netconsole</refname>
    <refpurpose>Output console data across the network.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>netconsole=</literal>[<replaceable>src-port</replaceable>]<literal>@</literal>[<replaceable>src-ip</replaceable>]<literal>/</literal>[<replaceable>dev</replaceable>]<literal>,</literal>[<replaceable>target-port</replaceable>]<literal>@</literal><replaceable>target-ip</replaceable><literal>/</literal>[<replaceable>target-mac-address</replaceable>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Send kernel console data across the network using UDP
	packets to another machine. Options are:

	<variablelist>

	<varlistentry>
	<term><replaceable>src-port</replaceable></term>
	<listitem>
	<para>Source port for the UDP packets.
	The default value is 6665.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><replaceable>src-ip</replaceable></term>
	<listitem>
	<para>Source IP address of the interface
	to use.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><replaceable>dev</replaceable></term>
	<listitem>
	<para>Network interface to use.
	<literal>eth0</literal> is an example.
	The network interface can also run normal network traffic, because
	the netconsole data is not intrusive and should cause no slowdown
	in other network operations.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><replaceable>target-port</replaceable></term>
	<listitem>
	<para>Port that the logging agent
	will use. The default value is 6666.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><replaceable>target-ip</replaceable></term>
	<listitem>
	<para>IP address for the logging
	agent.
	</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><replaceable>target-mac-address</replaceable></term>
	<listitem>
	<para>Ethernet MAC address
	for the logging agent.
	</para>
	</listitem>
	</varlistentry>
	</variablelist>
	</para>

	<para>
	To listen to this data, the remote machine can use the
	<command>syslogd</command> program, or run the
	<command>netcat</command> program as follows:
	<screen>
	<userinput>netcat -u -l -p </userinput><replaceable>port</replaceable>
	</screen>
	</para>
	<para>
	For more background on how to use this option,
	see the file
	<filename>Documentation/networking/netconsole.txt</filename>.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>debug</refname>
    <refpurpose>Enable kernel debugging.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
<!--

  AO: Does "match" accurately replace "default to"?
  gkh: "set to" is a bit better, changed.

-->
	Cause the kernel log level to be set to the
	debug level, so that all debug messages will be printed to the
	console at boot time.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>quiet</refname>
    <refpurpose>Disable all log messages.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>quiet</literal>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Set the default kernel log level to KERN_WARNING (4), which
	suppresses all messages during boot except extremely serious
	ones. (Log levels are defined under the
	<literal>loglevel</literal> parameter.)
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>earlyprintk</refname>
    <refpurpose>Show early boot messages.
    </refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
<!--

  AO: I thought the brackets weren't placed quite right, and I added
  the keep option.

-->
    <literal>earlyprintk=</literal>[<replaceable>vga</replaceable>|<replaceable>serial</replaceable>][,<literal>ttyS</literal><replaceable>n</replaceable>[,<replaceable>baudrate</replaceable>]][,<literal>keep</literal>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Show kernel log messages that precede the initialization of
	the traditional console.  These messages are typically never seen
	on the console unless you use this option.  Enabling this can be
	very useful for tracking down hardware issues. Currently, the
        option can specify either the
	VGA device or the serial port, but not both at the same time.
	Also, only the <literal>ttyS0</literal> or <literal>ttyS1</literal>
	serial devices will work. Interaction with the standard serial
	driver is not very good, and the VGA output will eventually be
	overwritten by the real console.
	</para>
	<para>
<!--

  AO: Does the following mean that by default the console doesn't
  display the messages that this option displays? Needs a bit of
  explanation.

  gkh: yes, these messages are never seen normally, unless this option is
  selected.  Changed the text a bit to help show this.

-->
	Append <literal>,keep</literal> in order not to disable the
	messages shown by this option when the real kernel console is
	initialized and takes over the system.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>loglevel</refname>
    <refpurpose>Set the default console log level.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>loglevel=</literal><replaceable>level</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Specify the initial console log level. Any log
	messages with levels less than this (that is, of higher priority) will be printed to the
	console, whereas any messages with levels equal to or greater than
    this will not be displayed.
	</para>
	<para>
	The console log level can also be changed by the <command>klogd</command> program, or
	by writing the specified level to the
	<filename>/proc/sys/kernel/printk</filename> file.
	</para>
	<para>
	The kernel log levels are:
	<variablelist>

	<varlistentry>
	<term><literal>0 (KERN_EMERG)</literal></term>
	<listitem>
	<para>The system is unusable.</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>1 (KERN_ALERT)</literal></term>
	<listitem>
	<para>Actions that must be taken care of immediately.</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>2 (KERN_CRIT)</literal></term>
	<listitem>
<!--

  AO: Is critical the same as fatal (this is, the boot is aborted)?

  gkh: No, these are all run-time things.  The machine might still boot fine,
  but something critical happened that needs to be fixed.

-->
	<para>Critical conditions.</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>3 (KERN_ERR)</literal></term>
	<listitem>
	<para>Non-critical error conditions.</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>4 (KERN_WARNING)</literal></term>
	<listitem>
	<para>Warning conditions that should be taken care of.</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>5 (KERN_NOTICE)</literal></term>
	<listitem>
	<para>Normal, but significant events.</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>6 (KERN_INFO)</literal></term>
	<listitem>
	<para>Informational messages that require no action.</para>
	</listitem>
	</varlistentry>

	<varlistentry>
	<term><literal>7 (KERN_DEBUG)</literal></term>
	<listitem>
<!--

  AO: I tried to put in some explanation, but I might be wrong.

  gkh: looks good to me.

-->
	<para>Kernel debugging messages, output by the kernel if the
	developer enabled debugging at compile time.</para>
	</listitem>
	</varlistentry>

	</variablelist>
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>log_buf_len</refname>
    <refpurpose>Set the size of the kernel log buffer.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>log_buf_len=</literal><replaceable>n</replaceable>[<replaceable>KMG</replaceable>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Set the size of the kernel's internal log buffer.
	<replaceable>n</replaceable> must be a power of 2, if not, it will be
	rounded up to be a power of two.
	This value can also be changed by the
	<literal>CONFIG_LOG_BUF_SHIFT</literal> kernel configuration value.
<!--

  AO: Which configuration value?

  gkh: now specified.

-->
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>initcall_debug</refname>
    <refpurpose>Debug the initcall functions in the kernel.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
<!--

  AO: Please define initcalls. Are they simply functions in the kernel
  code called during kernel initialization?

  gkh: yes, that is what they are.  changed.

-->
	Cause the kernel to trace all functions that are called by the
	kernel during initialization of the system as the kernel boots.
	This option is useful for determining
	where the kernel is dying during startup.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>kstack</refname>
    <refpurpose>How many words of the stack to print in kernel oopses.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>kstack=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Specify how many words from the kernel stack should be
	printed in the kernel oops dumps. <replaceable>n</replaceable> is an
	integer value.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>time</refname>
    <refpurpose>Show timing data on every kernel log message.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Cause the kernel to prefix every kernel log message
	with a timestamp.
	</para>
</refsect1>
</refentry>

</sect1>

<sect1>
<title>Interrupt options</title>

<para>
Interrupts are a complex aspect of kernel behavior. The boot-time
options deal mostly with the interface between the kernel and the
hardware that handles interrupts, such as the Intel chip's Advanced
Programmable Interrupt Controller (APIC).
</para>

<refentry>
  <refnamediv>
    <refname>apic</refname>
    <refpurpose>Change the verbosity of the APIC subsystem when booting.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para><literal>apic=</literal>[<replaceable>quiet</replaceable>(default)|<replaceable>verbose</replaceable>|<replaceable>debug</replaceable>]</para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
<!--

  AO: What is the difference between verbose and debug? Does debug
  show more?

  gkh: much more.  stuff that only a developer of the apic code would care
  about.

-->
	Control how much information the APIC subsystem generates when
	booting	the kernel.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>noapic</refname>
    <refpurpose>Do not use any IOAPICs.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Prevent the kernel from using any of the
	IOAPICs that might be present in the system.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>lapic</refname>
    <refpurpose>Enable the local APIC.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Cause the kernel to enable the local APIC even if
	the BIOS had disabled it.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>nolapic</refname>
    <refpurpose>Do not use the local APIC.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Tell the kernel not to use the local APIC.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>noirqbalance</refname>
    <refpurpose>Disable kernel IRQ balancing.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Disable all of the built-in kernel IRQ balancing logic.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>irqfixup</refname>
    <refpurpose>Basic fix to interrupt problems.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	When an interrupt is not handled, search all known interrupt
	handlers for it. This is intended to get systems with badly broken
	firmware running.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>irqpoll</refname>
    <refpurpose>Extended fix to interrupt problems.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	When an interrupt is not handled, search all known interrupt
	handlers for it and also check all handlers on each timer interrupt.
	This is intended to get systems with badly broken firmware running.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>noirqdebug</refname>
    <refpurpose>Disable unhandled interrupt detection.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	By default, the kernel attempts to detect and disable unhandled
	interrupt sources because they can cause problems with the
	responsiveness of the rest of the kernel if left unchecked. This
	option will disable this logic.
	</para>
</refsect1>
</refentry>

</sect1>

<sect1>
<title>Memory options</title>

<para>
The kernel handles memory in many different chunks and categories for
different purposes. These options allow you to tweak the sizes and settings.
</para>

<refentry>
  <refnamediv>
    <refname>highmem</refname>
    <refpurpose>Specify the size of the highmem memory zone.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>highmem=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Force the highmem memory zone to have an exact
	size of <replaceable>n</replaceable> bytes. This will work even on
	boxes that have no highmem zones by default. It can also
	reduce the size of the highmem zone for machines with a lot of
	memory.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>hugepages</refname>
    <refpurpose>Set the number of hugetlb pages.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>hugepages=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
<!--

  AO: I tried to define hugetlb. I think readers can find out most of
  the other memory values on their own.

  gkh: thanks.

-->
	The hugetlb feature lets you configure Linux to use 4MB pages,
	one thousand times the default size.
	If Linux is configured this way, this options sets the maximum
	number of hugetlb pages to be <replaceable>n</replaceable>.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>ihash_entries</refname>
    <refpurpose>Set the number of inode hash buckets.
    </refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>ihash_entries=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Override the default number of hash buckets
	for the kernel's inode cache. Recommended only for kernel
	experts.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>max_addr</refname>
    <refpurpose>Ignore memory.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>max_addr=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Cause the kernel to ignore all physical memory greater than or equal to the physical address
	<replaceable>n</replaceable>.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>mem</refname>
    <refpurpose>Force memory usage.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>mem=</literal><replaceable>n</replaceable>[<replaceable>KMG</replaceable>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Set the specific ammount of memory used by the
	kernel. When used with the <literal>memmap=</literal> option,
	physical address space collisions can be avoided. Without the
	<literal>memmap=</literal> option, this option could cause PCI
	devices to be placed at addresses that belong to unused RAM.
	<replaceable>n</replaceable> specifies the amount of memory to force and
	is measured in units of kilobytes (<literal>K</literal>), megabytes (<literal>M</literal>), or gigabytes (<literal>G</literal>).
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>mem</refname>
    <refpurpose>Disable the use of 4MB pages for kernel memory.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>mem=nopentium</literal>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Disable the use of huge (4MB) pages for kernel memory.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>memmap</refname>
    <refpurpose>Enable setting of an exact E820 memory map.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>memmap=</literal><replaceable>exactmap</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Use a specific memory map. The
	<replaceable>exactmap</replaceable> lines can be
	constructed based on BIOS output or other requirements.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>memmap</refname>
    <refpurpose>Force specific memory to be used.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>memmap=</literal><replaceable>n</replaceable>[<replaceable>KMG</replaceable>]<literal>@</literal><replaceable>start</replaceable>[<replaceable>KMG</replaceable>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Force the kernel to use a specific memory region.
	<replaceable>n</replaceable> is the size of the memory location and
	<replaceable>start</replaceable>is the start location in memory of the
	range. Units can be kilobytes (<literal>K</literal>),
	megabytes (<literal>M</literal>), or gigabytes
	(<literal>G</literal>).
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>noexec</refname>
    <refpurpose>Enable or disable non-executable mappings.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>noexec=</literal>[(<literal>on</literal>|(<literal>off</literal>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Enable or disable the kernel's ability to map sections of
	memory as non-executable. By default, the mapping is enabled (<literal>on</literal>).
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>reserve</refname>
    <refpurpose>Reserve some I/O memory.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>reserve=</literal><replaceable>n</replaceable>[<replaceable>KMG</replaceable>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
<!--

  AO: What are the units for n?

  gkh: same as the others, now changed.

-->
	Force the kernel to ignore some of the I/O memory areas.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>vmalloc</refname>
    <refpurpose>Force the vmalloc area to have a specific size.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>vmalloc=</literal><replaceable>n</replaceable>[<replaceable>KMG</replaceable>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Force vmalloc to have the exact size specified by
	<replaceable>n</replaceable>. This can be used to increase the minimum
	size of the vmalloc area (which is 128 MB on the x86 processor). It
	can also be used to decrease the size and leave more room for
	directly mapped kernel RAM.
<!--

  AO: I'm not talking here about the KMG because I know it's been done
  recently; I'll just put it in at the first instance in each section
  of the chapter.

  gkh: fine with me.

-->
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>norandmaps</refname>
    <refpurpose>Do not use address space randomization.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	By default, the kernel randomizes the address space of all programs
	when they are started. This option disables this feature. It
	is equivalent to writing <literal>0</literal> to the file
	<filename>/proc/sys/kernel/randomize_va_space</filename>.
<!--

  AO: There are only about three places where you talk about /proc
  equivalents to the options here. Are there other options that have
  /proc equivalents? I'd tend to say that, if there are a lot of such
  options, we should just remove the references to /proc. But if there
  are just a few, or if you think a few are particularly important,
  you can leave them in.

  gkh: there are only a very few that have them, so I think they should be
  left in.

-->
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>vdso</refname>
    <refpurpose>Enable or disable the VDSO mapping.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>vdso=</literal>[<literal>0</literal>|<literal>1</literal>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
<!--

  AO: Could you briefly define VDSO?

  gkh: Ugh, it's a complex thing, that I don't fully understand, and is
  probably beyond the scope here.  I've spelled it out now, hopefully that
  will help :)

-->
	Disable (0) or enable (1) the VDSO (Virtual Dynamic Shared Object)
	mapping option.  By default, it is enabled.
<!--

  AO: That's what I assume.
  gkh: yes.

-->

	</para>
</refsect1>
</refentry>

</sect1>

<sect1>
<title>Suspend options</title>

<para>
These options change the way the kernel handles suspension for
power-saving purposes.
</para>

<refentry>
  <refnamediv>
    <refname>resume</refname>
    <refpurpose>Specify the partition device for the suspend image.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>resume=</literal><replaceable>suspend_device</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Tell the kernel which disk device contains the
	suspended kernel image. If the data on the image is a valid kernel
	image created by the software suspend subsystem, it will be loaded
	into memory and the kernel will run it instead of continuing on
	with the normal boot process. <replaceable>suspend_device</replaceable>
	is the kernel device name, which might be different from what
	userspace thinks the device name is, so be careful with this option.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>noresume</refname>
    <refpurpose>Disable resume.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Disable the resume functionality of the kernel. Any
	swap partitions that were being used to hold system images to
	which the kernel could be restored will revert back to
	available swap space.
	</para>
</refsect1>
</refentry>

</sect1>


<sect1>
<title>CPU options</title>

<para>
These options control a wide range of behavior regarding timing,
processor use in multi-processor systems, and other processor issues.
</para>

<refentry>
  <refnamediv>
    <refname>cachesize</refname>
    <refpurpose>Override level 2 CPU cache size detection.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para><literal>cachesize=</literal><replaceable>n</replaceable></para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Sometimes CPU hardware bugs make them report the cache size
	incorrectly. The kernel will attempt to work around and fix known
	problems with most CPUs, but for some CPUs it is not possible to
	determine what the correct size should be. This option provides an
	override for these situations.
	<replaceable>n</replaceable> is measured in units of bytes.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>lpj</refname>
    <refpurpose>Set the loops per jiffy.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>lpg=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Specify the loops per jiffy that should be used by the
	kernel, and thus have the kernel avoid the time-consuming boot-time
	autodetection of this value. If <replaceable>n</replaceable> is
	<literal>0</literal>, the value will be autodetected as usual.
	</para>
	<warning>
	<para>
	On SMP systems, this value will be set on all CPUs, which
	might cause problems if the different CPUs need different settings.
	An incorrect value will cause incorrect delays in the kernel,
	which can lead to unpredictable I/O errors and other breakage.
	Although unlikely, in the extreme case this might damage your
	hardware.
	</para>
	</warning>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>nmi_watchdog</refname>
    <refpurpose>Set the NMI watchdog value.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>nmi_watchdog=</literal>[<literal>0</literal>|<literal>1</literal>|<literal>2</literal>|<literal>3</literal>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
<!--

  AO: 0 and 3 have the same effect and are therefore redundant, but
  what the hell.

  gkh: Not really, they have the same end result, but they do things a bit
  differently.  And yes, I don't know why it's done this way...

-->
	This is a debugging feature that allows the user to override the
	default non-maskable interrupt (NMI) watchdog value. <literal>0</literal> specifies that no
	NMI watchdog should be used. <literal>1</literal> specifies that
	the APIC should be used if present. <literal>2</literal> specifies
	that the local APIC should be used if present.
	<literal>3</literal> means that the NMI watchdog is invalid, so do
	not use it.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>no387</refname>
    <refpurpose>Always use the 387 emulation library.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Always use the 387 math emulation
	library, even if a 387 math coprocessor is present in the system.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>nofxsr</refname>
    <refpurpose>Disable x86 floating-point save and restore.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Disable the x86 floating-point extended register save
	and restore. The kernel will save only legacy floating-point
	registers on a task switch.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>no-hlt</refname>
    <refpurpose>Do not use the <literal>HLT</literal> instruction.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	This option is available because the <literal>HLT</literal>
	instruction does not work correctly for some x86
	processors. This option tells the kernel not to use the instruction.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>mce</refname>
    <refpurpose>Enable the machine check exception feature.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Some processors can check for machine errors
	(usually errors in the hardware). This option turns this subsystem
	on, if it has been built into the kernel configuration.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>nomce</refname>
    <refpurpose>Disable the machine check exception feature.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	 This option turns the subsystem off.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>nosep</refname>
    <refpurpose>Disable x86 SYSENTER/SYSEXIT support.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Disable x86 SYSENTER/SYSEXIT support in the kernel.
	This can cause some system calls to take longer.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>nosmp</refname>
    <refpurpose>Run as a single processor machine.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Tell an SMP kernel to act as a uniprocessor kernel, even on a
	multiprocessor machine.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>notsc</refname>
    <refpurpose>Disable the time stamp counter.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Disable the time stamp counter hardware in the system,
	if present.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>max_cpus</refname>
    <refpurpose>Maximum number of CPUs to use.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>maxcpus=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Specify the maximum number of processors that a SMP kernel
	should use, even if there are more processors present in the system.
	</para>
</refsect1>
</refentry>


</sect1>

<sect1>
<title>Scheduler options</title>

<para>
These options tweak the parameters used to make scheduling
decisions. Most depend on an intimate understanding of how scheduling
works in Linux.
<!--

  AO: An understanding I don't seem to have despite all my reading.

  gkh: Heh, nor do I :)
-->

</para>

<refentry>
  <refnamediv>
    <refname>isolcpus</refname>
    <refpurpose>Isolate CPUs from the kernel scheduler.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
<!--

  AO: I think this syntax works better, as you use elsewhere.

  gkh:  looks good.

-->
    <literal>isolcpus=</literal><replaceable>cpu_number</replaceable>[<literal>,</literal><replaceable>cpu_number</replaceable>,...]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Remove the specified CPUs, as defined by the
	<replaceable>cpu_number</replaceable> values, from the general kernel
	SMP balancing and scheduler algroithms. The only way to move a
	process onto or off an "isolated" CPU is via the CPU affinity syscalls.
	<replaceable>cpu_number</replaceable> begins at
	<literal>0</literal>, so
	the maximum value is 1 less than the number of CPUs on the system.
	</para>
	<para>
	This option is the preferred way to isolate CPUs. The alternative,
	manually setting the CPU mask of all tasks in the system, can cause
	problems and suboptimal load balancer performance.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>migration_cost</refname>
    <refpurpose>Override the default scheduler migrations costs.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>migration_cost=</literal><replaceable>level-1-useconds</replaceable>[<replaceable>level-2-useconds</replaceable>...]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	This is a debugging option that overrides the default scheduler
	migration cost matrix. The numbers specified by
	<replaceable>level-N-useconds</replaceable> are indexed by
	the "CPU domain distance" and are measured in microseconds.
	</para>
	<para>
	An example of this option is
	<literal>migration_cost=1000,2000,3000</literal> for a SMT NUMA
	machine. It sets up an intra-core migration cost of 1 ms, another
	inter-core migration cost of 2 ms, and another internode migration
	cost of 3 ms.
	</para>
	<warning>
	<para>
	Incorrect values can severely degrade scheduler
	performance, so this option should be used only for scheduler
	development, never for production environments.
	</para>
	</warning>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>migration_debug</refname>
    <refpurpose>Verbosity of migration cost auto-detection.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>migration_debug=</literal>[<literal>0</literal>|<literal>1</literal>|<literal>2</literal>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Set the migration cost debug level. If <literal>0</literal>
	is specified, no extra messages will be printed to the kernel log.
	This is the default value. <literal>1</literal> prints some
	information on how the matrix is determined.
	<literal>2</literal> is very verbose and is useful only if you
	use a serial console, as the amount of information will overflow the
	kernel log buffer.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>migration_factor</refname>
    <refpurpose>Multiply or divide the migration costs.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>migration_factor=</literal><replaceable>percent</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Modify the default migration costs by the
	specified <replaceable>percentage</replaceable>.
	This is a debugging option that can be used to proportionally increase or decrease
	the auto-detected migration costs for all entries of the migration
	matrix. For example, <literal>migration_factor=150</literal>
	increases migration costs by 50%, so the scheduler will be less
	eager to migrate cache-hot tasks.
	<literal>migration_factor=80</literal> decreases migration
	costs by 20%, thus making the scheduler will be more eager to
	migrate tasks.
	</para>
	<warning>
	<para>
	Incorrect values can severely degrade scheduler
	performance, so this option should be used only for scheduler
	development, never for production environments.
	</para>
	</warning>
</refsect1>
</refentry>

</sect1>

<sect1>
<title>Ramdisk options</title>

<para>
These options control how the storage of information in memory to
imitate disks (Ramdisks) is done, including init ramdisks that hold
information necessary at some stages of booting.
</para>

<refentry>
  <refnamediv>
    <refname>initrd</refname>
    <refpurpose>Location of initial ramdisk.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>initrd=</literal><replaceable>filename</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Specify where the initial ramdisk for the kernel boot
	is located.
	<!-- FIXME if this chapter gets added back
	Please see <xref linkend="LKN-initramfs" /> for more
	information about kernel ramdisks.
	-->
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>load_ramdisk</refname>
    <refpurpose>Load a kernel ramdisk from a floppy.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>load_ramdisk=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	If <replaceable>n</replaceable> is set to
	<literal>1</literal>, a
	ramdisk is loaded by the kernel at boot time from the floppy
	drive.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>noinitrd</refname>
    <refpurpose>Do not use any initrd.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Do not load any initial ramdisk, even
	if it is configured in other options passed to the kernel.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>prompt_ramdisk</refname>
    <refpurpose>Prompt for the list of ramdisks.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>prompt_ramdisk=1</literal>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Prompt the user for the
	initial ramdisk before attempting to read it from the floppy drive.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>ramdisk_blocksize</refname>
    <refpurpose>Blocksize of the ramdisk.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>ramdisk_blocksize=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Tell the ramdisk driver how many bytes to use per
	block. The default size is 1024.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>ramdisk_size</refname>
    <refpurpose>Size of the ramdisk.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>ramdisk_size=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Specify the size of the initial RAM disk in
	kilobytes. The default size is 4096 (4 MB). This option
	should be used instead of the older
	<literal>ramdisk</literal> command-line option.
	</para>
</refsect1>
</refentry>

</sect1>

<sect1>
<title>Root disk options</title>

<para>
These options control how the kernel finds and handles the filesystem
that contains the root filesystem.
</para>

<refentry>
  <refnamediv>
    <refname>ro</refname>
    <refpurpose>Mount the root device read-only on boot.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	The default for the kernel is to mount the root device as read-only
	at boot time. This option ensures that this is the mode the kernel
	uses. It overrides the <literal>rw</literal> command-line option, if it
	had been specified earlier on the boot command line.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>root</refname>
    <refpurpose>Specify the root filesystem to boot from.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>root=</literal><replaceable>device</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Tell the kernel which disk device the root filesystem
	image is on.
	<replaceable>device</replaceable> can be specified in one of the
	following ways:
	<variablelist>
	<varlistentry>
<!--

  AO: We could use x's instead of n's to represent hex numbers, but I
  think that's getting into fussy detail.

  gkh: agreed.

-->
        <term><replaceable>nnnn</replaceable></term>
        <listitem><para>A device number in hexadecimal represents the major
	and minor number of the device in the internal format that the
	kernel expects. This method is not recommended unless you
	have access to kernel internals.</para></listitem>
      	</varlistentry>
	<varlistentry>
        <term><literal>/dev/nfs</literal></term>
        <listitem><para>Use the NFS disk specified by the
	<literal>nfsroot</literal> boot option as the root disk.
	</para></listitem>
      	</varlistentry>
	<varlistentry>
        <term><literal>/dev/</literal><replaceable>&lt;diskname&gt;</replaceable></term>
        <listitem><para>Use the kernel disk name specified by
	<replaceable>&lt;diskname&gt;</replaceable> as the root disk.
	</para></listitem>
      	</varlistentry>
	<varlistentry>
        <term><literal>/dev/</literal><replaceable>&lt;diskname&gt;&lt;decimal&gt;</replaceable></term>
        <listitem><para>Use the kernel disk name specified by
	<replaceable>&lt;diskname&gt;</replaceable> and the partition specified
	by <replaceable>&lt;decimal&gt;</replaceable> as the root disk.
	</para></listitem>
      	</varlistentry>
	<varlistentry>
        <term><literal>/dev/</literal><replaceable>&lt;diskname&gt;</replaceable><literal>p</literal><replaceable>&lt;decimal&gt;</replaceable></term>
        <listitem><para>Use the kernel disk name specified by
	<replaceable>&lt;diskname&gt;</replaceable> and the partition specified
	by <replaceable>&lt;decimal&gt;</replaceable> as the root disk.  This is
	the same as above, but is needed when
	<replaceable>&lt;diskname&gt;</replaceable> ends with a digit.
<!--

  AO: It seems to me that it is needed if the first version could be
  confusing because another disk exists that ends in a digit and
  matches the specified disk name. Maybe no confusion would ever
  exist.

  gkh: the odds of that happening are pretty slim, otherwise this would
  have been changed because of that :)

-->
	</para></listitem>
      	</varlistentry>
	</variablelist>
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>rootdelay</refname>
    <refpurpose>Time to delay before attempting to mount the root filesystem.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>rootdelay=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Wait <replaceable>n</replaceable>
	seconds before trying to mount the root filesystem.  This can be
	useful if the root filesystem is on a USB or Firewire device, as
	those disk devices take a bit longer to be discovered by the
	kernel.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>rootflags</refname>
    <refpurpose>The root filesystem mount options.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>rootflags=</literal><replaceable>options</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Mount options that the kernel should use in mounting
	the root filesystem.  The <replaceable>options</replaceable> value
	depend on the filesystem type; see the documentation for the
	individual types for details on what is valid.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>rootfstype</refname>
    <refpurpose>The root filesystem type.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>rootfstype=</literal><replaceable>type</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Try to mount the root filesystem
	as this type of filesystem. For instance, <literal>rootfstype=ext3</literal>.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>rw</refname>
    <refpurpose>Mount the root device read-write on boot.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	The default for the kernel is to mount the root device as read-only
	at boot time.  This option mounts the root device as
	read-write instead.
	</para>
</refsect1>
</refentry>

</sect1>

<sect1>
<title>Init options</title>

<para>
The <command>init</command> process is the first to be started by the
kernel and is the ancestor of all other processes. These options
control which program is run and how it is run.
</para>

<refentry>
  <refnamediv>
    <refname>init</refname>
    <refpurpose>Program to run at init time.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>init=</literal><replaceable>filename</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Run the specified binary as the <command>init</command> process instead of the default
	<filename>/sbin/init</filename> program.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>rdinit</refname>
    <refpurpose>Run the <command>init</command> process from the ramdisk.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>rdinit=</literal><replaceable>full_path_name</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Run the program specified by
	<replaceable>full_path_name</replaceable> as the <command>init</command> process.  This file
	must be on the kernel ramdisk instead of on the root filesystem.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>S</refname>
    <refpurpose>Run <command>init</command> in single-user mode.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	The default for the kernel is to run <command>init</command> in multi-user mode.  This
	option runs <command>init</command> in single-user mode instead.
	</para>
</refsect1>
</refentry>

</sect1>

<sect1>
<title>kexec options</title>

<para>
The kexec subsystem is a specialized rebooting feature that allows a
fast reboot and is usually combined with the kdump facility that enables
the previous kernel's memory to be dumped to a safe place for analysis at a
later time. These options modify the kexec subsystem's parameters.
</para>

<refentry>
  <refnamediv>
    <refname>crashkernel</refname>
    <refpurpose>Reserve a portion of physical memory for kexec to use.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para><literal>crashkernel=</literal><replaceable>n</replaceable>[<replaceable>KMG</replaceable>]@<replaceable>start</replaceable>[<replaceable>KMG</replaceable>]</para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	The kexec subsystem likes to have a portion of physical memory
	reserved for it.  This option reserves that memory from the
	rest of the kernel and will switch to use it if the kernel panics.
	<replaceable>n</replaceable> specifies the amount of memory to
	reserve, and
	<replaceable>start</replaceable> specifies the location for this memory
	chunk. Both are measured in units of kilobytes (<literal>K</literal>),
	megabytes (<literal>M</literal>), or gigabytes
	(<literal>G</literal>).
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>elfcorehdr
    </refname>
    <refpurpose>Start of the kernel core image ELF header.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>elfcorhdr=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	The kernel, like every Linux executable, is stored in ELF format.
	This option specifies the physical address where the kernel core image's
	ELF header starts.  This is used by kexec to find the kernel when
	booting the secondary kernel image.
	</para>
</refsect1>
</refentry>

</sect1>

<sect1>
<title>RCU options</title>

<para>
Read Copy Update (RCU) is a portion of the kernel that handles mutual exclusion for
a variety of subsystems in a lock-less manner.  There are a number of
options that can be used to tune RCU in different ways:
</para>

<refentry>
  <refnamediv>
    <refname>rcu.blimit</refname>
    <refpurpose>RCU batch limit.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>rcu.blimit=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Set the maximum number of finished RCU callbacks to
	process in one batch.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>rcu.qhimark</refname>
    <refpurpose>RCU queue high level.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>rcu.qhimark=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Batch limiting is disabled when the number of queued RCU callbacks
	rises above <replaceable>n</replaceable>.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>rcu.qlowmark</refname>
    <refpurpose>RCU queue low level.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>rcu.qlowmark=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Batch limiting is re-enabled when the number of queued RCU callbacks
	falls below <replaceable>n</replaceable>.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>rcu.rsinterval</refname>
    <refpurpose>RCU callback queue length.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>rcu.rsinterval=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Set the number of additional RCU callbacks that should
	bee queued before forcing a reschedule on all CPUs.
	</para>
</refsect1>
</refentry>

</sect1>

<sect1>
<title>ACPI options</title>

<para>
These options control parameters that the Advanced Configuration
and Power Interface (ACPI) subsystem can use.
</para>

<refentry>
  <refnamediv>
    <refname>acpi</refname>
    <refpurpose>ACPI subsystem options.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>acpi=</literal>[<literal>force</literal>|<literal>off</literal>|<literal>noirq</literal>|<literal>ht</literal>|<literal>strict</literal>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	This is the main option for the Advanced Configuration and Power
	Interface (ACPI). Values are:

    <variablelist>

      <varlistentry>
	<term><literal>force</literal></term>
	<listitem><para>Force ACPI to be enabled.
	Can be used to override the kernel configuration option that disabled it.
	</para>
	</listitem>
      </varlistentry>
      <varlistentry>
	<term><literal>off</literal></term>
	<listitem><para>Disable ACPI. Can be used to
	override the kernel configuration option that enabled it.
	</para>
	</listitem>
      </varlistentry>
      <varlistentry>
	<term><literal>noirq</literal></term>
	<listitem><para>Prevent ACPI from being used
	for IRQ routing.
	</para>
	</listitem>
      </varlistentry>
      <varlistentry>
	<term><literal>ht</literal></term>
	<listitem><para>run only enough of the ACPI layer
	to enable HyperThreading on processors that are capable of
	it.
	</para>
	</listitem>
      </varlistentry>
      <varlistentry>
	<term><literal>strict</literal></term>
	<listitem><para>Make the ACPI layer be less
	tolerant of platforms that are not fully compliant with the ACPI
	specification.
	</para>
	</listitem>
      </varlistentry>

    </variablelist>
    </para>

</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>acpi_sleep</refname>
    <refpurpose>ACPI sleep options.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
<!--

  AO: The values are literal, not replaceable, right?
  gkh: yes, sorry.

-->
    <literal>acpi_sleep=</literal>[<literal>s3_bios</literal>]<literal>,</literal>[<literal>s3_mode</literal>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	During S3 resume (which happens after the machine has been suspended
	to RAM), hardware needs to be reinitialized properly.  For most
	devices this is simple, except for video cards, which are normally
	initialized by the BIOS.  The kernel does not have enough
	information to restore the video device, because that information is in
	the BIOS and not accessable at all.  This option lets the kernel
	try to use the ACPI subsystem to restore the video card in
	two different ways.
	</para>
	<para>
	See the file <filename>Documentation/power/video.txt</filename> for
	more information on this option and how to find the proper value
	for your type of hardware.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>acpi_sci</refname>
    <refpurpose>ACPI System Control Interrupt trigger mode.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>acpi_sci=</literal>[<literal>level</literal>|<literal>edge</literal>|<literal>high</literal>|<literal>low</literal>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Set the ACPI System Control Interrupt trigger mode.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>acpi_irq_balance</refname>
    <refpurpose>Enable ACPI IRQ balance.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Cause ACPI to balance the active IRQs.  This
	is the default option when operating in APIC mode.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>acpi_irq_nobalance</refname>
    <refpurpose>Disable ACPI IRQ balance.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Cause ACPI not to move the active IRQs.  This
	is the default option when operating in PIC mode.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>acpi_irq_isa</refname>
    <refpurpose>Mark the listed IRQs as used by ISA.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>acpi_irq_isa=</literal><replaceable>irq</replaceable>[<literal>,</literal><replaceable>irq</replaceable>...]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	If the IRQ balance option is enabled, mark the listed IRQs as used
	by the ISA subsystem.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>acpi_irq_pci</refname>
    <refpurpose>Mark the listed IRQs as used by PCI.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>acpi_irq_pci=</literal><replaceable>irq</replaceable>[<literal>,</literal>[<replaceable>irq</replaceable>...]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	If the IRQ balance option is enabled, mark the listed IRQs as used
	by the PCI subsystem.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>acpi_os_name</refname>
    <refpurpose>Fake the operating system name to ACPI.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>acpi_os_name=</literal><replaceable>name</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Tell the ACPI BIOS that the name of the running operating
	system is <replaceable>name</replaceable>.  This can be useful to spoof
	the BIOS into thinking that Windows is running instead of Linux,
	which can help solve some ACPI issues for older BIOSes.  As an
	example, use the string <literal>Microsoft 2001</literal> to
	spoof the BIOS into thinking that Windows 2001 is running on the
	machine.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>acpi_osi</refname>
    <refpurpose>Disable the _OSI ACPI method.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
<!--

  AO: I put in the brackets because you said the value might be
  absent.
  gkh: yes, thanks.

-->
    <literal>acpi_osi=</literal>[<replaceable>n</replaceable>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	This is actually a binary option despite the integer value.
	If <replaceable>n</replaceable> is absent, ACPI will disable the
	_OSI method.  If <replaceable>n</replaceable> is present, _OSI will not be
	disabled.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>acpi_serialize</refname>
    <refpurpose>Force serialization of AML methods.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Force the serialization of ACPI Machine Language methods.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>acpi_skip_timer_override</refname>
    <refpurpose>Skip interrupt override issues.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Allow the ACPI layer to recognize and ignore IRQ0/pin2
	Interrupt Override issues for broken nForce2 BIOSes that result in
	the XT-PIC timer acting up.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>acpi_dbg_layer</refname>
    <refpurpose>ACPI debug layer.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>acpi_dbg_layer=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Set the ACPI debug layers.
	<replaceable>n</replaceable> is an integer in which each bit indicates a
	different ACPI debug layer.  After the system has booted, the debug layers can
	be set via the <filename>/proc/acpi/debug_layer</filename> file.
	</para>
</refsect1>
</refentry>


<refentry>
  <refnamediv>
    <refname>acpi_fake_ecdt</refname>
    <refpurpose>ECDT workaround.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
<!--

  AO: I'm guessing here.

  gkh: good guess.

-->
	If present, this allows ACPI to workaround BIOS failures when it
	lacks an Embedded Controller Description Table.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>acpi_generic_hotkey</refname>
    <refpurpose>Use generic ACPI hotkey driver.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	This allows the ACPI consolidated generic hotkey driver to override
	the platform-specific driver if one is present.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>acpi_pm_good</refname>
    <refpurpose>Override pmtimer bug detection.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Force the kernel to assume that the machine's
	pmtimer latches its value and always returns good values.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>ec_intr</refname>
    <refpurpose>ACPI Embedded Controller interrupt mode.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>ec_intr=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Specify the ACPI embedded controller interrupt mode.
	If <replaceable>n</replaceable> is <literal>0</literal>, polling
	mode will be used, otherwise interrupt mode will be used.
	Interrupt mode is the default.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>memmap</refname>
    <refpurpose>Mark specific memory as ACPI data.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>memmap=</literal><replaceable>n</replaceable>[<replaceable>KMG</replaceable>]<literal>#</literal><replaceable>start</replaceable>[<replaceable>KMG</replaceable>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Marks a specific location and range of memory as ACPI data.
	<replaceable>n</replaceable> is the size of the memory location and
	<replaceable>start</replaceable>is the start location in memory of the
	range. Both are measured in units of kilobytes (<literal>K</literal>),
	megabytes (<literal>M</literal>), or gigabytes
	(<literal>G</literal>).
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>memmap</refname>
    <refpurpose>Mark specific memory as reserved.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>memmap=</literal><replaceable>n</replaceable>[<replaceable>KMG</replaceable>]<literal>$</literal><replaceable>start</replaceable>[<replaceable>KMG</replaceable>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	This marks a specific location and range of memory as reserved.
	<replaceable>n</replaceable> is the size of the memory location and
	<replaceable>start</replaceable> is the start location in memory of the
	range.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>pnpacpi</refname>
    <refpurpose>Turn PnP ACPI off.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>pnpacpi=off</literal>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Disable the PnP ACPI functionality.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>processor.max_cstate</refname>
    <refpurpose>Limit the processor to a maximum C-state.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>processor.max_cstate=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Limit the processor to a maximum C-state, no matter
	what the ACPI tables say it can support.  <replaceable>n</replaceable>
	is a valid C-state value.  A value of <literal>9</literal>
	overrides any DMI blacklist limit that might be present for
	this processor.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>processor.nocst</refname>
    <refpurpose>Ignore the _CST method for C-states.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Causes the ACPI core to ignore the _CST
	method of determining the processor C-states and use the legacy
	FADT method instead.
	</para>
</refsect1>
</refentry>

</sect1>

<sect1>
<title>SCSI options</title>

<para>
These options specify different parameters the SCSI subsystem can use.
A number of SCSI driver-specific options are also
available; please see the different driver documentation files in the
kernel directory <filename>Documentation/scsi/</filename> for details.
</para>

<refentry>
  <refnamediv>
    <refname>max_luns</refname>
    <refpurpose>Maximum number of SCSI LUNS to probe.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>max_luns=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Specify the maximum number of SCSI LUNS that the system should
	probe. <replaceable>n</replaceable> is an integer from 1 to
	4294967295.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>max_report_luns</refname>
    <refpurpose>Maximum number of SCSI LUNS received.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>max_report_luns=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Specifu the maximum number of SCSI LUNs that the system can
	receive. <replaceable>n</replaceable> is an integer from 1 to 16384.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>scsi_dev_flags</refname>
    <refpurpose>SCSI black/white list.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>scsi_dev_flags=</literal><replaceable>vendor</replaceable><literal>:</literal><replaceable>model</replaceable><literal>:</literal><replaceable>flags</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
<!--

  AO: Is it worth defining flags, or should the user already know them?

  gkh: they should know them if they are modifing this.

-->
	This option lets the user add entries to the SCSI black/white list
	for a specific vendor and model of device.
	</para>
</refsect1>
</refentry>

</sect1>


<sect1>
<title>PCI options</title>

<para>
These options specify different parameters the PCI subsystem can use.
</para>

<refentry>
  <refnamediv>
    <refname>
    </refname>
    <refpurpose>
    </refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>pci=<replaceable>option</replaceable>[,<replaceable>option</replaceable>...]</literal>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
Each <replaceable>option</replaceable> can be one of the following:
    <variablelist>
      <varlistentry>
	<term><literal>off</literal></term>
	<listitem><para>Do not probe for the PCI bus.
	</para></listitem>
	</varlistentry>
	<varlistentry>
	<term><literal>bios</literal></term>
	<listitem><para>Force the use of the PCI BIOS by not accessing the hardware
		directly.  This means that the kernel should trust the BIOS,
		which is not the standard thing to do (as BIOSes are known to
		lie more than they are known to be valid.)  Use this only if
		your machine has a non-standard PCI host bridge and the normal
		boot method is not working properly.
	</para></listitem>
	</varlistentry>
	<varlistentry>
	<term><literal>nobios</literal></term>
	<listitem><para>Do not use the PCI BIOS, but access the hardware directly
		instead.  This is the default method of probing for PCI devices
		in all kernels after 2.6.13.
	</para></listitem>
	</varlistentry>
	<varlistentry>
	<term><literal>conf1</literal></term>
	<listitem><para>Force use of PCI Configuration Mechanism 1 (a way to access PCI
		memory on i386 machines.)
	</para></listitem>
	</varlistentry>
	<varlistentry>
	<term><literal>conf2</literal></term>
	<listitem><para>Force use of PCI Configuration Mechanism 2 (a way to access PCI
		memory on i386 machines.)
	</para></listitem>
	</varlistentry>
	<varlistentry>
	<term><literal>nommconf</literal></term>
	<listitem><para>Disable use of the ACPI MMCONFIG table for PCI configuration.
	</para></listitem>
	</varlistentry>
	<varlistentry>
	<term><literal>nomsi</literal></term>
	<listitem><para>If the PCI_MSI kernel config parameter is enabled, this kernel
		boot option can be used to disable the use of MSI interrupts
		system-wide.
	</para></listitem>
	</varlistentry>
	<varlistentry>
	<term><literal>nosort</literal></term>
	<listitem><para>Do not sort PCI devices according to order given by the PCI
		BIOS. This sorting is done to get a device order compatible
		with much older kernel versions.
	</para></listitem>
	</varlistentry>
	<varlistentry>
	<term><literal>biosirq</literal></term>
	<listitem><para>Use PCI BIOS calls to get the interrupt routing table. These
		calls are known to be buggy on several machines and hang
		these machine when used, but on other machines they are the only way
		to get the interrupt routing table. Try this option if the
		kernel is unable to allocate IRQs or discover secondary PCI
		buses on your motherboard.
	</para></listitem>
	</varlistentry>
	<varlistentry>
	<term><literal>rom</literal></term>
	<listitem><para>Assign address space to expansion ROMs.  Use this with caution
		as certain devices share address decoders between ROMs and
		other resources.
	</para></listitem>
	</varlistentry>
	<varlistentry>
	<term><literal>irqmask=0x</literal><replaceable>nnnn</replaceable></term>
	<listitem><para>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.
	</para></listitem>
	</varlistentry>
	<varlistentry>
	<term><literal>pirqaddr=0x</literal><replaceable>n</replaceable></term>
	<listitem><para>Specify the physical address of the PIRQ table (normally
		generated by the BIOS) if it is outside the
	F0000-100000 (hexadecimal) range.
	</para></listitem>
	</varlistentry>
	<varlistentry>
	<term><literal>lastbus=<replaceable>n</replaceable></literal></term>
	<listitem><para>Scan all buses through bus <replaceable>n</replaceable>. Can be useful if the kernel is
		unable to find your secondary buses and you want to tell it
		explicitly which ones they are.
	</para></listitem>
	</varlistentry>
	<varlistentry>
	<term><literal>assign-busses</literal></term>
	<listitem><para>Always use your own PCI bus numbers, overriding
		whatever the firmware may have done.
	</para></listitem>
	</varlistentry>
	<varlistentry>
	<term><literal>usepirqmask</literal></term>
	<listitem><para>Honor 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.
	</para></listitem>
	</varlistentry>
	<varlistentry>
	<term><literal>noacpi</literal></term>
	<listitem><para>Do not use ACPI for IRQ routing or for PCI scanning.
	</para></listitem>
	</varlistentry>
	<varlistentry>
	<term><literal>routeirq</literal></term>
	<listitem><para>Do IRQ routing for all PCI devices.  This is normally done in
		<literal>pci_enable_device()</literal>, so this option is a
		temporary workaround for broken drivers that don't call it.
	</para></listitem>
	</varlistentry>
	<varlistentry>
	<term><literal>firmware</literal></term>
	<listitem><para>Do not re-enumerate the bus, but instead just use the
		configuration from the bootloader. This is currently used on
		IXP2000 systems where the bus has to be configured a certain
		way for adjunct CPUs.
	</para></listitem>
	</varlistentry>
    </variablelist>
    </para>
</refsect1>
</refentry>
</sect1>

<sect1>
<title>PnP BIOS options</title>

<refentry>
  <refnamediv>
    <refname>noisapnp</refname>
    <refpurpose>Disable the ISA PnP subsystem.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Disable the ISA PnP subsystem, if it has been enabled in the kernel
	configuration.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>pnpbios</refname>
    <refpurpose>PnP BIOS settings.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>pnpbios=</literal>[<literal>on</literal>|<literal>off</literal>|<literal>curr</literal>|<literal>no-curr</literal>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Set the main PnP BIOS settings.  <literal>on</literal>
	enables the PnP BIOS subsystem.  <literal>off</literal> disables
	the PnP BIOS subsystem.  <literal>curr</literal> tells the PnP BIOS
	subsystem to use the current static settings and
	<literal>no-curr</literal> tells the subsystem to probe for dynamic
	settings if possible.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>pnp_reserve_irq</refname>
    <refpurpose>PnP BIOS reserved IRQs.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>pnp_reserve_irq=</literal><replaceable>irq1</replaceable>[<literal>,</literal><replaceable>irq2</replaceable>...]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	List of the IRQs that the PnP BIOS subsystem
	should not use for autoconfiguration.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>pnp_reserve_dma</refname>
    <refpurpose>PnP BIOS reserved DMAs.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>pnp_reserve_dma=</literal><replaceable>dma1</replaceable>[<literal>,</literal><replaceable>dma2</replaceable>...]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	List of the DMAs that the PnP BIOS subsystem
	should not use for autoconfiguration.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>pnp_reserve_io</refname>
    <refpurpose>PnP BIOS reserved I/O ports.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>pnp_reserve_io=</literal><replaceable>io1</replaceable><literal>,</literal><replaceable>size1</replaceable>[<literal>,</literal><replaceable>io2</replaceable><literal>,</literal><replaceable>size2</replaceable>...]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	I/O ports that the PnP BIOS
	subsystem should not use for autoconfiguration.
	Each port is listed by its starting location and size.
<!--

  AO: I'm not sure this is right because I don't know how a port can
  have a size.

  gkh: yes it is, and ports can have a size that says how big it is.
-->
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>pnp_reserve_mem</refname>
    <refpurpose>PnP BIOS reserved memory regions.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>pnp_reserve_mem=</literal><replaceable>mem1</replaceable><literal>,</literal><replaceable>size1</replaceable>[<literal>,</literal><replaceable>mem2</replaceable><literal>,</literal><replaceable>size2</replaceable>...]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Memory regions that the PnP BIOS
	subsystem should not use for autoconfiguration.
	Each region is listed by its starting location and size.
	</para>
</refsect1>
</refentry>

</sect1>


<sect1>
<title>SELinux options</title>

<para>
These options change some fundamental aspects of SELinux startup.
</para>

<refentry>
  <refnamediv>
    <refname>checkreqprot</refname>
    <refpurpose>Set the initial checkreqprot flag value.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>checkreqprot=</literal>[<literal>0</literal>|<literal>1</literal>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Set the initial checkreqprot flag value.  <literal>0</literal>
	means that the check protection will be applied by the kernel and
	will include any implied execute protection.
	<literal>1</literal> means that the check protection is requested
	by the application.  The default value is set by a kernel
	configuration option.
	</para>
	<para>
	The value can be changed at runtime via the
	<filename>/selinux/checkreqprot</filename> file.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>enforcing</refname>
    <refpurpose>Set the initial enforcing status.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>enforcing=</literal>[<literal>0</literal>|<literal>1</literal>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Specify whether SELinux enforces its rules upon boot.  <literal>0</literal>
	means that SELinux will just log policy violations but wil not
	deny access to anything.  <literal>1</literal> means that the
	enforcement will be fully enabled with denials as well as logging.  The
	default value is <literal>0</literal>.
	</para>
	<para>
	The value can be changed at runtime via the
	<filename>/selinux/enforce</filename> file.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>selinux</refname>
    <refpurpose>Enable or disable SELinux at boot time.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>selinux=</literal>[<literal>0</literal>|<literal>1</literal>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	This option allows SELinux to be enabled
	(<literal>1</literal>) or disabled (<literal>0</literal>) to
	boot time.  The default value is set by a kernel configuration
<!--

  AO: I took out "at boot time." The option you're discussing right
  now is the boot-time option.

  gkh: fine.

-->
	option.
	</para>
	<para>
	If SELinux is enabled at boot time, the
	<filename>/selinux/disable</filename> file can be used later to
	disable it prior to the initial policy load.
	</para>
</refsect1>
</refentry>


<refentry>
  <refnamediv>
    <refname>selinux_compat_net</refname>
    <refpurpose>Set the network control model.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>selinux_compat_net=</literal>[<literal>0</literal>|<literal>1</literal>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Set the initial value for the SELinux network control model.
	<literal>0</literal> uses the new secmark-based packet
	controls, and <literal>1</literal> uses the legacy packet
	controls.	<replaceable>0</replaceable> is the default and preferred value.
	</para>
	<para>
	This value can be changed at runtime via the
	<filename>/selinux/compat_net</filename> file.
	</para>
</refsect1>
</refentry>


</sect1>

<sect1>
<title>Network options</title>

<para>
These options control low-level aspects of the networking subsystem.
</para>

<refentry>
  <refnamediv>
    <refname>netdev</refname>
    <refpurpose>Set various network device parameters.
    </refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>netdev=</literal>[<replaceable>irq</replaceable>],[<replaceable>io</replaceable>],[<replaceable>mem_start</replaceable>],[<replaceable>mem_end</replaceable>],[<replaceable>name</replaceable>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Specify network device parameters, which are
	specific to the driver used by the network
	device. Some drivers' source files document the applicable options.
	This option does not usually apply to PCI, USB, or other
	plug-and-play network devices.  It is intented for use only on
	devices that can not discover their own resource assignments.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>rhash_entries</refname>
    <refpurpose>Set the number of route cache hash buckets.
    </refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>dhash_entries=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	This option lets you override the default number of hash buckets
	for the kernel's route cache. Recommended only for kernel network
	experts.
	are doing.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>shapers</refname>
    <refpurpose>Set the maximum number of network shapers.
    </refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>shapers=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	This option lets you set the maximum number of network shapers
	that the kernel can use.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>thash_entries</refname>
    <refpurpose>Set the number of TCP connection hash buckets.
    </refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>thash_entries=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	This option lets you override the default number of hash buckets for
	the kernel's TCP connection cache.
	</para>
</refsect1>
</refentry>

</sect1>


<sect1>
<title>NFS options</title>

<para>
These options control Network File System startup.
</para>

<refentry>
  <refnamediv>
    <refname>lockd.nlm_grace_period</refname>
    <refpurpose>Assign a grace period to the lock manager.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>lockd.nlm_grace_period=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Set the NFS lock manager grace period.
	<replaceable>n</replaceable> is measured
	in seconds.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>lockd.nlm_tcpport</refname>
    <refpurpose>Assign a TCP port to the lock manager.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>lockd.nlm_tcpport=</literal><replaceable>port</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Set the TCP port that the NFS lock manager should use.
	<replaceable>port</replaceable> must be a valid TCP port value.
<!--

  AO: Is there a default?

  gkh: Well, 0, but you should probably specify something else for this to
  work properly, so no, no real default value.

-->
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>lockd.nlm_timeout</refname>
    <refpurpose>Assign a new timeout value to the lock manager.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>lockd.nlm_timeout=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Override the default time value for the NFS lock manager.
	<replaceable>n</replaceable> is measured in seconds.  If this
	option is not specified the default of 10 seconds will be used.
<!--

  AO: Default?

  gkh:  Oops, yes there is, now specified.
-->
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>lockd.nlm_udpport</refname>
    <refpurpose>Assign a UDP port to the lock manager.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>lockd.nlm_udpport=</literal><replaceable>port</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Set the UDP port that the NFS lock manager should use.
	<replaceable>port</replaceable> must be a valid UDP port value.
<!--

  AO: Default?

  gkh: nope, same as lockd.nlm_tcpport in that 0 will be used, but that
  will not work.

-->
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>nfsroot</refname>
    <refpurpose>Specifies the NFS root filesystem.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>nfsroot=</literal>[<replaceable>server-ip</replaceable><literal>:</literal>]<replaceable>root-dir</replaceable>[,<replaceable>nfs-options</replaceable>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Set the NFS root filesystem for diskless boxes, to
	enable them to boot properly over NFS.  If this parameter is not
	set, the value
	<literal>/tftpboot/</literal><replaceable>client_ip_address</replaceable>
	will be used as the root filesystem with the default NFS options.
<!--

  AO: The following does not correspond to the option. The option
  requires an IP address. Is localhost the default?

  gkh: no, I've rewritten this a bit better to hopefully explain this.  And
  the machine will have an IP address, that is what it is using to access
  the NFS host here.

-->
    <variablelist>
      <varlistentry>
        <term><replaceable>server-ip</replaceable></term>
        <listitem><para>IP address of the NFS
	server to connect to.</para></listitem>
      </varlistentry>
      <varlistentry>
        <term><replaceable>root-dir</replaceable></term>
        <listitem><para>Directory on the NFS
	server to mount as root.  If there is a <literal>%s</literal> token
	in this string, it will be replaced with the ASCII representation
	of the client's IP address.</para></listitem>
      </varlistentry>
      <varlistentry>
        <term><replaceable>nfs-options</replaceable></term>
        <listitem><para>The standard NFS options, such as <literal>ro</literal>,
	separated by commas.</para></listitem>
      </varlistentry>
    </variablelist>
    </para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>nfs.callback_tcpport</refname>
    <refpurpose>Set the NFSv4 TCP port for the callback channel.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>nfs.callback_tcpport=</literal><replaceable>port</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Specify the TCP port that the NFSv4 callback channel should
	listen on.  <replaceable>port</replaceable> must be a valid TCP port
	value.
<!--

  AO: Default?

  gkh:  Nope, no default value (other than 0 which is invalid.

-->
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>nfs.idmap_cache_timeout</refname>
    <refpurpose>Set the maximum lifetime for idmapper cache entries.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>nfs.idmap_cache_timeout=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Specify the maximum lifetime for idmapper cache entries.
	<replaceable>n</replaceable> is measured in seconds.
	</para>
</refsect1>
</refentry>

</sect1>

<sect1>
<title>Hardware specific options</title>

<para>
These options specify different parameters, depending on the hardware
present in the system.
</para>

<refentry>
  <refnamediv>
    <refname>nousb</refname>
    <refpurpose>Disable the USB subsystem.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	If this option is present, the USB subsystem will not be initialized.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>lp</refname>
    <refpurpose>Parallel port and its mode.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>lp=</literal>[<replaceable>0</replaceable>|<replaceable>port</replaceable>[,<replaceable>port</replaceable>...]|<literal>reset</literal>|<literal>auto</literal>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Specify the parallel port to use. The
	<literal>lp=port1,port2...</literal> format associates a
	sequence of parallel ports to
	devices, starting with <literal>lp0</literal>.
	An example is
	<literal>lp=none,parport0</literal>, which would suppress
	configuration of
	the <literal>lp0</literal> device and cause the <literal>lp1</literal>
	device to use the first parallel port.
	</para>
	<para>

	</para>
	<para>
	<literal>lp=0</literal> disables the printer driver.
	</para>
	<para>
	<literal>lp=reset</literal> causes the attached printers to be
	reset.  This option can be combined with the port specifications.
	</para>
	<para>
	<literal>lp=auto</literal>
	causes the kernel to examine the device ID from each port
	to determine whether a IEEE 1284-compatible printer is attached.  If so,
	the kernel will manage that printer.
	</para>

</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>parport</refname>
    <refpurpose>Specify the parallel port parameters.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>parport=[<replaceable>setting</replaceable>[,<replaceable>setting</replaceable>...]</literal>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Specify specific settings for parallel port drivers. Parallel ports are assigned in the order they are
	specified on the command line, starting with
	<literal>parport0</literal>.
	</para>
	<para>
	<literal>auto</literal> forces the
	driver to use any IRQ/DMA settings detected (the default is to
	ignore detected IRQ/DMA settings because of possible conflicts).
	You can also specify the base address, IRQ, and DMA settings
	in the format <literal>0x</literal><replaceable>nnnn</replaceable>[,<replaceable>irq</replaceable>[,<replaceable>dma</replaceable>]].
	<replaceable>irq</replaceable> and
	<replaceable>DMA</replaceable> can be numbers,
	<literal>auto</literal> to use detected settings on that particular port, or
	<literal>nofifo</literal> to avoid using a FIFO even if it is
	detected.
<!--

  AO: What does 0 do?

  gkh:  I'm confused, which 0?  The one in "parport0"?

-->
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>parport_init_mode</refname>
    <refpurpose>Parallel port initialization mode.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>parport_init_mode=</literal>[<literal>spp</literal>|<literal>ps2</literal>|<literal>epp</literal>|<literal>ecp</literal>|<literal>ecpepp</literal>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Specifies the mode that the parallel port should be operated in.
	This is necessary on the Pegasos computer where the firmware has no
	options for setting up the parallel port mode.  This option works
	for parallel port chips of type 686a and 8231.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>nr_uarts</refname>
    <refpurpose>Maximum number of UARTs to be registered.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>nr_uarts=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Specifies the maximum number of different UARTs that can be
	registered in the kernel.
	</para>
</refsect1>
</refentry>

</sect1>

<sect1>
<title>Timer specific options</title>

<para>
These options override default kernel behavior to fix problems with
certain chips.
</para>

<refentry>
  <refnamediv>
    <refname>enable_timer_pin_1</refname>
    <refpurpose>Enable pin 1 of the APIC timer.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Enable pin 1 of the APIC timer. This option can be useful to work
	around chipset bugs (on some ATI chipsets in particular.)  The
	kernel tries to set a reasonable default, but sometimes this option
	is necessary to override it.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>disable_timer_pin_1</refname>
    <refpurpose>Disable pin 1 of the APIC timer.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Disable pin 1 of the APIC timer.  Useful for the same reasons
	as <literal>enable_timer_pin_1</literal>.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>enable_8254_timer</refname>
    <refpurpose>Enable interrupt 0 timer routing over the 8254 chip.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Enable interrupt 0 timer routing over the 8254 chip in addition to
	routing over the IO-APIC. The kernel tries to set a reasonable default but
	sometimes this option is necessary to override it.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>disable_8254_timer</refname>
    <refpurpose>Disable interrupt 0 timer routing over the 8254 chip.</refpurpose>
  </refnamediv>
<refsect1>
  <title>Description</title>
	<para>
	Disable interrupt 0 timer routing over the 8254 chip in
	addition to routing
	over the IO-APIC. The kernel tries to set a reasonable default but
	sometimes this option is necessary to override it.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>hpet</refname>
    <refpurpose>Disable HPET and use PIT instead.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>hpet=disable</literal>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Disable the HPET timer source and tell the kernel to use the PIT
	timer source instead.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>clocksource</refname>
    <refpurpose>Set the specific clocksource.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>clocksource=</literal>[<literal>hpet</literal>|<literal>pit</literal>|<literal>tsc</literal>|<literal>acpi_pm</literal>|<literal>cyclone</literal>|<literal>scx200_hrt</literal>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Override the default kernel clocksource and use the clocksource
	with the specified name instead.
	</para>
</refsect1>
</refentry>


</sect1>

<sect1>
<title>Miscellaneous options</title>

<para>
These options should always be available, and don't depend on any specific
subsystem or hardware being present in the system in order to work
properly.
</para>


<refentry>
  <refnamediv>
    <refname>dhash_entries</refname>
    <refpurpose>Set the number of dentry hash buckets.
    </refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>dhash_entries=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	This option lets you override the default number of hash buckets
	for the kernel's dentry cache. Recommended only for kernel
	experts.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>elevator</refname>
    <refpurpose>Set the default I/O scheduler elevator.
    </refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>elevator=</literal>[<literal>anticipatory</literal>|<literal>cfq</literal>|<literal>deadline</literal>|<literal>noop</literal>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Specify the I/O scheduler.  See
	<xref linkend="CONFIG_IOSCHED_NOOP" /> for a list of the different
	I/O schedulers available, and what they do.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>hashdist</refname>
    <refpurpose>Distribute large hashes across NUMA nodes.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>hashdist=</literal>[<literal>0</literal>|<literal>1</literal>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Large hashes that are allocated during the boot process on the
	IA-64 platform are, by default, distributed across the
	different NUMA nodes.  This option lets the user turn this
	option on or off.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>combined_mode</refname>
    <refpurpose>Specify IDE driver usage.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>combined_mode=</literal>[<literal>combined</literal>|<literal>ide</literal>|<literal>libata</literal>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Control which driver uses the IDE ports in combined
	mode: the legacy IDE driver, <emphasis>libata</emphasis>, or both.  Note that using the
	ide or libata options may affect your device naming (e.g., by
	changing <literal>hdc</literal> to <literal>sdb</literal>).
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>max_loop</refname>
    <refpurpose>Maximum number of loopback devices.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>max_loop=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Specify the maximum number of loopback filesystem devices
	that can be mounted at the same time.  <replaceable>n</replaceable> is an
	integer from 1 to 256.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>panic</refname>
    <refpurpose>Time to wait after panic before rebooting.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>panic=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Specify the ammount of time in seconds that the
	kernel should wait after a panic happens before it reboots.  If
	this is set to <literal>0</literal> (the default value) the kernel
	will not reboot after panicking; it will simply halt.
<!--

  AO: Or hang?

  gkh: same thing :)

-->
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>pause_on_oops</refname>
    <refpurpose>Delay between kernel oopses.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>pause_on_oops=</literal><replaceable>n</replaceable>
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	Tell the kernel to halt all CPUs after the first oops
	for <replaceable>n</replaceable> seconds before continuing.  This is
	useful if oopses keep scrolling off of the screen before you can
	write them down or take a picture of them.
	</para>
</refsect1>
</refentry>

<refentry>
  <refnamediv>
    <refname>profile</refname>
    <refpurpose>Control the kernel profiling.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>profile=</literal>[<replaceable>schedule</replaceable><literal>,</literal>][<replaceable>number</replaceable>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
<!--

  AO: Is it feasible to list values for the schedule parameter?

  gkh: I can't seem to figure them out, so I don't know what they would be.
       Like I document, just use the "profile=2" option unless you do know
       what the schedular commands are, then you know what you are doing
       with them :)

-->
	This option affects how the kernel profiler is calculated.  If
	<literal>schedule</literal> is specified, the schedule points are
	affected by the value set in <replaceable>number</replaceable>.  If
	<literal>schedule</literal> is not specified,
	<replaceable>number</replaceable> is the step size as a power of two for
	statistical time-based profiling in the kernel.
	</para>
	<para>
	The most common use of this option is <literal>profile=2</literal>
	</para>
</refsect1>
</refentry>


</sect1>

<!--

template for options...

<refentry>
  <refnamediv>
    <refname>
    </refname>
    <refpurpose>
    </refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <para>
    <literal>apic=</literal>[<replaceable>quiet</replaceable>(default)|<replaceable>verbose</replaceable>|<replaceable>debug</replaceable>]
    </para>
  </refsynopsisdiv>
<refsect1>
  <title>Description</title>
	<para>
	</para>
</refsect1>
</refentry>

-->

</chapter>
<!-- vim: set ai tw=72 : -->