<!--

	The SGML source of the BootPrompt-Howto
	=====================================

	Maintained by Paul Gortmaker.

	Modification Date: Sept. 04, 2001

	(Don't forget to update the reference to the current kernel version
	in the Introduction section, and the date/version in the abstract!)

	History:

	1) August 1995 - Still no comprehensive list of kernel arguments
	   for users to look up existence/usage info. So I hacked this up,
	   having experience with the linuxdoc-sgml stuff from the
	   Ethernet-HowTo. (Of course the most up-to-date list is the kernel
	   itself, but that does not lend itself well to beginners.)

	2) July 1996 - Update to the v2.0 kernel, and add in all the
	   things I left out in the 1st version, nearly a year(!) ago.
	   Make copying conditions GPL (it was before, as I swiped the
	   the copying conditions from the GNU Make manual, but it didn't
	   explicitly say GPL).

	3) December 1996 - More minor updates up to and incl. v2.0.27
           kernel. Should be good for a while now... (ha!)

	4) November 1997 - Add in a few minor updates for v2.0.31 to
	   coincide with the new printing of LSL's book.

	5) Feb 1998 - Some more minor fixes (2.0.33).

	6) May 1998 - as above, 2.0.34 still isn't officially released.

	7) May 1999 - 2.2 (and 2.3) are released, time for an update!
	   Cite documentation files that come with the kernel instead
	   of taking info from them - makes maintenance easier.  Also
	   put copying conditions as LDP or GPL (I don't really care
	   either way - as long as people get access to the info within.)

	8) Sep 2001 -  Add some new 2.4 entries. 2.5 isn't out yet.

	9) Mar 2003 - (gasp!) current is 2.4.20, and 2.5.64.  More of
	   change 7 above - deleted SCSI, CD, and sound low level
	   driver info.

TODO:

	I'm considering the option of improving kernel-parameters.txt
	that comes with the kernel source, and dropping this HowTo
	altogether...  Something worth considering.

-->

<!doctype linuxdoc system>

<article>

<title>The Linux BootPrompt-HowTo
<author>by Paul Gortmaker.
<date>v1.4, Mar 21, 2003

<abstract>
	Questo &egrave; il BootPrompt-Howto, &egrave; una raccolta di tutti i
	possibili argomenti di avvio che possono essere passati al kernel Linux
	nel momento dell'avvio.
	Con una discussione di come il kernel ordina gli argomerti di avvio, inoltre &egrave;
	inclusa	una descrizione di alcuni software popolari usati per avviare i
	kernel Linux. Traduzione a cura di Sandro Cardelli, revisione a cura di Giulio
	Daprel&agrave; (giulio at pluto dot it)
</abstract>

<toc>

<sect>Introduzione<label id="main-intro">
<p>

	Il kernel ha la capacit&agrave; di accettare informazioni all'avvio
	nella forma di `riga di comando', simile ad una lista di argomenti
	che si darebbe ad un programma. In generale questo viene usato per
	fornire al kernel informazioni circa i parametri hardware
	che il kernel non sarebbe in grado di determinare di per se, o
	evitare/sovrascrivere i valori che il kernel altrimenti
	rileverebbe.

	&Egrave; il lavoro del boot loader (es. LILO, loadlin o Grub) di
	prendere queste informazioni dall'utente e metterle in un posto precedentemente
	concordato dove il kernel possa trovarle una volta che si avvia.

	La presente revisione copre i kernel fino e incluso il v2.4.20.
	e v2.5.63

	Il BootPrompt-Howto &egrave; di:
<quote>
	Paul Gortmaker, <tt/p_gortmaker @ yahoo.com/
</quote>

	This document is Copyright (c) 1995-2003 by Paul Gortmaker.
	Please see the Disclaimer and Copying information at the end
	of this document (<ref id="copyright" name="copyright">)
	for information about redistribution of
	this document and the usual `we are not responsible for what
	you manage to break...' type legal stuff.

<sect1>A chi si rivolge e applicabilit&agrave;
<p>
	La maggior parte degli utenti Linux non dovrebbero neanche guardare questo documento.
	Linux fa eccezionalmente un buon lavoro nella rilevazione della maggior parte dell'hardware,
	selezionando ragionevolmente le impostazioni di default per la maggior parte dei parameteri.
	L'informazione in questo documento mira agli utenti che possono desiderare
	modificare alcune impostazioni di default per ottimizzare il kernel per
	le proprie particolari macchine, o a un utente che ha `personalizzato il proprio'
	kernel per supportare un hardware non comune per il quale
	i default automatici non sono l'ottimo.

	Per il bene di questo documento &egrave; meglio dividere
	gli argomenti di avvio in due categorie generali; (a)una
	gestita dal kernel e (b)quella gestita da un driver di dispositivo.
	Gli esempi sarebbero <tt/init=/ che dice al kernel quale dovrebbe essere
	il primo programma da eseguire, contro <tt/aha154x=/ che
	dice ad un driver di dispositivo per una scheda SCSI quale risorsa hardware
	dovrebbe usare. Questo documento si concentra nel dare informazioni dettagliate
	su questi per i motivi descritti sotto.

	<em/NOTA IMPORTANTE:/ Gli argomenti di avvio relativi ai driver
	si applicano soltanto ai driver hardware che sono compilati direttamente nel
	kernel. Essi non hanno <em/nessun effetto/ sui driver che sono caricati
	come moduli. La maggior parte delle distribuzioni Linux hanno un kernel di base `nudo'
	, e i driver sono piccoli moduli che sono caricati dopo l'inizializzazione
	del kernel.
	Se non si &egrave; sicuri che si stiano usando moduli provare <tt>lsmod</tt>,
	guardare <tt/man depmod/ e <tt/man modprobe/ insieme con il
	contenuto del proprio <tt>/etc/modules.conf</tt>.

	Alla luce di questo, gli argomenti di avvio dei driver di dispositivo sono
	realmente usati solo da poche persone che compilano i propri kernel, e
	perci&ograve; hanno i sorgenti del kernel alla mano. Queste persone
	usualmente controllano i sorgenti per le opzioni e le sintassi richieste da
	quel driver per ottenere le informazioni pi&ugrave; aggiornate.

	Per esempio, se si stanno cercando quali argomenti dovrebbero essere
	passati al driver AHA1542 SCSI, allora si dovrebbe andare nella directory
	<tt>linux/drivers/scsi</tt>, e cercare nel file
	<tt/aha1542.c/ <tt>__setup(... , ...)</tt>.  La prima
	cosa tra parentesi &egrave; l'argomento che si fornisce all'avvio,
	e la seconda cosa &egrave; il nome della funzione che processa il proprio
	argomento. Di solito vicino alla cima di questa funzione o all'inizio
	del file del sorgente si trover&agrave; una descrizione degli argomenti
	di avvio che il driver accetta.


<sect1>Documentazione Relativa
<p>

	Per adesso, i sorgenti del kernel hanno il file
	<tt>linux/Documentation/kernel-parameters.txt</tt>. Questo
	file contiene una breve lista di tutti gli argomenti di avvio
	che si possono fornire, insieme a veloci link al posto dove,
	tra i sorgenti, si possa trovare dove sono analizzati gli argomenti.
	L'idea &egrave; che questo file dia agli sviluppatori un posto veloce
	e facile per aggiungere una breve descrizione di ogni nuovo argomento
	che essi aggiungono lavorando ai sorgenti. Cos&igrave; che esso
	probabilmente sar&agrave; sempre pi&ugrave; aggiornato di questo documento.
	Attualmente sto consideranto con discontinuit&agrave; questo documento alla luce
	dell'esistenza del <tt/kernel-parameters.txt/.  (Opinioni?)

	La directory <tt/linux/ si trova di solito in <tt>/usr/src/</tt>
	nella maggior parte delle distribuzioni. Tutti i riferimenti in questo documento
	a file che vengono forniti col kernel avranno il loro nome del path
	abbreviato che inizia per <tt/linux/ - si dovr&agrave; aggiungere
	<tt>/usr/src/</tt> o quant'altro appropriato per il proprio sistema.
	Alcune distribuzioni possono non installare i sorgenti completi del kernel
	di default, e inserire solo la directory <tt>linux/include</tt>.
	Se non si trova il file in questione allora installare i sorgenti del kernel
	e/o e fare uso dei comandi <tt/find/ e <tt/locate/ .
	Se non si trova il pacchetto dei sorgenti del kernel nella propria distribuzione
	allora i sorgenti del kernel sono disponibili su:

	<url url="http://www.kernel.org"
		name="Kernel Source Home">

	La succesiva miglior cosa da leggere nei sorgenti C del kernel, sar&agrave;
	qualsiasi altro file di documentazione che viene
	distribuito con il kernel stesso. Ci sono ora alcuni
	di questi, e la maggior parte di loro pu&ograve; essere trovata nella directory
	<tt>linux/Documentation</tt> e nelle sue sottodirectory.
	A volte ci sar&agrave; il file <tt/README.foo/ che pu&ograve; essere trovato
	nella relativa directoty driver (es. <tt>linux/drivers/???/</tt>,
	dove ci dovrebbero essere esempi di <tt/???/ <tt/scsi/, <tt/char/, o <tt/net/).
	La tendenza generale &egrave; di spostare questi file dentro la directory Documentation,
	cos&igrave; se un file menzionato in questo documento non &egrave; pi&ugrave;
	l&igrave; probabilmente &egrave; stato spostato.

	Se si &egrave; capito quali argomenti di avvio si intende usare, e
	ora si vuole sapere come passare l'informazione al kernel, allora
	guardare la documentazione che &egrave; fornita con il software che si
	usa per avviare il kernel (es.LILO o loadlin). Una breve descrizione
	&egrave; fornita di seguito, ma non &egrave; il sostituto della documentazione
	fornita con il software di avvio.

<sect1>Nuove Versioni di questo Documento<label id="new-doc">
<p>
	Nuove versioni di questo documento possono essere trovate via anonymous
	FTP nella maggior parte dei siti FTP Linux nella directory
	<tt>/pub/Linux/docs/HOWTO/</tt>. Saranno fatti aggiornamenti quando
	saranno disponibili nuove informazioni e/o driver. Se questa copia che
	si sta leggendo &egrave; pi&ugrave; vecchia di sei mesi, allora
	si dovrebbe probabilmente controllare se ne esiste una pi&ugrave; nuova.
	Suggerirei di vederlo via browser WWW o nel formato
	Postscript/dvi. Entrambi contengono cross-reference
	che sono rimaste in una semplice versione formato testo.

	Se si vuole avere la copia ufficiale, ecco l'URL.

	<url url="http://metalab.unc.edu/mdw/HOWTO/BootPrompt-HOWTO.html"
		name="BootPrompt-HOWTO">

<sect>Sommario degli argomenti di avvio<label id="oview">
<p>

	Questa sezione d&agrave; alcuni esempi di software che pu&ograve; essere usato
	per passare gli argomenti di avvio del kernel al kernel stesso.
	D&agrave; anche un'idea di come gli argomenti vengono processati,
	quali limitazioni ci sono su questi, e come essi vengono passati
	a ogni dispositivo appropriato per il quale sono predisposti.

	&Egrave; <em/importante/ notare che gli spazi <em/non/ dovrebbero essere
	usati in un argomento di boot, ma solo tra argomenti separati.
	Una lista di valori che sono per un singolo argomento devono essere
	separati da una virgola tra i valori, e ancora senza
	nessuno spazio. Vedere i seguenti esempi di sotto.

<code>
	ether=9,0x300,0xd0000,0xd4000,eth0  root=/dev/hda1            *GIUSTO*
	ether = 9, 0x300, 0xd0000, 0xd4000, eth0  root = /dev/hda1    *ERRATO*
</code>

	Una volta che il kernel Linux &egrave; su ed &egrave; in esecuzione, si possono
	vedere gli argomenti della riga di comando che sono stati piazzati all'avvio
	semplicemente digitando <tt>cat /proc/cmdline</tt> al prompt di una shell.

