Tutta quella roba che non stava bene da nessun'altra parte è stata cacciata qui. Potrebbe non essere rilevante e potrebbe non essere d'interesse generale, ma è comunque qui.
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:
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 è importante per le prestazioni.
Idealmente, si dovrebbe voler iniziare a trasmettere non appena il primo pacchetto in trasmissione arriva sul chip. Il "Tx FIFO threshold" è un parametro che specifica di iniziare a trasmettere quando N byte sono arrivati al NIC. Inizialmente, questo parametro è 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à i dati nel suo buffer di trasmissione prima di poter accedere di nuovo al bus, e questo causa una FIFO underrun.
Il driver risponde ad una FIFO underrun incrementando il "Tx FIFO threshold", e se questo succede un numero sufficiente di volte il chip finirà per operare in modalità store-and-forward, vale a dire che la trasmissione di un pacchetto non avrà inizio sino a quando esso non sia stato completamente trasferito al NIC.
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.
Dovrebbe essere piuttosto raro l'incontrare più 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.
Ci sono due comandi generici che possono essere passati al kernel al
momento del boot: ether e reserve. Si può far questo
con LILO, loadlin o qualsiasi altra utilità di boot che accetti
argomenti opzionali.
Per esempio, se il comando fosse 'blah' e si aspettasse 3 argomenti (diciamo 123, 456 e 789) allora con LILO si potrebbe usare:
LILO: linux blah=123,456,789
Questi parametri di boot possono essere resi permanenti cosicché non
si debba reinserirli ogni volta. Solitamente questo richiede solamente
l'inserimento di una riga come append="blah=123,456,789" all'inizio
del vostro /etc/lilo.conf. Si veda la documentazione di LILO per
ulteriori dettagli.
Per maggiori informazioni sui parametri di boot (e un elenco completo) si veda il BootPrompt-HOWTO.
etherIl parametro ether= viene usato in congiunzione con i driver direttamente
compilati nel kernel. Non ha assolutamente alcun effetto
su driver modulari. Nella sua forma più generale, può
somigliare a qualcosa come quel che segue:
ether=IRQ,IND_BASE,PARAM_1,PARAM_2,NOME
Tutti gli argomenti sono opzionali. Il primo argomento non numerico è interpretato come NOME.
IRQ: ovvio. Un valore di '0' (solitamente il valore predefinito) indica di usare autoIRQ. È accidentale che l'impostazione dell'IRQ sia prima di quella dell'ind_base: questo verrà corretto non appena cambia anche qualcos'altro.
IND_BASE: altrettanto ovvio. Il valore '0' (solitamente quello predefinito) indica di rilevare una scheda nell'elenco di indirizzi specifici per quella scheda.
PARAM_1: 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à), 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.
PARAM_2: 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.
NOME: 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 è per il rilevamento di un'unica scheda Ethernet, la 'eth0'. L'abilitazione di più schede è 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<n>' partendo da 'eth0'. Ulteriori schede Ethernet non LANCE dovevano essere esplicitamente assegnate a 'eth<n+1>', e il rilevamento standard di 'eth0' doveva essere disabilitato con qualcosa di simile a 'ether=0,-1,eth0' (sì, questo è un bug).
reserveQuesto comando di lilo viene usato proprio come il precedente 'ether=', ovvero viene accodato al nome di avvio selezionato in lilo.conf.
reserve=IO-base,estensione{,IO-base,estensione...}
In alcune macchine può essere necessario impedire ai driver di controllare la presenza di dispositivi (auto-probing) in regioni specifiche. Ciò può essere dovuto ad hardware mal progettato che causa il blocco del boot (come alcune schede Ethernet), ad hardware che viene mal identificato, ad hardware il cui stato è stato modificato da un rilevamento precedente, o semplicemente ad hardware che non vuole essere inizializzato dal kernel.
L'argomento di boot reserve 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à 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).
Le porte I/O nella regione specificata vengono protette dai controlli per la ricerca dei dispositivi. Questo si è 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.
Per esempio, la riga di boot
LILO: linux reserve=0x300,32 ether=0,0x300,eth0
impedisce a tutti i device driver, tranne a quelli della scheda Ethernet, di controllare se un dispositivo è presente nella regione 0x300-0x31f.
Come al solito per i comandi di boot, c'è un limite di 11 parametri, quindi si
possono specificare solo 5 regioni riservate per ciascun comando reserve.
Possono essere specificati più reserve se si hanno richieste insolitamente
complicate da descrivere.
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 modprobe(8) 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 modprobe.
La vostra distribuzione può 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.
Le informazioni che indicano quali moduli vengono usati e quali
opzioni vengono passate a ciascun modulo vengono solitamente salvate nel
file /etc/modules.conf. Le due opzioni principali di
interesse per le schede Ethernet che saranno usate in questo file sono
alias e options. Il comando modprobe consulta questo
file per informazioni sui moduli.
I moduli stessi sono tipicamente collocati in una directory chiamata
/lib/modules/`uname -r`/net dove il comando uname -r
restituisce la versione del kernel (e.g. 2.0.34). Si può andare li
per vedere quale modulo corrisponda alla propria scheda.
La prima cosa che ci deve essere nel file modules.conf è
una riga che indichi a modprobe quale driver usare per l'interfaccia
di rete eth0 (e per eth1 e per...). Per fare questo si
dovrà usare il comando alias. Per esempio, se si ha una scheda
ISA EtherEZ della SMC che usa il driver modulare smc-ultra.o,
si deve creare un alias per questo driver che corrisponda a
eth0, aggiungendo la riga:
alias eth0 smc-ultra
Nota Importante: l'alias summenzionato viene usato solo dalle utilità per
i moduli per convertire un nome di device generico (come ad esempio eth0)
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
(ethN per N=0,1,2,...). Quindi, se più di un modulo Ethernet viene
caricato, l'ethN assegnato al driver dal kernel può 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
ioctl(ethfd, SIOCGIFHWADDR, &ifreq).
L'altra cosa di cui si può aver bisogno è una riga options 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 alias con nessuna riga options, il kernel vi
avviserà (si veda dmesg) che l'auto rilevamento di una scheda ISA
non è una buona idea. Per eliminare questo problema, si
aggiunga un'altra riga che indica al modulo a quale indirizzo I/O base è
collocata la scheda, ad esempio perl'indirizzo esadecimale 0x280 si usi
options smc-ultra io=0x280
La maggior parte dei moduli ISA accettano parametri come io=0x340
e irq=12 sulla riga di comando di insmod. Fornire questi
parametri è RICHIESTO o almeno CALDAMENTE CONSIGLIATO per
evitare il rilevamento della scheda. Diversamente dai dispositivi PCI e
EISA, non c'è 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.
Un elenco di tutte le opzioni che ciascun modulo accetta può essere reperita nel file:
/usr/src/linux/Documentation/networking/net-modules.txt
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 è il caso di moduli che sono in grado di gestire più dispositivi con un unica copia del modulo, come tutti i driver basati su 8390 e il driver PLIP. Per esempio:
options 3c503 io=0x280,0x300,0x330,0x350 xcvr=0,1,0,1
Con la riga precedente si avrà 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.
Si noti inoltre che un modulo occupato non può essere rimosso.
Ciò significa che si dovrà usare ifconfig eth0 down (per disattivare
la scheda Ethernet) prima di rimuovere il modulo.
Il comando lsmod mostrerà quali moduli sono caricati e se sono in
uso, mentre il comando rmmod può essere usato per rimuoverli.
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à bene leggere il NET-2 Howto in modo che si possa realmente configurare il software che la userà. 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'è sempre un paragrafo o due che descrive i punti importanti.
A quanti cercano informazioni che non sono in alcun modo
specifiche su Linux (per esempio, cos'è 10BaseT, cos'è AUI, cosa fa un hub,
ecc.) suggerisco caldamente di rivolgersi a newsgroup come
comp.dcom.lans.ethernet e/o
comp.sys.ibm.pc.hardware.networking. Gli archivi dei newsgroup
come quelli a dejanews.com possono essere una insostituibile
fonte di informazioni. Si possono prendere le FAQ da RTFM (che
conserva tutte le FAQ dei newsgroup) all'URL seguente:
Si può anche dare un'occhiata alla cosiddetta 'Ethernet-HomePage', che è all'URL seguente:
This document is 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 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.
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.
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.
Permission is granted to copy and distribute translations of this document into another language, under the above conditions for modified versions.
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
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.
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ù grande di utenti,e non esiste maniera in cui io possa restare al corrente di tutti i nuovi sviluppi! Qui è 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. È un grande documento ed è facile non accorgersi di qualcosa. Se avete inviato una mail per una modifica e questa non è 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.
Grazie!
Paul Gortmaker, p_gortmaker@yahoo.com