Sophie

Sophie

distrib > Mandriva > 2008.1 > x86_64 > media > main-release > by-pkgid > e05c4514608e650af9b28d9be1d35a18 > files > 383

howto-html-it-10.1-4mdv2008.1.noarch.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.21">
 <TITLE>Linux Ethernet-HOWTO: Miscellanea</TITLE>
 <LINK HREF="Ethernet-HOWTO-7.html" REL=previous>
 <LINK HREF="Ethernet-HOWTO.html#toc8" REL=contents>
</HEAD>
<BODY>
Avanti
<A HREF="Ethernet-HOWTO-7.html">Indietro</A>
<A HREF="Ethernet-HOWTO.html#toc8">Indice</A>
<HR>
<H2><A NAME="misc"></A> <A NAME="s8">8.</A> <A HREF="Ethernet-HOWTO.html#toc8">Miscellanea</A></H2>


<P>Tutta quella roba che non stava bene da nessun'altra parte &egrave; stata
cacciata qui. Potrebbe non essere rilevante e potrebbe non essere
d'interesse generale, ma &egrave; comunque qui.</P>

<H2><A NAME="ss8.1">8.1</A> <A HREF="Ethernet-HOWTO.html#toc8.1">Buffer FIFO di Trasmissione ed Errori di Underrun</A>
</H2>

<P>Donald ha scritto una bella descrizione di che cosa sia un buffer FIFO
di trasmissione e di cosa succede quando si verifica un errore. Eccola a voi:</P>
<P>Nei casi in cui l'hardware lo supporta, i miei driver includono codice per
ottimizzare il comportamento della FIFO di trasmissione. Un tipico chip Ethernet ha una FIFO
di trasmissione che contiene i dati arrivati dal bus prima che questi vengano
trasmessi sul cavo. La maniera in cui questa FIFO viene gestita &egrave; importante
per le prestazioni.</P>
<P>Idealmente, si dovrebbe voler iniziare a trasmettere non appena il primo
pacchetto in trasmissione arriva sul chip. Il "Tx FIFO threshold" &egrave;
un parametro che specifica di iniziare a trasmettere quando N byte sono arrivati
al NIC. Inizialmente, questo parametro &egrave; settato per una configurazione
tipica, ma se una scheda video o un controller SCSI stanno causando dei prolungati
picchi di traffico PCI, il chip NIC esaurir&agrave; i dati nel suo buffer di trasmissione
prima di poter accedere di nuovo al bus, e questo causa una FIFO underrun.</P>
<P>Il driver risponde ad una FIFO underrun incrementando il "Tx FIFO threshold", e se
questo succede un numero sufficiente di volte il chip finir&agrave; per operare
in modalit&agrave; store-and-forward, vale a dire che la trasmissione di un pacchetto 
non avr&agrave; inizio sino a quando esso non sia stato completamente trasferito al NIC.</P>
<P>Alcuni progetti, come l'Adaptec Starfire, compiono un passo ulteriore e forniscono
un segnale che la FIFO ha quasi esaurito i dati. Questo permette al driver di 
configurare questo settaggio senza rischiare un errore di trasmissione.</P>
<P>Dovrebbe essere piuttosto raro l'incontrare pi&ugrave; di uno o due FIFO underrun:
o il chip ha un settaggio del "Tx FIFO threshold" che permette poche scelte oppure
il driver aumenta questo valore in grossi passi per mantenere i picchi di traffico
PCI contenuti dai loro limiti naturali.</P>

<H2><A NAME="lilo"></A> <A NAME="ss8.2">8.2</A> <A HREF="Ethernet-HOWTO.html#toc8.2">Passare al kernel argomenti Ethernet</A>
</H2>


<P>Ci sono due comandi generici che possono essere passati al kernel al
momento del boot: <CODE>ether</CODE> e <CODE>reserve</CODE>. Si pu&ograve; far questo
con LILO, loadlin o qualsiasi altra utilit&agrave; di boot che accetti
argomenti opzionali.</P>
<P>Per esempio, se il comando fosse 'blah' e si aspettasse 3 argomenti
(diciamo 123, 456 e 789) allora con LILO si potrebbe usare:</P>
<P><CODE>LILO: linux blah=123,456,789</CODE></P>
<P>Questi parametri di boot possono essere resi permanenti cosicch&eacute; non
si debba reinserirli ogni volta. Solitamente questo richiede solamente
l'inserimento di una riga come <CODE>append="blah=123,456,789"</CODE> all'inizio
del vostro <CODE>/etc/lilo.conf</CODE>. Si veda la documentazione di LILO per
ulteriori dettagli.</P>
<P>Per maggiori informazioni sui parametri di boot (e un elenco completo) si veda il
<A HREF="http://metalab.unc.edu/mdw/HOWTO/BootPrompt-HOWTO.html">BootPrompt-HOWTO</A>.</P>