<sect1>LILO (LInux LOader)<label id="lilo">
<p>
	Il programma LILO (LInux LOader) scritto da Werner Almesberger
	&egrave; il pi&ugrave; comunemente usato. Ha l'abilit&agrave; di avviare
	vari kernel, e memorizza l'informazioni di configurazione
	in un file formato testo. La maggior parte delle distribuzioni hanno LILO
	come boot-loader di default. LILO pu&ograve; avviare DOS, OS/2, Linux,
	FreeBSD, etc. senza nessuna difficolt&agrave;, ed &egrave; molto flessibile.

	Una tipica configurazione, dopo aver acceduto al proprio computer, far&agrave;
	fermare LILO e visualizzare brevemente <tt/LILO:/	Esso aspetter&agrave; poi
 	qualche secondo per ogni input opzionale da parte dell'utente, e in caso contrario
	avvier&agrave; il sistema di predefinito. Le etichette tipiche dei sistemi
	che le persone usano nel file di configurazione di LILO sono <tt/linux/
	e <tt/backup/ e <tt/msdos/. Se si vuole digitare un argomento di avvio
	occorre digitarlo qui, dopo aver digitato l'etichetta del sistema
	che si vuole che LILO avvii, come mostrato nell'esempio di sotto.

<code>
	LILO: linux root=/dev/hda1
</code>

	LILO &egrave; fornito di un'eccellente documentazione, e per gli scopi
	di avvio di argomenti discussi qui, il comando LILO <tt/append=/
	&egrave; di particolare importanza quando si vuole aggiungere un argomento
	all'avvio come un aggiunta permanente al file di configurazione di LILO.
	Si aggiunga semplicemente qualcosa tipo <tt/append = "foo=bar"/ al file
	<tt>/etc/lilo.conf</tt>. Pu&ograve; anche essere aggiunto in cima al
	file di configurazione, facendolo applicare a tutte le sezioni, o in una
	singola sezione di sistema aggiungendolo dentro una sezione <tt/image=/ .
	Prego vedere la documentazione LILO per una pi&ugrave; completa descrizione.

