bootparam

Hurricane Electric Internet Services: Accounts starting at $9.95/month
Hurricane Electric Internet Services























































NAME

       bootparam  -  Introduction  to boot time parameters of the
       Linux kernel


DESCRIPTION

       The Linux kernel accepts certain `command line options' or
       `boot  time  parameters'  at  the moment it is started. In
       general this is used to supply the kernel with information
       about  hardware  parameters  that  the kernel would not be
       able to determine on its own,  or  to  avoid/override  the
       values that the kernel would otherwise detect.

       When the kernel is booted directly by the BIOS (say from a
       floppy to which you  copied  a  kernel  using  `cp  zImage
       /dev/fd0'), you have no opportunity to specify any parame-
       ters.  So, in order to take advantage of this  possibility
       you  have to use software that is able to pass parameters,
       like LILO or loadlin.  For a few parameters one  can  also
       modify  the  kernel  image itself, using rdev, see rdev(8)
       for further details.

       The LILO program (LInux LOader) written by  Werner  Almes-
       berger  is  the  most commonly used. It has the ability to
       boot various kernels, and stores the configuration  infor-
       mation   in   a   plain   text   file.  (See  lilo(8)  and
       lilo.conf(5).)  LILO can boot DOS,  OS/2  Linux,  FreeBSD,
       etc., and is quite flexible.

       The other commonly used Linux loader is `LoadLin' which is
       a DOS program that has the capability to  launch  a  Linux
       kernel  from the DOS prompt (with boot-args) assuming that
       certain resources are available.  This is good for  people
       that want to launch Linux from DOS.

       It  is also very useful if you have certain hardware which
       relies on the supplied DOS driver to put the hardware into
       a  known state. A common example is `SoundBlaster Compati-
       ble' sound cards that require the DOS driver to twiddle  a
       few  mystical registers to put the card into a SB compati-
       ble mode. Booting DOS with the supplied driver,  and  then
       loading  Linux from the DOS prompt with loadlin avoids the
       reset of the card that happens if one rebooted instead.



THE ARGUMENT LIST

       Most of the boot args take the form of:

              name[=value_1][,value_2]...[,value_11]

       where `name' is a unique keyword that is used to  identify
       what part of the kernel the associated values (if any) are
       to be given to. Multiple boot args are just a space  sepa-
       rated  list  of  the above format. Note the limit of 11 is
       real, as the present code only handles 11 comma  separated
       parameters  per keyword. (However, you can re-use the same
       keyword with up to an additional 11 parameters  in  unusu-
       ally  complicated  situations, assuming the setup function
       supports it.)

       Most of the sorting goes on in linux/init/main.c.   First,
       the  kernel  checks  to  see if the argument is any of the
       special arguments `root=', `ro', `rw',  or  `debug'.   The
       meaning of these special arguments is described further on
       in the document.

       Then it walks a list of setup functions (contained in  the
       bootsetups  array) to see if the specified argument string
       (such as `foo') has been associated with a setup  function
       (`foo_setup()')  for  a  particular  device or part of the
       kernel. If you passed the kernel the line foo=3,4,5,6 then
       the  kernel  would  search  the bootsetups array to see if
       `foo' was registered. If it was, then it  would  call  the
       setup  function  associated  with  `foo' (foo_setup()) and
       hand it the arguments 3, 4, 5 and 6 as given on the kernel
       command line.

       Anything  of  the form `foo=bar' that is not accepted as a
       setup funtion as described above is then interpreted as an
       environment variable to be set. A (useless?) example would
       be to use `TERM=vt100' as a boot argument.

       Any remaining arguments that were not  picked  up  by  the
       kernel  and  were not interpreted as environment variables
       are then passed onto process one,  which  is  usually  the
       init  program.  The most common argument that is passed to
       the init process is the word `single' which instructs init
       to  boot  the computer in single user mode, and not launch
       all the usual daemons. Check the manual page for the  ver-
       sion  of  init  installed on your system to see what argu-
       ments it accepts.



GENERAL NON-DEVICE SPECIFIC BOOT ARGS

   `no387'
       Some i387 coprocessor chips have bugs that  show  up  when
       used  in  32  bit protected mode. For example, some of the
       early ULSI-387 chips would cause solid lockups while  per-
       forming  floating  point  calculations.  Using the `no387'
       boot arg causes Linux to ignore the maths coprocessor even
       if  you have one. Of course you must then have your kernel
       compiled with math emulation support!


   `no-hlt'
       Some of the early i486DX-100 chips have a problem with the
       `hlt'  instruction,  in that they can't reliably return to
       operating mode after this instruction is used.  Using  the
       `no-hlt'  instruction  tells Linux to just run an infinite
       loop when there is nothing else to do, and to not halt the
       CPU.  This  allows  people  with these broken chips to use
       Linux.


   `root=...'
       This argument tells the kernel what device is to  be  used
       as  the root filesystem while booting. The default of this
       setting is determined at compile time, and usually is  the
       value of the root device of the system that the kernel was
       built on. To override this value, and  select  the  second
       floppy   drive   as   the   root  device,  one  would  use
       `root=/dev/fd1'. (The root device can also  be  set  using
       rdev(8).)

       The  root  device can be specified symbolically or numeri-
       cally.  A symbolic specification has the  form  /dev/XXYN,
       where  XX designates the device type (`hd' for ST-506 com-
       patible hard disk, with Y in `a'-`h'; `sd' for  SCSI  com-
       patible  disk,  with  Y in `a'-`e'; `xd' for XT compatible
       disk, with Y either `a' or `b'; `fd' for floppy disk, with
       Y  the  floppy  drive  number  - fd0 would be the DOS `A:'
       drive, and fd1 would be `B:'), Y the driver letter or num-
       ber,  and  N  the  number  of the partition on this device
       (absent in the case of floppies).

       Note that this has nothing to do with the  designation  of
       these  devices  on  your  file system. The `/dev/' part is
       purely conventional.

       The more awkward and less portable  numeric  specification
       of  the  above possible root devices in major/minor format
       is also accepted. (e.g.  /dev/sda3 is major 8, minor 3, so
       you could use `root=0x803' as an alternative.)


   `ro' and `rw'
       The  `ro'  option  tells  the  kernel  to  mount  the root
       filesystem as `readonly' so  that  filesystem  consistency
       check  programs  (fsck)  can  do their work on a quiescent
       file system. No  processes  can  write  to  files  on  the
       filesystem   in   question  until  it  is  `remounted'  as
       read/write capable, e.g., by `mount -w -n -o  remount  /'.
       (See also mount(8).)

       The  `rw'  option  tells  the  kernel  to  mount  the root
       filesystem read/write.  This is the default.

       The choice between read-only and read/write  can  also  be
       set using rdev(8).


   `debug'
       Kernel  messages  are  handed off to the kernel log daemon
       klogd so that they may be logged to disk. Messages with  a
       priority  above  console_loglevel  are also printed on the
       console. (For these  levels,  see  <linux/kernel.h>.)   By
       default  this  variable is set to log anything more impor-
       tant than debug messages. This boot  argument  will  cause
       the  kernel  to also print the messages of DEBUG priority.
       The console loglevel can also be set at run  time  via  an
       option to klogd. See klogd(8).


   `reserve=...'
       This is used to protect I/O port regions from probes.  The
       form of the command is:

              reserve=iobase,extent[,iobase,extent]...

       In some machines it may be  necessary  to  prevent  device
       drivers from checking for devices (auto-probing) in a spe-
       cific region. This may be because of hardware that  reacts
       badly to the probing, or hardware that would be mistakenly
       identified, or merely hardware you don't want  the  kernel
       to initialize.

       The  reserve  boot-time  argument  specifies  an  I/O port
       region that shouldn't be probed. A device driver will  not
       probe  a  reserved  region,  unless  another boot argument
       explicitly specifies that it do so.

       For example, the boot line

              reserve=0x300,32  blah=0x300

       keeps all device drivers except the driver for `blah' from
       probing 0x300-0x31f.


   `ramdisk=...'
       This  specifies  the  size  in kB of the optional RAM disk
       device.  For  example,  if  one  wished  to  have  a  root
       filesystem  on  a  1.44MB  floppy loaded into the RAM disk
       device, they would use:

              ramdisk=1440

       This option is set at compile time (default: no RAM disk),
       and can be modified using rdev(8).


   `mem=...'
       The BIOS call defined in the PC specification that returns
       the amount of installed memory was  only  designed  to  be
       able  to  report up to 64MB.  Linux uses this BIOS call at
       boot to determine how much memory is  installed.   If  you
       have  more  than  64MB  of RAM installed, you can use this
       boot arg to tell Linux how  much  memory  you  have.   The
       value  is  in  decimal or hexadecimal (prefix 0x), and the
       suffixes `k' (times 1024) or `M' (times  1048576)  can  be
       used.   Here  is a quote from Linus on usage of the `mem='
       parameter.

       ``The kernel will accept any `mem=xx' parameter  you  give
       it, and if it turns out that you lied to it, it will crash
       horribly sooner or later.   The  parameter  indicates  the
       highest  addressable RAM address, so `mem=0x1000000' means
       you have 16MB of memory, for example.  For a 96MB  machine
       this would be `mem=0x6000000'.

       NOTE  NOTE NOTE: some machines might use the top of memory
       for BIOS cacheing or whatever, so you might  not  actually
       have up to the full 96MB addressable.  The reverse is also
       true: some chipsets will map the physical memory  that  is
       covered  by  the BIOS area into the area just past the top
       of memory, so the top-of-mem  might  actually  be  96MB  +
       384kB  for  example.   If  you tell linux that it has more
       memory than it actually does have, bad things will happen:
       maybe not at once, but surely eventually.''



BOOT ARGUMENTS FOR SCSI DEVICES

       General notation for this section:

       iobase  -- the first I/O port that the SCSI host occupies.
       These are specified in hexidecimal notation,  and  usually
       lie in the range from 0x200 to 0x3ff.

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

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

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


   `max_scsi_luns=...'
       A SCSI device can have a number of `sub-devices' contained
       within  itself.  The most common example is one of the new
       SCSI CD-ROMs that handle more than one  disk  at  a  time.
       Each  CD  is addressed as a `Logical Unit Number' (LUN) of
       that particular device. But most  devices,  such  as  hard
       disks,  tape drives and such are only one device, and will
       be assigned to LUN zero.

       Some poorly designed  SCSI  devices  cannot  handle  being
       probed  for LUNs not equal to zero. Therefore, if the com-
       pile time flag CONFIG_SCSI_MULTI_LUN  is  not  set,  newer
       kernels will by default only probe LUN zero.

       To  specify  the number of probed LUNs at boot, one enters
       `max_scsi_luns=n' as a boot  arg,  where  n  is  a  number
       between  one  and  eight.  To  avoid problems as described
       above, one would use n=1 to avoid  upsetting  such  broken
       devices.


   SCSI tape configuration
       Some  boot  time configuration of the SCSI tape driver can
       be achieved by using the following:

              st=buf_size[,write_threshold[,max_bufs]]

       The first two numbers are specified in units of  kB.   The
       default buf_size is 32kB, and the maximum size that can be
       specified is a ridiculous 16384kB.  The write_threshold is
       the value at which the buffer is committed to tape, with a
       default value of 30kB.   The  maximum  number  of  buffers
       varies  with  the  number  of  drives  detected, and has a
       default of two.  An example usage would be:

              st=32,30,2

       Full details can be found in the README.st file that is in
       the scsi directory of the kernel source tree.


   Adaptec aha151x, aha152x, aic6260, aic6360, SB16-SCSI configu-
       ration
       The aha numbers refer to cards and the aic  numbers  refer
       to  the actual SCSI chip on these type of cards, including
       the Soundblaster-16 SCSI.

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

              aha152x=iobase[,irq[,scsi-id[,reconnect[,parity]]]]

       If the driver was compiled with debugging enabled, a sixth
       value can be specified to set the debug level.

       All the parameters are as described at  the  top  of  this
       section, and the reconnect value will allow device discon-
       nect/reconnect if a non-zero value  is  used.  An  example
       usage is as follows:

              aha152x=0x340,11,7,1

       Note that the parameters must be specified in order, mean-
       ing that if you want to specify a parity setting, then you
       will have to specify an iobase, irq, scsi-id and reconnect
       value as well.


   Adaptec aha154x configuration
       The aha1542 series cards have an i82077 floppy  controller
       onboard,  while the aha1540 series cards do not. These are
       busmastering cards, and have parameters to set the ``fair-
       ness''  that  is used to share the bus with other devices.
       The boot arg looks like the following.

              aha1542=iobase[,buson,busoff[,dmaspeed]]

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

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

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


   Adaptec aha274x, aha284x, aic7xxx configuration
       These boards can accept an argument of the form:

              aic7xxx=extended,no_reset

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


   BusLogic SCSI Hosts configuration (`buslogic=')
       At  present,  the buslogic driver accepts only one parame-
       ter, that being the I/O base. It expects that to be one of
       the  following  valid  values: 0x130, 0x134, 0x230, 0x234,
       0x330, 0x334.


   Future Domain TMC-8xx, TMC-950 configuration
       If your card is not detected at boot time, you  will  then
       have to use a boot arg of the form:

              tmc8xx=mem_base,irq

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


   Pro Audio Spectrum configuration
       The PAS16 uses a NC5380 SCSI chip, and newer  models  sup-
       port  jumperless  configuration.  The  boot  arg is of the
       form:

              pas16=iobase,irq

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


   Seagate ST-0x configuration
       If  your  card is not detected at boot time, you will then
       have to use a boot arg of the form:

              st0x=mem_base,irq

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


   Trantor T128 configuration
       These cards are also based on the NCR5380 chip, and accept
       the following options:

              t128=mem_base,irq

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


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

       Always IN2000, Adaptec aha1740, EATA-DMA, EATA-PIO, Future
       Domain  16xx,  NCR5380  (generic), NCR53c7xx to NCR53c8xx,
       Qlogic, Ultrastor (incl. u?4f), Western Digital wd7000.



HARD DISKS

   IDE Disk/CD-ROM Driver Parameters
       The IDE driver accepts a number of parameters, which range
       from  disk  geometry specifications, to support for broken
       controller chips. Drive specific options are specified  by
       using `hdX=' with X in `a'-`h'.

       Non-drive  specific  options are specified with the prefix
       `hd='. Note that using a drive specific prefix for a  non-
       drive specific option will still work, and the option will
       just be applied as expected.

       Also note that `hd=' can be used  to  refer  to  the  next
       unspecified  drive  in  the (a, ..., h) sequence.  For the
       following discussions, the `hd=' option will be cited  for
       brevity.  See  the  file README.ide in linux/drivers/block
       for more details.


   The `hd=cyls,heads,sects[,wpcom[,irq]]' options
       These options are used to specify the physical geometry of
       the  disk.   Only the first three values are required. The
       cylinder/head/sectors values will be those used by  fdisk.
       The  write precompensation value is ignored for IDE disks.
       The IRQ value specified will  be  the  IRQ  used  for  the
       interface  that  the drive resides on, and is not really a
       drive specific parameter.


   The `hd=serialize' option
       The dual IDE interface CMD-640 chip is broken as  designed
       such  that when drives on the secondary interface are used
       at the same time as drives on the  primary  interface,  it
       will corrupt your data. Using this option tells the driver
       to make sure that both interfaces are never  used  at  the
       same time.


   The `hd=dtc2278' option
       This option tells the driver that you have a DTC-2278D IDE
       interface.  The driver then tries to do DTC specific oper-
       ations to enable the second interface and to enable faster
       transfer modes.


   The `hd=noprobe' option
       Do not probe for this drive. For example,
              hdb=noprobe hdb=1166,7,17

       would disable the probe, but still specify the drive geom-
       etry  so  that  it  would  be  registered as a valid block
       device, and hence useable.


   The `hd=nowerr' option
       Some drives apparently have the WRERR_STAT  bit  stuck  on
       permanently.   This enables a work-around for these broken
       devices.


   The `hd=cdrom' option
       This tells the IDE driver that there is an ATAPI  compati-
       ble CD-ROM attached in place of a normal IDE hard disk. In
       most cases the CD-ROM is identified automatically, but  if
       it isn't then this may help.


   Standard ST-506 Disk Driver Options (`hd=')
       The standard disk driver can accept geometry arguments for
       the disks similar to the IDE driver. Note however that  it
       only  expects three values (C/H/S) -- any more or any less
       and it will silently ignore you.  Also,  it  only  accepts
       `hd='  as an argument, i.e. `hda=' and so on are not valid
       here. The format is as follows:

              hd=cyls,heads,sects

       If there are two disks installed, the  above  is  repeated
       with the geometry parameters of the second disk.


   XT Disk Driver Options (`xd=')
       If you are unfortunate enough to be using one of these old
       8 bit cards that move data at a whopping 125kB/s then here
       is  the  scoop.   If  the card is not recognised, you will
       have to use a boot arg of the form:

              xd=type,irq,iobase,dma_chan

       The type value specifies the  particular  manufacturer  of
       the   card,   and   are   as  follows:  0=generic;  1=DTC;
       2,3,4=Western Digital,  5,6,7=Seagate;  8=OMTI.  The  only
       difference  between  multiple types from the same manufac-
       turer is the BIOS string used for detection, which is  not
       used if the type is specified.

       The  xd_setup()  function  does no checking on the values,
       and assumes that you entered all four values. Don't disap-
       point  it.   Here  is  an  example usage for a WD1002 con-
       troller  with  the  BIOS   disabled/removed,   using   the
       `default' XT controller parameters:
              xd=2,5,0x320,3




CD-ROMs (Non-SCSI/ATAPI/IDE)

   The Aztech Interface
       The syntax for this type of card is:

              aztcd=iobase[,magic_number]

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


   The CDU-31A and CDU-33A Sony Interface
       This  CD-ROM  interface  is found on some of the Pro Audio
       Spectrum sound cards, and other  Sony  supplied  interface
       cards.  The syntax is as follows:

              cdu31a=iobase,[irq[,is_pas_card]]

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

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


   The CDU-535 Sony Interface
       The syntax for this CD-ROM interface is:

              sonycd535=iobase[,irq]

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


   The GoldStar Interface
       The syntax for this CD-ROM interface is:

              gscd=iobase



   The Mitsumi Standard Interface
       The syntax for this CD-ROM interface is:

              mcd=iobase,[irq[,wait_value]]

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


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


   The Optics Storage Interface
       The syntax for this type of card is:

              optcd=iobase



   The Phillips CM206 Interface
       The syntax for this type of card is:

              cm206=[iobase][,irq]


       The  driver  assumes numbers between 3 and 11 are IRQ val-
       ues, and numbers between 0x300 and 0x370 are I/O ports, so
       you  can  specify  one, or both numbers, in any order.  It
       also accepts `cm206=auto' to enable autoprobing.


   The Sanyo Interface
       The syntax for this type of card is:

              sjcd=iobase[,irq[,dma_channel]]



   The SoundBlaster Pro Interface
       The syntax for this type of card is:

              sbpcd=iobase,type

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



Ethernet Devices

       Different  drivers  make  use of different parameters, but
       they all at least share having an IRQ, an  I/O  port  base
       value,  and  a  name.  In  its most generic form, it looks
       something like this:
              ether=irq,iobase[,param_1[,param_2,...param_8]],name

       The  first non-numeric argument is taken as the name.  The
       param_n values  (if  applicable)  usually  have  different
       meanings  for each different card/driver.  Typical param_n
       values are used  to  specify  things  like  shared  memory
       address, interface selection, DMA channel and the like.

       The  most common use of this parameter is to force probing
       for a second ethercard, as the default is  to  only  probe
       for one. This can be accomplished with a simple:

              ether=0,0,eth1

       Note  that  the values of zero for the IRQ and I/O base in
       the above example tell the driver(s) to autoprobe.

       The Ethernet-HowTo has extensive  documentation  on  using
       multiple cards and on the card/driver specific implementa-
       tion of the param_n values where used. Interested  readers
       should refer to the section in that document on their par-
       ticular card.



The Floppy Disk Driver

       There are many floppy driver options,  and  they  are  all
       listed  in README.fd in linux/drivers/block. This informa-
       tion is taken directly from that file.


   floppy=mask,allowed_drive_mask
       Sets the bitmask of allowed drives to  mask.  By  default,
       only  units 0 and 1 of each floppy controller are allowed.
       This is done because certain non-standard  hardware  (ASUS
       PCI  motherboards)  mess  up  the  keyboard when accessing
       units 2 or 3. This option is  somewhat  obsoleted  by  the
       cmos option.


   floppy=all_drives
       Sets the bitmask of allowed drives to all drives. Use this
       if you have more than two drives  connected  to  a  floppy
       controller.


   floppy=asus_pci
       Sets  the  bitmask  to  allow  only  units  0  and 1. (The
       default)


   floppy=daring
       Tells the floppy driver  that  you  have  a  well  behaved
       floppy   controller.    This  allows  more  efficient  and
       smoother operation, but may fail on  certain  controllers.
       This may speed up certain operations.


   floppy=0,daring
       Tells the floppy driver that your floppy controller should
       be used with caution.


   floppy=one_fdc
       Tells the floppy driver that you  have  only  floppy  con-
       troller (default)


   floppy=two_fdc or floppy=address,two_fdc
       Tells  the  floppy  driver  that  you have two floppy con-
       trollers. The second floppy controller is assumed to be at
       address. If address is not given, 0x370 is assumed.


   floppy=thinkpad
       Tells   the  floppy  driver  that  you  have  a  Thinkpad.
       Thinkpads use an inverted convention for the  disk  change
       line.


   floppy=0,thinkpad
       Tells the floppy driver that you don't have a Thinkpad.


   floppy=drive,type,cmos
       Sets  the  cmos type of drive to type.  Additionally, this
       drive is allowed in the bitmask. This  is  useful  if  you
       have  more  than  two  floppy  drives  (only  two  can  be
       described in the physical cmos), or if your BIOS uses non-
       standard  CMOS types.  Setting the CMOS to 0 for the first
       two drives (default) makes  the  floppy  driver  read  the
       physical cmos for those drives.


   floppy=unexpected_interrupts
       Print  a  warning  message when an unexpected interrupt is
       received (default behaviour)


   floppy=no_unexpected_interrupts or floppy=L40SX
       Don't print a message  when  an  unexpected  interrupt  is
       received.  This  is needed on IBM L40SX laptops in certain
       video modes. (There seems to  be  an  interaction  between
       video  and  floppy.  The unexpected interrupts only affect
       performance, and can safely be ignored.)



The Sound Driver

       The sound driver can also accept boot args to override the
       compiled  in  values.  This  is  not recommended, as it is
       rather complex. It is described in the Readme.Linux  file,
       in linux/drivers/sound. It accepts a boot arg of the form:

              sound=device1[,device2[,device3...[,device11]]]

       where each  deviceN  value  is  of  the  following  format
       0xTaaaId and the bytes are used as follows:

       T  -  device  type:  1=FM,  2=SB,  3=PAS, 4=GUS, 5=MPU401,
       6=SB16, 7=SB16-MPU401

       aaa - I/O address in hex.

       I - interrupt line in hex (i.e 10=a, 11=b, ...)

       d - DMA channel.

       As you can see it gets pretty messy, and  you  are  better
       off to compile in your own personal values as recommended.
       Using a boot arg  of  `sound=0'  will  disable  the  sound
       driver entirely.



The Bus Mouse Driver (`bmouse=')

       The busmouse driver only accepts one parameter, that being
       the hardware IRQ value to be used.



AUTHORS

       Linus Torvalds (and many others)



SEE ALSO

       klogd(8), lilo.conf(5), lilo(8), mount(8), rdev(8)

       This man page has been derived  from  the  Boot  Parameter
       HOWTO  (version 1.0.1) written by Paul Gortmaker. Slightly
       more information may be found in this (or a  more  recent)
       HOWTO.
Hurricane Electric Internet Services: Accounts starting at $9.95/month
Hurricane Electric Internet Services
Copyright (C) 1998 Hurricane Electric. All Rights Reserved.