<H3><A NAME="ether"></A> Il parametro <CODE>ether</CODE></H3>


<P>Il parametro <CODE>ether=</CODE> viene usato in congiunzione con i driver direttamente
compilati nel kernel. <EM>Non ha assolutamente alcun effetto</EM>
su driver modulari. Nella sua forma pi&ugrave; generale, pu&ograve;
somigliare a qualcosa come quel che segue:</P>
<P>
<BLOCKQUOTE><CODE>
ether=IRQ,IND_BASE,PARAM_1,PARAM_2,NOME
</CODE></BLOCKQUOTE>
</P>
<P>Tutti gli argomenti sono opzionali. Il primo argomento non numerico &egrave;
interpretato come NOME.</P>
<P><B>IRQ:</B> ovvio. Un valore di '0' (solitamente il valore
predefinito) indica di usare autoIRQ. &Egrave; accidentale che l'impostazione
dell'IRQ sia prima di quella dell'ind_base: questo verr&agrave; corretto
non appena cambia anche qualcos'altro.</P>
<P><B>IND_BASE:</B> altrettanto ovvio. Il valore '0' (solitamente quello
predefinito) indica di rilevare una scheda nell'elenco di indirizzi
specifici per quella scheda.</P>
<P><B>PARAM_1:</B>
Originariamente usato come valore per ridefinire l'indirizzo iniziale
della memoria per una scheda Ethernet a memoria condivisa, come la
WD80*3. Alcuni driver usano i 4 bit meno significativi di questo
valore per impostare il livello dei messaggi di debug. 0:
predefinito, 1-7: livello 1..7 (con 7 si ottiene il massimo della
verbosit&agrave;), 8: livello 0 (nessun messaggio). Inoltre, il driver LANCE
usa i 4 bit meno significativi di questo valore per selezionare il
canale DMA. Altrimenti usa auto-DMA.</P>
<P><B>PARAM_2:</B>
Il driver 3c503 usa questo valore per selezionare tra il transceiver
interno ed esterno. 0: predefinito/interno, 1: AUI esterno. La
scheda E21XX della Cabletron usa i 4 bit meno significativi di PARAM_2
per selezionare il mezzo d'uscita. Altrimenti lo rileva automaticamente.</P>
<P><B>NOME:</B>
Seleziona il dispositivo di rete a cui fa riferimento il valore. Il
kernel standard usa i nomi 'eth0', 'eth1', 'eth2' e 'eth3' per le
schede Ethernet attaccate sul bus e 'atp0' per gli adattatori
Ethernet 'pocket' su porta parallela. Il driver arcnet come nome usa 'arc0'.
L'impostazione predefinita &egrave; per il rilevamento di un'unica
scheda Ethernet, la 'eth0'. L'abilitazione di pi&ugrave; schede &egrave; possibile
solamente impostando esplicitamente il loro indirizzo base usando
questi parametri per LILO. Il kernel 1.0 trattava le schede Ethernet
basate su LANCE in modo speciale. Gli argomenti di LILO venivano sempre
ignorati e alle schede LANCE erano sempre assegnati i nomi 'eth&lt;n&gt;'
partendo da 'eth0'. Ulteriori schede Ethernet non
LANCE dovevano essere esplicitamente assegnate a 'eth&lt;n+1&gt;', e
il rilevamento standard di 'eth0' doveva essere disabilitato con qualcosa
di simile a 'ether=0,-1,eth0' (s&igrave;, questo &egrave; un bug).</P>

<H3><A NAME="reserve"></A> Il comando <CODE>reserve</CODE></H3>