<sect1>LoadLin<label id="loadlin">
<p>
	L'altro loader Linux usato comunemente &egrave; `LoadLin' il quale &egrave; un
	programma DOS che ha la capacit&agrave; di lanciare un kernel Linux
	da un prompt DOS (con argomenti d'avvio) presumendo che
	alcune risorse siano disponibili. Questo &egrave; buono per persone
	che usano il DOS e vogliono lanciare Linux dal DOS.

	&Egrave; anche molto utile se si ha un certo hardware che quale dipende
	dai driver forniti in DOS per avere l'hardware in uno stato
	conosciuto. Un esempio comune &egrave; la scheda audio `SoundBlaster Compatibile'
	che richiede il driver DOS per impostare alcuni registri proprietari
	per rendere la scheda in modalit&agrave; compatible SB. Avviando
	il DOS con i driver forniti, e caricando poi Linux da un
	prompt DOS con <tt>LOADLIN.EXE</tt> evita la reimpostazione della
	scheda, cosa che accadrebbe se invece avvenisse un riavvio. Perci&ograve; la
	scheda &egrave; lasciata in modalit&agrave;
	compatibile SB e pertanto &egrave; usabile sotto Linux.

	Ci sono anche altri programmi che possono essere usati per avviare Linux.
	Per una lista completa, guardare nei programmi disponibili
	sul proprio mirror locale ftp Linux, sotto <tt>system/Linux-boot/</tt>.

<sect1>L'utilit&agrave; ``rdev'' <label id="rdev">
<p>
	Ci sono alcuni dei parametri di avvio del kernel che hanno i loro
	valori di default memorizzati in vari byte nell'immagine del kernel stessa.
	C'&egrave; un'utilit&agrave; chiamata <tt/rdev/ che &egrave; installata sulla
	maggior parte dei sistemi, che sa dove sono questi valori e come modificarli.
	Pu&ograve; anche modificare cose che non hanno un argomento equivalente di
	avvio del kernel, come la modalit&agrave; video usata di default.

	L'utilit&agrave; rdev ha anche degli alias come swapdev, ramsize,
	vidmode e rootflags. Queste sono le cinque cose che rdev
	pu&ograve; modificare, quello che &egrave; il dispositivo di root, il
	dispositivo di swap, i parametri della RAM disk, la modalit&agrave; video di
	default, e il	settaggio sola-lettura/lettura-scrittura del dispositivo di root.

	Maggior informazioni su <tt/rdev/ possono essere trovate digitando
	<tt/rdev -h/ o leggendo la pagina di manuale inclusa (<tt/man rdev/).

<sect1>Come il Kernel ordina gli argomenti
<p>
	La maggior parte degli argomenti di avvio ha la forma di:
<code>
	nome&lsqb;=valore_1&rsqb;&lsqb,valore_2&rsqb;...&lsqb,valore_11&rsqb
</code>

	dove `nome' &egrave; una chiave unica che &egrave; usata per identificare
	a quale parte del kernel deve essere dato il valore associato (se c'&egrave;).
	Argomenti di avvio multipli sono elencati separati solo da spazio
	come il formato di sopra. Notare che il limite a 11 &egrave; reale, perch&eacute; il
	codice attuale gestisce solo 11 parametri separati da virgole per
	chiave. (Comunque, si pu&ograve; ri-usare la stessa chiave con
	altri 11 parametri aggiuntivi in situazioni inusualmente
	complicate, assumendo che la funzione di setup le supporti.)
	Notare anche che il kernel divide la lista in un massimo di
	dieci argomenti interi, e una seguente stringa, cos&igrave; non si
	possono realmente fornire 11 interi a meno che non si converta l'undicesimo
	argomento da una stringa a un intero nello stesso driver.

	La maggior parte dell'ordinamento viene effettuato in <tt>linux/init/main.c</tt>.
	Prima il kernel controlla per vedere se l'argomento &egrave; uno degli
	argomenti speciali `root=', `ro', `rw', o `debug'.
	Il significato di questi argomenti speciali &egrave; descritto in aggiunta
	a questo documento.

	Dopo scorre una lista di funzioni di setup (contenute nella tabella
	<tt/bootsetups/ ) per vedere se la stringa specificata
	dell'argomento (come `foo') &egrave; stata associata con una
	funzione di setup (<tt/foo_setup()/) per un particolare
	dispositivo o parte del kernel. Se si,
	passa al kernel la riga <tt>foo=3,4,5,6,bar</tt> dopo il
	kernel dovrebbe cercare nella tabella <tt/bootsetups/ per vedere se
	`foo' &egrave; registrato. Se c'&egrave;, esso chiamerebbe la
	funzione di setup associata a `foo' (<tt/foo_setup()/)
	per gestire gli argomenti interi
	3, 4, 5 e 6 come sono passati alla riga di comando del kernel, e
	gestire anche l'argomento stringa <tt/bar/.

<sect1>Impostazione delle variabili d'ambiente.
<p>
	Qualsiasi cosa nella forma `foo=bar' che non &egrave; accettata come una
	funzione di setup come descritto sopra viene allora interpretata come una
	variabile d'ambiente che deve essere impostata. Un esempio sarebbe
	usare <tt/TERM=vt100/ o <tt/BOOT_IMAGE=vmlinuz.bak/
	come argomento di avvio. Queste variabili d'ambiente
	sono tipicamente testate negli script di inizializzazione
	per abilitare o disabilitare una vasta gamma di cose.

<sect1>Il passaggio di argomenti al programma `init'
<p>
	Ogni argomento rimanente che non &egrave; stato preso dal
	kernel e non &egrave; stato interpretato come variabile d'ambiente
	viene passato al processo uno, il quale &egrave; usualmente il programma
	<tt/init/ . Il pi&ugrave; comune argomento passato al
	processo <tt/init/ &egrave; la parola <em/single/ la quale istruisce
	<tt/init/ di avviare il computer in modalit&agrave; singolo utente, non
	lanciando tutti i demoni usuali. Controllare la pagina di manuale per la
	versione di <tt/init/ installata sul proprio sistema per vedere quali
	argomenti accetta.

<sect>Argomenti di avvio Generali non specifici di dispositivo <label id="general">
<p>
	Questi sono argomenti di avvio che non sono relativi a nessuno
	specifico dispositivo o periferica. Essi sono invece relativi a
	certi parametri interni del kernel, come la gestione della memoria,
	gestione del ramdisk, gestione del filesystem di root e altri.

<sect1> Opzioni del Filesystem di root
<p>
	Tutte le seguenti opzioni si riferiscono a come il kernel seleziona
	e gestisce il filesystem di root.

<sect2>L'argomento `root='
<p>
	Questo argomento dice al kernel quale dispositivo deve essere usato come
	filesystem di root durante l'avvio. L'impostazione di default
	&egrave; il valore del dispositivo di root del sistema sul quale
	&egrave; stato compilato il kernel.
	Per esempio, se il kernel in questione &egrave; stato compilato su un sistema
	che usava `/dev/hda1' come parizione di root, allora il default
	del dispositivo di root dovrebbe essere `/dev/hda1'. Per sovrascrivere questo
	valore di default, e selezionare il secondo floppy drive come dispositivo di root,
	si dovrebbe usare `root=/dev/fd1'.

	Dispositivi di root validi sono ciascuno dei seguenti dispositivi:

	(1) da /dev/hdaN a /dev/hddN, che sarebbe la partizione N su disco compatibile ST-506
	da `a a d'.

	(2) da /dev/sdaN a /dev/sdeN, che sarebbe la partizione N su disco compatibile SCSI
	da `a a e'.

	(3) da /dev/xdaN a /dev/xdbN, che sarebbe la partizione N su disco compatibile XT
	da `a a b'.

	(4) /dev/fdN, che sarebbe il disco floppy drive numero N. Avendo
	N=0 dovrebbe essere il DOS drive `A:', e N=1  dovrebbe essere `B:'.

	(5) /dev/nfs, che non &egrave; realmente un dispositivo, ma piuttosto un
	flag per dire al kernel di prendere il fs di root via rete.

	(6) /dev/ram, che &egrave; la RAM disk.

	&Egrave; anche accettata la pi&ugrave; inopportuna e meno portabile specificazione
	numerica dei possibili dispositivi di disco di sopra nel formato major/minor.
	(es. /dev/sda3 &egrave; major 8, minor 3, cos&igrave; si potrebbe usare
	<tt/root=0x803/ come alternativa.)

	Questo &egrave; uno dei pochi argomenti di avvio del kernel che ha i propri
	default memorizzati nell'immagine del kernel, e che pu&ograve; perci&ograve;
	essere alterato con l'utilit&agrave; <tt/rdev/ .


<sect2>L'argomento `rootflags='
<p>
	Questo argomento permette di dare opzioni che si riferiscono al
	montaggio del filesystem di root proprio come si farebbe col programma
	<tt/mount/ . Un esempio potrebbe essere dare l'opzione
	<tt/noatime/ a un fs ext2.

<sect2>L'argomento `rootfstype='
<p>
	Questa opzione permette di dare una lista di tipi di fs separati da virgola
	che saranno provati per il corretto accoppiamento quando si prova a
	montare il filesystem di root. Questa lista sar&agrave; usata al posto
	di quella interna di default che usualmente inizia con ext2,
	minix ecc.

<sect2>L'argomento `ro'
<p>
	Quando il kernel si avvia, ha bisogno di un filesystem di root per leggerci
	le cose basilari. Questo &egrave; il filesystem di root che viene
	montato all'avvio. Comunque se il filesystem di root fosse montato
	con accesso di scrittura, non si potrebbe controllare in modo affidabile
	l'integrit&agrave; del filesystem	con alcuni file mezzi-scritti in corso.
	L'opzione `ro' dice al kernel di montare il filesystem di root come
	`sola lettura' cos&igrave; che ogni programma di controllo della consistenza
	del filesystem (fsck) possa con sicurezza assumere che non ci sono file
	mezzi-scritti	in corso durante l'esecuzione del controllo. Nessun programma
	o processo pu&ograve; scrivere su file sul filesystem in
	questione fino a che sia `ri-montato' con capacit&agrave; di lettura/scrittura.

	Questo &egrave; uno dei pochi argomenti di avvio del kernel che ha i suoi
	default memorizzati nell'immagine del kernel, e che possono perci&ograve;
	essere modificati con l'utilit&agrave; <tt/rdev/ .

<sect2>L'argomento `rw'
<p>
	Questo &egrave; l'esatto opposto di quello di sopra, in quanto dice al
	kernel di montare il filesystem di root in lettura/scrittura. Il default
	&egrave; di montare il filesystem di root in sola lettura. Non eseguire
	nessun programma tipo 'fsck' su un filesystem che &egrave; montato
	in lettura/scrittura.

	Lo stesso valore memorizzato nel file immagine menzionato sopra &egrave;
	usato anche per questo parametro, accessibile via <tt/rdev/.

<sect2>L'argomento `nfsroot='
<p>
	Questo argomento dice al kernel quale macchina, quale directory
	e quale opzioni NFS usare per il filesystem di root.
	Notare anche che
	&egrave; richiesto l'argomento <tt>root=/dev/nfs</tt> . Informazioni
	detagliate sull'uso di un fs NFS di root sono nel file
	<tt>linux/Documentation/nfsroot.txt</tt>.


<sect2>L'argomento `ip=' o `nfsaddrs='
<p>
	Se si sta usando NFS come filesystem di root, allora non ci sono
	programi tipo <tt/ifconfig/ e <tt/route/ presenti fino a che
	il fs di root non viene montato, e cos&igrave; il
	kernel deve configurare l'interfaccia di rete direttamente.
	Questo argomento di avvio imposta i vari indirizzi dell'interfaccia di rete
	che sono richiesti per comunicare attraverso la rete. Se questo argomento
	non viene fornito allora il kernel prova a usare RARP e/o BOOTP per
	reperire questi parametri.

<sect1>Opzioni relative alla gestione del RAM Disk
<p>
	Le seguenti opzioni sono tute relative a come il kernel gestisce
	il dispositivo disco di RAM, il quale &egrave; normalmente usato per l'avvio
	di macchine durante la fase d'installazione, o per macchine con
	driver modulari che necessitano di essere installati per accedere al
	filesystem di root.

<sect2>L'argomento `ramdisk_start='
<p>
	Per permettere a un'immagine del kernel di risiedere su un floppy disk insieme con
	un'immagine compressa di ramdisk, &egrave; stato aggiunto il comando
	`ramdisk_start=&lt;offset&gt;'. Il kernel non pu&ograve; essere incluso
	nell'immagine compressa del filesystem di ramdisk, perch&eacute; perch&eacute;
	dovrebbe essere memorizzato ad partire dal blocco zero cos&igrave; che il BIOS
	possa caricare il bootsector e poi il kernel possa avviarsi e funzionare.

	Notare: Se si sta usando un'immagine di ramdisk non-compressa, allora il kernel
	pu&ograve; essere una parte dell'immagine del filesystem che &egrave; stato
	caricato nel ramdisk, e il floppy pu&ograve; essere avviato con LILO, o i due
	possono essere separati come viene fatto per le immagini compresse.

	Se si sta usando un'impostazione a due-dischi boot/root (kernel sul disco 1,
	immagine di ramdisk sul disco 2) allora il ramdisk dovrebbe iniziare dal blocco
	zero, e dovrebbe essere usato un offset zero. Dal momento che questo &egrave;
	il valore di default, in realt&agrave; non si dovrebbe affatto usare tale comando.

<sect2>L'argomento `load_ramdisk='
<p>
	Questo parametro dice al kernel se provare a caricare
	un'immagine di ramdisk o no. Specificando `load_ramdisk=1' si dir&agrave; al
	kernel di caricare un floppy in ramdisk. Il valore di default &egrave;
	zero, significa che il kernel non dovrebbe provare a caricare un ramdisk.

	Vedere il file <tt>linux/Documentation/ramdisk.txt</tt>
	per una descrizione completa dei nuovi argomenti di avvio, e come
	usarli. Viene anche descritto come questi parametri possono essere impostati
	e memorizzati nell'immagine del kernel via `rdev'.

<sect2>L'argomento `prompt_ramdisk='
<p>
	Questo parametro dice al kernel se dare o no un prompt per chiedere di
	inserire il floppy contenente l'immagine del ramdisk. In una configurazione
	con singolo floppy l'immagine del ramdisk &egrave; sullo stesso floppy
	del kernel che ha appena terminato il caricamento/avvio, cos&igrave; non occorre
	un prompt. In questo caso si pu&ograve; usare `prompt_ramdisk=0'. In una
	configurazione a due floppy, occorrer&agrave; dare la possibilit&agrave; di
	cambiare disco, perci&ograve; si pu&ograve; usare `prompt_ramdisk=1'. Dal
	momento che questo &egrave; il valore di default non occorre in realt&agrave;
	che sia specificato. (Nota storica: Le persone scaltre usavano l'opzione di
	LILO `vga=ask' per mettere in pausa temporaneamente il processo di avvio e
	avere la possibilit&agrave; di cambiare il floppy di boot con quello di root.)

	Vedere il file <tt>linux/Documentation/ramdisk.txt</tt> per una descrizione
	completa dei nuovi argomenti di avvio, e come usarli. Viene anche descritto
	come questi parametri possono essere impostati e memorizzati nell'immagine
	del kernel attraverso `rdev'.

<sect2>L'argomento `ramdisk_size='
<p>
	Mentre &egrave; vero che il ramdisk cresce dinamicamente come richiesto,
	c'&egrave; un limite superiore per la propria dimensione cos&igrave; che non
	possa consumare tutta la RAM disponibile e rimanere in difficolt&agrave;. Il
	default &egrave; 4096 (cio&egrave; 4MB), che dovrebbe essere sufficentemente
	grande per qualsiasi bisogno. &Egrave; possibile sovrascrivere il default con
	una dimensione pi&ugrave; grande o pi&ugrave; piccola con questo
	argomento di avvio.

	Vedere il file <tt>linux/Documentation/ramdisk.txt</tt> per una descrizione
	completa dei nuovi argomenti di avvio, e di come usarli. Viene anche descritto
	come questi parametri possono essere impostati e memorizzati nell'immagine del
	kernel attraverso `rdev'.

<sect2>L'argomento `ramdisk_blocksize='
<p>
	Questo pu&ograve; essere regolato per una migliore gestione del comportamento
	della memoria. Citazione dal driver di ramdisk <tt/rd.c/:

	Dovrebbe essere auspicabile avere un soft-blocksize (che nel
	caso di driver di ramdisk &egrave; anche l'hard-blocksize ;) di
	PAGE_SIZE perch&eacute; facendo questo si raggiunger&agrave; una migliore
	impronta di memoria. Usando un rd_blocksize di BLOCK_SIZE nel peggiore dei casi
	renderemo le pagine buffer PAGE_SIZE/BLOCK_SIZE page non liberabili. Invece con un
	rd_blocksize di PAGE_SIZE si &egrave; sicuri che solo una pagina
	sar&agrave; protetta. Dipende dalla dimensione del ramdisk che si vuole
	per modificare il blocksize di ramdisk per raggiungere il migliore o il peggiore
	comportamento MM. Il default &egrave; ancora BLOCK_SIZE (che occorre a
	rd_load_image che suppone che il filesystem nell'immagine usi
	un blocksize BLOCK_SIZE)

<sect2>L'argomento `ramdisk=' (obsoleto)
<p>
	(NOTARE: questo argomento &egrave; obsoleto, e non dovrebbe essere usato ad eccezione
	dei kernel v1.3.47 e pi&ugrave; vecchi. I comandi che dovrebbero essere usati
	per il dispositivo di ramdisk sono documentati sopra. Kernel pi&ugrave; nuovi
	possono accettare questo come un alias per <tt/ramdisk_size/.)

	Questo specifica la dimensione in kB del dispositivo di RAM disk.
	Per esempio, se si vuole avere un filesystem di root su un floppy da 1.44MB
	che sia caricato su un dispositivo di RAM disk, si dovrebbe usare:

<code>
	ramdisk=1440
</code>

	Questo &egrave; uno dei pochi argomenti di avvio del kernel che ha i suoi
	default memorizzati nell'immagine del kernel, e che possono perci&ograve;
	essere modificati con l'utilit&agrave; <tt/rdev/ .



<sect2>L'argomento `noinitrd' (RAM disk iniziale)
<p>
	I kernel v2.x e successivi hanno una caratteristica dove il filesystem di root
	pu&ograve; essere inizialmente un RAM disk, e il kernel esegue <tt>/linuxrc</tt>
	su quell'imagine RAM. Questa caratteristica &egrave; usata tipicamente per
	permettere il caricamento di moduli che occorrono per montare il reale
	filesystem di root (es. carica i moduli di driver SCSI memorizzati nell'imagine
	di RAM disk, e dopo monta il reale filesystem di root su un disco SCSI.)

	L'effettvo argomento `noinitrd' determina che cosa accada ai
	dati initrd dopo che il kernel &egrave; stato avviato. Quando
	specificato, invece di convertirlo in un RAM disk, esso &egrave; accessibile
	via <tt>/dev/initrd</tt>, il quale pu&ograve; essere letto una volta
	prima che la RAM sia rilasciata al sistema. Per completi dettagli
	su come usare il RAM disk iniziale, prego consultare
	<tt>linux/Documentation/initrd.txt</tt>. In aggiunta, le pi&ugrave;
	recenti versioni di <tt/LILO/ e <tt/LOADLIN/ dovrebbero avere informazioni
	utili aggiuntive.


<sect1>Argomenti di avvio relativi alla gestione della memoria
<p>
	I seguenti argomenti alterano come Linux rileva o gestisce
	la memoria fisica e virtuale del proprio sistema.

<sect2>L'argomento `cachesize='
<p>
	Sovrascrive il rilevamento della dimensione della cache di CPU di secondo
	livello (in kB). A volte bug hardware di CPU fanno valutare la dimensione della
	cache incorrettamente. Il kernel far&agrave; dei tentativi per correggere i
	problemi conosciuti, ma per alcune CPU non &egrave; possibile determinare quale
	dovrebbe essere la dimensione corretta. Questa opzione fornisce una
	sovrascrittura per queste situazioni.

<sect2>L'argomento `mem='
<p>
	Questo argomento ha diversi scopi: lo scopo origninale era di
	specificare l'ammontare della memoria installata (o un valore minore di
	quello se si voleva limitare l'ammontare della memoria disponibile a
	linux).

	Il successivo scopo (e difficilmente usato) &egrave; di specificare
	<tt/mem=nopentium/ il quale dice al kernel Linux di non usare
	la caratteristica di prestazione della page table di di 4MB. Se si vuole usarlo
	per entrambi gli scopi, usare un <tt/mem=/ separato per ciascuno.

	La chiamata originale del BIOS definita nella specificazione del PC che
	riporta l'ammontare della memoria installata era progettata solo per
	essere in grado di riportare fino a 64MB. (s&igrave;, un'altra mancata previsione,
	proprio come il cilindro 1024 del disco... sigh.) Linux usa questa chiamata
	del BIOS all'avvio per determinare quanta memoria &egrave; installata. Una
	specifica pi&ugrave; nuova (e820) permette al BIOS di rilevare questo dato
	corretamente sulla maggior parte delle macchine di oggi. Se si ha pi&ugrave;
	di 64MB di RAM installata su una vecchia macchina, si pu&ograve; usare questo
	argomento di avvio per dire a Linux quanta memoria si ha.
	Ecco una citazione da Linus sull'uso del parametro <tt/mem=/ .

	``Il kernel accetter&agrave; ogni parametro `mem=xx' gli si fornisca, e se
	risulta che gli si &egrave; mentito, esso terminer&agrave; orribilmente prima
	o poi. Il parametro indica il pi&ugrave; alto indirizzo di RAM indirizzabile,
	cos&igrave; `mem=0x1000000' significa che si hanno 16MB di memoria, per esempio.
	Per una macchina di 96MB questo dovrebbe essere `mem=0x6000000'. Se si dice a
	Linux che ha pi&ugrave; memoria di quella che ha realmente, accadranno brutte
	cose: forse non la prima volta, ma prima o poi sicuramente.''

	Notare che l'argomento non deve essere in esadecimale, e pu&ograve; essere
	usato il suffisso `k' e `M' (case insensitive) per specificare kilobyte e
	Megabyte, rispettivamente. (Un `k' causer&agrave; uno spostamento di 10 bit
	al proprio valore, e una `M' causer&agrave; uno spostamento di 20 bit.)
	Un tipico esempio per una maccina da 128MB dovrebbe essere "<tt/mem=128m/".

	In alcuni casi, anche la memoria riportata attraverso e820 pu&ograve; essere sbagliata,
	e cos&igrave; &egrave; stata aggiunto <tt/mem=exactmap/ . Si usa questo
	insieme alla specifica di un'esatta mappa di memoria, come:

<code>
	mem=exactmap mem=640K@0 mem=1023M@1M
</code>

	per una macchina da 1GB con l'usuale 384k di spazio I/O mappato per la memoria ISA
	escluso dall'utilizzo.


<sect2>L'argomento `memfrac='
<p>
	La memoria &egrave; suddivisa in zone; su gli i386 queste zone
	corrispondono al `DMA' (per i dispositivi ISA legacy che possono indirizzare
	solo fino a 16MB via DMA); `Normal' per memorie da 16MB fino a 1GB, e
	`HighMem' per memorie oltre 1GB (assumendo che il proprio kernel
	sia compilato con il supporto highmem abilitato). I due (o tre) interi forniti
	qui determinano quanta memoria dovrebbe essere tenuta libera in ogni zona
	- con la dimensione della zona divisa per il numero
	fornito usato come minimo (cos&igrave; pi&ugrave; piccoli sono i numeri
	significa tenerne pi&ugrave; libera nella zona). I default sono attualmente
	<tt>memfrac=32,128,128</tt>.

<sect2>L'argomento `swap='
<p>
	Questo permette all'utente di aggiustare alcuni dei parametri della memoria virtuale (VM)
	che sono relativi allo swapping su disco. Esso accetta
	i seguenti otto parametri:

<code>
	MAX_PAGE_AGE
	PAGE_ADVANCE
	PAGE_DECLINE
	PAGE_INITIAL_AGE
	AGE_CLUSTER_FRACT
	AGE_CLUSTER_MIN
	PAGEOUT_WEIGHT
	BUFFEROUT_WEIGHT
</code>

	Agli hacker interessati si consiglia di leggere
	<tt>linux/mm/swap.c</tt> e anche di notare le buone cose in
	<tt>/proc/sys/vm</tt>. I Kernel sono forniti con
	della documentazione utile su questo nella directory
	<tt>linux/Documentation/vm/</tt> directory.

<sect2>L'argomento `buff='
<p>
	Simile all'argomento `swap=', questo permette all'utente di
	aggiustare alcuni dei parametri relativi alla gestione del buffer di memoria.
	Esso accetta i seguenti sei parametri:

<code>
	MAX_BUFF_AGE
	BUFF_ADVANCE
	BUFF_DECLINE
	BUFF_INITIAL_AGE
	BUFFEROUT_WEIGHT
	BUFFERMEM_GRACE
</code>

	Agli hacker interessati si consiglia di leggere
	<tt>linux/mm/swap.c</tt> e anche di notare le buone cose
	in <tt>/proc/sys/vm</tt>.I Kernel sono forniti con
	della documentazione utile su questo nella directory
	<tt>linux/Documentation/vm/</tt>.

<sect1>Altri vari argomenti di avvio del kernel
<p>
	Questi vari argomenti di avvio permettono all'utente di aggiustare certi
	parametri interni del kernel.

<sect2>L'argomento `acpi='
<p>
	Attualmente questo accetta solo `off' per disabilitare il sottosistema ACPI.

<sect2>L'argomento `console='
<p>
	Di solito la console &egrave; il primo terminale virtuale, e cos&igrave; i
	messaggi d'avvio appaiono sul proprio video VGA. A volte &egrave; interessante
	avere la possibilit&agrave; di usare un'altro dispositivo tipo una porta seriale
	(o perfino una stampante!) per fargli fare da console quando non &egrave;
	presente alcun dispositivo video. &Egrave; anche utile catturare i messaggi
	d'avvio se un problema ferma il loro progredire prima che essi possano essere
	loggati su disco. Un esempio sarebbe di usare <tt>console=ttyS1,9600</tt> per
	selezionare la seconda porta seriale a 9600 baud per fare da console.
	Maggiori informazioni possono essere trovate in
	<tt>linux/Documentation/serial-console.txt</tt>.

<sect2>L'argomento `debug'
<p>
	Il kernel comunica messaggi importanti (e non cos&igrave; importanti)
	all'operatore attraverso la funzione <tt/printk()/ .
	Se il messaggio &egrave; considerato importante, la funzione <tt/printk()/
	metter&agrave; una copia sulla console attuale cos&igrave; come
	la passer&agrave; al servizio <tt/klogd()/ cos&igrave; che esso
	rimanga loggato sul disco. La ragione per stampare i messaggi
	importanti alla console cos&igrave; come loggarli sul disco &egrave;
	perch&eacute; sotto sfortunate circostanze (es. un guasto di un disco)
	il messaggio non verr&agrave; riportato su disco e sar&agrave; perso.

	Il limite per cosa &egrave; e cosa non &egrave; considerato importante
	&egrave; impostato dalla variabile <tt/console_loglevel/ . Il default &egrave;
	di loggare ogni cosa pi&ugrave; importante di <tt/DEBUG/ (livello 7) alla
	console. (Questi livelli sono definiti nel file include
	<tt/kernel.h/) Specificando <tt/debug/ come argomento di avvio imposter&agrave;
	il livello di log della console a 10, cos&igrave; che <em/tutti/ i messaggi del
  kernel appariranno sulla console.

	Il livello di log della console pu&ograve; anche essere impostato usualmente
	all'avvio attraverso un'opzione del programma <tt/klogd()/ . Controllare la
	pagina di manuale per la versione installata sul proprio sistema per vedere
	come fare ci&ograve;.

<sect2>L'argomento `decnet='
<p>
	Se si sta usando DECnet, si possono fornire qui due interi separati da virgola
	per dare rispettivamente la propria area e nodo.

<sect2>L'argomento `devfs='
<p>
	Se si sta usando devfs, invece dei dispositivi standard statici
	in <tt>/dev/</tt> allora con questo argomento si possono fornire le parole
	<tt>only</tt> o <tt>mount</tt>.
	Ci sono anche argomenti aggiuntivi di debug che sono elencati
	nel sorgente.

<sect2>L'argomento `gpt'
<p>
	Se si sta usando la gestione della tabella delle partizioni EFI GUID, si
	pu&ograve; usare questo per sovrascrivere i problemi associati ad un invalido PMBR.

<sect2>L'argomento `idle='
<p>
	Impostando questo a `poll' causa al loop idle nel kernel di verificare
	l'occorrenza del flag di reschedule invece di aspettare il verificarsi
	dell'interrupt. Questo pu&ograve; determinare un incremento di performance su
	sistemi SMP (anche se al costo di un incremento del consumo di energia).

<sect2>L'argomento `init='
<p>
	Il kernel per default esegue il programma `init' all'avvio,
	il quale ha cura di impostare il computer per gli utenti
	attraverso l'esecuzione di programmi getty, eseguendo gli script `rc' e similari.
	Il kernel prima cerca <tt>/sbin/init</tt>, poi
	<tt>/etc/init</tt> (deprecato), e per ultimo,
	prover&agrave; a usare <tt>/bin/sh</tt> (possibilmente su <tt>/etc/rc</tt>).
	Se per esempio, il proprio programma init &egrave; corrotto e perci&ograve; blocca
	la possibilit&agrave; dell'avvio, si pu&ograve; semplicemente usare il prompt di avvio
	<tt>init=/bin/sh</tt> il quale all'avvio si caler&agrave; direttamente in una
	shell, permettendo la sostituzione del programma corrotto.

<sect2>L'argomento `isapnp='
<p>
	Questo prende la forma di:
	<tt>isapnp=read_port,reset,skip_pci_scan,verbose</tt>

<sect2>L'argomento `isapnp_reserve_dma='
	<p>
	Questo prende la forma di:
	<tt>isapnp_reserve_dma=n1,n2,n3,...nN</tt>
	dove n1 ... nN sono i numeri di canale DMA da non usare per il PnP.

<sect2>L'argomento `isapnp_reserve_io='
<p>
	Questo prende la forma di:
	<tt>isapnp_reserve_irq=io1,size1,io2,size2,...ioN,sizeN</tt>
	dove ioX,sizeX sono le coppie d'inizio e lunghezza delle regioni I/O
	nello spazio I/O che non devono essere usate dal PnP.

<sect2>L'argomento `isapnp_reserve_irq='
<p>
	Questo prende la forma di:
	<tt>isapnp_reserve_irq=n1,n2,n3,...nN</tt>
	dove n1 ... nN sono i numeri degli interrupt da non usare per il PnP.

<sect2>L'argomento `isapnp_reserve_mem='
<p>
	Questo prende la forma di:
	<tt>isapnp_reserve_mem=mem1,size1,mem2,size2,...memN,sizeN</tt>
	dove ioX,sizeX sono le coppie di inizio e lunghezza delle regioni I/O
	nello spazio di memoria che non devono essere usate dal PnP.

<sect2>L'argomento `kbd-reset'
<p>
	Normalmente su macchine basate su i386, il kernel Linux non
	resetta il controller della tastiera all'avvio, dal momento che si
	suppone lo faccia il BIOS. Ma come di solito, non tutte le macchine fanno quello
	che dovrebbero. Fornendo questa opzione pu&ograve; aiutare se si hanno
	problemi con il comportamento della propria tastiera. Esso semplicemente forza un
	reset al momento dell'inizializzazione. (Qualcuno sostiene che questo dovrebbe
	essere il comportamento di default in ogni caso).

<sect2>L'argomento `lockd.udpport=' e `lockd.tcpport'
<p>
	Questi dicono al kernel di usare i numeri di porta forniti per
	l'operazione lockd di NFS (per operazioni o UDP o TCP).

<sect2>L'argomento `maxcpus='
<p>
	Il numero fornito con questo argomento limita il numero massimo
	di CPU attivate in modalit&agrave; SMP. Usando un valore
	0 &egrave; equivalente all'opzione <tt/nosmp/ .

<sect2>L'argomento `mca-pentium'
<p>
	Le macchine IBM modello 95 Microchannel sembra si blocchino sul test che Linux
	usualmente fa per rilevare il tipo di accoppiamento del chip matematico.
	Dal momento che tutti i chip Pentium hanno incluso il processore matematico
	questo test (e il problema del blocco) pu&ograve; essere evitato usando
	questa opzione d'avvio.

<sect2>L'argomento `md='
<p>
	Se il proprio filesystem di root &egrave; su un dispositivo multiplo allora si
	pu&ograve; usare questo (assumendo che si sia compilato nel supporto d'avvio)
	per dire al kernel il layout del dispositivo multiplo. Il formato (dal file
	<tt>linux/Documentation/md.txt</tt>) &egrave;:

	<tt>md=md_device_num,raid_level,chunk_size_factor,fault_level,dev0,dev1,...,devN</tt>

	Dove <tt/md_device_num/ &egrave; il numero del dispositivo md, es. 0 significa
	md0, 1 significa md1, ecc. Per <tt/raid_level/, usare -1 per la modalit&agrave;
	lineare e 0 per la modalit&agrave; striped. Altre modalit&agrave; non sono
	attualmente supportate. Il <tt/chunk_size_factor/ &egrave; solo per il raid-0
	e raid-1 e imposta il chunk size come PAGE_SIZE spostando a sinistra il valore
	specificato. Il <tt/fault_level/ &egrave; solo per il raid-1 e imposta il
	numero massimo di fault al numero specificato. (Attualmente non supportato
	a causa della mancanza di supporto all'avvio per il raid1). I <tt/dev0-devN/
	sono una lista di dispositivi separati da virgola che compongono il dispositivo
	md individuale: es. <tt>/dev/hda1,/dev/hdc1,/dev/sda1</tt>

	Vedere anche <tt/raid=/.

<sect2>L'argomento `nmi_watchdog='
<p>
	Fornendo un intero non-zero si abiliter&agrave; l'interrupt watchdog
	non mascherabile (assumendo che il supporto IO APIC sia incluso).
	Questo verifica se il contatore di interrupt si incrementa (indicando la
	normale attivit&agrave; del sistema) e in caso contrario assume che un
	processore sia inceppato e forza un dump d'errore di informazioni diagnostiche.

<sect2>L'argomento `no387'
<p>
	Alcuni chip coprocessori i387 hanno bug si evidenziano quando usati in
	modalit&agrave; protetta a 32 bit. Per esempio alcuni dei primi chip ULSI-387
	causerebbero forti blocchi durante l'esecuzione di calcoli a virgola mobile,
	apparentemente dovuti a un bug nelle istruzioni FRSAV/FRRESTOR. L'uso
	dell'argomento di avvio `no387' fa s&igrave; che Linux ignori il coprocessore
	matematico in caso se ne abbia uno. Certamente si deve poi aver compilato il
	proprio kernel con il supporto all'emulazione matematica! Questo pu&ograve;
	anche essere utile se si ha una di queste macchine 386 <em/veramente/ vecchie
	che possono usare un 80287 FPU, dal momento che Linux non pu&ograve; usare un 80287.

<sect2>L'argomento `no-hlt'
<p>
	La famiglia delle CPU i386 (e da ci&ograve; i suoi successori) ha un'istruzione
	`hlt' che dice alla CPU che non deve accadere niente fino a che un dispositivo
	esterno (tastiera, modem, disco, etc.) invita la CPU a eseguire un task. Questo
	permette alla CPU di entrare in una modalit&agrave; a `basso consumo' dove essa
	si ferma come uno zombie fino a che un dispositivo esterno la sveglia
	(usualmente attraverso un interrupt). Alcuni dei primi chip i486DX-100 ebbero
	un problema con l'istruzione `hlt', in quanto essi non potevano ritornare
	attendibilmente alla modalit&agrave; operativa dopo che era stata usata questa
	istruzione. Usando l'istruzione `no-hlt' si dice a Linux di eseguire un loop
	infinito quando non c'&egrave; niente altro da fare, e di <em/non/ fermare la
	propria CPU quando non c'&egrave; attivit&agrave;. Questo permette alle persone
	con questi chip guasti di usare Linux, sebbene essi dovrebbero essere ben
	avvisati di cercare una sostituzione in garanzia dove possibile.

<sect2>L'argomento `no-scroll'
<p>
	Usando questo argomento all'avvio disabilita le caratteristiche di scroll che
	rendono difficile l'uso di terminali Braille.

<sect2>L'aromento `noapic'
<p>
	L'uso di questa opzione dice a un kernel SMP di non usare alcune delle
	caratteristiche avanzate del controller di interrupt su macchine multi processore.
	L'uso di questa opzione pu&ograve; essere richiesto quando un dispositivo
	(come quelli che usano i driver ne2k-pci o 3c59xi) ferma la generazione di
	interrupt (es. <tt>cat /proc/interrupts</tt> mostra lo stesso contatore di
	interrupt). Vedere <tt>linux/Documentation/IO-APIC.txt</tt> per maggiori
	informazioni.

<sect2>L'argomento `noht'
<p>
	Questo disabiliter&agrave; l'hyper-threading su processori intel che
	hanno questa caratteristica.

<sect2>L'argomento `noisapnp'
<p>
	Se ISA PnP &egrave; compilato nel kernel, questo lo disabiliter&agrave;.

<sect2>L'argomento `nomce'
<p>
	Alcuni processori pi&ugrave; recenti hanno la capacit&agrave; di auto-monitorare
	e rilevare le inconsistenze che non dovrebbero normalmente accadere.
	Se viene rilevata un'inconsistenza, avverr&agrave; un "Machine Check Exception"
	e il sistema sar&agrave; fermato (piuttosto che la perdita prosegua e i propri
	dati vengano corrotti). Si pu&ograve; usare questo argomento per disabilitare
	questa caratteristica, ma prima assicurarsi di controllare che la propria CPU
	non sia in surriscaldamento o altrimenti difettosa.

<sect2>L'argomento `nosmp'
<p>
	L'uso di questa opzione dir&agrave; a un kernel SMP su una macchina SMP di
	operare in singolo processore. Tipicamente usata solo per il debug
	e la determinazione se un particolare problema sia relativo al SMP.

<sect2>L'argomento `noresume'
<p>
	Se &egrave; abilitata la sospensione del software, ed &egrave; stata specificata
	una sospensione su file su disco, usando questo argomento si avr&agrave; un
	avvio normale e la sospensione dei dati sar&agrave; ignorata.

<sect2>L'argomento `notsc'
<p>
	L'uso di questa opzione dir&agrave; al kernel di non usare per niente il
	Time Stamp Counter, anche se la CPU ne ha uno.

<sect2>L'argomento `nofxsr"
<p>
	L'uso di questa opzione dir&agrave; al kernel di non usare
	alcun trucco di accellerazione incluso l'unit&agrave; a virgola mobile,
	anche se il processore li supporta.

<sect2>L'argomento `panic='
<p>
	Nello sfortunato evento di un kernel panic (es. un errore interno che viene
	rilevato dal kernel, e che il kernel decide sia serio a sufficenza da urlarlo
	e poi fermare il tutto), il comportamento di default &egrave; solo di fermarsi
	fino a che qualcuno si faccia avanti, si accorga del "panic message" sullo
	schermo e riavvii la macchina. Comunque se una macchina &egrave; in esecuzione
	non sorvegliata in un posto isolato pu&ograve; essere desiderabile farla
	resettare automaticamente cos&igrave; che
	la macchina ritorni in linea. Per esempio, usando all'avvio <tt/panic=30/
	il kernel dovrebbe provare a riavviarsi da solo 30 secondi dopo l'avvenuta del
	kernel panic. Un valore di zero d&agrave; il comportamento di default, che
	&egrave; di aspettare indefinitamente.

	Notare che questo valore di timeout pu&ograve; anche essere letto e impostato
	attraverso l'interfaccia sysctl sul <tt>/proc/sys/kernel/panic</tt>.

<sect2>L'argomento `pirq='
<p>
	Usando questa opzione si d&agrave; a un kernel SMP l'informazione sul valore
	di IRQ dello slot PCI per le schede madri SMP che non sono
	conosciute (o conosciute essere in blacklist).
	Vedere <tt>linux/Documentation/IO-APIC.txt</tt> per maggiori informazioni.

<sect2>L'argomento `profile='
<p>
	Gli sviluppatori del Kernel possono
	descrivere come e dove il kernel spende i suoi cicli di CPU
	nello sforzo di massimizzare l'efficenza e la performance. Questa opzione
	lascia impostare il contatore dello spostamento di profilo all'avvio.
	Tipicamente &egrave; impostato a due. Occorre un tool come
	<tt/readprofile.c/ che possa fare uso dell'output di <tt>/proc/profile</tt>

<sect2>L'argomento `quiet'
<p>
	Questo &egrave; molto grazioso e opposto all'argomento `debug'. Quando questo
	viene fornito, sono visualizzati alla console solo i messaggi del kernel
	critici di sistema e quelli importanti. I messaggi normali
	circa il rilevamento dell'hardware all'avvio sono soppressi.

<sect2>L'argomento `raid='
<p>
	Al momento accetta <tt/noautodetect/ . Vedere anche <tt/md=/.

<sect2>L'argomento `reboot='
<p>
	Questa opzione controlla il tipo di reboot che Linux far&agrave;
	quando si resetta il computer (tipicamente attraverso <tt>/sbin/init</tt>
	gestendo un Control-Alt-Delete). Il default dei kernel v2.0 &egrave; di fare
	un riavvio a `freddo' (es. un completo reset, il BIOS fa il controllo della
	memoria, ecc.) invece di un riavvio a `caldo' (es. reset parziale, nessun
	controllo della memoria). &Egrave; stato modificato per essere freddo di default
	dal momento che si tende a lavorare su hardware economico/guasto che fallisce
	il riavvio quando si richiede un riavvio a caldo. Per avere il vecchio
	comportamento (es. riavvio a caldo) usare <tt/reboot=w/ o in pratica
	funzioner&agrave; qualsiasi parola che inizia per <tt/w/.

	Le altre opzioni accettate sono `c', `b', `h', e `s', che stanno per cold/freddo,
	bios, hard, e SMP rispettivamente. L'opzione `s' prende una cifra opzionale
	per specificare quale CPU dovrebbe gestire il riavvio. Le opzioni
	possono essere combinate, dove ci&ograve; &egrave; sensato, es. <tt/reboot=b,s2/

<sect2>L'argomento `reserve='
<p>
	Questo viene usato per <em/proteggere/ regioni di porte I/O dalla rilevazione.
	La forma del comando &egrave;:

<tscreen>
	reserve=iobase,extent&lsqb;,iobase,extent&rsqb;...
</tscreen>

	In alcune macchine pu&ograve; essere necessario prevenire che i driver dei
	dispositivi controllino i dispositivi (auto-rilevamento) in una regione specifica.
	Questo pu&ograve; essere a causa di hardware mal progettato che causa
	<em/blocchi/ all'avvio (cos&igrave; come alcune schede ethernet), hardware che
	viene identificato erroneamente, hardware il cui stato viene modificato da un
	primo rilevamento, o solo hardware che non si vuole che il kernel inizializzi.

	L'argomento di avvio <tt/reserve/ risolve questo problema con la specifica di
	una regione di porta I/O che non dovrebbe essere rilevata. Quella regione
	&egrave; riservata nella tabella di registrazione delle porte del kernel come
	se un dispositivo fosse gi&agrave; stato trovato in quella regione (con il nome
	<tt/reserved/). Notare che questo meccanismo non dovrebbe essere necessario
	sulla maggior parte delle macchine. Dovrebbe essere necessario il suo uso solo
	quando c'&egrave; un problema o un caso speciale.

	Le porte I/O nella regione specificata sono protette contro i rilevamenti di
	dispositivi i quali eseguono un <tt/check_region()/ prima della cieca rilevazione
	dentro una regione di spazio I/O. Questo &egrave; stato inserito per essere usato
	quando alcuni driver erano sospesi su una NE2000, o mal-identificavano alcuni
	altri dispositivi come loro propri. Un corretto driver di dispositivo non dovrebbe
	scandagliare una regione riservata, a meno che un'altro argomento di avvio
	specifichi esplicitamente di farlo. Questo implica che <tt/reserve/ sar&agrave;
	molto spesso usato con altri argomenti di avvio. Quindi se si specifica
	una regione <tt/riservata/ per proteggere uno specifico dispositivo si deve
	generalmente specificare poi una rilevazione esplicita per quel dispositivo.
	La maggior parte dei driver ignorano la tabella di registrazione delle porte
	se gli viene fornito un indirizzo esplicito.

	Per esempio, la riga di avvio

<code>
	reserve=0x300,32  blah=0x300
</code>

	riserva dalla rilevazione tutti i driver di dispositivo eccetto il driver per `blah' <tt>0x300-0x31f</tt>.

	Come solito con le specifiche dell'avvio c'&egrave; un limite di 11 parametri,
	perci&ograve; si possono specificare solo 5 regioni riservate per chiave
	<tt/reserve/. Specifiche multiple di <tt/reserve/ funzioneranno se si ha una insolita
	e complicata richiesta.

<sect2> L'argomenyo `resume='
<p>
	Se si sta usando il software di sospensione, allora questo permetter&agrave; di
	specificare il nome del file dei dati di sospensione su disco che si
	vuole dal quale la macchina esegua il ripristino.

<sect2> L'argomento `vga='
<p>
	Notare che questo non &egrave; realmente un argomento di avvio. &Egrave; un'opzione
	che viene interpretata da LILO e non dal kernel come lo sono tutti gli altri
	argomenti di avvio. Comunque il suo uso &egrave; divenuto cos&igrave; comune
	che qui si merita una menzione. Esso pu&ograve; essere impostato attraverso l'uso
	di <tt/rdev -v/ o equivalentemente <tt/vidmode/ nel file vmlinuz.
	Questo permette di impostare il codice da usare per il BIOS video per modificare
	la modalit&agrave; di display di default prima del reale avvio del kernel Linux.
	Le modalit&agrave; tipiche sono 80x50, 132x44 e cos&igrave; via. Il miglior
	modo per usare questa opzione &egrave; di iniziare con <tt/vga=ask/ la quale
	proporr&agrave; una lista di varie modalit&agrave; che possono essere usate
	con il proprio adattatore video prima di avviare il kernel. Una volta
	scelto un numero che si vuole usare dalla lista di sopra, si
	pu&ograve; inserirlo al posto di `ask'. Per maggiori informazioni,
	vedere il file <tt>linux/Documentation/svga.txt</tt>
	che viene fornito con tutte le recenti versioni del kernel.

	Notare che i nuovi kernel (dal v2.1 in poi) hanno il codice di setup che
	modifica la modalit&agrave; video come un'opzione, viene elencato come
	<tt/supporto alla selezione della modalit&agrave; video/ cos&igrave; che occorre
	abilitare questa opzione se si desidera usare questa caratteristica\.

<sect>Argomenti di avvio per controllare il comportamento del bus PCI (`pci=')
<p>
	L'argomento `pci=' (non disponibile nei kernel v2.0)
	pu&ograve; essere usato per modificare il comportamento della rilevazione dei
	dispositivi a bus PCI e il comportamento del dispositivo stesso. In primo
	luogo il file <tt>linux/drivers/pci/pci.c</tt> controlla
	le opzioni <tt/pci=/ indipendentemente dall'architettura.
	Gli argomenti rimanenti permessi sono gestiti
	in <tt>linux/arch/???/kernel/bios32.c</tt> e sono
	elencati di seguito per ???=i386.

<sect1>L'argomento `pci=assign-busses'
<p>
	Questo dice al kernel di assegnare sempre tutti i numeri di bus PCI,
	sovrascrivendo qualsiasi cosa il firmware pu&ograve; aver fatto.

<sect1>Gli argomenti `pci=bios' e `pci=nobios'
<p>
	Questi sono usati per impostare o azzerare il flag che indica che la rilevazione
	PCI sta avvenendo attraverso il BIOS PCI. Il default &egrave; di usare il BIOS.

<sect1>Gli argomenti `pci=conf1' e `pci=conf2'
<p>
	Se &egrave; abilitata la modalit&agrave; diretta PCI, l'uso di questi abilita
	o il tipo di configurazione 1 o il tipo 2. Questi implicitamente
	azzerano anche il flag di rilevazione BIOS PCI (es. `pci=nobios').

<sect1>L'argomento `pci=irqmask='
<p>
	Questo permette all'utente di fornire un valore di maschera di IRQ, il quale
	&egrave; convertito usando strtol(). Esso imposter&agrave; un bit di maschera di valori IRQ
	che possono essere assegnati automaticamente ai dispositivi PCI. In questo modo
	si pu&ograve; far escludere al kernel gli IRQ delle proprie schede ISA.

<sect1>L'argomento `pci=lastbus='
<p>
	Questo permette all'utente di specificare un valore di ultimo bus, il quale
	&egrave; convertito usando strtol(). Esso scansioner&agrave; tutti i bus fino
	al bus N. Pu&ograve; essere utile se il kernel non &egrave; in grado di trovare
	i propri bus secondari e si vuole dirgli esplicitamente quali sono.

<sect1>L'argomento `pci=noacpi'
<p>

	Questo disabilita l'uso dell'informazione di routing di ACPI durante
	la fase di configurazione dei PCI.

<sect1>L'argomento `pci=nopeer'
<p>
	Questo disabilita il default di sistemazione dei peer bridge, il quale stando
	alle informazioni fa quanto segue:

	``In caso ci siano host bridge peer fa la scansione del bus di ognuno.
	Anche se alcune fonti sostengono che i bridge host dovrebbero avere
	il l'header tipo 1 e avere assegnato un numero di bus come per i bridge PCI2PCI
	la realt&agrave; non supera questa prova e il numero di bus
	&egrave; usualmente impostato dal BIOS al primo valore libero.''

<sect1>L'argomento `pci=nosort'
<p>
	Usando questo argomento si istruisce il kernel di non ordinare
	i dispositivi PCI durante la fase di rilevamento.

<sect1>L'argomento `pci=off'
<p>
	Usando questa opzione si disabilita il rilevamento di tutti i bus PCI. Ogni
	driver di dispositivo che fa uso di funzioni PCI per trovare
	e inizializzare l'hardware molto probabilmente non funzioner&agrave;.

<sect1>L'argomento `pci=usepirqmask'
<p>
	Questo imposta il flag USE_PIRQ_MASK durante l'init PCI.
	Il kernel onorer&agrave; la possibile maschera IRQ memorizzata
  nella tabella PIR BIOS. Questo &egrave; necessario su alcuni sistemi
	con BIOS fallati, specialmente alcuni notebook HP Pavilion N5400
	e Omnibook XE3. Questo non avr&agrave; effetto se
	&egrave; abilitato il routing ACPI IRQ.

<sect1>L'argomento `pci=rom'
<p>
	Questo imposta il flag ASSIGN_ROM durante la fase di rilevamento.
	Il kernel assegner&agrave; un'indirizzo di spazio per l'espansione ROM.
	Usare con cautela, poich&eacute; certi dispositivi condividono l'indirizzo
	decodificato tra ROM e altre risorse.


<sect>Argomenti di avvio per driver video frame buffer
<p>
	L'argomento `video=' (non disponibile nei kernel v2.0)
	&egrave; usato quando il livello di astrazione del dispositivo di frame buffer
	&egrave; compilato dentro il kernel. Se questo suona complicato, bene non
	&egrave; realmente troppo difficile. Di base significa che invece di avere un
	diverso programma video (il server X11R6) per ogni marca di scheda video
	(es. XF86_S3, XF86_SVGA, ...), il kernel dovrebbe avere
	un driver incluso disponibile per ogni scheda video ed esportare
	una singola interfaccia per il programma video cos&igrave; da
	richiedere solo un server X11R6 (XF86_FBDev). Questo &egrave; simile
	a come funziona la rete adesso - il kernel ha driver disponibili per
	ogni marca di scheda di rete ed esporta una singola interfaccia di rete
	cos&igrave; che esiste solo una versione del programma di rete
	(tipo Netscape) che funzioner&agrave; per tutti i sistemi, senza guardare alla
	marca della scheda di rete.


	Il formato tipico di questo argomento &egrave;
	<tt>video=name:option1,option2,...</tt>
	dove <tt/name/ &egrave; il nome di una generica opzione o di un
	driver frame buffer.
	L'opzione <tt/video=/ &egrave; passata da <tt>linux/init/main.c</tt>
	in <tt>linux/drivers/video/fbmem.c</tt> per ulteriori processi.
	Qui &egrave; controllato per alcune opzioni generiche prima di provare a
	accoppiarlo con un nome di driver conosciuto. Una volta che l'accoppiamento
	con un nome di driver &egrave; fatto, la lista di opzioni separate da virgola
	viene poi passata a quel particolare driver per l'esecuzione finale. La lista
	di nomi di driver validi pu&ograve; essere trovata leggendo la tabella
	<tt/fb_drivers/ nel file <tt/fbmem.c/ monzionato sopra.

	Informazioni sulle opzioni che ogni driver supporta saranno
	eventualmente trovate in <tt>linux/Documentation/fb/</tt> ma
	attualmente (v2.2) solo poche ci sono descritte.
	Sfortunatamente il numero
	di driver video e il numero delle opzioni per ciascuno
	&egrave; di per se abbastanza per un'altro documento e quindi
	troppo per essere elencato qui.

	Se non c'&egrave; file di Documentazione per la propria scheda, si
	dovr&agrave; prendere l'informazioni sulle opzioni
	direttamente dal driver. Andare in
	<tt>linux/drivers/video/</tt> e guardare il file appropriato
	<tt/???fb.c/ (i ??? si baseranno sul nome della scheda).
	L&agrave; cercare una funzione con <tt/_setup/ nel nome
	e si dovrebbero vedere quali opzioni il driver prova ad accoppiare,
	come <tt/font/ o <tt/mode/ o...

<sect1>L'argomento `video=map:...'
<p>
	Questa opzione &egrave; usata per impostare o sovrascrivere la console alla
	mappatura del dispositivo di frame buffer. Una lista di numeri separati da
	virgola imposta la mappatura, con il valore dell'opzione N preso a essere il
	numero di dispositivo frame buffer per la console N.

<sect1>L'argomento `video=scrollback:...'
<p>
	Un numero dopo i due punti imposter&agrave; la dimensione di memoria allocata
	per il buffer di scrollback. (Usare i tasti Shift e Pagina Su o Pagina Gi&ugrave;
	per fare lo scroll). Un suffisso di `k' o `K' dopo il numero indicher&agrave;
	che il numero deve essere interpretrato come kilobyte
	invece di byte.

<sect1>L'argomento `video=vc:...'
<p>
	Un numero o una gamma di numeri (es. <tt/video=vc:2-5/)
	specificher&agrave; la prima, o la prima e l'ultima console virtuale
	frame buffer. L'uso di questa opzione ha anche l'effetto di impostare la console
	frame buffer perch&eacute; <em/non/ sia la console di default.

<sect>Argomenti di avvio per perfiferiche SCSI.
<p>
	Questa sezione contiene le descrizioni degli argomenti di avvio che
	sono usati per passare informazioni circa gli adattatori host SCSI
	installati, e i dispositivi SCSI.

<sect1>Argomenti per i driver Superiori e Medio-livello
<p>
	I driver di livello superiore gestiscono tutti gli oggetti SCSI, senza badare
	se essi siano dischi, unit&agrave; a nastri, o CD-ROM.
	I driver di medio livello gestiscono oggetti come dischi, CD-ROM e
	unit&agrave; a nastri senza entrare nelle specifiche dei driver di dispositivi
	degli adattatori host di basso livello.

<sect2>Massime LUN rilevate (`max_scsi_luns=')
<p>
	Ogni dispositivo SCSI pu&ograve; avere un numero di `sotto-dispositivi' contenuti
	in se stesso. L'esempio pi&ugrave; comune &egrave; ogni
	CDROM SCSI che gestisce pi&ugrave; di un disco per volta.
	Ogni CD &egrave; indirizzato come un `Numero di Unit&agrave; Logica' (LUN) di
	quel particolare dispositivo. Ma la maggior parte dei dispositivi, come hard disk,
	unit&agrave; a nastro e simili sono solo un dispositivo, e saranno
	assegnati alla LUN zero.

	Il problema sorge con dispositivi a singolo LUN con firmware difettoso.
	Alcuni dispositivi SCSI mal progettati (vecchi e sfortunatamente anche nuovi)
	non possono gestire la rilevazione per LUN non uguale a zero. Essi
	risponderanno con un blocco, e la possibilit&agrave; di far cadere
	con loro l'intero bus SCSI.

	Il kernel ha un'opzione di configurazione che permette
	di impostare il numero massimo di LUN rilevati. Il default &egrave; di
	rilevare solo LUN zero, per evitare il problema descritto sopra.

	Per specificare il numero di LUN rilevati all'avvio, si immette
	`max_scsi_luns=n' come argomento di avvio, dove n &egrave; un numero tra
	uno e otto. Per evitare i problemi descritti sopra, si dovrebbe
	usare n=1 per evitare imprevisti con dispositivi guasti.

<sect2>Registrazione avvenimenti SCSI (`scsi_logging=')
<p>
	Fornendo un valore non-zero a questo argomento di avvio abilita
	la registrazione di tutti gli eventi SCSI (errori, scansioni, mlqueue, mlcomplete,
	llqueue, llcomplete, hlqueue, hlcomplete). Notare che un miglior
	controllo di questi eventi che sono registrati pu&ograve; essere ottenuto
	attraverso l'interfaccia <tt>/proc/scsi/scsi</tt> se non si &egrave;
	interessati agli eventi che accadono all'avvio prima
	che il filesystem <tt>/proc/</tt> sia accessibile.

<sect2>Parametri per unit&agrave; a nastro SCSI (`st=')
<p>
	Alcune configurazioni di avvio di unit&agrave; a nastri SCSI pu&ograve;
	essere realizzata con l'uso del seguente:

<code>
	st=buf_size&lsqb;,write_threshold&lsqb;,max_bufs&rsqb;&rsqb;
</code>

	I primi due numeri sono specificati in unit&agrave; di kB.
	Il default <tt/buf_size/ &egrave; 32kB, e la massima dimensione
	che pu&ograve; essere specificata &egrave; un ridicolo 16384kB.
	Il <tt/write_threshold/ &egrave; il valore al quale il buffer
	viene connesso all'unit&agrave; a nastro, con un valore di default di 30kB.
	Il massimo numero di buffer varia con il numero di drive
	rilevati, e ha un default di due. Un esempio d'uso dovrebbe essere:

<code>
	st=32,30,2
</code>

  Dettagli completi possono essere trovati nel file <tt/README.st/ che &egrave;
	nella directory <tt/scsi/ dell'albero dei sorgenti del kernel.

<sect1>Argomenti per driver di adattatori host SCSI
<p>

	Questi sono argomenti per driver di dispositivi host SCSI di basso livello,
	e come tali sono tipicamente usati solo da chi compila
	il proprio kernel con i driver SCSI inclusi. Queste
	persone sono avvisate di controllare i sorgenti per la lista aggiornata
	delle opzioni che possono essere fornite ai loro driver.

	<tt/aha152x=/ Adaptec aha151x, aha152x, aic6260, aic6360, SB16-SCSI

	<tt/aha1542=/ Adaptec aha1540, aha1542

	<tt/aic7xxx=/ Adaptec aha274x, aha284x, aic7xxx

	<tt/advansys=/ AdvanSys SCSI Host Adaptors

	<tt/in2000=/ Always IN2000 Host Adaptor

	<tt/AM53C974=/ AMD AM53C974 based hardware

	<tt/BusLogic=/ ISA/PCI/EISA BusLogic SCSI Hosts

	<tt/eata=/ EATA SCSI Cards

	<tt/tmc8xx=/ Future Domain TMC-8xx, TMC-950

	<tt/fdomain=/ Future Domain TMC-16xx, TMC-3260, AHA-2920

	<tt/ppa=/ IOMEGA Parallel Port / ZIP drive

	<tt/ncr5380=/ NCR5380 based controllers

	<tt/ncr53c400=/ NCR53c400 based controllers

	<tt/ncr53c406a=/ NCR53c406a based controllers

	<tt/pas16=/ Pro Audio Spectrum

	<tt/st0x=/ Seagate ST-0x

	<tt/t128=/ Trantor T128

	<tt/u14-34f=/ Ultrastor SCSI cards

	<tt/wd7000=/ Western Digital WD7000 cards


<sect>Hard Disk
<p>
	Questa sezione elenca tutti gli argomenti di avvio associati con
	MFM/RLL, ST-506, XT standard, e dispositivi disco drive IDE.
	Notare che entrambi i driver IDE e generici ST-506 HD
	accettano l'opzione `hd='.

<sect1>Parametri di driver Dischi/CD-ROM IDE
<p>
	Il driver IDE accetta un numero di parametri, che spazia
	dalle specifiche della geometria del disco, al supporto avanzato di controller
	di chip o controller chip guasti. I seguenti sono il sunto di
	alcuni dei pi&ugrave; comuni argomenti di avvio. Per dettagli completi, si
	dovrebbe <em/veramente/ consultare il file <tt/ide.txt/ nella directory
	<tt>linux/Documentation</tt>, dal quale &egrave; estratto questo riassunto.

<code>

 "hdx="  &egrave; riconosciuto per tutte le "x" da "a" a "h", come "hdc".
 "idex=" &egrave; riconosciuto per tutte le "x" da "0" a "3", come "ide1".

 "hdx=noprobe"		: l'unit&agrave; pu&ograve; essere presente, ma non rilevarla
 "hdx=none"		: l'unit&agrave; NON &egrave; presente, ignorare cmos e non rilevarla
 "hdx=nowerr"		: ignorare il bit WRERR_STAT su questa unit&agrave;
 "hdx=cdrom"		: l'unit&agrave; &egrave; presente, ed &egrave; un'unit&agrave; cdrom
 "hdx=cyl,head,sect"	: disk drive &egrave; presente, con la geometria specificata
 "hdx=autotune"		: il driver prover&agrave; a sintonizzare la velocit&agrave; dell'interfaccia
				alla pi&ugrave; veloce modalit&agrave; PIO supportata,
				se possibile solo per questa unit&agrave;.
				Non completamente supportata da tutti i tipi di chipset,
				abbastanza probabile che causi problemi con
				unit&agrave; pi&ugrave; vecchie o insolite.

 "idex=noprobe"		: non provare ad accedere o usare questa interfaccia
 "idex=base"		: rilevare un'interfaccia all'indirizzo specificato,
				dove "base" &egrave; usualmente 0x1f0 o 0x170
				e "ctl" &egrave; assunto essere "base"+0x206
 "idex=base,ctl"	: specifica entrambi base e ctl
 "idex=base,ctl,irq"	: specifica base, ctl, e numero di irq
 "idex=autotune"	: il driver prover&agrave; a sintonizzare la velocit&agrave; dell'interfaccia
				alla pi&ugrave; veloce modalit&agrave; PIO supportata,
				per tutte le unit&agrave; su questa interfaccia.
				Non pienamente supportata da tutti i tipi di chipset,
				abbastanza probabile che causi problemi con
				unit&agrave; IDE pi&ugrave; vecchie o insolite.
 "idex=noautotune"	: il driver NON prover&agrave; a sintonizzare la velocit&agrave; dell'interfaccia
				Questo &egrave; il default per la maggior parte dei chipset,
				eccetto il cmd640.
 "idex=serialize"	: non sovrapporre operazioni su idex e ide(x^1)

</code>

	I seguenti sono validi SOLO su ide0,
	e i default per la base ctl port non devono essere alterati.

<code>

 "ide0=dtc2278"		: esamina/supporta l'interfaccia DTC2278
 "ide0=ht6560b"		: esamina/supporta l'interfaccia HT6560B
 "ide0=cmd640_vlb"	: *RICHIESTO* per schede VLB con il chip CMD640
			  (non per PCI -- rilevato automaticamente)
 "ide0=qd6580"		: esamina/supporta l'interfaccia qd6580
 "ide0=ali14xx"		: esamina/supporta chipset ali14xx (ALI M1439/M1445)
 "ide0=umc8672"		: esamina/supporta chipset umc8672

</code>

	Durante l'installazione di qualche sistema PCMCIA, si pu&ograve; essere in grado
	di rilevare il proprio CD-ROM usando:
<code>

 "ide2=0x180,0x386"	: rileva la locazione dell'interfaccia tipica PCMCIA IDE

</code>

	Qualsiasi altra cosa &egrave; rigettata con il messaggio "BAD OPTION".
	Notare anche che c'&egrave; un implicito <tt/ide0=0x1f0 ide1=0x170/
	in assenza di ogni altro argomento ide di avvio.

<sect1>Old MFM/RLL/Standard ST-506 Disk Driver Options (`hd=')
<p>
	I driver di disco standard possono accettare argomenti di geometria per
	i dischi simili ai driver IDE. Notare comunque che ci si
	aspetta solo tre valori (C/H/S) -- altri in pi&ugrave; o in meno
	saranno ignorati silenziosamente. Inoltre, si accetta solo
	`hd=' come argomento, es. `hda=', `hdb=' e cos&igrave; via non
	sono validi qui. Il formato &egrave; come il seguente:

<code>
	hd=cyls,heads,sects
</code>

	Se ci sono due dischi installati, il suddetto viene ripetuto
	per i parametri di geometria del secondo disco.

<sect1>Opzioni di driver disco XT (`xd=', `xd_geo=')
<p>
	Se si &egrave; sufficentemente sfortunati da usare uno di queste vecchie
	schede a 8 bit che trasferiscono dati al massimo a 125kB/s allora ecco
	lo scoop. Il programma di rilevamento per queste schede cerca un BIOS installato,
	e se non &egrave; presente, non rilever&agrave; la propria scheda. Oppure,
	se la stringa di firma del proprio BIOS non &egrave; riconosciuta anche in questo caso
	non verr&agrave; rilevato. In ogni caso, si dovr&agrave; usare un
	argomento di avvio della forma:

<code>
	xd=type,irq,iobase,dma_chan
</code>

	Il valore <tt/type/ specifica la particolare marca della
	scheda, e i valori sono i seguenti: 0=generic; 1=DTC; 2,3,4=Western Digital,
	5,6,7=Seagate; 8=OMTI. La sola differenza tra tipi multipli
	dello stesso costruttore &egrave; la stringa del BIOS usata per il rilevamento,
	la quale non &egrave; usata se &egrave; specificato type.

	La funzione <tt/xd_setup()/ non controlla i valori, e
	assume che si immettano tutti i quattro valori. Non deluderla.
	Ecco un esempio di utilizzo per un controller WD1002 con il BIOS
	disabilitato o rimosso, usando i parametri di `default' del controller XT:

<code>
	xd=2,5,0x320,3
</code>

	Se la geometria del disco che il kernel stampa appare tutta
	sbagliata rispetto a quella che si conosce, &egrave; possibile sovrascriverla
	facilmente, con:

<code>
	xd_geo=cyl_xda,head_xda,sec_xda
</code>

	Aggiungere un'altra virgola e altri tre valori CHS se si &egrave;
	sufficentemente sciocchi da avere due dischi del vecchio pezzo da buttare...

<sect>I driver sonori
<p>

	Notare che sono stati riscritti molta parte del nucleo audio
	e relativi driver. Il materiale vecchio &egrave; generalmente
	chiamato `OSS' e il nuovo &egrave; chiamato `ALSA'. L'intenzione
	&egrave; di abbandonare l'OSS. Per evitare conflitti di nome,
	il materiale ALSA generalmente ha `snd-' come prefisso a tutti i
	parametri di avvio.

	Notare che ogni driver ha il proprio
	argomento individuale di avvio condiviso (kernel molto vecchi usavano
	<tt/sound=/). Inoltre, generalmente nessun default era impostato
	al momento della compilazione (es. <em>occorre</em> fornire un argomento
	di avvio per far rilevare vecchie schede ISA non-PNP.)
	La miglior fonte di informazioni per la propria scheda sono i file
	in <tt>linux/Documentation/sound/</tt>.

<sect1>Argomenti Individuali di driver di dispositivi audio
<p>

<sect2>ALSA ISA drivers
<p>
	<tt/snd-dummy=/ Dummy soundcard

	<tt/snd-mpu401=/ mpu401 UART

	<tt/snd-mtpav=/ MOTU Midi Timepiece

	<tt/snd-serial=/ Serial UART 16450/16550 MIDI

	<tt/snd-virmidi=/ Dummy soundcard for virtual rawmidi devices

	<tt/snd-ad1816a=/ ADI SoundPort AD1816A

	<tt/snd-ad1848=/ Generic driver for AD1848/AD1847/CS4248

	<tt/snd-als100=/ Avance Logic ALS100

	<tt/snd-azt2320=/ Aztech Systems AZT2320 (and 2316)

	<tt/snd-cmi8330=/ C-Media's CMI8330

	<tt/snd-cs4231=/ Generic driver for CS4231 chips

	<tt/snd-cs4232=/ Generic driver for CS4232 chips

	<tt/snd-cs4236=/ Generic driver for CS4235/6/7/8/9 chips

	<tt/snd-dt019x=/ Diamond Technologies DT-019x

	<tt/snd-es1688=/ Generic ESS AudioDrive ESx688

	<tt/snd-es18xx=/ Generic ESS AudioDrive ES18xx

	<tt/snd-gusclassic=/ Gus classic

	<tt/snd-gusextreme=/ Gus extreme

	<tt/snd-gusmax=/ Gus Max

	<tt/snd-interwave=/ Interwave

	<tt/snd-interwave-stb=/ Interwave

	<tt/snd-opl3sa2=/ Yamaha OPL3SA2

	<tt/snd-opti93x=/ OPTi 82c93x based cards

	<tt/snd-opti92x-cs4231=/ OPTi 82c92x/CS4231

	<tt/snd-opti92x-ad1848=/ OPTi 82c92x/AD1848

	<tt/snd-es968=/ ESS AudioDrive ES968

	<tt/snd-sb16=/ SoundBlaster 16

	<tt/snd-sbawe=/ SoundBlaster 16 AWE

	<tt/snd-sb8=/ Old 8 bit SoundBlaster (1.0, 2.0, Pro)

	<tt/snd-sgalaxy=/ Sound galaxy

	<tt/snd-wavefront=/ Wavefront

<sect2>driver OSS
<p>

	<tt/ad1848=/ AD1848

	<tt/adlib=/ Adlib

	<tt/mad16=/ MAD16

	<tt/pas2=/ ProAudioSpectrum PAS16

	<tt/sb=/ SoundBlaster

	<tt/uart401=/ UART 401 (on card chip)

	<tt/uart6850=/ UART 6850 (on card chip)

	<tt/opl3=/ Yamaha OPL2/OPL3/OPL4 FM Synthesizer (on card chip)

	<tt/opl3sa=/ Yamaha OPL3-SA FM Synthesizer (on card chip)

	<tt/opl3sa2=/ Yamaha OPL3-SA2/SA3 FM Synthesizer (on card chip)

<sect2>driver ALSA PCI
<p>

	<tt/snd-ali5451=/ ALi PCI audio M5451

	<tt/snd-als4000=/ Avance Logic ALS4000

	<tt/snd-cmipci=/ C-Media CMI8338 and 8738

	<tt/snd-cs4281=/ Cirrus Logic CS4281

	<tt/snd-cs46xx=/ Cirrus Logic Sound Fusion CS46XX

	<tt/snd-emu10k1=/ EMU10K1 (SB Live!)

	<tt/snd-ens1370=/ Ensoniq ES1370 AudioPCI

	<tt/snd-ens1371=/ Ensoniq ES1371 AudioPCI

	<tt/snd-es1938=/ ESS Solo-1 (ES1938, ES1946, ES1969)

	<tt/snd-es1968=/ ESS Maestro 1/2/2E

	<tt/snd-fm801=/ ForteMedia FM801

	<tt/snd-intel8x0=/ Intel ICH (i8x0) chipsets

	<tt/snd-maestro3=/ ESS Maestro3/Allegro (ES1988)

	<tt/snd-korg1212=/ Korg 1212 IO

	<tt/snd-rme32=/ RME Digi32, Digi32/8 and Digi32 PRO

	<tt/snd-nm256=/ NeoMagic 256AV and 256ZX

	<tt/snd-rme96=/ RME Digi96, Digi96/8 and Digi96/8 PRO/PAD/PST

	<tt/snd-rme9652=/ RME Digi9652 audio interface

	<tt/snd-hdsp=/ RME Hammerfall DSP

	<tt/snd-sonicvibes=/ S3 SonicVibes

	<tt/snd-trident=/ Trident 4DWave DX/NX & SiS SI7018

	<tt/snd-via82xx=/ VIA South Bridge  VT82C686A/B/C, VT8233A/C, VT8235

	<tt/snd-ymfpci=/ Yamaha DS1/DS1E

	<tt/snd-ice1712=/ ICEnsemble ICE1712 (Envy24)


<sect>CD-ROM (Non-SCSI/ATAPI/IDE)
<p>
	Questa sezione elenca tutti i possibili argomenti di avvio riguardanti
	questi vecchi dispositivi CD-ROM su schede di interfaccia proprietarie.
	Notare che questo non include CD-ROM SCSI o
	IDE/ATAPI. Per questi tipi di CD-ROM vedere l'appropriata sezione.

	Notare che la maggior parte di questi CD-ROM hanno file di documentazione che
	<em/dovrebbero/ essere letti, e sono tutti in un posto a portata di mano:
	<tt>linux/Documentation/cdrom</tt>.

<sect1>Argomenti di driver per vecchi CD-ROM
<p>

	<tt/aztcd=/ Aztech Interface

	<tt/cdu31a=/ CDU-31A and CDU-33A Sony Interface (Also Old PAS)

	<tt/sonycd535=/ CDU-535 Sony Interface

	<tt/gscd=/ GoldStar Interface

	<tt/isp16=/ ISP16 Interface

	<tt/mcd=/ Mitsumi Standard Interface

	<tt/mcdx=/ Mitsumi XA/MultiSession Interface

	<tt/optcd=/ Optics Storage Interface

	<tt/cm206=/ Phillips CM206 Interface

	<tt/sjcd=/ Sanyo Interface

	<tt/sbpcd=/ SoundBlaster Pro Interface

<sect>Driver Seriali e ISDN
<p>

<sect1>I driver ISDN
<p>

	Prego vedere <tt>linux/Documentation/isdn/</tt> per completi
	dettagli di tutte le opzioni che i seguenti driver ISDN accettano.

	<tt/icn=/ ICN ISDN driver

	<tt/pcbit=/ PCBIT ISDN driver

	<tt/teles=/ Teles ISDN driver

<sect1>I driver Seriali
<p>
	Prego vedere <tt>linux/Documentation/</tt> e/o il file <tt/README/
	in <tt>linux/drivers/char</tt> per completi dettagli di
	tutte le opzioni che i seguenti driver supportano.

	<tt/digi=/ DigiBoard Driver

	<tt/riscom8=/ RISCom/8 Multiport Serial Driver

	<tt/baycom=/ Baycom Serial/Parallel Radio Modem

<sect>Altri dispositivi Hardware
<p>
	Ogni altro dispositivo che non rientra in nessuna delle suddette categorie
	viene raggruppato qui.

<sect1>Dispositivi Ethernet (`ether=', `netdev=')
<p>
	Diversi driver fanno uso di diversi parameteri, ma tutti
	almeno condividono il fatto di avere un IRQ, un valore di base di porta I/O, e
	un nome. Nella sua forma pi&ugrave; generica, appare qualcosa di questo tipo:

<code>
	ether=irq,iobase&lsqb;,param_1&lsqb;,param_2,...param_8&rsqb;&rsqb;&rsqb;,name
</code>

	Il primo argomento non numerico viene preso come nome.
	I valori <tt/param_n/ (se applicabili) hanno usualmente
	diversi significati per ogni scheda o driver diversi.
	I tipici valori <tt/param_n/ sono usati per specificare cose
	come l'indirizzo di memoria condivisa, la selezione dell'interfaccia, il
	canale DMA e similari.

	L'uso pi&ugrave; comune di questo parametro &egrave; di forzare la rilevazione
	di una seconda scheda ethernet, dal momento che il default &egrave; di rilevarne solo
	una (con kernel 2.4 o pił vecchi). Questo pu&ograve; essere realizzato
	con un semplice:

<code>
	ether=0,0,eth1
</code>

	Notare che i valori zero per l'IRQ e base I/O nell'esempio di
	sopra dicono al/ai driver di autorilevarli.

	NOTE IMPORTANTI GLI UTENTI DI MODULI: Questo sopra <em/non/ forzer&agrave; il
	rilevamento della seconda scheda se si usano i driver come moduli caricabili
	durante l'esecuzione (invece di averli compilati dentro il kernel).
	La maggior parte delle distribuzioni Linux usano un kernel minimale combinato con una
	grande selezione di driver modulari. Il parametro <tt/ether=/ si applica soltanto
	ai driver compilati direttamente dentro il kernel.

	L'Ethernet-HowTo ha una documentazione completa e vasta
	sull'uso di schede multiple e sull'implementazione specifica dei valori
	<tt/param_n/ su schede e driver dove vengono utilizzati.
	I lettori interessati dovrebbero far riferimento alla sezione in quel documento
	delle loro particolari schede per maggiori e complete informazioni.
	<url url="http://metalab.unc.edu/mdw/HOWTO/Ethernet-HOWTO.html"
	name="Ethernet-HowTo">

<sect1>Il Floppy Disk Driver (`floppy=')
<p>
	Ci sono molte opzioni floppy driver, e sono tutte elencate in
	<tt/floppy.txt/ dentro <tt>linux/Documentation</tt>. Ci sono troppe
	opzioni in quel file per essere elencate qui. Invece, sono riportate qui solo
	quelle opzioni che possono essere richieste per fare un'installazione di Linux
	e per farlo funzionare con meno del normale hardware.

	<tt/floppy=0,daring/
	Dice al driver floppy che il proprio controller floppy dovrebbe essere usato
	con cautela (disabilita tutte le operazioni audaci).

	<tt/floppy=thinkpad/
	Dice al driver floppy che si ha un Thinkpad. I Thinkpad usano una
	convenzione invertita per il segnale di cambio disco.

	<tt/floppy=nodma/
	Dice al driver floppy di non usare DMA per il trasferimento dei dati.
        Questo serve sugli Omnibook HP, i quali non hanno un canale DMA
        praticabile per il driver floppy. Questa opzione &egrave; utile anche
        quando si riceve frequentemente il messaggio `Unable to allocate DMA memory'.
	L'uso di `nodma' non &egrave; raccomandato se
        si ha un FDC senza un FIFO (8272A o 82072). 82072A e
        successivi vanno bene). Il modello FDC &egrave; riportato all'avvio.
	Inoltre occorre almeno un 486 per usare nodma.

	<tt/floppy=nofifo/
	Disabilita interamente il FIFO. Questo serve se si riceve il messaggio `Bus
	master arbitration error' dalla propria scheda Ethernet (o
	da altri dispositivi) mentre si accede al floppy.

	<tt/floppy=broken_dcl/
	Non usare il segnale di cambio disco (DisckChangeLine), ma assumere che il
	disco sia stato cambiato ogni volta che il nodo del dispositivo viene riaperto.
	Serve su alcune box dove il segnale di cambio disco &egrave; guasto o non supportato.
	Questa dovrebbe essere considerata una misura di ripiego, effettivamente questo rende
	l'operazione col floppy meno efficente a causa dell'inutile pulitura della cache,
	e leggermente pi&ugrave; inaffidabile. Verificare il collegamento
	del proprio cavo e le impostazioni dei jumper se si hanno problemi al DCL
	. Comunque, alcune vecchie unit&agrave;, e anche alcuni Laptop
	sono conosciuti non avere il DCL.

	<tt/floppy=debug/
	Stampa messaggi (aggiuntivi) di debug.

	<tt/floppy=messages/
	Stampa messaggi informativi per alcune operazioni (notifiche di cambio disco,
	avvertenze circa sovra e sotto funzionamenti, e circa l'autorilevamento).

<sect1>Il driver Bus Mouse (`bmouse=')
<p>
	Il driver busmouse accetta solo un parametro, che rappresenta
	il valore di IRQ hardware che deve essere usato.

<sect1>Il driver MS Bus Mouse (`msmouse=')
<p>
	Il driver MS mouse acetta solo un parametro, che rappresenta
	il valore IRQ hardware che deve essere usato.

<sect1>Il driver Printer (`lp=')
<p>
	Con questo argomento di avvio si pu&ograve; dire al driver della stampante
	quale porte usare e quali porte <em/non/ usare. Questo ultimo diventa pratico
	se non si vuole che il driver della stampante richieda tutte le porte parallele
	disponibili, cos&igrave; che altri driver (es. PLIP, PPA) possano usarle al suo posto.

	Il formato dell'argomento &egrave; multipli i/o, coppie di IRQ. Per esempio,
	<tt/lp=0x3bc,0,0x378,7/ dovrebbe usare la porta a <tt/0x3bc/ in modalit&agrave; (polling) senza IRQ
	, e usare IRQ 7 per la porta a <tt/0x378/. La porta
	a <tt/0x278/ (se c'&egrave;) dovrebbe non essere rilevata, dal momento che l'autorilevamento avviene solo
	in assenza di un argomento <tt/lp=/. Per disabilitare interamente
	il driver della stampante, si pu&ograve; usare <tt/lp=0/.

<sect1>Il driver della porta parallela IP (`plip=')
<p>

	Usando <tt>plip=timid</tt> dir&agrave; al driver plip di evitare
	qualsiasi porta che appaia essere in uso da altri dispositivi a porta parallela,
	Diversamente si pu&ograve; usare <tt>plip=parportN</tt> dove
	<tt>N</tt> &egrave; un intero non-zero che indica la porta parallela
	da usare. (Usando <tt>N</tt>=0 disabiliter&agrave; il driver plip.)

<sect>Copie, Traduzioni, Chiusura, etc.
<p>
	Hey, ce l'abbiamo fatta alla fine! (Phew...)  Adesso solo le note legali.

<sect1>Copyright and Disclaimer<label id="copyright">
<p>
	This document is Copyright (c) 1995-1999 by Paul Gortmaker.
	Copying and redistribution is allowed under the conditions as
	outlined in the Linux Documentation Project Copyright, available
	from where you obtained this document, OR as outlined in the
	GNU General Public License, version 2 (see linux/COPYING).

	This document is <em/not/ gospel. However, it is probably the most
        up to date info that you will be able to find. Nobody is responsible
        for what happens to your hardware but yourself. If your stuff
        goes up in smoke, or anything else bad happens,
        we take no responsibility. ie. THE AUTHOR IS NOT RESPONSIBLE
        FOR ANY DAMAGES INCURRED DUE TO ACTIONS TAKEN BASED ON THE
        INFORMATION INCLUDED IN THIS DOCUMENT.

	A hint to people considering doing a translation.  First,
	translate the SGML source (available via FTP from the HowTo
	main site) so that you can then generate other output formats.
	Be sure to keep a copy of the original English SGML source that
	you translated from! When an updated HowTo is released,
	get the new SGML source for that version, and then a simple
	<tt/diff -u old.sgml new.sgml/ will show you exactly what has
	changed so that you can easily incorporate those changes into
	your translated SMGL source without having to re-read or
	re-translate everything.

	If you are intending to incorporate this document into a
	published work, please make contact (via e-mail) so that
	you can be supplied with the most up to date information
	available. In the past, out of date versions of the Linux
	HowTo documents have been published, which caused the developers
	undue grief from being plagued with questions that were already
	answered in the up to date versions.

<sect1>Chiusura
<p>
	Se si fosse trovato qualsiasi errore di digitazione, o informazioni obsolete in questo
	documento, si prega di farmelo sapere. &Egrave; facile omettere qualcosa,
	perch&eacute; il kernel (e il numero dei driver) &egrave; immenso comparato
	a come era quando ho iniziato questo documento.

	Grazie,

	Paul Gortmaker, <tt/p_gortmaker @ yahoo.com/

</article>