<P>Questo comando di lilo viene usato proprio come il precedente 'ether=',
ovvero viene accodato al nome di avvio selezionato in lilo.conf.</P>
<P>
<BLOCKQUOTE><CODE>
reserve=IO-base,estensione{,IO-base,estensione...}
</CODE></BLOCKQUOTE>
</P>
<P>In alcune macchine pu&ograve; essere necessario impedire ai driver di 
controllare la presenza di dispositivi (auto-probing) in regioni specifiche.
Ci&ograve; pu&ograve; essere dovuto ad hardware mal progettato che causa il <EM>blocco</EM> del boot
(come alcune schede Ethernet), ad hardware che viene mal identificato, ad hardware il cui
stato &egrave; stato modificato da un rilevamento precedente, o semplicemente ad hardware
che non vuole essere inizializzato dal kernel.</P>
<P>L'argomento di boot <CODE>reserve</CODE> indirizza questo problema
specificando una regione di porte di I/O che non deve essere
controllata. Tale regione viene riservata nella tabella di
registrazione delle porte del kernel come se vi si fosse gi&agrave; rilevato
un dispositivo. Si noti che questo meccanismo non dovrebbe essere
necessario nella maggior parte della macchine a meno che non si sia
riscontrato un problema (o di avere a che fare con un caso particolare).</P>
<P>Le porte I/O nella regione specificata vengono protette dai controlli per la ricerca dei
dispositivi. Questo si &egrave; reso necessario per gestire i casi in cui alcuni driver si
piantavano su di una NE2000 o erroneamente identificavano altri dispositivi come propri.
Un driver di dispositivo correttamente scritto non dovrebbe controllare una regione riservata
a meno che qualche altro argomento di boot non specifici esplicitamente di far questo.
La maggior parte dei driver ignora la tabella di registrazione delle porte se gli viene
passato un indirizzo specifico.</P>
<P>Per esempio, la riga di boot</P>
<P>
<BLOCKQUOTE><CODE>
LILO: linux  reserve=0x300,32  ether=0,0x300,eth0
</CODE></BLOCKQUOTE>
</P>
<P>impedisce a tutti i device driver, tranne a quelli della scheda
Ethernet, di controllare se un dispositivo &egrave; presente nella regione 0x300-0x31f.</P>
<P>Come al solito per i comandi di boot, c'&egrave; un limite di 11 parametri, quindi si
possono specificare solo 5 regioni riservate per ciascun comando <CODE>reserve</CODE>.
Possono essere specificati pi&ugrave; <CODE>reserve</CODE> se si hanno richieste insolitamente
complicate da descrivere.</P>

<H2><A NAME="modules"></A> <A NAME="ss8.3">8.3</A> <A HREF="Ethernet-HOWTO.html#toc8.3">Usare un driver Ethernet come modulo</A>
</H2>


<P>La maggior parte delle distribuzioni di Linux utilizzano ora dei
kernel con pochissimi driver al loro interno. I driver vengono ora piuttosto
forniti come gruppo di moduli indipendenti caricabili dinamicamente.
Questi driver modulari sono tipicamente caricati
dall'amministratore con il comando <CODE>modprobe(8)</CODE> o in alcuni casi
sono automaticamente caricati dal kernel attraverso 'kerneld' (nei
kernel 2.0) o 'kmod' (nei kernel 2.1) che a loro volta chiamano <CODE>modprobe</CODE>.</P>
<P>La vostra distribuzione pu&ograve; offrire un comodo strumento grafico
per la configurazione dei moduli Ethernet. Se possibile prima si dovrebbe
provare a usare quello. La descrizione che segue descrive che cosa
sta dietro a qualsiasi programma di configurazione e indica cosa quei programmi
vadano a modificare.</P>
<P>Le informazioni che indicano quali moduli vengono usati e quali
opzioni vengono passate a ciascun modulo vengono solitamente salvate nel
file <CODE>/etc/modules.conf</CODE>. Le due opzioni principali di
interesse per le schede Ethernet che saranno usate in questo file sono
<CODE>alias</CODE> e <CODE>options</CODE>. Il comando <CODE>modprobe</CODE> consulta questo
file per informazioni sui moduli.</P>
<P>I moduli stessi sono tipicamente collocati in una directory chiamata
<CODE>/lib/modules/`uname -r`/net</CODE> dove il comando <CODE>uname -r</CODE>
restituisce la versione del kernel (e.g. 2.0.34). Si pu&ograve; andare li
per vedere quale modulo corrisponda alla propria scheda.</P>
<P>La prima cosa che ci deve essere nel file <CODE>modules.conf</CODE> &egrave;
una riga che indichi a <CODE>modprobe</CODE> quale driver usare per l'interfaccia
di rete <CODE>eth0</CODE> (e per <CODE>eth1</CODE> e per...). Per fare questo si
dovr&agrave; usare il comando <CODE>alias</CODE>. Per esempio, se si ha una scheda
ISA EtherEZ della SMC che usa il driver modulare <CODE>smc-ultra.o</CODE>,
si deve creare un <CODE>alias</CODE> per questo driver che corrisponda a
<CODE>eth0</CODE>, aggiungendo la riga:</P>
<P>
<PRE>
        alias eth0 smc-ultra
</PRE>
</P>
<P>Nota Importante: l'alias summenzionato viene usato solo dalle utilit&agrave; per
i moduli per convertire un nome di device generico (come ad esempio <CODE>eth0</CODE>)
nel nome specifico del modulo del driver. Quando il driver viene caricato non
vede mai questo alias: invece, esso si limita a scegliere il primo nome libero
(<CODE>ethN</CODE> per N=0,1,2,...). Quindi, se pi&ugrave; di un modulo Ethernet viene
caricato, l'<CODE>ethN</CODE> assegnato al driver dal kernel pu&ograve; non
corrispondere con quello assegnatogli dall'alias, a seconda dell'ordine in cui
i moduli vengono caricati. Se dovete assicurarvi che una specifica scheda
venga assegnata un indirizzo IP specifico, allora si legga l'indirizzo della
hardware della scheda e si assegni l'indirizzo IP a seconda di quello. Se
state scrivendo un vostro shell script per far questo, potete limitarvi a
fare il parsing dell'output di ifconfig, altrimenti in C potete usare la
chiamata</P>
<P><CODE>ioctl(ethfd, SIOCGIFHWADDR, &amp;ifreq)</CODE>.</P>
<P>L'altra cosa di cui si pu&ograve; aver bisogno &egrave; una riga <CODE>options</CODE> che
indichi quali opzioni devono essere usate con un particolare modulo (o
alias di modulo). Continuando con l'esempio di prima, se si usa
solamente la riga <CODE>alias</CODE> con nessuna riga <CODE>options</CODE>, il kernel vi
avviser&agrave; (si veda <CODE>dmesg</CODE>) che l'auto rilevamento di una scheda ISA
non &egrave; una buona idea. Per eliminare questo problema, si
aggiunga un'altra riga che indica al modulo a quale indirizzo I/O base &egrave;
collocata la scheda, ad esempio perl'indirizzo esadecimale <CODE>0x280</CODE> si usi</P>
<P>
<PRE>
        options smc-ultra io=0x280
</PRE>
</P>
<P>La maggior parte dei moduli ISA accettano parametri come <CODE>io=0x340</CODE>
e <CODE>irq=12</CODE> sulla riga di comando di <CODE>insmod</CODE>. Fornire questi
parametri &egrave; <EM>RICHIESTO</EM> o almeno <EM>CALDAMENTE CONSIGLIATO</EM> per
evitare il rilevamento della scheda. Diversamente dai dispositivi PCI e
EISA, non c'&egrave; alcun modo sicuro per fare l'auto rilevamento della
maggior parte dei dispositivi ISA e quindi lo si dovrebbe evitare
quando si usa un driver come modulo.</P>
<P>Un elenco di tutte le opzioni che ciascun modulo accetta pu&ograve; essere
reperita nel file:</P>
<P><CODE>/usr/src/linux/Documentation/networking/net-modules.txt</CODE></P>
<P>Si raccomanda la sua lettura per scoprire quali opzioni si possano
usare con la propria scheda. Si noti che alcuni moduli supportano
un elenco di valori separati da virgola. Solitamente questo &egrave; il caso
di moduli che sono in grado di gestire pi&ugrave; dispositivi con un unica copia del
modulo, come tutti i driver basati su 8390 e il driver PLIP. Per
esempio:</P>
<P>
<HR>
<PRE>
        options 3c503 io=0x280,0x300,0x330,0x350 xcvr=0,1,0,1
</PRE>
<HR>
</P>
<P>Con la riga precedente si avr&agrave; un unico modulo che controlla quattro
schede 3c503, con la scheda 2 e 4 che usano il transceiver esterno.
Non si aggiungano spazi attorno a '=' o alle virgole.</P>
<P>Si noti inoltre che un modulo <EM>occupato</EM> non pu&ograve; essere rimosso.
Ci&ograve; significa che si dovr&agrave; usare <CODE>ifconfig eth0 down</CODE> (per disattivare
la scheda Ethernet) prima di rimuovere il modulo.</P>
<P>Il comando <CODE>lsmod</CODE> mostrer&agrave; quali moduli sono caricati e se sono in
uso, mentre il comando <CODE>rmmod</CODE> pu&ograve; essere usato per rimuoverli.</P>

<H2><A NAME="ss8.4">8.4</A> <A HREF="Ethernet-HOWTO.html#toc8.4">Documentazione correlata</A>
</H2>


<P>La maggior parte dei queste informazioni provengono da messaggi che ho
salvato dai gruppi comp.os.linux, che si sono dimostrati una
insostituibile fonte di informazioni. Altre informazioni utili
provengono da un gruppo di piccoli file di Donald stesso.
Naturalmente, se si sta impostando una scheda Ethernet, allora sar&agrave;
bene leggere il NET-2 Howto in modo che si possa realmente configurare
il software che la user&agrave;. Inoltre, se ci si diverte a fare un po'
l'hacker, si possono sempre trovare alcune informazioni addizionali
nei file sorgente dei driver. Solitamente prima che cominci il codice
c'&egrave; sempre un paragrafo o due che descrive i punti importanti.</P>
<P>A quanti cercano informazioni che non sono in alcun modo
specifiche su Linux (per esempio, cos'&egrave; 10BaseT, cos'&egrave; AUI, cosa fa un hub,
ecc.) suggerisco caldamente di rivolgersi a newsgroup come
<EM>comp.dcom.lans.ethernet</EM> e/o
<EM>comp.sys.ibm.pc.hardware.networking</EM>. Gli archivi dei newsgroup
come quelli a <CODE>dejanews.com</CODE> possono essere una insostituibile
fonte di informazioni. Si possono prendere le FAQ da RTFM (che
conserva tutte le FAQ dei newsgroup) all'URL seguente:</P>
<P>
<A HREF="ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/">Usenet FAQs</A></P>
<P>Si pu&ograve; anche dare un'occhiata alla cosiddetta 'Ethernet-HomePage', che
&egrave; all'URL seguente:</P>
<P>
<A HREF="http://wwwhost.ots.utexas.edu/ethernet/ethernet-home.html">Ethernet-HomePage</A></P>


<H2><A NAME="copyright"></A> <A NAME="ss8.5">8.5</A> <A HREF="Ethernet-HOWTO.html#toc8.5">Liberatoria e copyright (in originale inglese)</A>
</H2>

<P>This document is <EM>not</EM> 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 ethercard
or any other hardware goes up in smoke (...nearly impossible!)
we take no responsibility. ie. THE AUTHORS ARE NOT RESPONSIBLE
FOR ANY DAMAGES INCURRED DUE TO ACTIONS TAKEN BASED ON THE
INFORMATION INCLUDED IN THIS DOCUMENT.</P>
<P>This document is Copyright (c) 1993-2000 by Paul Gortmaker.
Permission is granted to make and distribute verbatim copies
of this manual provided the copyright notice and this permission
notice are preserved on all copies.</P>
<P>Permission is granted to copy and distribute modified versions
of this document under the conditions for verbatim copying,
provided that this copyright notice is included exactly as in
the original, and that the entire resulting derived work is
distributed under the terms of a permission notice identical
to this one.</P>
<P>Permission is granted to copy and distribute translations
of this document into another language, under the above
conditions for modified versions.</P>
<P>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
<CODE>diff -u old.sgml new.sgml</CODE> 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.</P>
<P>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.</P>

<H2><A NAME="ss8.6">8.6</A> <A HREF="Ethernet-HOWTO.html#toc8.6">Chiusura</A>
</H2>

<P>Agli albori dell'era Linux (circa dieci anni fa), non esistevano molti driver
e nemmeno molti utenti, e io avevo il tempo di seguire lo sviluppo dei singoli
driver, leggere dei problemi comuni nelle newsgroup, e rispondere alle domande
e alle e-mail. Ma le cose sono molto diverse ora: ci sono moltissimi driver,
ed un numero ancora pi&ugrave; grande di utenti,e non esiste maniera in cui io
possa restare al corrente di tutti i nuovi sviluppi! Qui &egrave; dove ho
bisogno del vostro aiuto: se avete trovato un nuovo driver che non viene
menzionato qui, se avete trovato qualche errore madornale o informazione non
aggiornata, inviatemi una e-mail. &Egrave; un grande documento ed &egrave; facile non
accorgersi di qualcosa. Se avete inviato una mail per una modifica e questa
non &egrave; stata inclusa nella versione successiva, non si esiti a scrivere ancora,
in quanto potrebbe essersi persa tra la marea di SPAM e spazzatura che ricevo
nella posta elettronica.</P>
<P>Grazie!</P>
<P>Paul Gortmaker, <CODE>p_gortmaker@yahoo.com</CODE></P>
<HR>
Avanti
<A HREF="Ethernet-HOWTO-7.html">Indietro</A>
<A HREF="Ethernet-HOWTO.html#toc8">Indice</A>
</BODY>
</HTML>