Linux Ethernet-HOWTO
 by Paul Gortmaker
 v2.7, 5 maggio 1999

 Questo � Ethernet Howto, una raccolta di informazioni su quali dispos�
 itivi Ethernet possono essere usati con Linux e su come configurarli.
 Si noti che questo Howto si concentra sull'aspetto hardware e sui
 driver a basso livello delle schede Ethernet e non tratta l'aspetto
 software di cose come ifconfig e route.  Si veda il Network Howto per
 tali informazioni. Traduzione a cura di Lorenza Romano
 ([email protected]) e Giovanni Bortolozzo ([email protected]).

 1.  Introduzione


 Ethernet-Howto tratta delle schede che si dovrebbero e non si
 dovrebbero acquistare; di come configurarle, di come usarne pi� di una
 e di altri problemi e quesiti frequenti. Comprende informazioni
 dettagliate sull'attuale livello di supporto di tutte le pi� comuni
 schede Ethernet disponibili.

 Non comprende l'aspetto software delle cose, che � trattato nel NET-3
 Howto.  Si noti anche che quesiti generali, non specifici su Linux,
 riguardanti Ethernet, non trovano (o almeno non dovrebbero trovare)
 risposta qui. Per quesiti di quel tipo, si vedano le eccellenti
 informazioni nelle FAQ di comp.dcom.lans.ethernet, che possono essere
 scaricate via FTP da rtfm.mit.edu come tutte le altre FAQ dei
 newsgroup.

 Questa revisione tratta i kernel stabili fino alla versione 2.2.7
 compresa.

 Ethernet-Howto � di:

      Paul Gortmaker, [email protected]


 Fonte principale di informazioni per la versione iniziale di Ethernet-
 Howto, disponibile esclusivamente in formato ASCII, � stato:

      Donald J. Becker, [email protected]


 che dovremmo ringraziare per aver scritto la grande maggioranza dei
 driver attualmente disponibili per Linux  per le schede Ethernet. �
 anche l'autore dell'originario NFS server. Grazie Donald!

 Questo documento � Copyright (c) 1993-1999 di Paul Gortmaker.  Si
 vedano la liberatoria e le informazioni sulla copia alla fine di
 questo documento (``copyright'') per informazioni circa la
 ridistribuzione e le solite questioni legali ``non siamo responsabili
 per ci� che riuscirai a rompere...''.


 1.1.  Nuove versioni di questo documento


 Nuove versioni di questo documento possono essere reperite
 all'indirizzo:

 Ethernet-HOWTO <http://metalab.unc.edu/mdw/HOWTO/Ethernet-HOWTO.html>

 o per chi desidera usare FTP e/o procurarsi formati non HTML:

 Sunsite HOWTO Archive <ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/>

 Questo � il sito ufficiale, ma il documento pu� anche essere trovato
 nei diversi mirror WWW/ftp. Gli aggiornamenti vengono fatti appena
 nuove informazioni e/o driver diventano disponibili. Se la copia che
 si sta leggendo � vecchia di pi� di 6 mesi, si dovrebbe controllare
 per vedere se � disponibile una copia aggiornata.

 Questo documento � disponibile in diversi formati (postscript, dvi,
 ASCII, HTML, ecc.).  Personalmente consiglio di leggerlo in HTML
 (attraverso un browser WWW) o in formato Postscript/dvi. Entrambi
 contengono riferimenti incrociati che non sono inclusi nel formato
 ASCII.



 1.2.  Come usare Ethernet-Howto

 Poich� questa guida sta diventando sempre pi� grande, probabilmente
 non si vuole sprecare il resto del pomeriggio leggendola per intero. E
 la buona notizia � che non la si deve leggere tutta. Le versioni HTML
 e Postscript/dvi hanno un indice che aiuter� senz'altro a trovare ci�
 di cui si ha bisogno molto pi� velocemente.

 Pu� essere che si stia leggendo questo documento perch� non si riesce
 a far funzionare le cose e non si sa cosa controllare o verificare. La
 sezione ``AIUTO -- Non funziona!'' � rivolta ai nuovi utenti di Linux
 e metter� nella direzione giusta.

 Tipicamente gli stessi problemi e quesiti sono posti pi� e pi� volte
 da diverse persone. Pu� essere che il proprio problema specifico sia
 una delle Frequently Asked Questions (domande frequenti) e trova
 risposta nella sezione FAQ di questo documento (``Sezione FAQ'').
 Tutti dovrebbero dare un'occhiata a questa sezione prima di inviare
 una richiesta di aiuto.

 Se non si possiede una scheda Ethernet, allora si dovr� in primo luogo
 scegliere una scheda (``Che scheda si dovrebbe acquistare...'').

 Se si possiede gi� una scheda Ethernet, ma non si � sicuri di poterla
 usare con Linux, allora si dovr� leggere la sezione che contiene
 informazioni specifiche su ogni produttore e le relative schede
 (``Informazioni specifiche su...'').

 Se si � interessati ad alcuni degli aspetti tecnici dei driver dei
 dispositivi per Linux, allora si pu� dare una scorsa alla sezione
 contenente questo tipo di informazioni (``Informazioni tecniche'').


 1.3.  AIUTO -- Non funziona!


 Okay, niente panico. Questa sezione vi condurr� per mano nel processo
 che consente di far funzionare le cose anche se non si hanno
 precedenti conoscenze di Linux o sull'hardware Ethernet.

 La prima cosa da fare � scoprire il modello della propria scheda
 cosicch� si possa determinare se Linux ha un driver per quella
 particolare scheda. Generalmente schede diverse sono controllate in
 modo diverso dal computer ospite e il driver per Linux (se ne esiste
 uno) contiene queste informazioni per il controllo in un formato che
 permette a Linux di utilizzare la scheda.  Se non si ha un manuale o
 qualcosa del genere che dia informazioni sul modello della scheda,
 allora si pu� provare la sezione di aiuto sulle schede misteriose (si
 veda la sezione ``Identificare una scheda sconosciuta'').

 Ora che si sa che tipo di scheda si possiede, si leggano da cima a
 fondo i dettagli a essa relativi nella sezione sulle specifiche delle
 schede (``Informazioni specifiche su...'') che elenca in ordine
 alfabetico i produttori di schede, i numeri identificativi dei modelli
 e se c'� o meno un driver per Linux.  Se � catalogata come ``Non
 supportata'' ci si pu� pressoch� arrendere qui. Se non si riesce a
 trovare la propria scheda nell'elenco, si controlli per vedere se il
 suo manuale la cataloga come ``compatibile'' con un altro tipo di
 scheda conosciuto. Ci sono per esempio centinaia se non migliaia di
 schede diverse costruite per essere compatibili con il progetto
 originario NE2000 della Novell.

 Assumendo che si sia scoperto che esiste un driver per Linux per la
 propria scheda, � ora necessario trovarlo e farne uso.  Solo perch�
 Linux ha un driver per la propria scheda ci� non significa che esso
 sia compreso in ogni kernel (il kernel � il nucleo del sistema
 operativo, la prima cosa caricata all'avvio e contiene, tra le altre
 cose, i driver per le diverse parti hardware).  A seconda di chi ha
 prodotto la particolare distribuzione di Linux che si sta usando ci
 possono essere solo alcuni kernel precompilati e un grosso insieme di
 driver sotto forma di piccoli moduli separati, oppure un sacco di
 kernel, che coprono un enorme insieme di combinazioni di driver
 incorporati.

 Molte distribuzioni di Linux adesso contengono un gruppo di piccoli
 moduli, i diversi driver. I moduli necessari tipicamente vengono
 caricati in un secondo tempo nel processo di avvio o su richiesta non
 appena serve un driver per accedere ad un particolare dispositivo.
 Occorrer� inserire questo modulo nel kernel dopo che � stato avviato.
 Si vedano le informazioni fornite con la propria distribuzione
 sull'installazione e l'uso dei moduli, oltre alla sezione sui moduli
 in questo documento (``Usare i driver Ethernet come moduli'').

 Se non si � trovato n� un kernel precompilato con il proprio driver,
 n� il driver in forma modulare, � probabile che si possieda una scheda
 rara e si dovr� compilare il proprio kernel includendo il driver. Una
 volta installato Linux, la compilazione di un kernel su misura non �
 affatto difficile. Essenzialmente si risponde s� o no a cosa si vuole
 che il kernel contenga e poi gli si dice di compilarlo. Esiste un
 Kernel-Howto che aiuter� a far questo.

 A questo punto si dovrebbe essere riusciti in qualche modo ad avviare
 un kernel con il proprio driver incorporato o a caricare il driver
 come modulo. Poich� circa la met� dei problemi che ha la gente �
 dovuta al non avere caricato il driver n� in un modo n� nell'altro,
 ora si potrebbe scoprire che le cose funzionano.

 Se non funziona ancora allora � necessario verificare che il kernel
 stia effettivamente rilevando la scheda. Per fare questo, dopo che il
 sistema si � avviato e sono stati caricati tutti i moduli, fatto il
 login, digitare dmesg | more.  Questo permetter� di rivedere i
 messaggi che il kernel ha fatto scorrere sullo schermo durante il
 processo di avvio. Se la scheda � stata rilevata si dovrebbe vedere da
 qualche parte in quell'elenco, un messaggio del driver della propria
 scheda che inizia con eth0 e cita il nome del driver e i parametri
 hardware per i quali � stata configurata (configurazione degli
 interrupt, indirizzo delle porte di input/output, ecc.).  Nota: Linux
 all'avvio elenca tutte le schede PCI installate nel sistema, senza
 badare ai driver disponibili, non si scambi questo per la rilevazione
 dei driver che avviene pi� tardi.

 Se non si vede un messaggio di identificazione del driver di questo
 tipo, allora il driver non ha rilevato la propria scheda e questo � il
 motivo per il quale le cose non funzionano. Si vedano le FAQ
 (``Sezione FAQ'') per il da farsi se la propria scheda non viene
 rilevata. Nel caso si possieda una scheda NE2000 compatibile, nella
 sezione FAQ vi sono anche alcuni suggerimenti specifici per fare in
 modo che la scheda venga rilevata.
 Se la scheda viene rilevata ma il messaggio di rilevamento riporta un
 errore di qualche tipo, come un conflitto di risorsa, probabilmente il
 driver non sar� inizializzato correttamente e la scheda continuer� a
 non essere utilizzabile. Anche i pi� comuni messaggi di errore di
 questo tipo sono elencati nella sezione FAQ insieme ad una soluzione.

 Se il messaggio di rilevamento sembra corretto, confrontare bene le
 risorse della scheda riportate dal driver con quelle per le quali la
 scheda � fisicamente configurata (attraverso dei piccoli ponticelli di
 colore nero sulla scheda o attraverso delle utilit� software fornite
 dal produttore). Queste devono corrispondere esattamente.  Per esempio
 se la scheda � configurata per IRQ 15 e il driver riporta nei messaggi
 di avvio IRQ 10, le cose non funzioneranno. La sezione FAQ tratta i
 casi pi� comuni di driver che non rilevano correttamente le
 informazioni di configurazione delle diverse schede.

 A questo punto si � riusciti a far s� che la propria scheda sia
 rilevata con tutti i parametri corretti e, se tutto va bene, le cose
 funzionano. Altrimenti si ha o un errore di configurazione software o
 un errore di configurazione hardware. Un errore di configurazione
 software � il non configurare correttamente gli indirizzi di rete
 usando i comandi ifconfig e route e dettagli su come fare queste cose
 sono esaurientemente descritti nel Network HowTo e nella ``Network
 Administrator Guide''. Probabilmente entrambi si trovano nel CD-ROM
 che si � usato per l'installazione.

 Un errore di configurazione hardware si ha quando un qualche conflitto
 di risorsa o errore di configurazione (che il driver non ha rilevato
 in fase di avvio) impedisce alla scheda di funzionare correttamente.
 Ci� pu� essere osservato in parecchie situazioni diverse. (1) Si ha un
 messaggio di errore quando ifconfig tenta di aprire il dispositivo per
 usarlo, del tipo ``SIOCSFFLAGS: Try again''. (2) Il driver riporta
 messaggi d'errore su eth0 (li si pu� vedere usando dmesg | more) o
 strane incongruenze ogniqualvolta prova a mandare o ricevere dati. (3)
 Digitando cat /proc/net/dev appaiono numeri diversi da zero in una
 delle colonne errs, drop, fifo, frame o carrier corrispondenti a eth0.
 (4) Digitando cat /proc/interrupts appare un numero di interrupt nullo
 per la scheda.  Anche la maggior parte dei tipici errori di
 configurazione hardware sono discussi nella sezione FAQ.

 Bene, se si � arrivati a questo punto e le cose non funzionano ancora,
 si legga la sezione FAQ di questo documento, si legga la sezione sulle
 specifiche dei produttori che descrive la propria scheda, e se ancora
 non funziona allora si dovrebbe riccorrere all'invio di una richiesta
 di aiuto ad un opportuno newsgroup. Se si invia la richiesta, si
 descrivano dettagliatamente tutte le informazioni del caso tipo la
 marca della scheda, la versione del kernel, i messaggi del driver
 all'avvio, l'output di cat /proc/net/dev, una chiara descrizione del
 problema e naturalmente cosa si � gi� provato a fare per far
 funzionare le cose.

 Sorprenderebbe sapere quante persone inviano cose inutili del tipo
 ``Pu� aiutarmi qualcuno? La mia scheda Ethernet non funziona'' e
 nient'altro.  I lettori dei newsgroup tendono a ignorare queste
 richieste stupide, mentre una descrizione dettagliata del problema pu�
 consentire a un ``Linux-guru'' di individuare immediatamente il
 problema.




 2.  Che scheda si dovrebbe acquistare per Linux?


 La risposta a questa domanda dipende molto da cosa si intende
 esattamente fare con la propria connessione di rete e quanto traffico
 dovr� sostenere.

 Se si prevede un singolo utente che occasionalmente faccia una
 sessione FTP o una connessione WWW, allora probabilmente anche una
 vecchia scheda ISA a 8 bit far� al proprio caso.

 Se si intende installare un server e si vuole che l'overhead della CPU
 per la trasmissione e ricezione dei dati sia mantenuto al minimo,
 probabilmente si deve considerare una delle schede PCI che usano un
 chip con capacit� di bus-mastering, per esempio il chip tulip (21xxx)
 della DEC o il chip Pcnet-PCI della AMD.

 Se si � in una situazione intermedia tra le due citate, una qualsiasi
 delle schede a basso costo PCI o ISA a 16 bit con driver stabili andr�
 bene.


 2.1.  E quali sono i driver stabili?


 Per schede ISA a 16 bit, i seguenti driver sono piuttosto maturi e non
 si dovrebbero avere problemi se si acquista una scheda che li
 utilizza:

 SMC-Ultra/EtherEZ, SMC-Elite (WD80x3), 3c509, Lance, NE2000.

 Ci� non significa che tutti gli altri driver non siano stabili. Si d�
 il caso che quelli sopra siano i pi� vecchi e i pi� utilizzati fra
 tutti i driver per Linux e questo li rende l'alternativa pi� sicura.

 Si noti che alcune schede madri economiche possono avere problemi con
 il bus-mastering fatto dalle schede Lance ISA e che alcuni cloni
 NE2000 possono avere problemi a essere rilevati all'avvio.

 I driver PCI per Linux pi� comunemente usati sono probabilmente quelli
 per le Vortex/Boomerang (3c59x/3c9xx) della 3Com, il tulip (21xxx)
 della DEC e la EtherExpressPro 100 dell'Intel.  Anche le diverse
 schede clone della NE2000 PCI sono estremamente comuni, ma l'acquisto
 di un clone di questa scheda non � raccomandato a meno che spendere il
 meno possibile non sia pi� importante che avere una scheda moderna
 concepita per elevate prestazioni.



 2.2.  Schede a 8 bit e schede a 16 bit a confronto

 Probabilmente non � pi� possibile acquistare una scheda ISA a 8 bit
 nuova, ma per i prossimi anni ne salterranno fuori molte, e a prezzi
 molti bassi, ai raduni in cui avvengono scambi di pezzi per computer.
 Questo le render� popolari per i sistemi ``Ethernet casalinghi''.
 Quanto sopra � valido adesso anche per le schede ISA a 16 bit visto
 che ora sono le schede PCI a essere molto comuni.

 Alcune schede a 8 bit che forniscono adeguate prestazioni per un uso
 dal leggero al medio sono la wd8003, la 3c503 e la ne1000.  La 3c501
 fornisce prestazioni scadenti; queste povere reliquie dei tempi XT,
 vecchie di 12 anni, dovrebbero essere evitate (si mandino ad Alan, le
 colleziona...).

 Il canale dati a 8 bit non nuoce cos� tanto alle prestazioni: ci si
 pu� aspettare di scaricare via ftp da un host veloce da 500 a 800kB/s
 con una scheda a 8 bit wd8003 (su un bus ISA veloce).  Se la maggior
 parte del proprio traffico di rete � verso siti remoti allora il collo
 di bottiglia nel percorso sar� altrove e la sola differenza in
 velocit� di cui ci si accorger� � durante l'attivit� di rete nella
 propria sottorete.
 2.3.  Schede Ethernet (VLB/EISA/PCI) a 32 bit


 Si noti che una rete a 10Mbps tipicamente non giustifica la richiesta
 di una interfaccia a 32 bit.  Si veda ``I/O programmato vs. ...'' sul
 perch� avere una scheda Ethernet a 10Mbps su un bus ISA a 8 MHz
 realmente non � un collo di bottiglia. Anche se avere la scheda
 Ethernet su un bus veloce non significher� necessariamente
 trasferimenti pi� veloci, ci� di solito comporter� una riduzione del
 carico della CPU e questo � un vantaggio per sistemi multi utente.

 Naturalmente per reti a 100Mbps, che sono attualmente una
 consuetudine, l'interfaccia a 32 bit � una cosa di cui non si pu� fare
 a meno per far uso dell'intera banda.

 La AMD offre i chip a 32 bit PCnet-VLB e PCnet-PCI.  Si veda ``AMD
 PCnet-32'' per informazioni sulle versioni a 32 bit del chip LANCE /
 PCnet-ISA.

 Il chip 21xxx PCI ``tulip'' della DEC � un'altra alternativa per i pi�
 esigenti (si veda ``DEC 21040'').  Molti produttori realizzano schede
 che usano questo chip e il prezzo di queste schede senza nome � di
 solito abbastanza conveniente.

 Un'altra possibilit� sono le schede PCI `Vortex' e `Boomerang' della
 3Com e il prezzo � abbastanza conveniente se si riesce a procurarsene
 una con un contratto di valutazione, finch� dura (si veda
 ``3c590/3c595'').

 Anche le schede PCI EtherExpress Pro 10/100 della Intel si dice
 funzionino bene con Linux (si veda ``EtherExpress'')

 Parecchi produttori di cloni hanno iniziato a fare NE2000 PCI basate
 su chip RealTek o Winbond. Anche queste schede sono supportate dal
 driver per Linux ne2000 per i kernel versione v2.0.31 e pi� recenti.
 Comunque si trae profitto solo dalla interfaccia bus pi� veloce visto
 che la scheda usa ancora l'antichissima interfaccia driver ne2000.
 Dalla versione v2.0.34 (e superiori) � disponibile anche un driver
 separato specifico per queste schede PCI ne2k-pci.c che � pi�
 efficiente del driver ISA ne.c.


 2.4.  Schede e driver a 100Mbps disponibili


 La lista dell'hardware a 100Mbps attualmente supportato � la seguente:
 schede con chip DEC 21140; schede 3c595/3c90x Vortex; le
 EtherExpressPro10/100B; le PCnet-FAST; le SMC 83c170 (epic100) e le HP
 100VG ANY-LAN.

 Per ciascun tipo si dia un'occhiata alle informazioni specifiche sui
 produttori presenti in questo documento. Pu� essere necessario dare
 un'occhiata anche a uno di questi:




 Linux and 100Mbs Ethernet
 <http://cesdis.gsfc.nasa.gov/linux/misc/100mbs.html>

 Donald's 100VG Page
 <http://cesdis.gsfc.nasa.gov/linux/drivers/100vg.html>

 Dan Kegel's Fast Ethernet Page <http://alumni.caltech.edu/~dank/fe/>


 2.5.  100VG e 100BaseT a confronto


 100BaseT � molto pi� importante di 100VG e il seguente messaggio
 promazionale di Donald tratto da una delle sue news informative pi�
 vecchie inviate su comp.os.linux riassume abbastanza bene la
 situazione: �Per coloro che non ne sono al corrente, esistono due
 standard Ethernet a 100Mbs in competizione, 100VG (conosciuto anche
 come 100baseVG e 100VG-AnyLAN) e 100baseT (con tipi di cavo 100baseTx,
 100baseT4 e 100baseFx).  Lo standard 100VG � entrato per primo sul
 mercato e penso sia stato strutturato meglio rispetto al 100baseTx.
 Facevo il tifo affinch� vincesse ma certamente non vincer�. HP e altri
 hanno fatto parecchie scelte sbagliate:

 1) Rinviando lo standard cos� da poter favorire IBM e supportare i
 frame token ring. Ci� sembr� una buona idea all'epoca visto che
 avrebbe consentito alle imprese che usavano token ring di aggiornare
 senza che i loro manager dovessero ammmettere di aver fatto un errore
 molto costoso commissionando la tecnologia sbagliata. Ma non ci si
 guadagn� nulla visto che i due tipi di frame non potevano coesistere
 su una rete, il token ring � un pantano di complessit� e comunque IBM
 pass� a 100baseT.

 2) Producendo esclusivamente schede ISA e EISA (un modello PCI � stato
 annunciato solo recentemente). Il bus ISA � troppo lento per 100Mbs ed
 esistono relativamente poche macchine EISA. All'epoca VLB era comune,
 veloce e conveniente e PCI una alternativa fattibile. Ma il buon senso
 ``tradizionalista'' riteneva che i server si sarebbero fermati ai pi�
 costosi bus EISA.

 3) Non inviandomi un databook. S� questa mossa � stata la vera ragione
 del fallimento di 100VG :-). Ho richiesto ovunque informazioni di
 programmazione e tutto ci� che ho potuto ottenere � stata una brochure
 a colori dalla AT&T, di qualche pagina, su carta patinata, che
 descriveva quanto meraviglioso fosse il chipset Regatta.�



 2.6.  Tipi di cavo che la propria scheda dovrebbe supportare

 Se si sta allestendo una piccola rete ``personale'', si dovr�
 probabilmente usare thinnet ovvero cavi Ethernet sottili. Cio� la
 versione con connettori standard BNC.  La thinnet o cablaggio Ethernet
 sottile (cavo coassiale RG-58) con connettori BNC (di metallo, da
 spingere e girare per chiudere) � chiamata tecnicamente 10Base2.

 Stanno diventando comuni anche moltissime schede Ethernet in una
 versione ``mista'' (combo) per soli $10-$20 in pi�. Queste schede
 hanno incorporato sia il transceiver per il doppino intrecciato
 (twisted pair) che per thinnet, consentendo di cambiare idea in
 seguito.

 Il cavo a doppino intrecciato e connettori RJ-45 (giant phone jack --
 connettore telefonico gigante) � chiamato tecnicamente 10BaseT. Lo si
 pu� sentir chiamare anche UTP (Unshielded Twisted Pair -- doppino
 intrecciato non schermato).

 La pi� datata thick (spessa) Ethernet (cavo coassiale da 10mm), che si
 trova solo nelle installazioni pi� vecchie, � chiamata 10Base5. La
 spina a 15 pin, a forma di lettera D, che si trova su alcune schede
 Ethernet (il connettore AUI) � usato per connettere transceiver
 esterni e thick Ethernet.

 Installazioni aziendali estese useranno probabilmente 10BaseT
 piuttosto che 10Base2. 10Base2 non offre alcuna possibilit� di
 aggiornamento a una 100Base-qualsiasi.
 Si veda ``Cavi, coassiali,...'' per altre informazioni riguardanti i
 diversi tipi di cavi Ethernet.



 3.  Domande frequenti

 Ecco alcuni dei quesiti posti pi� frequentemente a proposito dell'uso
 di Linux con una connessione Ethernet. Alcuni dei quesiti pi�
 specifici sono classificati in ``base al costruttore''.  Pu� essere
 che il quesito per il quale si ha bisogno di una risposta sia gi�
 stato posto da qualcun altro (e abbia trovato risposta!), perci� anche
 se non si trova la risposta qui, probabilmente si pu� trovare ci� che
 di cui si ha bisogno in un archivio di news come Dejanews
 <http://www.dejanews.com>.


 3.1.  Driver alpha -- come procurarseli e come usarli

 Ho sentito che � disponibile un driver aggiornato oppure un driver
 preliminare o alpha (sperimentale) per la mia scheda. Dove posso
 procurarmelo?

 Il ``pi� nuovo dei nuovi'' driver pu� essere trovato sul sito FTP di
 Donald: cesdis.gsfc.nasa.gov nell'area /pub/linux/. Qui le cose
 cambiano abbastanza frequentemente perci� si cerchi bene. In
 alternativa, per localizzare il driver che si sta cercando, pu� essere
 pi� facile usare un browser WWW all'indirizzo:

 Don's   Linux Home Page <http://cesdis.gsfc.nasa.gov/linux/>

 (ci si guardi dai browser WWW che fanno il ``munge'' (NdT munge:
 trasformare in modo imperfetto le informazioni [dal Jargon Lexicon])
 del sorgente sostituendo i TAB con spazi e cos� via -- se si � incerti
 usare ftp o almeno un URL FTP per scaricare).

 Ora, se il driver � realmente un alpha o pre-alpha, lo si tratti come
 tale. In altre parole, non si reclami perch� non si capisce cosa
 farne. Se non si riesce a capire come installarlo allora probabilmente
 non lo si dovrebbe provare. Anche se mette fuori uso la propria
 macchina, non si reclami. Si mandi invece un rapporto ben documentato
 del bug o, ancora meglio, una patch!

 Si noti che alcuni dei driver sperimentali/alpha ``utilizzabili'' sono
 stati inclusi nell'albero dei sorgenti del kernel standard.  Una delle
 prime cose che verranno chieste quando si esegue make config �
 ``Prompt for development and/or incomplete code/drivers'' (proposta
 per il codice o driver in fase di sviluppo o incompleti).  Si dovr�
 rispondere ``Y'' (s�) per richiedere l'inclusione di un qualche driver
 alpha/sperimentale.


 3.2.  Come usare pi� di una scheda Ethernet per macchina


 Cosa � necessario fare affinch� Linux possa utilizzare due schede
 Ethernet?

 La risposta a questo quesito dipende se si sta/stanno usando il/i
 driver come modulo caricabile o direttamente compilato nel kernel.
 Adesso moltissime distribuzioni di Linux usano driver modulari. Ci�
 evita di dover distribuire un mucchio di kernel ciascuno contenente un
 insieme diverso di driver.  Si usa invece un singolo kernel di base e
 i driver necessari per un particolare sistema utente vengono caricati
 una volta che l'avvio del sistema � arrivato al punto tale da poter
 accedere ai file dei moduli dei driver (memorizzati di solito in
 /lib/modules/).

 Con il driver come modulo: Nel caso di driver PCI, in genere il modulo
 rileva automaticamente tutte le schede installate di quello specifico
 modello. Comunque il rilevamento di una scheda non � una operazione
 sicura per schede ISA, perci� di solito � necessario fornire
 l'indirizzo base di I/O della scheda affinch� il modulo sappia dove
 guardare.  Questa informazione � memorizzata nel file
 /etc/conf.modules.

 Come esempio si consideri un utente che ha due schede ISA NE2000, una
 a 0x300 ed una a 0x240 e le righe da mettere nel file
 /etc/conf.modules:


         alias eth0 ne
         alias eth1 ne
         options ne io=0x240,0x300



 Come agisce: se l'amministratore (o il kernel) fa un modprobe eth0
 oppure un modprobe eth1 allora dovrebbe essere caricato il driver ne.o
 sia per eth0 che per eth1. Inoltre quando � caricato il modulo ne.o,
 dovrebbe esserlo con le opzioni io=0x240,0x300 cosicch� il driver sa
 dove cercare le schede. Si noti che 0x � importante, cose del tipo
 300h, comunemente usate nel mondo DOS, non funzionano. Cambiando
 l'ordine di 0x240 e 0x300 si cambier� quale scheda fisica finir� in
 eth0 e quale in eth1.

 Per gestire pi� schede, molti driver modulari ISA possono accettare
 diversi valori di I/O separati da virgole, come in questo esempio.
 Comunque, alcuni driver (pi� vecchi?), come il modulo 3c501.o,
 attualmente sono in grado di gestire solo una scheda per modulo
 caricato.  In questo caso si pu� caricare il modulo due volte per far
 s� che entrambe le schede siano rilevate.  Il file /etc/conf.modules
 dovrebbe presentarsi cos�:


         alias eth0 3c501
         alias eth1 3c501
         options eth0 -o 3c501-0 io=0x280 irq=5
         options eth1 -o 3c501-1 io=0x300 irq=7



 In questo esempio l'opzione -o � stata usata per dare a ogni istanza
 del modulo un nome univoco, poich� non � possibile caricare due moduli
 con lo stesso nome.  � anche usata l'opzione irq= per specificare la
 configurazione IRQ hardware della scheda (questo metodo pu� essere
 usato anche con moduli che accettano valori di I/O separati da
 virgole, ma � meno efficiente poich� il modulo finisce per essere
 caricato due volte anche se non sarebbe realmente necessario).

 Come esempio finale, si consideri un utente con una scheda 3c503 a
 0x350 e una SMC Elite16 (wd8013) a 0x280.  Avranno:


         alias eth0 wd
         alias eth1 3c503
         options wd io=0x280
         options 3c503 io=0x350




 Per le schede PCI, tipicamente sono necessarie solamente le righe
 alias per correlare le interfacce ethN con l'appropriato nome del
 driver, poich� l'I/O base di una scheda PCI pu� essere rilevato in
 modo sicuro.

 I moduli disponibili sono tipicamente memorizzati in
 /lib/modules/`uname -r`/net dove il comando uname -r fornisce la
 versione del kernel (es. 2.0.34).  Si pu� guardare l� per vedere quale
 corrisponde alla propria scheda.  Una volta che si hanno le
 impostazioni corrette nel proprio file conf.modules, si pu� collaudare
 il tutto con:


         modprobe ethN
         dmesg | tail



 dove `N' � il numero dell'interfaccia Ethernet che si sta collaudando.

 Con il driver compilato nel kernel: Se si ha il driver compilato nel
 kernel, allora tutto quel che serve per usare pi� schede Ethernet lo
 si ha gi�.  Comunque si noti che al momento, per default, solo una
 scheda Ethernet � rilevata automaticamente.  Ci� aiuta a evitare
 possibili blocchi all'avvio causati dal rilievo di schede ``ombrose''.

 (Nota: dagli ultimi kernel 2.1.x, i rilievi al boot sono stati
 separati in sicuri ed insicuri, in modo che tutti quelli sicuri (es.
 PCI e EISA) trovino automaticamente tutte le loro schede.  Nei sistemi
 con pi� di una scheda Ethernet e almeno una scheda ISA, sar� ancora
 necessario fare una delle cose che seguono.)

 Ci sono due modi per abilitare l'auto-rilevamento della seconda (e la
 terza, e...) scheda.  Il metodo pi� semplice � di passare al momento
 dell'avvio, degli argomenti al kernel, solitamente usando LILO.  Il
 rilevamento della seconda scheda pu� essere ottenuto con un semplice
 argomento di boot come ether=0,0,eth1.  In questo caso eth0 e eth1
 saranno assegnate nell'ordine in cui sono rilevate le schede al boot.
 Diciamo che si vuole che la scheda a 0x300 sia eth0 e quella a 0x280
 sia eth1, allora si potrebbe usare


      LILO: linux ether=5,0x300,eth0 ether=15,0x280,eth1


 Il comando ether= accetta pi� della terna IRQ, I/O e nome mostrata
 sopra.  Si veda la sezione ``Passare argomenti Ethernet...'' per la
 sintassi completa, i parametri specifici delle schede e dritte su
 LILO.

 Questi argomenti di boot possono essere resi permanenti cosicch� non
 si debba reinserirli ogni volta.  Si veda l'opzione di configurazione
 di LILO append nel manuale di LILO.

 Il secondo metodo (non raccomandato) � di modificare il file Space.c e
 sostituire la voce 0xffe0 per l'indirizzo I/O con uno zero.  La voce
 0xffe0 dice di non cercare quel dispositivo -- rimpiazzandola con uno
 zero si abiliter� l'autorilevamento di quel dispositivo.

 Si noti che, se si intende usare Linux come gateway tra due reti, si
 dovr� ricompilare un kernel abilitando l'IP forwarding (inoltro degli
 IP).  Solitamente usare un vecchio AT/286 con un software del tipo
 ``kbridge'' � una soluzione migliore.

 Se si sta leggendo questa cosa mentre si naviga in rete, si potrebbe
 guardare il mini-howto che Donald ha nel suo sito WWW. Si veda
 Multiple Ethercards
 <http://cesdis.gsfc.nasa.gov/linux/misc/multicard.html>.


 3.3.  Il comando ether=  non � servito a niente. Perch�?

 Come descritto sopra, il comando ether= funziona solo per driver
 compilati nel kernel.  Adesso molte distribuzioni usano i driver in
 forma modulare, perci� il comando ether= � usato ancora raramente
 (certa documentazione pi� vecchia non � ancora stata aggiornata per
 riportare questo cambiamento). Se si vogliono adoperare le opzioni per
 un driver Ethernet modulare si devono fare modifiche al file
 /etc/conf.modules.

 Se si sta usando un driver compilato nel kernel e si � aggiunto un
 comando ether= al proprio file di configurazione LILO, si noti che
 esso non avr� effetto fino a che non si riesegue lilo per eseguire il
 file di configurazione aggiornato.



 3.4.  Problemi con schede NE1000/NE2000 (e cloni)

 Problema: Una scheda clone PCI NE2000 non � rilevata all'avvio usando
 una versione del kernel v2.0.x.

 Causa: Il driver ne.c, fino alla versione del kernel v2.0.30, conosce
 solo il numero identificativo PCI delle schede clone basate su RealTek
 8029. Da allora, molti altri hanno distribuito cloni PCI NE2000 con
 diversi numeri identificativi PCI, perci� il driver non li rileva.

 Soluzione: La soluzione pi� facile consiste nell'aggiornare il kernel
 di Linux alla versione v2.0.31 (o pi� recente). Essa � a conoscenza
 dei numeri identificativi di circa cinque diversi chip PCI NE2000 e li
 rileva automaticamente all'avvio o nella fase di caricamento del
 modulo. Se si aggiorna alla versione 2.0.34 (o pi� recente) esiste un
 driver specifico NE2000 solo PCI che � leggermente pi� piccolo e pi�
 efficiente del driver originario ISA/PCI.

 Problema: Una scheda clone PCI NE2000 si presenta come una ne1000
 (scheda a 8 bit!) all'avvio o quando si carica il modulo ne.o per la
 versione v2.0.x, perci� non funziona.

 Causa: Alcuni cloni PCI non implementano l'accesso byte wide (perci�
 non sono realmente compatibili NE2000 al 100%). Ci� fa pensare al
 sistema che siano schede NE1000.

 Soluzione: � necessario aggiornare il kernel alla versione v2.0.31 (o
 pi� recente) come descritto sopra.  Adesso il driver controlla che non
 si verifichi questo problema hardware.

 Problema: Una scheda PCI NE2000 ha prestazioni orribili, anche se si
 riduce la dimensione della finestra come descritto nella sezione
 ``Suggerimenti per le prestazioni''.

 Causa: Le specifiche per il chip 8390 originale, progettato e
 commercializzato pi� di dieci anni fa, osservavano che per ottenere la
 massima affidabilit�, era necessaria una lettura fittizia dal chip
 prima di ogni operazione di scrittura. Il driver ha i mezzi per farlo
 ma � stato disabilitato per default sin dai tempi dei kernel v1.2. Un
 utente ha riferito che riabilitare questa 'mis-feature' ha migliorato
 le prestazioni ottenute con un clone economico PCI NE2000.

 Soluzione: Visto che questa soluzione � stata riportata da una sola
 persona, non ci si illuda troppo. La riabilitazione della lettura
 prima della scrittura si ottiene semplicemente modificando il file del
 driver in linux/drivers/net/, togliendo il commento alla riga
 contenente NE_RW_BUGFIX e poi ricompilando il kernel o il modulo come
 al solito. Se funziona si invii una e-mail che descrive la differenza
 di prestazioni e il tipo  di scheda/chip che si possiede (la stessa
 cosa pu� essere fatta anche per il driver ne2k-pci.c).

 Problema: Il driver ne2k-pci.c, con una scheda PCI NE2000, riporta
 messaggi di errore del tipo timeout waiting for Tx RDC e non funziona
 bene.

 Causa:  La propria scheda e/o il collegamento tra la scheda e il bus
 PCI non pu� gestire l'ottimizzazione I/O a long word usata in questo
 driver.

 Soluzione: Prima di tutto, si controllino le impostazioni disponibili
 nel BIOS/CMOS setup per vedere se alcune di quelle correlate alla
 temporizzazione del bus PCI, sono troppo stringenti per ottenere
 operazioni affidabili.  Altrimenti, l'uso del driver ISA/PCI ne.c (o
 la rimozione di #define USE_LONGIO dal driver ne2k-pci.c) dovrebbe
 permettere di usare la scheda.

 Problema: Una scheda ISA Plug and Play NE2000 (per esempio RealTek
 8019) non � rilevata.

 Causa: Le specifiche originarie NE2000 (e perci� il driver per Linux
 NE2000) non hanno il supporto per il Plug and Play.

 Soluzione: Si usi il disco di configurazione DOS fornito con la scheda
 per disabilitare PnP e per assegnare la scheda ad uno specifico
 indirizzo di I/O e IRQ. Si aggiunga una riga a /etc/conf.modules del
 tipo options ne io=0xNNN dove 0xNNN � l'indirizzo di I/O in formato
 esadecimale a cui la scheda � stata assegnata (ci� assume che si stia
 usando un driver modulare; se non � cos� si usi all'avvio un argomento
 ether=0,0xNNN,eth0).  Pu� accadere anche che si debba entrare nel
 BIOS/CMOS setup e contrassegnare l'IRQ come Legacy-ISA al posto di
 PnP. In alternativa, se � necessario lasciare PnP abilitato per la
 compatibilit� con qualche altro sistema operativo, si consideri il
 pacchetto isapnptools. Si provi man isapnp per capire se � gi�
 installato nel proprio sistema. Se non lo �, si dia un'occhiata al
 seguente URL:

 ISA PNP Tools <http://www.roestock.demon.co.uk/isapnptools/>


 Problema: Un driver NE*000 riporta `not found (no reset ack)' durante
 il rilevamento all'avvio.

 Causa: Ci� � collegato alla modifica vista in precedenza.  Dopo la
 verifica iniziale che un 8390 � all'indirizzo di I/O rilevato, si
 effettua la riinizializzazione (reset).  Quando la scheda ha
 completato tale operazione, si suppone dichiari (acknowlodge) che �
 completata. La propria scheda non lo fa e cos� il driver assume che
 nessuna scheda NE sia presente.

 Soluzione: Si pu� dire al driver che si possiede una scheda scadente
 specificando al momento dell'avvio il valore esadecimale 0xbad,
 solitamente non usato, per mem_end (NdT: si noti che ``bad'' significa
 letteralmente ``cattivo, brutto, scarso, ecc.'').  Quando si usa
 0xbad, si deve anche fornire un I/O base diverso da zero per la
 scheda.  Per esempio, una scheda a 0x340 che non dichiara il
 completamento del reset dovrebbe usare qualcosa del tipo:


      LILO: linux ether=0,0x340,0,0xbad,eth0


 Ci� permette che il rilevamento della scheda continui anche se la pro�
 pria scheda non effettua l'ACK del reset. Se si sta usando il driver
 come modulo, allora si pu� fornire l'opzione bad=0xbad proprio come si
 fornisce l'indirizzo di I/O.


 Problema: Una scheda NE*000 blocca la macchina al primo accesso alla
 rete.

 Causa: Questo problema � stato riportato per kernel a partire dalla
 versione 1.1.57 fino alla corrente. Sembra confinato a poche schede
 clone configurabili via software. Apparentemente sie aspettano di
 essere inizializzate in qualche modo speciale.

 Soluzione: Diverse persone hanno riferito che l'esecuzione del
 programma DOS di configurazione software e/o l'uso del driver per DOS
 forniti con la scheda prima di fare il boot ``a caldo'' di Linux (cio�
 usando loadlin o con il ``saluto a tre dita'' (CTRL-ALT-CANC))
 consente alla scheda di funzionare. Ci� indicherebbe che queste schede
 necessitano di essere inizializzate in un modo particolare,
 leggermente diverso da ci� che fa l'attuale driver per Linux.

 Problema: Una scheda Ethernet NE*000 a 0x360 non viene rilevata.

 Causa: La propria scheda ha uno spazio degli indirizzi di I/O ampio
 0x20, il che la fa entrare in collisione con la porta parallela a
 0x378.  Altri dispositivi che possono essere l� sono il secondo
 controller del floppy (se in dotazione) a 0x370 e il controller
 secondario IDE a 0x376--0x377.  Se la/le porta/e sono gi� assegnate ad
 un altro driver, il kernel non permette che avvenga il rilevamento.


 Soluzione: Si sposti la propria scheda ad un indirizzo del tipo 0x280,
 0x340, 0x320 o si compili senza il supporto per la stampante su porta
 parallela.

 Problema: La rete ``scompare'' ogniqualvolta si stampa qualcosa
 (NE2000).

 Causa: Il problema � lo stesso visto sopra, ma si ha un kernel pi�
 vecchio che non verifica la sovrapposizione delle regioni di I/O. Si
 usi la stessa soluzione vista prima e ancora meglio ci si procuri un
 nuovo kernel.

 Problema: NE*000 ethercard probe at 0xNNN: 00 00 C5 ... not found.
 (invalid signature yy zz)

 Causa: Prima di tutto, si ha una scheda NE1000 o NE2000 all'indirizzo
 0xNNN?  Se s�, l'indirizzo hardware riportato ha l'aria di essere uno
 valido?  Se s�, allora si possiede un clone NE*000 disgraziato. Si
 suppone che tutti i cloni NE*000 abbiano il valore ox57 nei byte 14 e
 15 della PROM SA sulla scheda. La propria scheda non ce l'ha -- essa
 ha invece 'yy zz'.

 Soluzione: Ci sono due modi di aggirare l'ostacolo. Il pi� facile
 consiste nell'usare un valore di mem_end 0xbad come descritto sopra
 per il problema `no reset ack'. Ci� consentir� di bypassare il
 controllo della firma, sempre che si fornisca anche un valore I/O base
 diverso da zero. Questa soluzione non richiede di ricompilare il
 kernel.

 Il secondo metodo (per hacker) comporta la modifica delle stesso
 driver e la ricompilazione del proprio kernel (o modulo). Il driver
 (usr/src/linux/drivers/net/ne.c) contiene un elenco ``Hall of Shame''
 (Ndt: gioco di parole con ``Hall of Fame''; ``fame''= famoso,
 ``shame''=vergogna, disonore) pressappoco alla riga 42. Questo elenco
 � usato per rilevare cloni disgraziati. Per esempio, le schede DFI
 usano ``DFI'' nei primi 3 byte della PROM al posto di usare 0x57 nei
 byte 14 e 15 (come dovrebbero fare).

 Problema: La macchina si blocca durante l'avvio giusto dopo il
 messaggio `8390...' oppure `WD....'. La rimozione della NE2000 risolve
 il problema.

 Soluzione: Si cambi l'indirizzo base della propria NE2000 con qualcosa
 del tipo 0x340. In alternativa si pu� usare l'argomento di boot
 ``reserve='' in combinazione con l'argomento ``ether='' per tutelare
 la scheda da rilievi di altri driver di dispositivi.

 Causa: Il proprio clone NE2000 non � un clone abbastanza buono. Una
 NE2000 effettiva � un abisso senza fondo che intrappola ogni driver
 che stia facendo l'autorilevamento nel suo spazio.  Spostare la NE2000
 ad un indirizzo meno popolare la porta fuori dalla portata di altri
 rilievi automatici, consentendo alla macchina di avviarsi.

 Problema: La macchina si blocca all'avvio durante il rilevamento SCSI.

 Causa: � lo stesso problema visto precedentemente, si cambi
 l'indirizzo della scheda Ethernet o si usino gli argomenti di boot
 reserve/ether.

 Problema: La macchina si blocca all'avvio durante il rilevamento della
 scheda sonora.

 Causa: No, in realt� ci� avviene durante il rilevamento SCSI
 ``silenzioso'' ed � lo stesso problema visto precedentemente.

 Problema: NE2000 non rilevata all'avvio -- nessun tipo di messaggio.

 Soluzione: Non esiste una ``soluzione magica'' visto che possono
 essere parecchie le cause per cui non � stata rilevata. Il seguente
 elenco dovrebbe aiutare a risolvere i possibili problemi.

 1) Si compili un nuovo kernel che includa solo i driver dei
 dispositivi di cui si ha bisogno. Si verifichi che si stia davvero
 avviando il kernel nuovo. Dimenticare di eseguire lilo, eccetera pu�
 portare ad avviare quello vecchio (si guardi attentamente l'ora e la
 data di compilazione riportati all'avvio).  Suona ovvio, ma l'abbiamo
 fatto tutti in passato. Ci si assicuri che il driver sia
 effettivamente incluso nel nuovo kernel cercando nel file System.map
 cose tipo ne_probe.

 2) Si guardino attentamente i messaggi all'avvio. Davvero non accenna
 mai al fatto che sta facendo un rilevamento ne2k, per esempio `NE*000
 probe at 0xNNN: not found (blah blah)' o fallisce proprio
 silenziosamente? C'� una grossa differenza.  Si usi dmesg|more per
 rivedere i messaggi di avvio dopo aver fatto il login o si digiti
 Shift-PgUp per scorrere il contenuto dello schermo dopo che l'avvio si
 � completato e appare il prompt del login.

 3) Dopo l'avvio si esegua un cat /proc/ioports e si verifichi che
 l'intero spazio di I/O richiesto dalla scheda sia libero. Se si parte
 da 0x300, il driver n2ek richieder� 0x300-0x31f.  Se un qualsiasi
 altro driver di dispositivo ha occupato anche solo una porta da
 qualche parte in quell'intervallo, il rilevamento non avr� luogo a
 quell'indirizzo e continuer� silenziosamente al prossimo degli
 indirizzi rilevati. Un caso frequente � avere il driver lp che riserva
 0x378 o il secondo canale IDE che riserva 0x376, il che impedisce al
 driver ne il rilevamento in 0x360-0x380.

 4) Allo stesso modo come sopra per cat /proc/interrupts. Ci si
 assicuri che nessun altro dispositivo abbia occupato l'interrupt per
 il quale � stata impostata la scheda. In questo caso, il rilevamento
 avviene e il driver Ethernet protesta rumorosamente all'avvio perch�
 non riesce a ottenere la linea IRQ desiderata.

 5) Se si � ancora perplessi del fallimento silenzioso del driver,
 allora lo si modifichi aggiungendo alcuni printk() al rilevamento.
 Per esempio con il ne2k si potrebbero aggiungere/rimuovere righe
 (contrassegnate rispettivamente con un '+' o  '-') in
 linux/drivers/net/ne.c tipo:


 ______________________________________________________________________
     int reg0 = inb_p(ioaddr);

 +    printk("NE2k probe - now checking %x\n",ioaddr);
 -    if (reg0 == 0xFF)
 +    if (reg0 == 0xFF) {
 +       printk("NE2k probe - got 0xFF (vacant I/O port)\n");
         return ENODEV;
 +    }
 ______________________________________________________________________



 Perci� esso produrr� messaggi di output per ogni indirizzo di porta
 che esamina e si potr� capire se l'indirizzo della propria scheda �
 stato o no rilevato.

 6) Ci si pu� anche procurare il diagnostico ne2k nel sito ftp di Don
 (pure citato nell'howto) e vedere se � in grado di rilevare la propria
 scheda dopo che si � avviato Linux. Si usi l'opzione `-p 0xNNN' per
 dirgli dove cercare la scheda (l'indirizzo di default � 0x300 e non va
 a guardare da nessun'altra parte a differenza del rilevamento
 all'avvio).  L'output risultante quando trova una scheda sar� qualcosa
 del tipo:


 ______________________________________________________________________
 Checking the ethercard at 0x300.
   Register 0x0d (0x30d) is 00
   Passed initial NE2000 probe, value 00.
 8390 registers: 0a 00 00 00 63 00 00 00 01 00 30 01 00 00 00 00
 SA PROM  0: 00 00 00 00 c0 c0 b0 b0 05 05 65 65 05 05 20 20
 SA PROM 0x10: 00 00 07 07 0d 0d 01 01 14 14 02 02 57 57 57 57

 NE2000 found at 0x300, using start page 0x40 and end page 0x80.
 ______________________________________________________________________



 I propri valori register e PROM saranno probabilmente diversi. Si noti
 che tutti i valori PROM sono duplicati per una scheda a 16 bit,
 l'indirizzo Ethernet (00:00:c0:b0:05:65) appare nella prima riga e la
 firma ripetuta 0x57 appare alla fine della PROM.

 L'output risultante quando non c'� nessuna scheda installata a 0x300
 sar� qualcosa del tipo:









 ______________________________________________________________________
 Checking the ethercard at 0x300.
   Register 0x0d (0x30d) is ff
   Failed initial NE2000 probe, value ff.
 8390 registers: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 SA PROM      0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 SA PROM 0x10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

  Invalid signature found, wordlength 2.
 ______________________________________________________________________



 I valori 0xff si presentano poich� quello � il valore restituito
 quando si legge una porta di I/O libera.  Si possono vedere dei valori
 diversi da 0xff anche se si ha qualche altro tipo di hardware nella
 regione rilevata.

 7) Si provi a fare un warm boot di Linux da un dischetto di avvio per
 DOS (attraverso loadlin) dopo aver eseguito il driver per DOS o il
 programma di configurazione forniti. Pu� essere che faccia una qualche
 `magia' extra (cio� non standard) per inizializzare la scheda.

 8) Si provi il packet driver di Russ Nelson ne2000.com per vedere se
 almeno questo riesce a rilevare la propria scheda -- se no, allora le
 cose non vanno bene. Esempio:


      A:> ne2000 0x60 10 0x300


 Gli argomenti sono: il vettore degli interrupt software, l'IRQ
 hardware e l'I/O base. Lo si pu� trovare in un qualsiasi archivio
 msdos nel file pktdrv11.zip.  La versione attuale pu� essere pi�
 recente della 11.



 3.5.  Problemi con le schede SMC Ultra/EtherEZ e WD80*3


 Problema: Si ottengono messaggi tipo il seguente:


         eth0: bogus packet size: 65531, status=0xff, nxpg=0xff



 Causa: C'� un problema di memoria condivisa.

 Soluzione: La causa pi� comune � dovuta a macchine PCI che non sono
 configurate per mappare dispositivi nella memoria ISA.  Perci� si
 finisce per leggere la RAM del PC (tutti valori 0xff) invece della RAM
 della scheda che contiene i dati provenienti dal pacchetto ricevuto.

 Altri tipici problemi facili da risolvere sono: i conflitti di scheda,
 avere la cache o la ``shadow ROM'' abilitata per quella regione o
 avere il proprio bus ISA che va ad una velocit� superiore agli 8 MHz.
 Si trovano anche un numero sorprendente di guasti di memoria sulle
 schede Ethernet, perci� si esegua un programma di diagnostica nel caso
 in cui se ne possieda uno per la propria scheda.

 Problema: La scheda SMC EtherEZ non funziona nella modalit� a memoria
 non condivisa (PIO).


 Causa: Le versioni pi� vecchie del driver Ultra supportavano la scheda
 solo nella modalit� a memoria condivisa.

 Soluzione: Il driver a partire dalla versione del kernel 2.0 supporta
 anche la modalit� ad I/O programmato. Si aggiorni alla versione v2.0 o
 pi� recente.

 Problema: Le vecchie wd8003 e/o le wd8013 configurabili con i
 ponticelli ottengono sempre l'IRQ sbagliato.

 Causa: Le vecchie schede wd8003 e i cloni wd8013 configurabili con i
 ponticelli non possiedono la EEPROM dalla quale il driver pu� leggere
 l'impostazione dell'IRQ. Se il driver non � in grado di leggere l'IRQ
 allora esso prova a scoprirlo automaticamente con auto-IRQ. Se l'auto-
 IRQ restituisce il valore zero, il driver non fa altro che assegnare
 IRQ 5 a una scheda a 8 bit o IRQ 10 a una scheda a 16 bit.

 Soluzione: Si eviti il codice di auto-IRQ e si comunichi al kernel
 qual � l'IRQ per il quale la scheda � stata configurata nel proprio
 file di configurazione dei moduli (o mediante una argomento di boot
 per i driver compilati nel kernel).

 Problema: La scheda SMC Ultra � rilevata come wd8013, ma l'IRQ e
 l'indirizzo base della memoria condivisa sono sbagliati.

 Causa: La scheda Ultra assomiglia molto a una wd8013 e se il driver
 Ultra non � presente nel kernel, il driver wd pu� scambiare la Ultra
 per una wd8013. Il rilevamento della Ultra avviene prima del
 rilevamento della wd perci� questo di solito non accade. La Ultra
 memorizza l'IRQ e l'indirizzo base della memoria in un modo diverso
 nella EPROM, da cui i valori contraffatti riportati.

 Soluzione: Si ricompili il kernel con solo i driver di cui si ha
 bisogno. Se si ha una commistione di schede ultra e wd nella stessa
 macchina e si stanno usando i moduli allora si carichi per primo il
 modulo ultra.


 3.6.  Problemi con le schede 3Com

 Problema: La 3c503 si prende l'IRQ N, ma questo serve per una qualche
 altro dispositivo che ha bisogno dell'IRQ N (per esempio il driver del
 CDROM, il modem, ecc.). Si pu� risolvere la cosa senza ricompilare il
 kernel?

 Soluzione: Il driver della 3c503 cerca una linea di IRQ libera
 nell'ordine {5, 9/2, 3, 4} e dovrebbe scegliere una linea che nessuno
 sta usando. Il driver decide quando la scheda � attivata con ifconfig.

 Se si sta usando un driver modulare, si possono usare dei parametri
 del modulo per impostare molte cose, incluso il valore dell'IRQ.

 Ci� che segue imposta l'IRQ9, la locazione base 0x300, <valori
 ignorati> e if_port #1 (il transceiver esterno).




      io=0x300 irq=9 xcvr=1


 In alternativa, se il driver � compilato nel kernel, � possibile
 fissare gli stessi valori all'avvio passando i parametri attraverso
 LILO.


      LILO: linux ether=9,0x300,0,1,eth0


 Ci� che segue imposta l'IRQ3, la ricerca della locazione base, <valori
 ignorati> e il transceiver di default if_port #0 (il transceiver
 interno).


      LILO: linux ether=3,0,0,0,eth0


 Problema: 3c503: configured interrupt X invalid, will use autoIRQ.

 Causa: La sheda 3c503 pu� usare solo uno degli IRQ{5, 2/9, 3, 4} (solo
 queste linee sono connesse alla scheda). Se si passa un valore di IRQ
 che non appartiene al precedente insieme, si otterr� il messaggio
 sopra indicato.  Di solito non � necessario specificare un valore di
 interrupt per la 3c503. La 3c503 effettuer� l'autoIRQ quando viene
 usato ifconfig e sceglie uno degli IRQ{5, 2/9, 3, 4}.

 Soluzione: Si usi uno degli IRQ validi elencati sopra oppure si
 abiliti l'autoIRQ ma senza specificare la linea IRQ in alcun modo.

 Problema: I driver per la 3c503 forniti non utilizzano la porta AUI
 (thicknet). Come si pu� optare per essa al posto della porta thinnet
 di default?

 Soluzione: La porta 3c503 AUI pu� essere selezionata al momento
 dell'avvio per i driver compilati nel kernel e all'inserzione del
 modulo per i driver modulari.  La selezione avviene impostando ad 1 il
 bit meno significativo della variabile attualemente non usata
 dev->rmem_start, cosicch� un parametro all'avvio tipo:


      LILO: linux ether=0,0,0,1,eth0


 dovrebbe funzionare per i driver compilati nel kernel.

 Per specificare la porta AUI quando si carica il driver come modulo �
 sufficiente aggiungere xcvr=1 alla riga delle opzioni del modulo
 insieme con i propri valori di I/O e IRQ.


 3.7.  FAQ non specifiche su una particolare scheda



 3.7.1.  Linux e schede Ethernet ISA di tipo Plug and Play


 Per ottenere i migliori risultati (e il minimo rompimento) si
 raccomanda di usare il programma (di solito DOS) fornito con la
 propria scheda per disabilitare il meccanismo PnP e impostarla
 definitivamente a un indirizzo di I/O e un IRQ. Ci si assicuri che
 l'indirizzo di I/O che si utilizza sia rilevato all'avvio o, se si
 usano i moduli, si fornisca l'indirizzo sotto forma di opzione io= in
 /etc/conf.modules.  Pu� darsi che si debba anche entrare nel BIOS/CMOS
 setup e contrassegnare l'IRQ come Legacy-ISA al posto di PnP (se il
 proprio computer ha questa opzione).

 Si noti che non � necessario avere DOS installato per eseguire un
 programma di configurazione basato su DOS. Di solito � sufficiente
 avviare da un dischetto DOS ed eseguire i programmi dal dischetto
 fornito.  Si pu� anche scaricare gratuitamente OpenDOS e FreeDOS.

 Se si necessita, per la compatibilit� con qualche altro sistema
 operativo, che sia abilitato il PnP, allora con Linux si dovr� usare
 il pacchetto isapnptools per configurare ogni volta la(e) scheda(e)
 all'avvio.  Ci si dovr� ancora assicurare che l'indirizzo di I/O
 scelto per la scheda sia rilevato dal driver o fornito sotto forma di
 opzione io=.


 3.7.2.  La scheda Ethernet non � rilevata all'avvio


 Di solito la causa di ci� e che si sta usando un kernel che non
 include il supporto per la propria particolare scheda. Per un kernel
 modulare ci� significa che non si � richiesto di caricare il modulo di
 cui si ha bisogno o che � necessario specificare al modulo un
 indirizzo come opzione.

 Se si sta usando un kernel basato sui moduli per esempio quelli
 installati dalla maggior parte delle distribuzioni Linux, allora si
 provi a usare l'utilit� di configurazione della distribuzione, per
 selezionare il modulo adatto alla propria scheda. Per le schede ISA �
 una buona idea determinare l'indirizzo di I/O della scheda e
 aggiungerlo come opzione (per esempio io=0x340) se l'utilit� di
 configurazione ne richiede qualcuna.  Se non c'� alcuna utilit� di
 configurazione allora si dovr� aggiungere il nome corretto del modulo
 (e le opzioni) al file /etc/conf.modules -- si veda man modprobe per
 maggiori dettagli.

 Se si sta usando un kernel precompilato che � parte della
 distribuzione, allora si controlli la documentazione per vedere che
 kernel si � installato e se � stato compilato con il supporto per la
 propria scheda.  Se non lo � stato, allora o si prova a procurarsene
 uno con il supporto per la propria scheda, oppure se ne compili uno su
 misura.

 Solitamente � una buona cosa compilare il proprio kernel con solo i
 driver di cui si ha bisogno, poich� questa cosa non solo riduce la
 dimensione del kernel (risparmiando memoria RAM preziosa per le
 applicazioni!) ma riduce anche il numero di rilevamenti che possono
 incasinare hardware ``sensibile''.  Compilare un kernel non � cos�
 complicato come sembra.  Si deve solo rispondere s� o no a una serie
 di domande su quali driver si vogliono, e lui fa tutto il resto.

 Un'altra causa importante � l'avere un altro dispositivo che usa una
 parte dello spazio di I/O di cui ha bisogno la propria scheda.  Molte
 schede usano uno spazio di I/O di 16 o 32 byte.  Se la propria scheda
 � impostata a 0x300 ed usa 32 byte. allora il driver chieder� la
 regione 0x300-0x31f.  Se un qualsiasi altro dispositivo ha registrato
 anche solo una porta da qualche parte in quell'intervallo, il
 rilevamento non avr� luogo a quell'indirizzo e il driver continuer�
 silenziosamente con il prossimo indirizzo fra quelli che prova.
 Quindi, dopo il boot, si faccia cat /proc/ioports per verificare che
 l'intero spazio d'I/O che la scheda richiede � libero.

 Un altro problema � l'avere la propria scheda impostata con i
 ponticelli a un indirizzo di I/O che non viene controllato di default.
 L'elenco di tali indirizzi per ogni driver si trova facilmente proprio
 dopo i commenti iniziali nel sorgente del driver.  Anche se
 l'impostazione I/O della propria scheda non � nell'elenco degli
 indirizzi controllati, la si pu� fornire al boot (per i driver
 compilati nel kernel) con il comando ether= come descritto in
 ``Passare argomenti  Ethernet...''.  I driver modulari possono fare
 uso dell'opzione io= in /etc/conf.modules per specificare un indirizzo
 che non � controllato di default.


 3.7.3.  ifconfig  mostra un indirizzo di I/O sbagliato per la scheda


 No, non lo fa.  Lo si sta solamente interpretando in modo scorretto.
 Questo non � un bug e i numeri riportati sono corretti.  Capita solo
 che in alcune schede basate su 8390 (wd80x3, smc-ultra, ecc.) il chip
 8390 in realt� risiede a un offset rispetto alla prima porta di I/O
 assegnata.  Questo � il valore salvato in dev->base_addr ed � ci� che
 ifconfig riporta.  Se si vuole vedere l'intero intervallo di porte che
 la propria scheda usa, allora si provi cat /proc/ioports che dar� i
 numeri che ci si aspetta.


 3.7.4.  La macchina PCI rileva la scheda ma il driver ma no


 Alcuni BIOS PCI potrebbero non abilitare tutte le schede PCI
 all'accensione, specialmente se � attivata l'opzione ``PNP OS'' del
 BIOS.  Questa mis-feature � per supportare la versione corrente di
 Window che ancora usa alcuni driver in real mode.  Si disabiliti
 questa opzione oppure si provi ad aggiornare a un driver pi� recente
 che abbia il codice per abilitare una scheda disabilitata.


 3.7.5.  Le schede ISA a memoria condivisa non funzionano in una
 macchina PCI ( 0xffff )


 Questa cosa solitamente si presenta come una serie di letture di
 valori 0xffff.  Nessun tipo di scheda a memoria condivisa potr�
 funzionare in una macchina PCI finch� non si configuri correttamente
 il BIOS PCI.  Lo si deve impostare per permettere l'accesso in memoria
 condivisa dal bus ISA alla regione di memoria che la propria scheda
 cerca di usare. Se non si capisce quali impostazioni sono appropriate
 allora si chieda al proprio fornitore o all'esperto di computer
 locale. Per i BIOS AMI, solitamente c'� una sezione ``Plug and Play''
 dove ci dovrebbero essere delle impostazioni tipo ``ISA Shared Memory
 Size'' e ``ISA Shared Memory Base''.  Per le schede come la wd8013 e
 la SMC Ultra, si modifichi la dimensione predefinita da ``Disabled'' a
 16kB e si metta l'indirizzo della memoria condivisa della propria
 scheda nell'altra impostazione.


 3.7.6.  Sembra che la scheda invii dati ma non riceve niente


 Si faccia un cat /proc/interrupts.  Il totale corrente del numero di
 eventi di interrupt generati dalla propria scheda sar� nell'elenco
 dato dal comando precedente.  Se � a zero e/o non aumenta quando si
 prova a usare la scheda allora probabilmente c'� un conflitto di
 interrupt con un altro dispositivo installato nel computer
 (indifferentemente dal fatto che l'altro dispositivo abbia o meno un
 driver installato/disponibile). Si cambi l'IRQ di uno dei due
 dispositivi a un IRQ libero.



 3.7.7.  Supporto per Asynchronous Transfer Mode (ATM)


 Werner Almesberger sta lavorando al supporto ATM per Linux. Sta
 lavorando con la scheda ENI155p della Efficient Networks ENI155p
 (Efficient Networks <http://www.efficient.com/>) e la scheda ZN1221
 della Zeitnet (Zeitnet <http://www.zeitnet.com/>).


 Werner sostiene che il driver per la ENI155p � abbastanza stabile,
 mentre quello per la ZN1221 non � ancora finito.

 Si veda lo stato attuale dei driver al seguente URL:

 Linux ATM Support <http://lrcwww.epfl.ch/linux-atm/>


 3.7.8.  Supporto per Gigabyte Ethernet


 C'� un qualche supporto per gigabyte Ethernet sotto Linux?

 S�, attualmente ce ne sono almeno due.  Un driver per l'adattatore
 Gigabit Ethernet PCI G-NIC della Packet Engines � disponibile nei
 kernel v2.0 e v2.2.  Per maggiori dettagli, supporto e driver
 aggiornati, si veda:

 http://cesdis.gsfc.nasa.gov/linux/drivers/yellowfin.html

 Il driver acenic.c disponibile nei kernel v2.2 pu� essere usato con la
 scheda Gigabit Ethernet AceNIC della Alteon e con altre schede basate
 su Tigon come la 3c985 della 3Com.  Il driver dovrebbe funzionare
 anche con la GA620 della NetGear, ma la cosa non � ancora stata
 verificata.


 3.7.9.  Supporto FDDI

 C'� il supporto FDDI per Linux?

 S�. Larry Stefani ha scritto un driver per v2.0 usando le schede DEFEA
 (FDDI EISA) e DEFPA (FDDI PCI) della Digital.  Era stato incluso nel
 kernel v2.0.24.  Attualmente non sono supportate altre schede.


 3.7.10.  Supporto Full Duplex


 Il Full Duplex mi dar� i 20MBps? Linux lo supporta?

 Cameron Spitzer ha scritto quanto segue sulle schede 10Base-T full
 duplex: �Se se ne connette una a uno switched hub full duplex e il
 proprio sistema � abbastanza veloce e non sta facendo molto altro, pu�
 mantenere la connessione occupata in entrambe le direzioni.  Non ci
 sono cose tipo 10BASE-2 o 10BASE-5 full duplex.  Il full duplex
 funziona disabilitando il rilevamento delle collisione
 nell'adattatore. Questo � il motivo per cui non lo si pu� fare con un
 cavo coassiale; la LAN in questo modo non funzionerebbe. Il 10BASE-T
 (interfaccia RJ45) usa fili separati per la trasmissione e la
 ricezione cos� � possibile utlizzare entrambe le direzioni nello
 stesso momento.  Lo switching hub si fa carico del problema delle
 collisioni.  La frequenza dei segnali � 10Mbps.�

 Quindi come si pu� vedere si sar� in grado di ricevere e trasmettere
 solo a 10Mbps e cos� non ci si aspetti un incremento delle prestazioni
 di un fattore 2. Che sia o meno supportato, la cosa dipende dalla
 scheda e forse anche dal driver.  Alcune schede possono fare l'auto
 negoziazione, altre hanno bisogno del supporto da parte del driver e
 per altre ancora � necessario che l'utente selezioni un'opzione nella
 configurazione EEPROM della scheda.  Comunque solamente utilizzatori
 seri/pesanti noteranno la differenza tra le due modalit�.




 3.7.11.  Schede Ethernet per Linux su macchine SMP

 Se si spendono soldi in pi� su un computer multi processore (MP)
 allora si comperi anche una buona scheda Ethernet.  Per i kernel v2.0
 non � veramente necessario, ma lo � sicuramente per quelli v2.2.  La
 maggior parte delle schede pi� vecchie non intelligenti (per esempio
 progetti per bus ISA PIO e memoria condivisa) non furono mai pensate
 considerando in alcun modo l'uso con macchina MP.  La tendenza attuale
 � di comperare una scheda intelligente di progettazione moderna e
 assicurarsi che il driver sia stato scritto (o aggiornato) per gestire
 le operazioni MP (le parole chiave sono ``progettazione moderna'': le
 NE2000 PCI sono semplicemente un progetto di 10 anni fa adattato a un
 bus moderno).  La presenza del testo spin_lock nei sorgenti del driver
 � un buona indicazione che il driver � stato scritto per gestire le
 operazioni MP.  Si veda sotto per i dettagli completi su perch� di
 dovrebbe acquistare una buona scheda per l'uso MP (e cosa accade se
 non lo si fa).

 Nei kernel v2.0, solo un processore alla volta era permesso ``in
 modalit� kernel'' (ovvero poteva cambiare i dati del kernel e/o
 eseguire device driver). Quindi dal punto di vista della scheda (e del
 driver associato) non c'era niente di diverso rispetto ad operazioni
 uni-processore (UP) e le cose funzionavano come prima (questo era il
 modo pi� semplice di ottenere una versione MP di Linux funzionante: un
 unico grosso lock (blocco, semaforo) attorno a tutto il kernel
 permette l'accesso ad un solo processore alla volta. In questo modo si
 sa che non si avranno due processori che provano a cambiare la stessa
 cosa allo stesso tempo!).

 Lo svantaggio nel permettere un solo processore alla volta in modalit�
 kernel � che si ottengono prestazioni di tipo MP solamente se si
 eseguono programmi indipendenti e che fanno calcoli pesanti.  Se i
 programmi fanno un sacco di input/output (I/O) come la lettura e la
 scrittura di dati su disco o attraverso la rete, allora tutti i
 processori tranne uno saranno in stallo in attesa che le loro
 richieste di I/O siano completate mentre l'unico processore in
 esecuzione in modalit� kernel freneticamente prova a eseguire tutti i
 device driver per soddisfare le richieste di I/O.  Il kernel diventa
 il collo di bottiglia e poich� c'� solo un processore in modalit�
 kernel, le prestazioni di una macchina MP in presenza di I/O pesante,
 in questo caso detoriorano velocemente verso quelle di una macchina a
 singolo processore.

 Poich� questa cosa � chiaramente inferiore al caso ideale
 (specialmente per server di file/WWW, router, ecc.) i kernel v2.2
 hanno un lock pi� fine. Ci� significa che pi� di un processore alla
 volta pu� essere in modalit� kernel. Invece di un unico grosso lock
 attorno all'intero kernel, ci sono un sacco di piccoli lock che
 proteggono i dati critici dall'essere manipolati da pi� di un
 processore alla volta, per esempio un processore pu� eseguire il
 driver della scheda di rete, mentre nello stesso momento un altro
 esegue il driver il disco.

 Okay, con tutto questo bene in mente, ecco qui le insidie: il lock pi�
 fine significa che si pu� avere un processore che prova a inviare dati
 attraverso un driver Ethernet mentre un altro prova ad accedere allo
 stesso driver/scheda per fare qualcos'altro (per esempio ottenere le
 statiche della scheda per il comando cat /proc/net/dev). Oops, le
 statistiche della propria scheda sono state appena inviate attraverso
 il cavo, mentre invece si volevano i dati per le proprie statistiche.
 S�, si � un po' confusa la scheda chiedendole di fare due (o pi�!)
 cose alla volta ed � probabile che mandi in crash la propria macchina
 mentre ci prova.

 Quindi il driver che funzionava per UP non � pi� abbastanza buono:
 necessita di essere aggiornato con i lock che controllano l'accesso
 alla scheda cosicch� i tre processi di ricezione, trasmissione e
 manipolazione dei dati di configurazione siano serializzati al grado
 necessario alla scheda per funzionare stabilmente. La parte strana qui
 � che un driver non ancora aggiornato con lock per operazioni MP
 stabili, sembrer� probabilmente funzionare su macchine MP in presenza
 di un leggero carico di rete, ma provocher� il crash della macchine o
 almeno esibir� uno strano comportamento quando due (o pi�!) processori
 proveranno a fare pi� di uno di questi tre processi nello stesso
 momento.

 Un driver Ethernet aggiornato per MP richieder� (al minimo) un lock
 attorno al driver che limiti l'accesso ai punti d'ingresso del kernel
 nel driver in maniera ``uno alla volta, prego''.  Con questa cosa, le
 cose saranno serializzate cosicch� l'hardware sottostante dovrebbe
 essere trattato come se fosse usato in una macchina UP, e quindi
 dovrebbe essere stabilee. Lo svantaggio � che un unico lock attorno
 all'intero driver Ethernet ha le stesse implicazioni negative sulle
 prestazioni dell'avere un unico grosso lock attorno a tutto il kernel
 (ma su scala pi� piccola), ovvero si pu� avere un solo processore alla
 volta che usa la scheda.  [Nota tecnica: L'impatto sulle prestazioni
 pu� anche includere un incremento nelle latenze degli interrupt se i
 lock che � necessario aggiungere sono del tipo irqsave e sono tenuti
 per un lungo periodo di tempo.]

 Possibili miglioramenti a questa situazione possono essere fatti in
 due modi.  Si pu� provare a minimizzare il tempo tra quando si fa il
 lock e quando lo si rilascia, e/o si pu� implementare un lock pi� fine
 all'interno del driver (per esempio un lock attorno all'intero driver
 sarebbe eccessivo se invece fosse necessario solamente un lock o due
 per proteggere contro l'accesso simultaneo a una coppia di
 registri/impostazioni delicati della scheda).

 Comunque, per le pi� vecchie schede     non intelligenti che non sono
 mai state progettate pensando all'uso MP, nessuno di questi
 miglioramenti pu� essere realizzato.  Peggio ancora le schede non
 intelligenti tipicamente richiedono che il processore sposti dati tra
 la scheda e la memoria del computer, cosicch� nel caso peggiore il
 lock sar� mantenuto per tutto il tempo necessario per spostari ogni
 pacchetto da 1.5kB sul bus ISA.

 Le pi� moderne schede intelligenti tipicamente spostano i dati
 direttamente da e nella memoria del computer senza nessun aiuto da
 parte di un processore.  Questa � una grande vittoria, poich� il lock
 � mantenuto allora solo per il breve tempo che il processore impiega
 per dire alla scheda dove prendere/mettere nella memoria il prossimo
 pacchetto di dati.  Inoltre le schede pi� moderne tendono meno a
 richiedere un grosso unico lock attorno all'intero driver.



 3.7.12.  Schede Ethernet per Linux su piattaforma PCI Alpha/AXP


 Dalla versione v2.0, solo i driver 3c509, depca, de4x5, pcnet32 e
 tutti quelli 8390 (wd, smc-ultra, ne, 3c503, ecc.) sono stati resi
 ``indipendenti dall'architettura'' cos� da poter funzionare su sistemi
 basati su CPU DEC Alpha.  Possono funzionare anche altri driver PCI
 aggiornati presenti nella pagina WWW di Donald poich� sono stati
 scritti appositamente indipendenti dall'architettura.

 Si noti che le modifiche richieste per rendere un driver indipendente
 dall'architettura non sono cos� complicate.  Si deve solo fare quanto
 segue:



 �  moltiplicare tutti i valori relativi ai jiffies per HZ/100 per
    tener conte del diverso valore di HZ che usa l'Alpha.  (timeout=2;
    diventa timeout=2*HZ/100;)

 �  sostituire tutti deriferimenti dei puntatori nella memoria di I/O
    (da 640k a 1MB) con le appropriate chiamate readb() writeb()
    readl() writel() calls, come mostrato in questo esempio.


 ______________________________________________________________________
 -       int *mem_base = (int *)dev->mem_start;
 -       mem_base[0] = 0xba5eba5e;
 +       unsigned long mem_base = dev->mem_start;
 +       writel(0xba5eba5e, mem_base);
 ______________________________________________________________________



 -sostituire tutte le chiamate memcpy() che hanno la memoria I/O come
 sorgente o destinazione con le appropriate memcpy_fromio() o
 memcpy_toio().

 I dettagli sulla gestione degli accessi alla memoria in maniera
 indipendente dall'architettura sono documentati nel file
 linux/Documentation/IO-mapping.txt fornito con i kernel recenti.


 3.7.13.  Ethernet per Linux su hardware SUN/Sparc

 Per le informazioni pi� aggiornate sulla roba Sparc, si provi il
 seguente URL:

 Linux Sparc <http://www.geog.ubc.ca/sparc>

 Si noti che qualche hardware Ethernet Sparc     riceve il suo
 indirizzo MAC dal computer ospite, e quindi ci si pu� ritrovare con
 pi� interfacce allo stesso indirizzo MAC.  Se si ha bisogno di mettere
 pi� di una interfacia nella stessa rete, allora si usi l'opzione hw di
 ifconfig per assegnare un indirizzo MAC univoco.

 Le questioni riguardati il porting dei driver PCI su piattaforma Sparc
 sono simili a quelle citate sopra per la piattaforma AXP. Inoltre ci
 possono essere un po' di questione relative all'endian, poich� la
 Sparc � big endian mentre AXP e ix86 sono little endian.


 3.7.14.  Ethernet per Linux su altro hardware

 Ci sono parecchie altre piattaforme hardware sulle quali pu� girare
 Linux, come Atari/Amiga (m68k).  Come nel caso Sparc � meglio
 controllare nel sito ufficiale del port di Linux per quella
 piattaforma per vedere cosa attualmente � supportato (sono benvenuti
 link ai suddetti siti -- inviatemeli!)


 3.7.15.  Connettere 10 o 100 BaseT senza un hub

 Possono connettere assieme sistemi basati su 10/100BaseT (RJ45) senza
 un hub?

 Senza altri dispositivi/marchingegni si possono collegare facilmente 2
 macchine, ma non di pi�.  Si veda ``Doppino   intrecciato'', che
 spiega come farlo.  E no, non si pu� far su un hub semplicemente
 incrociando un po' di fili assieme e qualcos'altro.  � praticamente
 impossibile gestire bene il segnale di collisione senza duplicare
 l'hub.
 3.7.16.  SIOCSIFxxx: No such device

 Ricevo un sacco di messaggi `SIOCSIFxxx: No such device' al boot,
 seguiti da un `SIOCADDRT: Network is unreachable'.  Cosa c'� che non
 va?

 Il proprio dispositivo Ethernet non � stato rilevato al boot o
 all'inserzione del modulo e quando sono eseguiti ifconfig e route non
 hanno nessun dispositivo con cui lavorare.  Si usi dmesg | more per
 rivedere i messaggi di boot e vedere se c'� un qualche messaggio sul
 rilevamento della scheda Ethernet.


 3.7.17.  SIOCSFFLAGS: Try again

 Ricevo `SIOCSFFLAGS: Try again' quando eseguo `ifconfig'. Eh?

 Qualche altro dispositivo si � preso l'IRQ che la propria scheda
 Ethernet prova ad usare e quindi questa non pu� usarlo.  Non si deve
 necessariamente riavviare per risolvere ci�, poich� alcuni dispositivi
 si prendono l'IRQ solo quando ne hanno bisogno e poi lo rilasciano
 quando hanno fatto. Esempi sono alcuni schede sonore, porte seriali,
 driver per floppy disk, ecc.  Si pu� digiare cat /proc/interrupts per
 vedere quali interrupt sono attualmente in uso.  La maggior parte dei
 driver per schede Ethernet per Linux si prendono l'IRQ solo quando
 sono attivate per l'uso con `ifconfig'.  Se si riesce a far s� che
 l'altro dispositivo rilasci la linea IRQ richiesta allora si dovrebbe
 essere in grado di `Try again' (riprovare) con ifconfig.


 3.7.18.  Usare `ifconfig' e Link UNSPEC con l'indirizzo hardware
 00:00:00:00:00:00

 Quando eseguo ifconfig senza alcun argomento, mi dice che LINK �
 UNSPEC (invece di 10Mbs Ethernet) e dice anche che il mio indirizzo
 hardware � di tutti zeri.

 Questo � perch� si sta usando una versione del programma `ifconfig'
 pi� recente della versione del kernel.  Questa nuova versione di
 ifconfig non � in grado di riportare queste propriet� quando usata con
 un kernel pi� vecchio.  Si pu� o aggiornare il proprio kernel, tornare
 a una versione pi� vecchia di `ifconfig' oppure semplicemente ignorare
 la cosa.  Il kernel conosce l'indirizzo hardware e non gli interessa
 se ifconfig non pu� leggerlo.

 Si possono ricevere strane informazioni se il programma ifconfig che
 si sta usando � molto pi� vecchio del proprio kernel.


 3.7.19.  Enorme numero di errori in RX e TX

 Quando eseguo ifconfig senza alcun argomento, mi dice che ho un enorme
 numero di errori sia nei pacchetti ricevuti che trasmessi.  Tutto
 sembra funzionare bene. Cosa c'� che non va?

 Si guardi bene. Dice RX packets grande numero PAUSE errors 0 PAUSE
 dropped 0 PAUSE overrun 0.  E la stessa cosa per la colonna TX. Quindi
 i grandi numeri che si vedono sono il numero totale di pacchetti che
 la propria macchina ha ricevuto e trasmesso.  Se ancora si trova la
 cosa confusa, si provi invece ad usare cat /proc/net/dev.


 3.7.20.  Voci in /dev/  per le schede Ethernet

 Ho /dev/eth0 come link (collegamento) a /dev/xxx. � giusto?

 Contrariamente a ci� che si � sentito, i file in /dev/* non sono
 utilizzati. Si pu� cancellare qualsiasi /dev/wd0, /dev/ne0 e voce
 simile.


 3.7.21.  Linux e i ``trailer''

 Dovrei disabilitare i trailer quando uso `ifconfig' con la mia scheda?

 Non si possono disabilitare i trailer e nemmeno si dovrebbe volerlo
 fare. I `trailer' sono degli stratagemmi (hack) per evitare la copia
 dei dati negli strati di rete.  L'idea era di usare un banale header
 di dimensione fissata `H', mettere le informazioni dell'header di
 dimensione variabile alla fine del pacchetto e allocare tutti gli `H'
 byte del pacchetto prima dell'inizio della pagina.  Sebbene fosse una
 buona idea, in pratica ha mostrato di non funzionare bene.  Se
 qualcuno suggerisce l'uso di `-trailers', si noti che � l'equivalente
 del sangue delle capre sacrificali.  Non sar� niente per risolvere il
 problema, ma se il problema si risolve da solo allora qualcuno pu�
 affermare una profonda conoscenza delle arti magiche.



 3.7.22.  Accesso a basso livello al dispositivo Ethernet

 Come posso accedere a basso livello al dispositivo Ethernet in Linux,
 senza passare attraverso TCP/IP e company?


 ______________________________________________________________________
         int s=socket(AF_INET,SOCK_PACKET,htons(ETH_P_ALL));
 ______________________________________________________________________



 Questo consente di avere un socket che riceve qualsiasi tipo di
 protocollo. Si facciano chiamate recvfrom() a questo socket e lui
 riempir� sockaddr con il tipo di dispositivo nel campo sa_family e il
 nome del dispositivo nell'array sa_data. Non so chi abbia
 originariamente inventato SOCK_PACKET per Linux (c'� da anni) ma � una
 cosa superba.  Si pu� usare anche per inviare roba grezza attraverso
 chiamate sendto(). Naturalmente per fare entrambe le cose si deve
 avere l'accesso come root.


 4.  Suggerimenti per le prestazioni

 Ecco qua un po' di trucchi che si possono usare se si soffre di una
 basso throughput Ethernet o per guadagnare un po' di velocit� nei
 trasferimenti ftp.

 Il programma ttcp.c � un buon test per misurare la velocit� di
 throughput.  Un altro modo comunemente usato � di fare un ftp> get
 grosso_file /dev/null dove   grosso_file � >1MB e risiede nel buffer
 di Tx della macchina (si faccia il `get' almeno due volte, poich� la
 prima volta si appronter� la cache del buffer nella macchina di
 trasmissione).  Si deve mettere il file nella cache del buffer perch�
 non si � interessati ad includere nella misura la velocit� di accesso
 ai file dal disco.  Questo � anche il motivo per cui si inviano i dati
 in ingresso a /dev/null piuttosto che dentro il disco.


 4.1.  Concetti generali

 Anche una scheda a 8 bit � in grado di ricevere pacchetti back-to-back
 (uno dietro l'altro) senza alcun problema.  Le difficolt� nascono
 quando il computer non riesce a estrarre i pacchetti ricevuti dalla
 scheda abbastanza velocemente da far spazio ai pacchetti in arrivo.
 Se il computer non libera abbastanza velocemente la memoria della
 scheda dai pacchetti gi� ricevuti, la scheda non avr� spazio per
 mettere i nuovi pacchetti.

 In questo caso o si scartano (drop) i nuovi pacchetti oppure si
 scrivono sopra a quelli gi� ricevuti (overrun).  In entrambi i casi si
 interrompe seriamente il flusso regolare del traffico
 causando/richiedendo la ritramissione e degradando seriamente le
 prestazioni anche di un fattore 5!

 Le schede con a bordo pi� memoria possono fare la ``bufferizzazione''
 di pi� pacchetti e quindi gestire grossi picchi (burst) di pacchetti
 back-to-back senza perderne nessuno.  D'altra parte ci� significa che
 la scheda non necessita pi� di una bassa latenza dal computer riguardo
 all'estrazione dei pacchetti dal buffer per evitare la perdita di
 pacchetti.

 La maggior parte delle schede a 8 bit hanno un buffer da 8kB e la
 maggior parte di quelle a 16 ne hanno uno da 16kB.  La maggior parte
 dei driver di Linux riserva 3kB del buffer per due buffer Tx, quindi
 nel caso di una scheda a 8 bit rimangono solo 5kB di spazio per la
 ricezione. Questo spazio � sufficiente solo per tre pacchetti Ethernet
 a dimensione massima (1500 byte).


 4.2.  Schede ISA e velocit� del bus ISA

 Come menzionato in precedenza, se i pacchetti sono rimossi abbastanza
 velocemente dalla scheda allora la condizione di drop/overrun non
 avverr� anche se la dimensione del buffer per i pacchetti Rx �
 piccola.  Il fattore che determina la frequenza con la quale i
 pacchetti sono rimossi dalla scheda e messi nella memoria del computer
 � la velocit� del percorso dati che collega le due, ovvero la velocit�
 del bus ISA (se la CPU � un vecchio e lento 386sx-16 allora anche
 questo avr� la sua influenza).

 Il clock del bus ISA raccomandato � circa 8Mhz, ma molte schede madri
 e dispositivi periferici possono essere fatti funzionare a frequenze
 pi� elevate. La frequenza di clock per il bus ISA solitamente pu�
 essere impostata nel CMOS setup, selezionando un divisore della
 frequenza di clock della scheda madre/CPU.  Alcune schede madri ISA e
 PCI/ISA possono non avere questa opzione e quindi si � incastrati
 nelle impostazioni di fabbrica.

 Per esempio, ecco qui alcune velocit� di ricezione misurate dal
 programma TTCP su un 486 a 40Mhz, con una scheda a 8 bit WD8003EP, a
 diverse velocit� del bus ISA.


 ______________________________________________________________________
         Velocit� bus ISA (MHz)     Rx TTCP (kB/s)
         ----------------------    --------------
         6.7                       740
         13.4                      970
         20.0                      1030
         26.7                      1075
 ______________________________________________________________________



 Voglio vedere chi riesce a far meglio di 1075kB/s con una qualsiasi
 scheda Ethernet a 10Mb/s usando TCP/IP.  Comunque, non ci si aspetti
 che qualsiasi sistema funzioni a velocit� del bus ISA molto elevate.
 La maggior parte dei sistemi non funzioneranno correttamente a
 velocit� superiori a 13MHz (inoltre, in alcuni sistemi PCI la velocit�
 del bus ISA � fissata a 8 Mhz, cosicch� l'utente finale non ha la
 possibilit� di incrementarla).

 Oltre a una velocit� di trasferimento pi� elevata, si trarr� anche
 beneficio da una riduzione nell'uso della CPU dovuta alla durata
 minore dei cicli di memoria e di I/O (si noti che anche i dischi fissi
 e le schede video presenti nel bus ISA mostreranno solitamente un
 aumento delle prestazioni dovuto all'incremento della velocit� del bus
 ISA).

 Ci si assicuri di fare un back up dei propri dati prima di fare
 esperimenti con velocit� del bus ISA superiori agli 8Mhz e di
 controllare accuratamente che tutte le periferiche ISA funzionino
 correttamente dopo aver fatto qualsiasi incremento alla velocit� del
 bus.


 4.3.  Impostare la finestra TCP di ricezione (TCP Rx Window)


 Ancora una volta, le schede con poca memoria RAM a bordo e percorsi
 dati tra la scheda e la memoria del computer relativamente lenti
 avranno problemi.  L'impostazione predefinita per la finestra di
 ricezione TCP � di 32kB, il che significa che un computer veloce nella
 sottorete a cui appartiene la propria macchina, pu� scaricare in
 quest'ultima 32kB di dati senza fermarsi per controllare se tutti sono
 stati ricevuti correttamente.

 Le versioni recenti del comando route hanno la possibilit� di
 impostare al volo la dimensione di questa finestra.  Solitamente la
 riduzione della dimensione di questa finestra � necessaria solo per la
 rete locale, poich� i computer che sono dietro ad un paio di router e
 gateway sono abbastanza `bufferizzati' da non porre problemi.  Un
 esempio d'uso potrebbe essere:


 ______________________________________________________________________
         route add <qualcosa> ... window <dim_fin>
 ______________________________________________________________________



 dove dim_fin � la dimensione della finestra che si vuole usare (in
 byte).  Una scheda 3c503 a 8 bit su un bus ISA che va a 8Mhz o meno
 dovrebbe funzionare bene con una dimensione della finestra di circa
 4kB.  Una finestra troppo grande causer� drop e overrun dei pacchetti
 e una riduzione drastica del throughput.  Si pu� verificare lo stato
 operativo facendo cat /proc/net/dev che mostrer� tutte le situazioni
 di drop/overrun avvenute.


 4.4.  Incrementare le prestazioni NFS

 Alcuni hanno scoperto che l'uso di una scheda a 8 bit in client NFS
 causa prestazioni pi� povere di quelle che ci si aspetta, quando si
 usa la dimensione dei paccheti NFS di 8kB (nativa della Sun).

 Una possibile causa per questa cosa potrebbe essere la differente
 dimensione del buffer a bordo tra schede a 8 e 16 bit.  La dimensione
 massima di un pacchetto Ethernet � circa 1500 byte.  Affinch� arrivi
 un pacchetto NFS di 8kB ci vogliono circa sei pacchetti back to back
 Ethernet di dimensione massima.  Sia le schede a 8 bit che quelle a 16
 non hanno problemi a ricevere pacchetti back to back.  Il problema
 sorge quando la macchina non rimuove in tempo i pacchetti dal buffer
 della scheda e il buffer va in overflow.  E nemmeno il fatto che le
 schede a 8 bit necessitano di un ulteriore ciclo di bus ISA per ogni
 trasferimento aiuta.  Quel che si pu� fare se si ha una scheda a 8 bit
 � di impostare la dimensione del trasferimento NFS a 2kB (o anche 1kB)
 o provare a incrementare la velocit� del bus ISA per far s� che il
 buffer della scheda venga ripulito pi� velocemente. Ho scoperto che
 una vecchia scheda WD8003E a 8MHz (senza altro carico di sistema) pu�
 sostenere grosse ricezioni a dimensioni NFS di 2kB, ma non a 4kB, dove
 le prestazioni si degradano di un fattore tre.

 D'altra parte, se l'opzione predefinita di mount � di usare la
 dimensione di 1kB e si ha almeno una scheda isa a 16 bit, si trover�
 un incremento significativo nel passare a 4kB (o anche 8kB).


 5.  Informazioni specifiche su rivenditori, produttori e modelli

 Nel seguito sono elencate molte schede in ordine alfabetico per nome
 del rivenditore (produttore) e poi identificativo del prodotto.  Oltre
 all'ID di ciascun prodotto, ci potr� essere ``Supportata'', ``Semi
 supportata'' oppure ``Non supportata''.

 Supportata significa che esiste un driver per la scheda e molti lo
 stanno usando felicemente e sembra quindi abbastanza affidabile.

 Semi supportata significa che esiste un driver, ma � vera almeno una
 delle descrizioni seguenti: (1) Il driver e/o l'hardware ha dei bug
 che possono provocare prestazioni scadenti, fallimenti di connessione
 e persino crash.  (2) Il driver � nuovo e la scheda � poco comune e
 quindi il driver � stato poco usato/collaudato e il suo autore ha
 quindi ricevuto pochi riscontri. Ovviamente la (2) � preferibile alla
 (1) e la descrizione di ciascuna scheda/driver dovrebbe chiarire quale
 delle due valga.  In entrambi i casi, probabilmente sar� necessario
 rispondere `Y' (s�) alla domanda ``Prompt for development and/or
 incomplete code/drivers?'' quando si lancia make config.

 Non supportata significa invece che attualmente non � disponibile
 alcun driver per quella scheda.  Ci� pu� essere dovuto alla mancanza
 d'interesse nell'hardware che � raro/poco comune, o al fatto che il
 produttore non vuole rilasciare la documentazione sull'hardware
 necessaria per scrivere un driver.

 Si noti che la differenza tra ``Supportata'' e ``Semi supportata'' �
 abbastanza soggettiva ed � basata sui commenti degli utenti osservati
 nei messaggi inviati ai vari newsgroup e mailing list (dopo tutto, �
 impossibile per una persona sola collaudare tutti i driver con tutte
 le schede per ogni versione del kernel!!!).  Quindi si faccia
 attenzione perch� pu� succedere che si trovi una scheda segnata come
 semi-supportata, che nel proprio caso funziona perfettamente (il che �
 bene), oppure una scheda indicata come supportata, che in realt� d�
 una serie infinita di problemi (il che non � proprio bene).

 Dopo lo stato, c'� il nome che il driver ha nel kernel di Linux.
 Questo � anche il nome del modulo del driver che si potrebbe usare
 nella riga alias eth0 nome_driver presente nel file di configurazione
 dei moduli /etc/conf.modules.



 5.1.  3Com

 Se non si � sicuri di cosa sia la propria scheda, ma si pensa che sia
 una scheda 3Com, probabilmente lo si pu� scoprire dal numero di
 assemblaggio. La 3Com ha un documento `Identifying 3Com Adapters By
 Assembly Number' (ref 24500002) che molto probabilmente far� al
 proprio caso.  Si veda ``Informazioni tecniche dalla 3Com'' per
 maggiori informazioni su come ottenere documenti dalla 3Com.
 Si noti inoltre che la 3Com ha un sito FTP con diverse cose carine:
 ftp.3Com.com.

 Quelli che leggono questo documento tramite un browser WWW, possono
 provare a vedere anche nel sito WWW della 3Com.


 5.1.1.  3c501

 Stato: Semi supportata, Nome del Driver: 3c501

 Questa obsoleta scheda a 8 bit dell'et� della pietra � veramente
 troppo ``demente'' per poter essere usata.  La si eviti come la peste.
 Non si compri questa scheda, nemmeno per scherzo.  Le sue prestazioni
 sono orribili ed ha un sacco di problemi.

 Per quelli che non sono ancora convinti, la 3c501 pu� solamente fare
 una cosa alla volta: mentre sta rimuovendo un pacchetto dal buffer non
 pu� ricevere un altro pacchetto, nemmeno pu� riceverne uno mentre sta
 caricando un pacchetto trasmesso.  Questa cosa andava bene per le reti
 composte da computer basati su 8088 dove l'elaborazione di un
 pacchetto e la risposta richiedevano decine di millisecondi, ma le
 reti moderne inviano pacchetti back-to-back (uno dopo l'altro)
 praticamente per qualsiasi transazione.

 L'autoIRQ funziona, non � usato il DMA, l'autoprobe cerca solo a 0x280
 e a 0x300 e il livello di debug � impostato con il terzo argomento al
 momento del boot.

 Ancora una volta, l'uso della 3c501 � vivamente sconsigliato!  Ancora
 di pi� con un kernel con l'IP multicast, ci si inchioder� mentre si
 ascoltano tutti i pacchetti multicast.  Si vedano i commenti in cima
 al codice sorgente per ulteriori dettagli.


 5.1.2.  EtherLink II, 3c503, 3c503/16

 Stato: Supportata, Nome del driver: 3c503 (+8390)

 La 3c503 non ha un ``EEPROM setup'' e quindi non � necessario eseguire
 nessun programma di diagnostica/setup prima di usare la scheda con
 Linux.  L'indirizzo della memoria condivisa della 3c503 � impostato
 usando i ponticelli in comune con l'indirizzo della PROM di boot.  Ci�
 confonde molta gente che ha familiarit� con altre schede ISA, dove di
 solito si lascia sempre il ponticello impostato per ``disabilitare'' a
 meno che non si abbia una PROM di boot.

 Queste schede dovrebbero andare alla stessa velocit� delle WD80x3 a
 pari larghezza di bus, ma in realt� sono un po' pi� lente.  Queste
 schede Ethernet hanno anche un modalit� ad I/O programmato che non usa
 le funzionalit� offerte dal 8390 (gli ingegneri della 3Com hanno
 scoperto troppi bachi!).  Il driver 3c503 di Linux funziona anche con
 la 3c503 in modalit� I/O programmato, ma � pi� lento e meno affidabile
 rispetto alla modalit� a memoria condivisa.  Inoltre la modalit� ad
 I/O programmato non viene ben collaudata quando vengono aggiornati i
 driver.  Non si dovrebbe usare la modalit� in I/O programmato a meno
 che non se ne abbia bisogno per compatibilit� con MS-DOS.

 La linea IRQ della 3c503 � impostata nel software, con nessun
 suggerimento da parte della EEPROM.  Diversamente dal driver MS-DOS,
 quello per Linux ha la funzionalit� di autoIRQ: usa la prima linea IRQ
 libera fra {5,2/9,3,4}, selezionandola ogni volta che la scheda �
 configurata con ifconfig (versioni pi� vecchie del driver selezionano
 l'IRQ all'avvio).  La chiamata ioctl() in `ifconfig' restituir� EAGAIN
 se non c'� alcuna linea IRQ disponibile.

 Alcuni problemi comuni che la gente ha con la 503 sono discussi in
 ``Problemi con...''.

 Se si intende usare questo driver come modulo caricabile probabilmente
 si dovrebbe vedere ``Utilizzare i driver Ethernet come moduli'' per
 informazioni specifiche sui moduli.

 Si noti che alcune vecchie workstation diskless (senza dischi) 386
 hanno gi� una 3c503 (fatta dalla 3Com e venduta sotto nome diverso,
 come `Bull') ma l'ID di produzione non � un ID 3Com e quindi non sar�
 rilevata.  Maggiori dettagli possono essere trovati nel pacchetto
 Etherboot, di cui si avr� comunque bisogno per avviare queste macchine
 diskless.


 5.1.3.  Etherlink Plus 3c505

 Stato: Semi supportata, Nome del driver: 3c505

 � un driver che era stato scritto da Craig Southeren
 [email protected].  Queste schede usano anche il chip i82586.
 Non ci sono poi tante schede di questo tipo in giro.  � incluso nel
 kernel standard, ma viene dichiarato come driver alpha.  Si veda la
 sezione ``Driver alpha'' per importanti informazioni sull'uso con
 Linux di driver Ethernet in alpha-test.

 Se si ha intenzione di usare una di queste schede si dovrebbe leggere
 anche il file /usr/src/linux/drivers/net/README.3c505.  Contiene
 diverse opzioni che si possono abilitare o disabilitare.


 5.1.4.  Etherlink-16 3c507

 Stato: Semi supportata, Nome del driver: 3c507

 Questa scheda usa uno dei chip Intel e lo sviluppo del driver �
 strettamente legato allo sviluppo del driver per la Ether Express
 dell'Intel.  Il driver � incluso nel kernel standard, ma come driver
 sperimentale.  Si veda la sezione ``Driver alpha'' per importanti
 informazioni sull'uso con Linux di driver Ethernet in alpha-test.


 5.1.5.  Etherlink III, 3c509 / 3c509B

 Stato: Supportata, Nome del driver: 3c509

 Questa scheda � piuttosto economica e ha buone prestazioni per essere
 una ISA senza bus-master.  Gli svantaggi sono che la 3c509 originale
 richiede una latenza di interrupt molto bassa.  La 3c509B non dovrebbe
 soffrire dello stesso problema, poich� ha un buffer pi� grande (vedere
 sotto).  Queste schede usano i trasferimenti PIO, analogamente a una
 scheda ne2000 e quindi, in confronto, una scheda a memoria condivisa
 come una wd8013 sar� pi� efficiente.

 La 3c509 originale ha un buffer per i pacchetti piccolino (4kB totali,
 2kB Rx, 2k Tx), cosicch� qualche volta il driver perde dei pacchetti
 se gli interrupt sono mascherati troppo a lungo.  Per minimizzare
 questo problema, si pu� provare a non mascherare gli interrupt durante
 i trasferimenti dei dischi IDE (si veda man hdparm) e/o a incrementare
 la velocit� del proprio bus ISA cosicch� i trasferimenti dei dischi
 IDE terminino prima.

 Il pi� recente modello 3c509B ha 8kB sulla scheda e il buffer pu�
 essere diviso in 4/4, 5/3 o 6/2 per Rx/Tx.  Questa impostazione �
 modificabile con l'utilit� di configurazione DOS ed � salvata nella
 EEPROM.  Questo dovrebbe alleviare il suddetto problema della 3c509
 originale.

 Gli utilizzatori della 3c509B dovrebbero usare l'utilit� DOS fornita
 per disabilitare il supporto plug and play e per impostare il tipo di
 uscita di cui si ha bisogno.  Il driver per Linux attualmente non
 supporta la ``Autodetect media setting'', quindi si deve selezionare
 10Base-T, 10Base-2 oppure AUI.  Si noti che per disabilitare
 completamente il PnP, si dovrebbe fare un 3C5X9CFG /PNP:DISABLE e poi
 farlo seguire da un reset della macchina per assicurarsi che abbia
 avuto effetto.

 Alcuni chiedono delucidazioni sulle impostazioni ``Server or
 Workstation'' e ``Highest Modem Speed'' presenti nella utilit� di
 configurazione sotto DOS.  Donald scrive �Questi sono solo degli hint
 ai driver e il driver di Linux non usa questi parametri: ottimizza
 sempre per la massima velocit� di trasferimento piuttosto che per la
 bassa latenza (`Server').  La bassa latenza era di importanza critica
 per i vecchi throughput IPX non-windowed.  Per ridurre la latenza il
 driver MS-DOS per la 3c509 disabilita gli interrupt per alcune
 operazioni, bloccando gli interrupt per la porta seriale.  Da qui la
 necessit� dell'impostazione `modem speed'.  Il driver per Linux
 rimuove la necessit� di disabilitare gli interrupt per lunghi periodi
 di tempo operando solo su interi pacchetti, ad esempio non cominciando
 a trasmettere un pacchetto finch� non sia stato completamente
 trasferito nella scheda.�

 Si noti che il rilevamento della scheda ISA usa un metodo diverso
 rispetto a quello di molte schede.      In sostanza, si chiede alla
 scheda di rispondere inviando dati ad una ID_PORT (le porte da 0x100 a
 0x1ff con intervalli di 0x10).  Questo rilevamento implica che una
 scheda particolare sar� sempre rilevata per prima in una
 configurazione con pi� 3c509 ISA.  La scheda con il pi� basso
 indirizzo Ethernet hardware alla fin fine sar� sempre la eth0.  Questa
 cosa non dovrebbe preoccupare nessuno, tranne quelli che vogliono
 assegnare un indirizzo hardware da 6 byte a una particolare
 interfaccia.  Se si hanno pi� schede 3c509, la cosa migliore �
 aggiungere i comandi ether=0,0,ethN senza specificare la porta di I/0
 (ovvero si usi I/O=zero) e permettere al rilevamento di determinare
 quale scheda � la prima.  L'uso di un valore I/O non nullo assicura
 solamente che non saranno rilevate tutte le schede, quindi non lo si
 faccia.

 Se questa cosa veramente vi risulta noiosa, si dia un'occhiata
 all'ultimo driver di Donald, in quanto si pu� essere in grado di usare
 un valore 0x3c509 nei campi dell'indirizzo di memoria inutilizzati per
 ordinare il rilevamento ed adattarlo alle proprie necessit�.


 5.1.6.  3c515

 Stato: Supportata, Nome del driver: 3c515

 Questa scheda, nome in codice ``CorkScrew'', � la scheda a 100Mbps ISA
 offerta dalla 3COM.  Un driver relativamente nuovo di Donald � incluso
 nei kernel v2.2.  Per informazioni pi� aggiornate, probabilmente si
 dovrebbe guardare nella pagina relativa alla Vortex:

 Vortex <http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html>



 5.1.7.  3c523

 Stato: Semi supportata, Nome del driver: 3c523


 Questa scheda su bus MCA usa l'i82586. Chris Beauregard ha modificato
 il driver ni52 per farlo funzionare con queste schede.  Il driver pu�
 essere trovato nell'albero dei sorgenti dei kernel v2.2.

 Maggiori dettagli possono essere trovati nella pagina di MCA-Linux a
 http://glycerine.cetmm.uni.edu/mca/.


 5.1.8.  3c527

 Stato: Non supportata.

 S�, un'altra scheda MCA.  No, non risquote molto interesse.  Se si �
 impelagati con l'MCA maggior fortuna la si ha con la 3c529.


 5.1.9.  3c529

 Stato: Supportata, Nome del driver: 3c509

 Questa scheda in realt� usa lo stesso chipset della 3c509.  Molto
 prima che il supporto MCA fosse aggiunto al kernel, Donald ha messo un
 hook nel driver della 3c509 che cerca le schede MCA dopo aver provato
 a rilevare quelle EISA e prima di cercare le ISA.  Il codice di
 rilevamento richiesto � incluso nel driver distribuito con i kernel
 v2.2.  Maggiori dettagli nella pagina di MCA-Linux a

 http://glycerine.cetmm.uni.edu/mca/


 5.1.10.  3c562

 Stato: Supportata, Nome del driver: 3c589 (distribuito separatamente)

 Questa scheda PCMCIA � la combinazione di una scheda Ethernet 3c589B
 con un modem.  All'utente finale il modem appare come un modem
 normalissimo.  La sola difficolt� � far s� che i due driver di Linux
 condividano lo stesso interrupt.  C'� il supporto per alcuni nuovi
 registri e un po' per la condivisione degli interrupt hardware.  Si
 deve usare un kernel v.2.0 o pi� recenti che ha il supporto per la
 condivisione degli interrupt.


 Grazie ancora a Cameron per aver fornito a David Hinds un campione di
 questo prodotto e la documentazione.  Il supporto lo si cerchi nel
 pacchetto PCMCIA di David.

 Si veda la sezione ``Supporto PCMCIA'' per maggiori informazioni sui
 chipset PCMCIA, abilitatori di socket, ecc.


 5.1.11.  3c575

 Stato: Sconosciuto.

 � in sviluppo un driver per questa scheda PCMCIA e si spera che in
 futuro sia incluso nel pacchetto PCMCIA di David.  Per sapere lo stato
 attuale � meglio controllare nel pacchetto PCMCIA.



 5.1.12.  3c579

 Stato: Supportata, Nome del driver: 3c509


 La versione EISA della 509.  La versione EISA attuale usa lo stesso
 chip a 16 bit invece che un interfaccia a 32 bit, quindi l'incremento
 di prestazioni non � meraviglioso.  Ci si assicuri che la scheda sia
 configurata per la modalit� di indirizzamento EISA.  Si legga la
 sezione precedente sulla 3c509 per informazioni sul driver.


 5.1.13.  3c589 / 3c589B

 Stato: Semi-supportata, Nome del driver: 3c589

 Molti stanno usando questa scheda PCMCIA da un po' di tempo.  Si noti
 che il supporto non � (al momento) incluso nell'albero dei sorgenti
 del kernel.  La ``B'' nel nome significa la stessa cosa che nel caso
 della 3c509.

 Sono disponibili dei driver nel sito ftp di Donald e nel pacchetto
 PCMCIA di David Hinds.  Sar� necessario avere anche un controller
 PCMCIA supportato.  Si veda la sezione ``Supporto PCMCIA'' per
 maggiori informazioni su driver, chipset, abilitatori di socket
 PCMCIA, ecc.


 5.1.14.  3c590 / 3c595

 Stato: Supportate, Nome del driver: 3c59x

 Queste schede ``Vortex'' sono per macchine a bus PCI: '590 � l'offerta
 3Com per i 10Mbps mentre la '595 � l'offerta per i 100Mbs.  Si noti
 inoltre che si pu� usare la '595 come una '590 (cio� in modalit� a
 10Mbps).  Il driver � incluso nei sorgenti del kernel v2.0, ma �
 continuamente aggiornato.  Se si hanno problemi con il driver nel
 kernel v2.0, si pu� trovare un driver pi� aggiornato partendo dall'URL
 seguente:

 Vortex <http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html>

 Si noti che in giro si sono due diverse schede 3c590: i primi modelli
 con 32kB di memoria sulla scheda e gli ultimi modelli che hanno solo
 8kB di memoria.  � possibile che non si sar� in grado di trovare una
 nuova 3c59x sul mercato ancora per molto, poich� � stata sostituita
 con la 3c90x.  Se si vuole comprarne una usata da qualcuno, si provi a
 trovare la versione con 32kB.  La 3c595 ha 64kB, in quanto non si pu�
 andare molto lontano con soli 8kB a 100Mbps!

 Un ringraziamento a Cameron Spitzer e Terry Murphy della 3Com per aver
 inviato schede e documentazione a Donald cosicch� ha potuto scrivere
 il driver.

 Donald ha messo su una mailing list per il supporto al driver Vortex.
 Per unirsi alla lista, si faccia semplicemente:

 echo subscribe | /bin/mail [email protected]



 5.1.15.  3c592 / 3c597

 Stato: Supportate, Nome del driver: 3c59x

 Queste sono le versioni EISA della serie di schede 3c59x.  Le
 3c592/3c597 (altrimenti note come Demon) dovrebbero funzionare con il
 driver vortex discusso in precedenza.



 5.1.16.  3c900 / 3c905 / 3c905B

 Status: Supportate, Nome del driver Name: 3c59x

 Queste schede (altrimenti note come `Boomerang' o EtherLink III XL)
 sono state realizzate per prendere il posto delle schede 3c590/3c595.

 Il supporto per la revisione `B' (Cyclone) � stato aggiunto solo di
 recente.  Per usare questa scheda con i vecchi kernel v2.0, si deve
 ottenere il driver 3c59x.c aggiornato dal sito di Donald a:

 Vortex-Page <http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html>

 Per qualsiasi dubbio si veda la pagina WWW suddetta.  Donald ha messo
 su una mailing list per il supporto del driver Vortex, annunci, ecc.
 Per unirsi alla lista, si faccia semplicemente:

 echo subscribe | /bin/mail [email protected]


 5.1.17.  3c985

 Stato: Supportata, Nome del driver: acenic

 Questo driver di Jes Sorensen � disponibile nei kernel v2.2.  Supporta
 diverse altre schede Gigabit oltre al modello 3Com.


 5.2.  Accton



 5.2.1.  Accton MPX

 Stato: Supportata, Nome del driver: ne (+8390)

 Non ci si faccia ingannare dal nome.  Questa � una scheda compatibile
 con la NE2000 e dovrebbe funzionare con il driver ne2000.


 5.2.2.  Accton EN1203, EN1207, EtherDuo-PCI

 Stato: Supportata, Nome del driver: de4x5, tulip

 Questa � un'altra implementazione del chip PCI 21040 della DEC.  La
 scheda EN1207 ha il 21140 e ha pure un connettore 10Base-2, che si �
 dimostrato causare un po' di problemi a qualcuno nella selezione di
 quel mezzo.  Per altri ha funzionato bene usando la scheda con 10Base-
 T e 100Base-T.  Quindi come per qualsiasi acquisto, la si dobrebbe
 provare assicurandosi di poterla restituire nel caso non funzioni.

 Si veda ``DEC 21040'' per maggiori informazioni su queste schede e la
 situazione attuale del driver.


 5.2.3.  Accton EN2209 Parallel Port Adaptor (EtherPocket)

 Stato: Semi supportata, Nome del driver: ?

 � disponibile un driver per questi adattatori su porta parallela ma
 non fa ancora parte dei sorgenti del kernel 2.0 e 2.1.  Si deve
 scaricare il driver da:

 http://www.unix-ag.uni-siegen.de/~nils/accton_linux.html


 5.2.4.  Accton EN2212 PCMCIA Card

 Stato: Semi supportata, Nome del driver: ?

 David Hinds stava lavorando su un driver per questa scheda e quindi
 per conoscere lo stato attuale la cosa migliore � quindi quella di
 controllare l'ultima release del suo pacchetto PCMCIA.


 5.3.  Allied Telesyn/Telesis



 5.3.1.  AT1500

 Stato: Supportata, Nome del driver: lance

 Questa � una serie di schede Ethernet a bassa costo che usa la
 versione 79C960 del chip LANCE dell'AMD. Sono schede bus-master e
 quindi fra le pi� veloci schede Ethernet per bus ISA disponibili.

 Informazioni sulla selezione del DMA e la numerazione del chip possono
 essere trovate in ``AMD LANCE''.

 Informazioni tecniche aggiuntive sulle schede Ethernet basate su AMD
 LANCE possono essere trovate nella sezione ``Note su AMD...''.


 5.3.2.  AT1700

 Stato: Supportata, Nome del driver: at1700

 Si noti che per accedere a questo driver durante il make config si
 deve ancora rispondere `Y' alla domanda iniziale ``Prompt for
 development and/or incomplete code/drivers?''.  Ci� � dovuto
 semplicemente allo scarso responso avuto sulla stabilit� del driver a
 causa della relativa rarit� della scheda.  Se si hanno problemi con il
 driver distribuito assieme al kernel, pu� interessare un driver
 alternativo reperibile a:

 http://www.cc.hit-u.ac.jp/nagoya/at1700/

 La serie di schede Ethernet AT1700 della Allied Telesis sono basate
 sul chip MB86965 della Fujitsu.  Questo chip usa un'interfaccia ad I/O
 programmato e una coppia di buffer di trasmissione di dimensione
 fissa.  Ci� permette l'invio back-to-back di piccoli gruppi di
 pacchetti, con una breve pausa durante lo scambio dei buffer.

 Una caratteristica unica � l'abilit� di pilotare un cavo STP (Shielded
 Twisted Pair - doppino intrecciato schermato) da 15 Ohm comunemente
 utilizzato per il Token Ring, oltre ai cavi UTP (unshielded twisted
 pair - doppino intrecciato non schermato) da 100 Ohm del 10baseT.
 Della scheda ne esiste pure una versione per fibra ottica (AT1700FT).

 Il chip Fujitsu utilizzato nella AT1700 ha un difetto di
 progettazione: pu� essere reinizializzato completamente solo operando
 un ciclo completo di alimentazione della macchina.  Premendo solamente
 il pulsante di reset non si inizializza l'interfaccia.  Questo non
 sarebbe tanto male, tranne per il fatto che pu� essere rilevata in
 modo affidabile solo quando � stata reinizializzata.  La
 soluzione/work-around � di spegnere la macchina se il kernel ha
 problemi a rilevare l'AT1700.




 5.3.3.  AT2450

 Stato: Supportata, Nome del driver: pcnet32

 Questa � la versione PCI della AT1500 e non soffre dei problemi cha ha
 la scheda PCI 79c970 della Boca.  Informazioni sulla selezione del DMA
 e la numerazione del chip possono essere trovate nella sezione ``AMD
 LANCE''.

 Ulteriori informazioni tecniche sulle schede Ethernet basate sul LANCE
 dell'AMD possono essere trovate nella sezione ``Note su AMD...''.


 5.3.4.  AT2500

 Stato: Semi supportata, Nome del driver: rtl8139

 Questa scheda usa il chip 8139 della RealTek.  Si veda la sezione
 ``RealTek 8139''.


 5.3.5.  AT2540FX

 Stato: Semi supportata, Nome del driver: eepro100

 Questa scheda usa il chip i82557 e quindi pu�/potrebbe funzionare con
 il driver eepro100.  Se la si prova si � invitati ad inviare un
 rapporto cosicch� queste informazioni possano essere aggiornate.


 5.4.  AMD / Advanced Micro Devices


 Carl Ching dell'AMD � stato talmente gentile da fornire descrizioni
 molto dettagliate su tutti i pi� importati prodotti Ethernet dell'AMD
 che mi hanno aiutato a chiarire un po' questa sezione.


 5.4.1.  AMD LANCE (7990, 79C960/961/961A, PCnet-ISA)

 Stato: Supportata, Nome del driver: lance

 In realt� non ci sono schede Ethernet dell'AMD.  Probabilmente si sta
 leggendo questa sezione perch� le sole cose che si possono leggere
 sopra la propria scheda dicono AMD e uno dei numeri suddetti.  Il 7990
 � il chip `LANCE' originale, ma molte cose (tra cui questo documento)
 fanno riferimento a tutti questi chip simili come chip `LANCE'
 (...incorrettamente potrei aggiungere).

 Questi numeri fanno riferimento a chip dell'AMD che sono il cuore di
 molte schede Ethernet.  Per esempio la AT1500 della Allied Telesis (si
 veda la sezione ``AT1500'') e la NE1500/2100 (si veda la sezione
 ``NE1500'') usano questi chip.

 Il 7990/79c90 � stato da tempo rimpiazzato da nuove versioni.  Il
 79C960 (detto anche PCnet-ISA) essenzialmente contiene il nucleo della
 79c90, assieme a tutto l'altro hardware di supporto, che permette una
 soluzione Ethernet in un unico chip.  Il 79c961 (PCnet-ISA+) � una
 versione Plug and Play senza ponticelli della '960.  L'ultimo chip
 della serie ISA � il 79c961A (PCnet-ISA II), che aggiunge piene
 funzionalit� full duplex.  Tutte le schede con uno di questi chip
 dovrebbero funzionare con il driver lance.c, ad eccezione di quelle
 veramente vecchie che usano il 7990 originale in una configurazione a
 memoria condivisa.  Queste vecchie schede possono essere identificate
 dalla mancanza di jumper per il canale DMA.

 Un problema comune � la ricezione del messaggio `busmaster arbitration
 failure'.  Questo � mostrato quando il driver LANCE non pu� accedere
 al bus dopo che � passato un ragionevole intervallo di tempo (5us).
 Solitamente indica che l'implementazione del bus-master della scheda
 madre ha problemi o qualche altro dispositivo sta intasando il bus,
 oppure c'� un canale DMA in conflitto.  Se il proprio BIOS ha
 l'opzione GAT (che sta per Guaranteed Access Time -- tempo di accesso
 garantito) si provi ad attivare/alterare questa impostazione per
 vedere se � di qualche aiuto.

 Si noti inoltre che il driver cerca una scheda valida solo in questi
 indirizzi: 0x300, 0x320, 0x340, 0x360 e qualsiasi indirizzo fornito
 con l'argomento di boot ether= � ignorato silenziosamente (questa cosa
 verr� corretta).  Quindi per ora ci si assicuri che la propria scheda
 sia configurata per uno dei suddetti indirizzi I/O.

 Il driver dovrebbe funzionare ancora bene anche se sono installati pi�
 di 16 MB di memoria, in quanto, quando serve, sono usati i `bounce-
 buffer' in memoria bassa (i.e. qualsiasi dato sopra il 16 MB � copiato
 dentro un buffer sotto il 16 MB prima di essere dato alla scheda
 perch� lo trasmetta).

 Il canale DMA pu� essere impostato con i bit meno significativi
 dell'altrimenti inutilizzato valore di dev->mem_start (PARAM_1) (si
 veda ``PARAM_1'').  Se non impostato � rilevato abilitando a turno
 tutti i canali DMA liberi e controllando se l'inizializzazione ha
 successo.

 La scheda HP-J2405A � un eccezione: con questa scheda � facile leggere
 i valori impostati nella EEPROM per IRQ e DMA.

 Si veda la sezione ``Note su AMD...'' per maggiori informazioni su
 questi chip.


 5.4.2.  AMD 79C965 (PCnet-32)

 Stato: Supportata, Nome del driver: pcnet32

 Questa � la PCnet-32: una versione bus-master a 32 bit del chip LANCE
 originale per sistemi VL-bus e local bus.  Sebbene questi chip possano
 funzionare con il driver lance.c standard, � disponibile anche una
 versione a 32 bit (pcnet32.c) che non si preoccupa mai delle
 limitazioni ai 16 MB associati con il bus ISA.


 5.4.3.  AMD 79C970/970A (PCnet-PCI)

 Stato: Supportata, Nome del driver: pcnet32

 Questa � la PCnet-PCI: simile alla PCnet-32, ma progettata per i
 sistemi basati su bus PCI.  Si vedano le informazioni sulla PCnet-32.
 Si noti che � necessario compilare un kernel abilitando il supporto
 per il PCI.  La '970A aggiunge al progetto originale della '970 il
 supporto per il full duplex oltre ad altre caratteristiche.

 Si noti che l'implementazione Boca della 79C970 fallisce su macchine
 Pentium veloci.  � un problema hardware, in quanto affligge anche gli
 utenti DOS.  Si veda la sezione sulla Boca per maggiori dettagli.


 5.4.4.  AMD 79C971 (PCnet-FAST)

 Stato: Supportata, Nome del driver: pcnet32


 Questo � il chip a 100Mbit per sistemi PCI della AMD, che supporta
 anche le operazioni full duplex.  � stato introdotto nel giugno 1996.


 5.4.5.  AMD 79C972 (PCnet-FAST+)

 Stato: Sconosciuto, Nome del driver: pcnet32

 Questa dovrebbe funzionare proprio come la '971 ma la cosa non �
 ancora stata confermata.


 5.4.6.  AMD 79C974 (PCnet-SCSI)

 Stato: Supportata, Nome del driver: pcnet32

 Questa � la PCnet-SCSI, che in pratica viene trattata come una '970
 dal punto di vista Ethernet.  Si vedano anche le informazioni
 precedenti.  Non mi si chieda se � supportata la parte SCSI del chip:
 questo � Ethernet-HowTo, non lo SCSI-HowTo.


 5.5.  Ansel Communications



 5.5.1.  AC3200 EISA

 Stato: Semi-supportata, Nome del driver: ac3200

 Si noti che per accedere a questo driver durante il make config si
 deve ancora rispondere `Y' alla domanda iniziale ``Prompt for
 development and/or incomplete code/drivers?''.  Questa cosa �
 semplicemente dovuta allo scarso responso da parte degli utenti sulla
 stabilit� del driver a causa della relativa rarit� della scheda.

 Questo driver � incluso nel kernel attuale con un driver in alpha
 test.  � basata sul comune chip NS8390 usato nelle schede ne2000 e
 wd80x3.  Si veda la sezione ``Driver sperimentali'' in questo
 documento per importanti informazioni riguardanti i driver
 sperimentali.

 Se la si usa, lo si faccia sapere ad uno di noi, poich� il riscontro
 da parte degli utenti � stato basso, anche se il driver � nel kernel
 gi� a partire dalla versione 1.1.25.

 Se si intende utilizzare questo driver come modulo caricabile
 probabilmente si dovrebbe vedere la sezione ``Usare i driver Ethernet
 come moduli'' per informazioni specifiche sui moduli.


 5.6.  Apricot



 5.6.1.  Apricot Xen-II On Board Ethernet

 Stato: Semi supportata, Nome del driver: apricot

 Questa scheda Ethernet on board usa un chip i82596 bus-master.  Pu�
 essere solo all'indirizzo I/O 0x300.  Guardando nei sorgenti del
 driver, sembra anche che l'IRQ sia fissato via hardware al 10.

 Le prime versioni di questo driver avevano la tendenza a pensare che
 qualsiasi cosa presente a 0x300 fosse una NIC apricot.  Da allora
 l'indirizzo hardware � verificato per evitare questi falsi rilievi.
 5.7.  Arcnet

 Stato: Supportata, Nome del driver: arcnet (arc-rimi, com90xx,
 com20020)

 Con il costo ormai veramente basso e le migliori prestazioni di
 Ethernet, � possibile che molti posti diano via gratis il loro
 hardware Arcnet, il che risulta in un sacco di sistemi domestici con
 Arcnet.

 Un vantaggio di Arcnet � che tutte le schede hanno la medesima
 interfaccia cosicch� un unico driver funziona per tutte.  Hanno pure
 una gestione degli errori e quindi si pu� supporre che non perdano mai
 pacchetti (bellissimo per il traffico UDP!).

 Il driver arcnet di Avery Pennarun � nel kernel dalla versione 1.1.80.
 Il driver arcnet usa `arc0' come nome invece del solito `eth0' dei
 dispositivi Ethernet.  Segnalazioni di bug e racconti di successo
 possono essere inviati a:

 [email protected]

 Nel kernel standard ci sono file d'informazioni sull'impostazione dei
 ponticelli e suggerimenti generali.

 Si pu� supporre che il driver funzioni anche con le schede ARCnet a
 100Mbs!


 5.8.  AT&T


 Si noti che la StarLAN della AT&T � una tecnologia orfana, come la
 LattisNet della SynOptics e non pu� essere usata in un ambiente
 10Base-T standard, senza un hub che le `parla' entrambe.


 5.8.1.  AT&T T7231 (LanPACER+)

 Stato: Non supportata.

 Queste schede StarLAN usano un interfaccia simile a quella del chip
 i82586.  Ad un certo punto Matthijs Melchior
 ([email protected]) si era messo a giocare con il driver
 3c507 e quasi aveva qualcosa di funzionante.  Non ho sentito pi�
 niente da allora.


 5.9.  Boca Research


 S�, fanno molto pi� che solo schede seriali multiporta. :-)


 5.9.1.  Boca BEN (ISA, VLB, PCI)

 Stato: Supportata, Nome del driver: lance, pcnet32

 Questa schede sono basate sui chip PCnet dell'AMD.  Gli acquirenti
 accorti dovrebbero essere avvisati che molti utenti hanno avuto un
 sacco di problemi con queste schede VLB/PCI.  Sono stati colpiti
 specialmente i possessori di sistemi Pentium veloci.  Si noti che
 questo non � un problema del driver, in quanto colpisce anche gli
 utenti DOS/Win/NT.  Il numero del supporto tecnico della Boca � (407)
 241-8088 e pu� essere raggiunto anche a [email protected].  Le
 vecchie schede ISA non sembra soffrano dello stesso problema.
 Donald ha fatto un test comparativo tra una scheda PCI della Boca e
 una implementazione PCnet/PCI simile della Allied Telsyn e ha rilevato
 che i problemi dipendono dall'implementazione Boca del chip PCnet/PCI.
 Si pu� accedere ai risultati di questi test nel server www di Don.

 Linux at CESDIS <http://cesdis.gsfc.nasa.gov/linux/>

 La Boca sta offrendo una `warranty repair' (ripazione in garanzia) per
 i possessori di tali schede che consiste nell'aggiunta di un
 condensatore, ma sembra che la cosa non funzioni al 100% per molte
 persone, sebbene aiuti un po'.

 Se ancora si � convinti di comprare una di queste schede, allora
 almeno si provi ad ottenere una garanzia incondizionata di
 restituzione entro 7 giorni, cosicch� se non funziona bene nel proprio
 sistema, la si pu� sempre restituire.

 Per ulteriori infomazioni generali sui chip della AMD si veda ``AMD
 LANCE''.

 Informazioni tecniche ulteriori sulle schede Ethernet AMD LANCE
 possono essere trovate nella sezione ``Note su AMD...''.


 5.10.  Cabletron


 Donald scrive: �S�, un'altra di quelle compagnie che non vuole
 rilasciare le sue informazioni per la programmazione.  Hanno aspettato
 mesi prima di confermare che tutte le loro informazioni erano
 proprietarie, sprecando deliberatamente il mio tempo.  Se si pu� si
 evitino queste schede come la peste.  Si noti che ad alcuni che hanno
 telefonato alla Cabletron sono state dette cose del tipo `un certo D.
 Becker sta lavorando su un driver per Linux' -- facendo sembrare che
 io lavori per loro.  Questo NON � vero.�


 Apparentemente la Cabletron ha cambiato la sua politica riguardo le
 informazioni per la programmazione (come la Xircom) da quando Donald
 ha fatto quei commenti parecchi anni fa: si mandi una email a
 [email protected] se si vuole verificare questa cosa o chiedere le
 infomazioni per la programmazione.  Comunque, a questo punto, c'� una
 richiesta minima per driver modificati/aggiornati per le vecchie
 schede E20xx e E21xx.


 5.10.1.  E10**, E10**-x, E20**, E20**-x

 Stato: Semi supportate, Nome del driver: ne (+8390)

 Queste sono praticamente dei cloni delle NEx000 che si dice funzionino
 con i driver standard NEx000, grazie a un controllo specifico durante
 il rilevamento.  Se ci sono dei problemi, difficilmente possono essere
 risolti, poich� non sono disponibili le informazioni per la
 programmazione.


 5.10.2.  E2100

 Stato: Semi supportata, Nome del driver: e2100 (+8390)

 Ancora, non si pu� fare molto quando le informazioni per la
 programmazione sono proprietarie.  Le E2100 ha un pessimo progetto.
 Ogniqualvolta mappa la sua memoria condivisa durante un trasferimento
 di pacchetti, la mappa dentro un'intera regione di 128K!  Ci�
 significa che in quella regione non si pu� usare con sicurezza un
 altro dispositivo gestito a memoria condivisa, nemmeno un'altra E2100.
 Funzioner� per maggior parte del tempo, ma tutto un tratto non lo far�
 pi� (s�, questo problema pu� essere evitato disabilitando gli
 interrupt mentre si trasferiscono i pacchetti, ma quasi certamente si
 perderanno colpi di clock).  Inoltre, se si mal programma la scheda o
 si ferma la macchina proprio al momento sbagliato, nemmeno il bottone
 di reset sar� utile. Si deve spegnere la macchina e lasciarla spenta
 per almeno 30 secondi.

 La selezione del mezzo � automatica, ma volendo lo si pu� imporre con
 i bit meno significativi del parametro dev->mem_end.  Se veda
 ``PARAM_2''.  Gli utilizzatori dei moduli possono specificare un
 valore xcvr=N come options nel file /etc/conf.modules.

 Inoltre, non si scambi la E2100 per un clone della NE2100.  La E2100 �
 un NetSemi DP8390 a memoria a condivisa, ``rozzamente'' simile alla
 demente della WD8013, mentre la NE2100 (e la NE1500) usano un AMD
 LANCE con bus-mastering.

 Nel kernel standard � incluso un driver per la E2100.  Comunque,
 poich� non sono disponibili informazioni per la programmazione, non si
 aspettino le correzioni di eventuali bachi.  Non se ne usi una a meno
 che non la si possegga gi�.

 Se si ha intenzione di usare questo driver come modulo caricabile
 probabilmente si dovrebbe vedere la sezione ``Usare i driver Ethernet
 come moduli'' per infomazioni specifiche sui moduli.


 5.10.3.  E22**

 Stato: Semi supportata, Nome del driver: lance

 Secondo le infomazioni in un bollettino tecnico della Cabletron,
 queste schede usano il chip PC-Net dell'AMD (si veda ``AMD PC-Net'') e
 dovrebbero quindi funzionare con il driver lance generico.


 5.11.  Cogent


 Ecco come e dove possono essere raggiunti:


         Cogent Data Technologies, Inc.
         175 West Street, P.O. Box 926
         Friday Harbour, WA 98250, USA.

         Cogent Sales
         15375 S.E. 30th Place, Suite 310
         Bellevue, WA 98007, USA.

         Supporto tecnico:
         Telefono (360) 378-2929 tra le 8 e 17 PST
         Fax (360) 378-2882
         Compuserve GO COGENT
         Bulletin Board Service (360) 378-5405
         Internet: [email protected]




 5.11.1.  EM100-ISA/EISA

 Stato: semi supportata, Nome del driver: smc9194

 Queste schede usano il chip SMC 91c100 e potrebbero funzionare con il
 driver per SMC 91c92, ma la cosa non � ancora stata verificata.


 5.11.2.  Cogent eMASTER+, EM100-PCI, EM400, EM960, EM964

 Stato: Supportate, Nome del driver: de4x5, tulip

 Queste sono un'altra implementazione del DEC 21040 che quindi dovrebbe
 funzionare tranquillamente con il driver standard per il 21040.

 La EM400 e la EM964 sono schede a quattro porte che usano un bridge
 DEC 21050 e 4 chip 21040.

 Si veda ``DEC 21040'' per maggiori informazioni su queste schede e la
 situazione attuale.


 5.12.  Compaq


 La Compaq non � veramente in affari per la costruzione di schede
 Ethernet, ma un sacco di loro sistemi hanno controller Ethernet
 integrati nella scheda madre.


 5.12.1.  Compaq Deskpro / Compaq XL (Embedded AMD Chip)

 Stato: Supportati, Nome del driver: pcnet32

 Le macchine come quella della serie XL hanno un chip PCI 79c97x
 dell'AMD nella scheda madre che pu� essere usato con il driver LANCE
 standard.  Ma prima di usarlo, si devono utilizzare alcuni trucchetti
 per far s� che il BIOS PCI si metta in un posto dove Linux lo possa
 vedere.  Frank Maas � stato cos� gentile da fornire i dettagli
 operativi:

 �Il problema con questa macchina Compaq � che la directory PCI �
 caricata in memoria alta, in un punto che il kernel di Linux non pu�
 (non vuole) raggiungere.  Risultato: la scheda non � mai rilevata e
 nemmeno usabile (altro effetto: non funziona nemmeno il mouse).  Il
 workaround (come descritto approfonditamente in http://www-
 c724.uibk.ac.at/XL/) � di caricare MS-DOS, lanciare un piccolo driver
 che ha scritto la Compaq e poi caricare il kernel di Linux usando
 LOADLIN.  Ok, vi do il tempo per dire `yuck, yuck', ma per ora questo
 � il solo metodo che conosco.  Il driver semplicemente sposta la
 directory PCI nel posto dov'� di solito (e dove Linux la pu�
 trovare).�

 Ulteriori informazioni generali sui chip AMD possono essere trovate in
 ``AMD LANCE''.


 5.12.2.  Compaq Nettelligent/NetFlex (Embedded ThunderLAN Chip)

 Stato: Supportata, Nome del driver: tlan

 Questi sistemi usano un chip ThunderLAN della Texas Instruments.
 Informazioni sul driver ThunderLAN possono essere trovare in
 ``ThunderLAN''.


 5.13.  Danpex



 5.13.1.  Danpex EN9400

 Stato: Supportata, Nome del driver: de4x5, tulip

 Ecco un'altra scheda basata sul chip 21040 della DEC, che si dice
 funzioni bene e che costa relativamente poco.

 Si veda ``DEC 21040'' per maggiori informazioni su queste schede e
 l'attuale situazione del driver.


 5.14.  D-Link



 5.14.1.  DE-100, DE-200, DE-220-T, DE-250

 Stato: Supportata, Nome del driver: ne (+8390)

 Alcune delle prime schede D-Link non avevano la firma (signature) 0x57
 nella PROM, ma il driver ne2000 ne � conscio.  Per quanto riguarda le
 schede configurabili via software, si pu� scaricare il programma di
 configurazione da www.dlink.com.  Le schede DE2** erano le
 maggiormente segnalate per avere errori spuri di mismatch
 nell'indirizzo di trasferimento con le prime versioni di Linux.  Si
 noti che esistono anche schede della Digital (DEC) chiamate DE100 e
 DE200, ma la somiglianza finisce qui.


 5.14.2.  DE-520

 Stato: Supportata, Nome del driver: pcnet32

 Questa � una scheda PCI che usa la versione PCI del chip LANCE
 dell'AMD.  Informazioni sulla selezione del DMA e la numerazione del
 chip possono essere trovate nella sezione ``AMD LANCE''.

 Ulteriori informazioni tecniche sulle schede Ethernet basate sul LANCE
 dell'AMD le si pu� trovare nella sezione ``Note su AMD...''.


 5.14.3.  DE-528

 Stato: Supportata, Nome del driver: ne, ne2k-pci (+8390)

 Apparentemente la D-Link ha cominciato a fare anche cloni PCI della
 NE2000.



 5.14.4.  DE-530

 Stato: Supportata, Nome del driver: de4x5, tulip

 Questa � un'implementazione del chip DEC 21040 ed � riportato che
 funziona con il driver generico tulip per il 21040.

 Si veda la sezione ``DEC 21040'' per maggiori informazioni su queste
 schede e sullo stato attuale del driver.


 5.14.5.  DE-600

 Stato: Supportata, Nome del driver: de600


 Ai possessori di un portatile e a tutti quelli che vorrebbero un
 metodo veloce per mettere il loro computer su Ethernet piacer� usare
 questa schede.  Il driver � incluso nei sorgenti del kernel standard.

 Il driver � stato scritto da Bjorn Ekwall [email protected].  Ci si
 aspetti una velocit� di trasferimento di circa 180kb/s da questa
 scheda attraverso la porta parallela.  Si dovrebbe leggere il file
 README.DLINK nell'albero dei sorgenti del kernel.

 Si noti che il nome del device da passare a ifconfig ora � eth0 e non
 pi� il dl0 usato in precedenza.

 Se la propria porta parallela non � all'indirizzo standard 0x378
 allora si deve ricompilare.  Bjorn scrive: �Poich� il driver DE-620
 prova a spremere anche l'ultimo microsecondo dal ciclo, ho reso l'irq
 e l'indirizzo delle costanti piuttosto che delle variabili.  Questo
 consente di ottenere una velocit� usabile, ma significa anche che non
 si possono modificare questi assegnamenti p.es. da lilo; si _deve_
 ricompilare...�.  Si noti inoltre che alcuni portatitili implementano
 la porta parallela on board a 0x3bc che � dove erano/sono le porte
 parallele sulle schede monocromatiche.


 5.14.6.  DE-620

 Stato: Supportata, Nome del driver: de620

 Analoga alla DE-600, con solo due formati d'uscita.   Bjorn ha scritto
 un driver per questo modello per le versioni del kernel pari e
 superiori alla 1.1.  Si vedano le informazioni precedenti sulla
 DE-600.


 5.14.7.  DE-650

 Stato: Semi supportata, Nome del driver: de650 (?)

 Alcuni hanno usato questa scheda PCMCIA per abbastanza tempo nei loro
 computer portatili.  In pratica � un 8390, come una NE2000.  Si
 suppone che anche la scheda PCMCIA LinkSys e la IC-Card Ethernet siano
 dei cloni della DE-650.  Si noti che al momento questo driver non �
 parte del kernel standard, e quindi si devono applicare alcune patch.

 Si veda ``Supporto PCMCIA'' in questo documento e, se si pu�, si dia
 un'occhiata a:

 Don's PCMCIA Stuff <http://cesdis.gsfc.nasa.gov/linux/pcmcia.html>


 5.15.  DFI



 5.15.1.  DFINET-300 e DFINET-400

 Stato: Supportate, Nome del driver: ne (+8390)

 Ora queste schede sono rilevate (sin dal 0.99pl15) grazie a Eberhard
 Moenkeberg [email protected] che ha notato che usano `DFI' nei primi 3
 byte della PROM, invece di usare 0x57 nei byte 14 e 15, che � quello
 che fanno tutte le schede NE1000 e NE2000 (la 300 � un pseudo-clone
 della NE1000 a 8 bit e la 400 lo � della NE2000).




 5.16.  Digital / DEC



 5.16.1.  DEPCA, DE100/1, DE200/1/2, DE210, DE422

 Stato: Supportate, Nome del driver: depca

 Nel file sorgente `depca.c' � inclusa della documentazione, che
 comprende informazioni su come usare pi� di una di queste schede in
 una macchina.  Si noti che la DE422 � una scheda EISA.  Queste schede
 sono tutte basate sul chip LANCE dell'AMD.  Si veda la sezione ``AMD
 LANCE'' per maggiori informazioni.  Possono essere usate sino ad un
 massimo di due schede ISA, perch� possono essere impostate solamente
 per gli indirizzi di I/O base 0x300 e 0x200.  Se si intende farlo, si
 leggano le note nel file sorgente del driver depca.c nell'albero dei
 sorgenti del kernel standard.

 Questo driver funzioner� anche sulle macchine basate su CPU Alpha e ci
 sono diverse ioctl() con le quali l'utente pu� giocare.


 5.16.2.  Digital EtherWorks 3 (DE203, DE204, DE205)

 Stato: Supportata, Nome del driver: ewrk3

 Queste schede usano un chip proprietario della DEC, invece del chip
 LANCE utilizzato nelle prime schede come la DE200.  Queste schede
 supportano sia la memoria condivisa che l'I/O programmato, sebbene
 raggiungano una calo di prestazioni del 50% se si usa la modalit� PIO.
 La dimensione della memoria condivisa pu� essere impostata a 2kB, 32kB
 o 64kB, ma con questo driver sono state testate solamente le prime due
 dimensioni.  David dice che le prestazioni sono virtualmente identiche
 tra il modo a 2kB e quello a 32kB.  Maggiori informazioni (tra cui
 l'uso del driver come modulo caricabile) sono presenti all'inizio del
 file sorgente ewrk3.c e anche nel file README.ewrk3.  Ambedue i file
 sono nella distribuzione standard del kernel.  Questo driver ha il
 supporto per le CPU Alpha, come il depca.c.

 Il driver standard ha diverse chiamate ioctl() interessanti che
 possono essere usate per ottenere ed azzerare le statistiche sui
 pacchetti, leggere/scrivere la EEPROM, cambiare l'indirizzo hardware e
 cose cos�.  Gli smanettoni possono vedere il codice sorgente per
 maggiori informazioni su queste possibilit�.

 David ha scritto anche un programma di configurazione per questa
 scheda (sulla falsa riga del programma DOS NICSETUP.EXE) assieme con
 altri strumenti.  Possono essere trovati in praticamente tutti i siti
 FTP di Linux nella directory /pub/Linux/system/Network/management (si
 cerchi il file ewrk3tools-X.XX.tar.gz).


 5.16.3.  DE425 EISA, DE434, DE435, DE500

 Stato: Supportate, Nome del driver: de4x5, tulip

 Queste schede si basano sul chip 21040 menzionato sotto.  La DE500 usa
 il chip 21140 per fornire connessioni Ethernet a 10/100Mbs.  Si deve
 leggere la sezione sul 21040 qui sotto per ulteriori informazioni.  Ci
 sono alcuni opzioni da passare in compilazione per le schede non DEC
 che usano questo driver.  Si veda il file README.de4x5 per i dettagli.

 Tutte le schede Digital rileveranno automaticamente il mezzo (tranne,
 temporaneamente, la DE500 a causa di un brevetto).


 Questo driver � pronto anche per le CPU Alpha e pu� essere caricato
 come modulo.  Gli utenti possono raggiungere l'interno del driver
 attraverso chiamate ioctl. Si vedano gli strumenti 'ewrk3' e il
 sorgente de4x5.c per informazioni su come farlo.


 5.16.4.  DEC 21040, 21041, 2114x, Tulip

 Stato: Supportate, Nome del driver: de4x5, tulip

 Il DEC 21040 � una soluzione Ethernet bus-mastering in un unico chip,
 simile al chip PCnet dell'AMD.  Il 21040 � progettato specificatamente
 per l'architettura di bus PCI.  La nuova scheda PCI EtherPower della
 SMC usa questo chip.  Per le schede basate su questo chip � possibile
 scegliere tra due driver.  C'� il driver DE425 discusso in precedenza
 e driver generico `tulip' per il 21040.

 Attenzione: Sebbene la propria scheda possa essere basata su questo
 chip, nel proprio caso i driver potrebbero non funzionare.  David C.
 Davies scrive:

 �Non c'� alcuna garanzia che il `tulip.c' o il `de4x5.c' funzionino
 con una qualsiasi scheda basata sui DC2114x oltre a quelle per cui
 sono stati scritti.  PERCH�??  Perch� c'� un registro, il General
 Purpose Register (CSR12) che (1) nel DC21140A � programmabile da
 qualsiasi produttore e tutti lo fanno in modo differente (2) nei
 DC21142/3 c'� ora un registro di controllo SIA (a la DC21041).  Il
 solo piccolo raggio di speranza � che riusciamo a decodificare la SROM
 per aiutare l'impostazione nel driver.  Comunque, questa non � una
 soluzione garantita in quanto alcuni produttori (per esempio la scheda
 SMC 9332) non seguono le raccomandazioni Digital Semiconductor sul
 formato di programmazione della SROM.�

 In termini meno tecnici, ci� significa che se non si � sicuri che una
 scheda sconosciuta con un chip DC2114x funzioner� con i driver per
 Linux, allora ci si assicuri di porterla restituire dove la si �
 comprata prima di pagare.

 Nella maggior parte delle ultime schede EtherPower della SMC al posto
 del 21040 si pu� trovare il pi� aggiornato chip 21041.  Il 21140 � per
 supportare il 100Base-? e funziona con i driver per Linux per il chip
 21040.  Per usare il driver de4x5 di David con una scheda non DEC, si
 deve guardare il file README.de4x5 per i dettagli.

 Donald ha usato le schede EtherPower-10/100 della SMC per sviluppare
 il driver `tulip'.  Si noti che il driver presente nel albero standard
 dei sorgenti al momento non � la versione pi� aggiornata.  Se si hanno
 problemi con questo driver, ci si dovrebbe procurare la versione pi�
 nuova dal sito ftp/WWW di Donald.

 Tulip Driver <http://cesdis.gsfc.nasa.gov/linux/drivers/tulip.html>

 Questo URL contiene anche un elenco (non esaustivo) delle diverse
 schede/vendor che usano il chip 21040.

 Si noti inoltre che il driver tulip al momento � ancora considerato un
 driver sperimentale (si veda la sezione ``Driver sperimentali'') e
 dovrebbe essere trattato come tale.  Per usarlo, si dovr� modificare
 il file arch/i386/config.in e decommentare la riga per il supporto
 CONFIG_DEC_ELCP.

 Donald ha messo su anche una mailing list per gli annunci sul driver
 tulip, ecc.  Per unirsi alla lista si digiti:

 echo subscribe | /bin/mail [email protected]

 5.17.  Farallon

 La Farallon vende gli adattatori e i transceiver EtherWave.  Questo
 dispositivo permette di mettere in daisy chain diversi dispositivi
 10baseT.


 5.17.1.  Farallon Etherwave

 Stato: Supportato, Nome del driver: 3c509

 � riportato che questo driver sia un clone del 3c509 che include il
 transceiver EtherWave.  La gente l'ha usata con successo con Linux e
 l'attuale driver 3c509.  Sono troppo costose per l'uso comune, ma sono
 una grande opzione in casi speciali.  I prezzi degli hublet partono da
 $125, e la Etherwave aggiunge $75-$100 al prezzo della scheda


 5.18.  Fujitsu


 Diversamente da molti costruttori di chip di rete, la Fujitsu ha fatto
 e venduto anche alcune schede di rete basate sui loro chip.


 5.18.1.  Fujitsu FMV-181/182/183/184

 Stato: Supportato, Nome del driver: fmv18x

 Secondo quel che afferma il driver, queste schede sono semplicemente
 un'implementazione del MB86965 della Fujitsu, il che le rende molto
 simili alle schede AT1700 della Allied Telesis.


 5.19.  Hewlett Packard


 Le schede 272** usano l'I/O programmato, similmente alle schede
 NE*000, ma la porta del trasferimento dei dati pu� essere `spenta'
 quando non vi si accede, evitando problemi con i driver che fanno
 l'autorilevamento.

 Grazie a Glenn Talbott per l'aiuto fornito nel chiarire la confusione
 in questa sezione a proposito dei numeri di versione dell'hardware HP.


 5.19.1.  27245A

 Stato: Supportata, Nome del diver: hp (+8390)

 Una 10BaseT a 8 Bit basata sul 8390, non � raccomandata per tutte
 quelle ragioni delle 8 bit. � stata riprogettata un paio di anni fa
 per essere altamente integrata e ci� ha causato alcune modifiche nei
 tempi di inizializzazione che affliggono solo i programmi di test, non
 i driver LAN (la nuova scheda non � `pronta' subito dopo si entra ed
 esce dalla modalit� loopback).

 Se si intende usare questo driver come modulo caricabile probabilmente
 si dovrebbe vedere la sezione ``Usare i driver Ethernet come modulo''
 per informazioni specifiche sui moduli.


 5.19.2.  HP EtherTwist, PC Lan+ (27247, 27252A)

 Stato: Supportate, Nome del driver: hp+ (+8390)

 La HP PC Lan+ � diversa dalla scheda HP PC Lan standard.  Questo
 driver � stato aggiunto all'elenco dei driver del kernel standard
 durante il ciclo di sviluppo del v1.1.x.  Pu� essere fatta funzionare
 in modalit� PIO come una ne2000, o in modalit� a memoria condivisa
 come una wd8013.

 La 47B � una scheda a 16 bit 10BaseT con AUI a 16 Bit basata su 8390 e
 la 52A � una 16 bit ThinLan con AUI basata su 8390.  Queste schede
 hanno una RAM da 32K per la bufferizzazione dei pacchetti da
 trasmettere/ricevere invece dei soliti 16KB e entrambe offrono il
 rilievo automativo del connettore LAN.

 Se si intende usare questo driver come modulo caricabile probabilmente
 si dovrebbe vedere la sezione ``Usare i driver Ethernet come modulo''
 per informazioni specifiche sui moduli.


 5.19.3.  HP-J2405A

 Stato: Supportata, Nome del driver: lance

 Queste schede costano meno e sono un po' pi� veloci delle
 27247/27252A, ma mancano di alcune caratteristiche quali AUI, la
 connettivit� ThinLAN e il boot PROM socket.  Sono una versione del
 LANCE abbastanza generica, ma piccole diversit� nel progetto le
 rendono incompatibili con il driver `NE2100' generico.  Il supporto
 speciale per queste schede (comprensivo della lettura del canale DMA
 dalla scheda) � incluso grazie alle informazioni fornite da Glenn
 Talbott dell'HP.

 Ulteriori informazioni tecniche sulle schede basate su LANCE possono
 essere trovate nella sezione ``Note su AMD...''


 5.19.4.  HP-Vectra On Board Ethernet

 Stato: Supportata, Nome del driver: lance

 L'HP-Vectra ha un chip PCnet dell'AMD sulla piastra madre.
 Informazioni sulla selezione del DMA e la numerazione del chip possono
 essere trovate nella sezione ``AMD LANCE''.

 Ulteriori informazioni tecniche sulle schede basate su LANCE possono
 essere trovate nella sezione ``Note su AMD...''


 5.19.5.  Schede HP 10/100 VG Any Lan (27248B, J2573, J2577, J2585,
 J970, J973)

 Stato: Supportate, Nome del driver: hp100

 Questo driver supporta anche alcuni dei prodotti VG della Compex.
 Poich� il driver supporta schede ISA, EISA e PCI, quando si esegue
 make config sui sorgenti del kernel lo si trova nella sezione relativa
 alle schede ISA.


 5.19.6.  HP NetServer 10/100TX PCI (D5013A)

 Stato: Supportata, Nome del driver: eepro100

 Apparentemente queste sono semplicemente delle schede EtherExpress Pro
 10/100B dell'Interl rimarchiate.  Si veda la sezione su Intel per
 maggiori informazioni.


 5.20.  IBM / International Business Machines



 5.20.1.  IBM Thinkpad 300

 Stato: Supportato, Nome del driver: znet

 � compatibile con la Z-note della Zenith basata su Intel.  Si veda
 ``Z-note'' per maggiori informazioni.

 Suppongo che questo sito abbia un esauriente elenco di cosette utili
 per le nuove versioni del ThinkPad.  Ancora non l'ho verificato
 personalmente.

 Thinkpad-info <http://peipa.essex.ac.uk/html/linux-thinkpad.html>

 Quelli che non possono usare un browser WWW, provino a
 peipa.essex.ac.uk:/pub/tp750/


 5.20.2.  IBM Credit Card Adaptor for Ethernet

 Stato: Semi-supportato, Nome del driver: ? (distribuito separatamente)

 Molti stanno usando questa scheda PCMCIA con Linux.  Valgono le solite
 cose, come la necessit� di avere nel proprio portatile un chipset
 PCMCIA supportato e che si deve applicare una patch al kernel standard
 per il supporto PCMCIA.

 Si veda ``Supporto PCMCIA'' in questo documento e se si pu� si dia
 un'occhiata a:

 Don's PCMCIA Stuff <http://cesdis.gsfc.nasa.gov/linux/pcmcia.html>



 5.20.3.  IBM Token Ring

 Stato: Semi supportata, Nome del driver: ibmtr

 Il supporto per il token ring richiede molto pi� che la sola scrittura
 di un driver per i dispositivi.  Richiede anche la scrittura delle
 routine di instradamento per il token ring.  � nella scrittura di
 queste ultime che si perde la maggior parte del tempo.

 Peter De Schrijver ha speso un po' di tempo sul Token Ring.  Ha
 lavorato con schede Token Ring ISA e MCA dell'IBM.

 L'attuale codice per il token ring � stato incluso all'inizio dello
 sviluppo dei kernel della serie 1.3.x.

 Peter dice che � stato originariamente testato su schede MCA 16/4
 Megabit Token Ring, ma dovrebbe funzionare con altre schede basate sul
 chip Tropic.


 5.21.  Schede Ethernet ICL



 5.21.1.  ICL EtherTeam 16i/32

 Stato: Supportata, Nome del driver: eth16i


 Questo driver l'ha scritto Mika Kuoppala ([email protected]) ed �
 stato introdotto verso il kernel 1.3.4x.  Usa il chip MB86965 della
 Fujitsu, usato anche nelle schede at1700.


 5.22.  Schede Ethernet Intel

 Si noti che la nomenclatura delle diverse schede Intel � ambigua e
 confusa al massimo.  Se si hanno dubbi, si veda il numero i8xxxx sul
 chip principale della scheda oppure, per le schede PCI, si usino le
 informazioni sul PCI nella directory /proc e poi si confronti con i
 numeri elencati qui.


 5.22.1.  Ether Express

 Stato: Supportata, Nome del driver: eexpress

 Questa scheda usa il i82586 dell'Intel.  Le prime versioni di questo
 driver (nei kernel v1.2) erano classificate come sperimentali e non
 funzionavano bene per la maggior parte della gente.  Quelli che
 l'hanno provato dicono che il driver nei kernel v2.0 sembra funzionare
 molto meglio, sebbene il driver sia ancora sperimentale e un po'
 problematico sulle macchine pi� veloci.

 I commenti all'inizio del sorgente del driver elencano alcuni problemi
 (e correzioni!) associati con queste schede.  Il trucchetto di
 rimpiazzare nel driver tutti gli outb con outb_p si dice abbia
 funzionato per pi� di un utente.


 5.22.2.  Ether Express PRO/10

 Stato: Supportata, Nome del driver: eepro

 Bao Chau Ha ha scritto un driver per queste schede incluso nei primi
 kernel v1.3.x.  Pu� funzionare anche con alcuni sistemi Ethernet
 integrati della Compaq basati sul chip i82595.


 5.22.3.  Ether Express PRO/10 PCI (EISA)

 Stato: Semi supportata, Nome del driver: ? (distribuito separatamente)

 John Stalba ([email protected]) ha scritto un driver per la versione
 PCI.  Queste schede usano il chip d'interfaccia PLX9036 PCI con un
 chip i82596 LAN controller della Intel.  Se la propria scheda ha il
 chip i82557, allora non si possiede questa scheda ma piuttosto la
 versione discussa dopo e quindi si deve usare il driver EEPro100.

 Si pu� ottenere il driver sperimentale per la propria scheda PCI
 PRO/10 assieme alle instruzioni per usarlo a:

 EEPro10 Driver <http://www.ultranet.com/~stalba/eep10pci.html>

 Se si ha una scheda EISA, probabilmente si dovr� lavorare un po' sul
 driver per tener conto delle differenze (PCI vs. EISA) nei meccanismi
 di rilievo usati nei due casi.



 5.22.4.  Ether Express PRO 10/100B

 Stato: Supportata, Nome del driver: eepro100


 Si noti che questo driver non funzioner� con le vecchie schede 100A.
 I numeri dei chip elencati nel driver sono i82557/i82558.  Per
 aggiornamenti del driver e/o supporto sul driver, si veda

 EEPro-100B Page
 <http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html>

 Per iscriversi alla mailing list relativa a questo driver, si faccia:

 echo subscribe | /bin/mail [email protected]

 Apparentemente Donald ha firmato un accordo di non-disclosure che dice
 che lui non pu� effettivamente rivelare il codice sorgente del driver!
 Che cosa dire di questa insulsaggine da parte di Intel?



 5.23.  Kingston


 La Kingston fa diverse schede, tra cui schede basate su NE2000+, AMD
 PCnet e DEC tulip.  La maggior parte di queste schede dovrebbero
 funzionare bene con i rispetti driver.  Si veda la pagina web della
 Kingston <http://www.kingston.com>

 La KNE40 basata sul 21041 tulip della DEC si dice funzioni bene con il
 driver tulip generico.



 5.24.  LinkSys


 La LinkSys ha fatto una manciata di diversi cloni NE2000, alcuni sono
 schede ISA semplici, altre ISA plug-and-play e altri ancora sono cloni
 PCI della ne2000 basati su uno dei chip PCI ne2000 supportati.
 Semplicemente ci sono troppi modelli per elencarli tutti qui.

 Le LinkSys sono ``Linux-friendly'' e c'� pure una pagina WWW specifica
 per il supporto di Linux e hanno anche la parola Linux stampata sulla
 scatola di alcuni dei loro prodotti.  Si veda:

 http://www.linksys.com/support/solution/nos/linux.htm



 5.24.1.  Schede LinkSys Etherfast 10/100.

 Stato: Supportate, Nome del driver: tulip

 Si noti che queste schede sono state sottoposte a parecchie
 `revisioni' (ovvero sono stati usati diversi chip) tutte sotto lo
 stesso nome.  La prima usava il chip della DEC.  La seconda revisione
 usava il PNIC 82c168 PCI della Lite-On e il supporto per questo era
 stato aggiunto al supporto per il driver tulip standard (dalla
 versione 0.83).  Ulteriori informazioni sul PNIC sono disponibili a:

 http://cesdis.gsfc.nasa.gov/linux/drivers/pnic.html

 Altre informazioni sulle diverse versioni di queste schede possono
 essere trovate nella pagina WWW della LinkSys menzionata in
 precendenza.




 5.24.2.  LinkSys Pocket Ethernet Adapter Plus (PEAEPP)

 Stato: Supportata, Nome del driver: de620

 Questo � un clone (o supposto tale) nel DE-620 e si dice funzioni bene
 con quel driver.  Si veda ``DE-620'' per maggiori informazioni.


 5.24.3.  LinkSys PCMCIA Adaptor

 Stato: Supportato, Nome del driver: de650 (?)

 Questa � una versione rimarchiata del DE-650.  Si veda ``DE-650'' per
 maggiori informazioni.


 5.25.  Microdyne



 5.25.1.  Microdyne Exos 205T

 Stato: Semi supportata, Nome del driver: ?

 Un'altra scheda basata sul chip i82586. Dirk Niggemann dirk-
 [email protected] ha scritto un driver che lui classifica come ``pre-
 alpha'' e vorrebbe che la gente testasse.  Gli si scriva per maggiori
 dettagli.


 5.26.  Mylex


 La Mylex pu� essere raggiunta ai seguenti numeri, nel caso qualcuno
 voglia chiedere qualcosa.


         MYLEX CORPORATION, Fremont
         Sales:  800-77-MYLEX, (510) 796-6100
         FAX:    (510) 745-8016.



 Hanno anche un sito web: Mylex WWW Site <http://www.mylex.com>


 5.26.1.  Mylex LNE390A, LNE390B

 Stato: Supportata, Nome del driver: lne390 (+8390)

 Queste sono delle schede EISA piuttosto vecchie che fanno uso di
 un'implementazione a memoria condivisa simile alla wd80x3.  Nella
 serie attuale 2.1.x del kernel � presente un driver per queste schede.
 Ci si assicuri di impostare l'indirizzo della memoria condivisa sotto
 il primo MB o oltre il pi� alto indirizzo della memoria RAM
 fisicamente installata nella macchina.


 5.26.2.  Mylex LNP101

 Stato: Supportata, Nome del driver: de4x5, tulip

 Questa � una scheda PCI basata sul chip 21040 della DEC.  �
 selezionabile con uscita 10BaseT, 10Base2 e 10Base5.  Si � verificato
 che la scheda LNP101 funziona con il driver 21040 generico.

 Si veda la sezione sul chip 21040 (``DEC 21040'') per maggiori
 informazioni.


 5.26.3.  Mylex LNP104

 Stato: Semi supportata, Nome del driver: de4x5, tulip

 La LNP104 usa il chip 21050 della DEC per gestire quattro porte
 10BaseT indipendenti.  Dovrebbe funzionare con i driver 21040 recenti
 che sanno come condividere gli IRQ, ma nessuno ha ancora riportato di
 averci provato (a quanto ne so).


 5.27.  Novell Ethernet, NExxxx e cloni associati


 Il prefisso `NE' viene da Novell Ethernet.  La Novell ha seguito il
 progetto pi� economico del databook della National Semiconductor e
 vende i diritti di produzione Eagle, solo per immettere sul mercato
 schede Ethernet a prezzi ragionevoli (la ormai ubiqua scheda NE2000).


 5.27.1.  NE1000, NE2000

 Stato: Supportata, Nome del driver: ne (+8390)

 La ne2000 � ora il nome generico del progetto base fatto attorno al
 chip 8390 della NatSemi.  Usano l'I/O programmato piuttosto che la
 memoria condivisa, il che comporta maggiore facilit� di installazione
 ma prestazioni un po' pi� basse e un po' di problemi.  Alcuni dei
 problemi pi� comuni che capitano con le schede NE2000 sono elencati in
 ``Problemi con...''.

 Alcuni cloni della NE2000 usano il chip `AT/LANTic' 83905 della
 National Semiconductor, che offre una modalit� a memoria condivisa
 simile a quella della wd8013 e la configurazione via software della
 EEPROM.  La modalit� a memoria condivisa permette un minor utilizzo
 della CPU (cio� � pi� efficiente) rispetto alla modalit� ad I/O
 programmato.

 In generale non � una buona idea mettere un clone della NE2000
 all'indirizzo I/O 0x300 perch� praticamente tutti i driver di
 dispositivo cercano l� al boot.  Alcuni cloni NE2000 ``poveri'' non la
 prendono bene ad essere rilevati in aree sbagliate e risponderanno
 bloccando la macchina.  Inoltre anche 0x320 non va bene perch� i
 driver SCSI rilevano a 0x330.

 Donald ha scritto un progamma di diagnostica per NE2000 (ne2k.c) che
 va bene per tutte le schede ne2000.  Si veda la sezione ``Programmi
 diagnostici'' per maggiori informazioni.

 Se si intende usare questo driver con modulo caricabile probabilmente
 si dovrebbe vedere la sezione ``Usare i driver Ethernet come moduli''
 per informazioni specifiche sui moduli.


 5.27.2.  NE2000-PCI (RealTek/Winbond/Compex)

 Stato: Supportata, Nome del driver: ne, ne2k-pci (+8390)

 S�, che ci si creda o no, la gente sta facendo schede PCI basate su
 progetto dell'interfaccia dell'ne2000 che ha ormai pi� di 10 anni.  Al
 momento praticamente tutte queste schede sono basate sul chip 8029
 della RealTek, o sul chip 89c940 della Winbond.  Anche le schede
 Compex, KTI, VIA e Netvin apparentemente usano questi chip, ma hanno
 un diverso ID PCI.

 L'ultimo kernel v2.0 ha il supporto per rilevare automaticamente tutte
 queste schede ed usarle (se si sta usando un kernel v2.0.34 o pi�
 vecchio, lo si dovrebbe aggiornare per assicurarsi che la propria
 scheda sia rilevata).  Ora ci sono due driver tra cui scegliere:
 l'originale driver ISA/PCI ne.c o quello relativamente nuovo solo PCI
 ne2k-pci.c.

 Per usare il driver ISA/PCI originale si deve rispondere `Y'
 all'opzione `Other ISA cards' quando si lancia make config perch� in
 realt� si sta usando lo stesso driver NE2000 che usano le schede ISA
 (la qual cosa dovrebbe suggerire che queste schede non sono cos�
 intelligenti come pu� essere, ad esempio, una PCNet-PCI o una DEC
 21040...).

 Il nuovo driver solo PCI differisce dal driver ISA/PCI nel fatto che
 tutto il supporto per le vecchie schede a 8 bit NE1000 � stato rimosso
 e che i dati sono spostati da e nella scheda in blocchi pi� grandi,
 senza alcuna pausa tra un'operazione e l'altra che le vecchie NE2000
 ISA richiedono per operare in maniera affidabile.  Il risultato � un
 driver pi� efficiente, ma non ci si ecciti troppo in quanto le
 differenze non saranno cos� ovvie nel funzionamento normale (se si
 vuole veramente la massima efficenza assieme ad un basso utilizzo
 della CPU, allora una NE2000 PCI � semplicemente una scelta povera).
 Aggiornamenti del driver e ulteriori informazioni possono essere
 trovate a:

 http://cesdis.gsfc.nasa.gov/linux/drivers/ne2k-pci.html

 Se si possiede una scheda PCI NE2000 che non � rilevata dalla versione
 pi� recente del driver, si contatti il manutentore del driver NE2000
 citato nel file /usr/src/linux/MAINTAINERS e gli si spedisca l'output
 di cat /proc/pci e dmesg dimodoch� possa aggiungere il supporto per la
 scheda.

 Si noti inoltre che diversi prodottori di schede sono noti per
 attaccare l'etichetta `NE2000 Compatible' sulle scatole dei loro
 prodotti anche se sono completamente differenti (e.g. PCNet-PCI o
 RealTek 8139).  Se si � in dubbio si controlli il numero del chip
 principale con quelli in questo documento.


 5.27.3.  NE-10/100

 Stato: Non supportata.

 Queste sono delle schede ISA a 100Mbps basate sui chip DP83800 e
 DP83840 della National Semiconductor.  Attualmente non c'� alcun
 driver che le supporta n� nessuno ha ancora detto che sta lavorando su
 un driver.  Apparentemente non � disponibile la documentazione sul
 chip ad eccezione di un file PDF che non fornisce abbastanza dettagli
 per scrivere un driver.


 5.27.4.  NE1500, NE2100

 Stato: Supportate, Nome del driver: lance

 Queste schede usano il chip LANCE 7990 originale dell'AMD e sono
 supportate usando il driver lance di Linux.  I cloni NE2100 pi� nuovi
 usano il chip aggiornato PCnet-ISA dell'AMD.

 Alcune delle prime versioni del driver lance avevano problemi con la
 determinazione della linea IRQ attraverso l'autoIRQ     delle schede
 Novell/Eagle 7990.  Teoricamente questa cosa ora � stata corretta.  Se
 non lo fosse, allora si specifichi l'IRQ usando LILO e si renda noto
 che questo � ancora un problema.

 Informazioni sulla selezione del DMA e la numerazione del chip possono
 essere trovate nella sezione ``AMD LANCE''.

 Ulteriori informazioni tecniche sulle schede basate su LANCE si
 trovano nella sezione ``Note su AMD...''


 5.27.5.  NE/2 MCA

 Stato: Semi supportata, Nome del driver: ne2

 C'erano anche un po' di schede NE2000 microchannel fatte da diverse
 compagnie.  Questo driver, disponibile nei kernel v2.2, rilever� le
 seguenti schede MCS: Novell Ethernet Adapter NE/2, Compex ENET-16 MC/P
 e Arco Ethernet Adapter AE/2.


 5.27.6.  NE3200

 Stato: Non supportata

 Questa vecchia scheda EISA usa un 80186 a 8Mhz assieme con un i82586.
 Nessuno sta lavorando su un driver in quanto non ci sono n�
 informazioni disponibili sulla scheda n� una reale richiesta per un
 driver.


 5.27.7.  NE3210

 Stato: Supportata, Nome del driver: ne3210 (+8390)

 Questa scheda EISA � completamente diversa dalla NE3200, poich� usa un
 chip 8390 della Nat Semi.  Il driver pu� essere trovato nell'albero
 dei sorgenti del kernel v2.2.  Ci si assicuri si impostare l'indirizzo
 della memoria condivisa sotto il primo MB o superiore all'indirizzo
 pi� alto della RAM fisica installata nella macchina.


 5.27.8.  NE5500

 Stato: Supportata, Nome del driver: pcnet32

 Queste sono semplicemente delle schede con il chip PCnet-PCI ('970A)
 dell'AMD.  Maggiori informazioni sulle schede basate su LANCE/PCnet
 possono essere trovate nella sezione ``AMD LANCE''.



 5.28.  Proteon



 5.28.1.  Proteon P1370-EA

 Stato: Supportata, Nome del driver: ne (+8390)

 Apparentemente questa � un clone NE2000 e funziona bene con Linux.


 5.28.2.  Proteon P1670-EA

 Stato: Supportata, Nome del driver: de4x5, tulip

 Questa � un'altra scheda PCI basata sul chip Tulip della DEC.  Si dice
 funzioni bene con Linux.

 Si veda la sezione sul chip 21040 (``DEC 21040'') per maggiori
 informazioni sul driver.



 5.29.  Pure Data



 5.29.1.  PDUC8028, PDI8023

 Stato: Supportata, Nome del driver: wd (+8390)

 Le serie di schede PDUC8028 e PDI8023 della Pure Data si dice
 funzionino, grazie a uno speciale codice di rilevamento fornito da
 Mike Jagdis [email protected].  Il supporto � integrato con il
 driver WD.


 5.30.  Racal-Interlan


 La Racal Interlan pu� essere raggiunta via WWW a www.interlan.com.
 Credo che in passato fosse conosciuta anche come MiCom-Interlan.


 5.30.1.  ES3210

 Stato: Semi supportata, Nome del driver: es3210

 Questa � una scheda EISA a memoria condivisa basata su 8390.  Con il
 kernel v2.2 � distribuito un driver sperimentale e si dice funzioni
 bene, ma il rilevamento EISA dell'IRQ e dell'indirizzo della memoria
 condivisa non senbra funzionare bene con (almeno) le prime revisioni
 della scheda (comunque questo problema non � ristretto al solo mondo
 Linux...).  In quel caso, si devono fornire tali informazioni al
 driver.  Per esempio, per una scheda all'IRQ 5 e memoria condivisa a
 0xd0000 che usa un driver modulare, si aggiuga options es3210 irq=5
 mem=0xd0000 a /etc/conf.modules.  Oppure con il driver compilato nel
 kernel, all'avvio si passi ether=5,0,0xd0000,eth0.  L'I/O base �
 rilevato automaticamente e quindi dovrebbe essere usato il valore 0.


 5.30.2.  NI5010

 Stato: Semi supportata, Nome del driver: ni5010

 Solitamente ci si doveva procurare separatamente il driver per queste
 vecchie schede a 8 bit della MiCom-Interlan, ma ora � distribuito con
 i kernel v2.2 come driver sperimentale.


 5.30.3.  NI5210

 Stato: Semi supportata, Nome del driver: ni52

 Anche questa scheda usa uno dei chip dell'Intel.  Michael Hipp ha
 scritto un driver e ora � incluso nel kernel standard come driver
 `alpha'.  Michael vorrebbe sentire dei commenti dagli utenti che
 posseggono questa scheda.  Si veda ``Driver sperimentali'' per
 conoscere importanti informazioni sull'uso dei driver Ethernet
 sperimentali.

 5.30.4.  NI6510 (non EB)

 Stato: Semi supportata, Nome del driver: ni65

 C'� anche un driver per la NI6510 basata su LANCE ed � sempre stato
 scritto da Michael Hipp.  Anche questo � un driver sperimentale.  Per
 qualche ragione questa scheda non � compatibile con il driver LANCE
 generico.  Si veda ``Driver sperimentali'' per conoscere importanti
 informazioni sull'uso dei driver Ethernet sperimentali.


 5.30.5.  EtherBlaster (aka NI6510EB)

 Stato: Supportata, Nome del driver: lance

 Dal kernel 1.2.23, al driver LANCE generico � stato aggiunto un
 controllo per la firma 0x52, 0x44 specifica della NI6510EB.  Comunque
 alcuni hanno riportato che questa firma non � la stessa per tutte le
 schede NI6510EB, il che fa s� che il driver LANCE non rilevi la
 scheda.  Se questo succede, si pu� cambiare il controllo (verso la
 riga 322 in lance.c) a printk() cosicch� stampi i valori per la
 propria scheda e poi usarli come default invece di 0x52, 0x44.

 Usando il driver lance, probabilmente le schede dovrebbero essere
 usate in modalit� ad `alte prestazioni' e non in compatibilit� NI6510.


 5.31.  RealTek



 5.31.1.  Adattatore pocket RealTek RTL8002/8012 (AT-Lan-Tec)

 Stato: Supportato, Nome del driver: atp

 Questo � un adattatore pocket generico e a basso costo, venduto dalla
 AT-Lan-Tec e (probabilmente) da molti altri fornitori.  Nel kernel
 standard � presente un driver.  Si noti che le informazioni pi�
 importanti sono contenute nel file sorgente del driver `atp.c'.

 Si noti che nelle prime versioni di questo driver il nome di device da
 passare a ifconfig non era eth0 bens� atp0.


 5.31.2.  RealTek 8009

 Stato: Supportata, Nome del driver: ne (+8390)

 Questa � un clone ISA della NE2000 e si dice funzioni bene con il
 driver NE2000 di Linux.  Dal sito WWW della RealTek
 (http://www.realtek.com.tw) o via FTP dallo stesso sito pu� essere
 scaricato il programma rset8009.exe.


 5.31.3.  RealTek 8019

 Stato: Supportata, Nome del driver: ne (+8390)

 Questa � la versione Plug and Pray della scheda precedente.  Si usi il
 software per DOS per disabilitare il Pnp ed abilitare la
 configurazione senza ponticelli; si configuri la scheda ad un
 indirizzo I/O ed a un'IRQ ragionevoli e si dovrebbe essere pronti per
 partire (se si usa il driver come modulo, non si dimentichi di
 aggiungere l'opzione io=0xNNN a /etc/conf.modules).  Dal sito WWW
 della RealTek (http://www.realtek.com.tw) o via FTP dallo stesso sito
 pu� essere scaricato il programma rset8009.exe.
 5.31.4.  RealTek 8029

 Stato: Supportata, Nome del driver: ne, ne2k-pci (+8390)

 Questa � una impletazione PCI a singolo chip di un clone NE2000.
 Diversi vendor adesso vendono schede con questo chip.  Si veda la
 sezione ``NE2000-PCI'' per informazioni sull'uso di una qualsiasi di
 queste schede.  Si noti che questo � un progetto di pi� di 10 anni fa
 semplicemente adattato al bus PCI.  Le prestazioni non saranno molto
 migliori rispetto a quelle dell'eqivalente modello ISA.


 5.31.5.  RealTek 8129/8139

 Stato: Semi-supportate, Nome del driver: rtl8139

 Una soluzione Ethernet PCI a chip singolo della RealTeak.  Un driver
 per le schede basate su questo chip � stato incluso nella release
 v2.0.34 di Linux.  Al momento nei kernel v2.2 se si vuole avere
 accesso a questo driver si deve rispondere `Y' quando viene chiesto se
 si vogliono i driver sperimentali.  Per maggiori informazioni si veda:

 http://cesdis.gsfc.nasa.gov/linux/drivers/rtl8139.html



 5.32.  Sager



 5.32.1.  Sager NP943

 Stato: Semi supportata, Nome del driver: 3c501

 Questa � semplicemente un clone della 3c501, con un diverso prefisso
 S.A. nella PROM.  Suppongo che sia talmente demente quanto la 3c501
 originale.  Il driver cerca l'ID della NP943 e poi la tratta
 semplimente come un 3c501.  Si veda la sezione ``3Com 3c501'' per
 tutte le ragioni per le quali veramente non si deve usare una di
 queste schede.


 5.33.  Schneider & Koch



 5.33.1.  SK G16

 Stato: Supportata, Nome del driver: sk_g16

 Questo driver � stato incluso nei kernel v1.1 ed � stato scritto da
 PJD Weichmann e SWS Bern.  Sembra che la SK G16 sia simile alla
 NI6510, per il fatto che � basata sulla prima edizione del chip LANCE.
 Ancora una volta, sembra che pure questa scheda non funzioni con il
 driver LANCE generico.


 5.34.  SEEQ



 5.34.1.  SEEQ 8005

 Stato: Supportata, Nome del driver: seeq8005


 Questo driver � stato incluso nei primi kernel v1.3 ed � stato scritto
 da Hamish Coleman.  Nel driver sono incluse pochissime informazioni
 sulla scheda e quindi ci sono pure poche informazioni da mettere qui.
 Se si hanno domande, probabilmente la cosa migliore � di scrivere a
 [email protected].


 5.35.  SMC (Standard Microsystems Corp.)


 La divisione Ethernet della Western Digital � stata acquisita dalla
 SMC molti anni fa, quando la wd8003 e wd8013 erano i prodotti di
 punta.  Da allora la SMC ha continuato a fare schede ISA basate
 sull'8390 (Elite16, Ultra, EtherEZ) e ha aggiunto alla gamma anche
 diversi prodotti PCI.

 Informazioni per contattare la SMC:

 SMC / Standard Microsystems Corp., 80 Arkay Drive, Hauppage, New York,
 11788, USA.  Supporto tecnico telefonico: 800-992-4762 (USA) o
 800-433-5345 (Canada) o 516-435-6250 (Altri nazioni).  Richieste di
 documentazione: 800-SMC-4-YOU (USA) o 800-833-4-SMC (Canada) o
 516-435-6255  (Altre nazioni).  Supporto tecnico via E-mail:
 [email protected]. Sito FTP: ftp.smc.com.  Sito WWW: SMC
 <http://www.smc.com>.


 5.35.1.  WD8003, SMC Elite

 Stato: Supportate, Nome del driver: wd (+8390)

 Queste sono le versioni ad 8 bit della scheda.  Il chip 8003 a 8 bit �
 leggermente meno costoso, ma vale solo se destinato ad un uso leggero.
 Si noti che alcune schede senza EEPROM (cloni con i ponticelli o
 schede we8003 veramente vecchie) non hanno modo di riportare la linea
 IRQ utilizzata.  In questo caso, � usato auto-irq e se fallisce, il
 driver assegna l'IRQ 5 senza dire niente.  Dal sito FTP della SMC si
 possono scaricare i dischetti di configurazione/driver.  Si noti che
 alcune delle versioni pi� recenti del rpogramma `SuperDisk' della SMC
 falliranno nel rilevare le veramente vecchie schede senza EEPROM.  Il
 file SMCDSK46.EXE sembra essere una buona scelta a tutto tondo.
 Inoltre le impostazioni dei ponticelli per tutte le loro schede si
 possono trovare in un file testo ASCII nel summenzionato archivo.
 L'ultima (migliore?) versione pu� essere ottenuta da ftp.smc.com.

 Poich� questo sono in pratica analoghe alle loro controparti a 16 bit
 (WD8013 / SMC Elite16), si dovrebbe vedere la sezione successiva per
 maggiori informazioni.



 5.35.2.  WD8013, SMC Elite16

 Stato: Supportate, Nome del driver: wd (+8390)

 Negli anni sono stati aggiunti al progetto altri registri e una EEPROM
 (le prime schede wd8003 sono apparse circa 10 anni fa!).  I cloni
 solitamente vanno sotto il nome `8013' e tipicamente usano un progetto
 senza EEPROM (con i ponticelli).  Gli ultimi modelli delle schede SMC
 montano un chip 83c690 della SMC invece dell'originale DP8390 della
 National presente nelle prime schede.  Il progetto a memoria condivisa
 rende queste schede un po' pi� veloci delle schede PIO, specialmente
 con pacchetti pi� grossi.  Pi� importante, dal punto del vista del
 driver, si evitano cos� un po' di bachi nella modalit� ad I/O
 programmato dell'8390, permettendo accessi multi-thread sicuri al
 buffer dei pacchetti e non si ha il registro dati dell'I/O programmato
 che pianta la macchina durante il controllo al boot.

 Le schede non EEPROM che non possono leggere l'IRQ selezionato
 proveranno a fare l'auto-irq e se falliscono assegneranno
 silenziosamente l'IRQ 10 (le versioni a 8 bit assegnano l'IRQ 5).

 Le schede con a bordo dimensioni di memoria non standard la possono
 specificare all'avvio (o come opzione in /etc/conf.modules se si usano
 i moduli).  La dimensione standard della memoria � di 8kB per le
 schede a 8 bit e 16kB per quelle a 16 bit.  Per esempio, le schede pi�
 vecchie WD8003EBT potevano essere impostate attraverso i ponticelli
 per 32kB di memoria.  Per usare appieno questa RAM, si dovrebbe usare
 qualcosa di simile a (con I/O=0x280 e IRQ 9):

 ______________________________________________________________________
         LILO: linux ether=9,0x280,0xd0000,0xd8000,eth0
 ______________________________________________________________________



 Si veda anche ``Problemi dell'8013'' per alcuni dei problemi pi�
 comuni e le risposte alle domande pi� frequenti.

 Se si intende usare questo driver come modulo caricabile probabilmente
 si dovrebbe vedere la sezione ``Usare i driver Ethernet come modulo''
 per informazioni specifiche sui moduli.


 5.35.3.  SMC Elite Ultra

 Stato: Supportata, Nome del driver: smc-ultra (+8390)

 Questa scheda Ethernet � basata sul chip 83c790 della SMC che ha un
 po' di nuove caratteristiche rispetto al 83c690.  Sebbene possieda una
 modalit� simile alle schede SMC pi� vecchie, non � completamente
 compatibile con i vecchi driver WD80*3-  Comunque in questa modalit�
 condivide la maggior parte del codice con gli altri driver 8390 anche
 se funziona leggermente pi� veloce rispetto ad un clone WD8013.

 Poich� parte della Ultra sembra una 8013, il controllo per la Ultra si
 suppone trovi una Ultra prima che il controllo per la wd8013 abbia la
 possibilit� di indentificarla in maniera errata.

 Donald ha riferito che � possibile scrivere un driver separato per la
 modalit� `Altego' della Ultra che permette di concatenare la
 trasmissione al costo di un uso inefficiente dei buffer di ricezione,
 ma probabilmente ci� non avverr�.

 Gli utilizzatori di adattatori host SCSI bus master prendano nota: Nel
 manuale distribuito con Interactive UNIX, � riportato che un bug nella
 SMC Ultra causer� corruzione dei dati con dischi SCSI utilizzati
 attraverso un adattatore host aha-154X. Questa cosa affligge
 probabilmente anche le schede aha-154X compatibili, come le schede
 BusLogic e gli adattatori host AMI-Fastdisk SCSI.

 La SMC ha riconosciuto che il problema si presenta con Interactive e
 con vecchie versioni dei driver per Windows NT.  � un conflitto
 hardware con le prime versioni della scheda che pu� essere aggirato
 nel progetto del driver.  Il driver Ultra attuale protegge da questo
 abilitando la memoria condivisa solo durante il trasferimento con la
 scheda.  Ci si assicuri che la propria versione del kernel sia almeno
 1.1.84 e che la versione riportata dal driver al boot sia almeno smc-
 ultra.c:v1.12, altrimenti si � vulnerabili.

 Se si intende usare questo driver come modulo caricabile probabilmente
 si dovrebbe vedere la sezione ``Usare i driver Ethernet come modulo''
 per informazioni specifiche sui moduli.


 5.35.4.  SMC Elite Ultra32 EISA

 Stato: Supportata, Nome del driver: smc-ultra32 (+8390)

 Questa scheda EISA ha molto in comune con la sua controparte ISA.  Un
 driver funzionante (e stabile) � incluso sia nei kernel v2.0 che
 v.2.2.  Grazie a Leonard Zubkoff per aver acquistato alcune di queste
 schede dimodoch� sia stato possibile aggiungerne il supporto per
 Linux.


 5.35.5.  SMC EtherEZ (8416)

 Stato: Supportata, Nome del driver: smc-ultra (+8390)

 Questa scheda usa il chip 83c795 della SMC e supporta le specifiche
 Plug 'n Play.  Ha anche una modalit� SMC Ultra compatibile, che le
 permette di essere usata con il driver Ultra per Linux. Per migliori
 risultati si usi il programma fornito dalla SMC (disponibile nel loro
 sito www/ftp) per disabilitare il PnP e configurarla per la modalit� a
 memoria condivisa.  Si vedano le informazioni precedenti per alcune
 note sul driver Ultra.

 Per i kernel v1.2, la scheda ha dovuto essere configurata per l'uso a
 memoria condivisa.  Comunque i kernel v2.0 possono usare la scheda in
 modalit� a memoria condivisa o I/O programmato.  La modalit� a memoria
 condivisa � leggermente pi� veloce e usa anche meno risorse di CPU.


 5.35.6.  SMC EtherPower PCI (8432)

 Stato: Supportata, Nome del driver: de4x5, tulip

 NB: La EtherPower II � una scheda completamente diversa. Si veda
 sotto!  Queste schede sono un'implementazione base del 21040 della
 DEC, cio� un unico grosso chip e una coppia di transceiver.  Donald ha
 usato una di queste schede per lo sviluppo del driver 21040 generico
 (meglio noto come tulip.c).  Grazie a Duke Kamstra, ancora una volta,
 per aver fornito una scheda sulla quale fare lo sviluppo.

 Alcune delle ultime revisioni di questa scheda usano il pi� recente
 chip 21041 della DEC, che pu� causare problemi con versioni pi�
 vecchie del driver tulip. Se si hanno problemi ci si assicuri di usare
 l'ultima versione del driver, che potrebbe non essere ancora stata
 inclusa nell'attuale albero dei sorgenti del kernel.

 Si veda ``DEC 21040'' per ulteriori dettagli sull'uso di una di queste
 schede e sullo stato attuale del driver.

 Apparentemente, l'ultima revisione delle scheda, la EtherPower-II usa
 il chip 9432.  Al momento non � chiaro se questa funzioner� con il
 driver attuale.  Come sempre, se non si � sicuri, si verifichi di
 poter restituire la scheda se non funziona con il driver per Linux
 prima di pagarla.


 5.35.7.  SMC EtherPower II PCI (9432)

 Stato: Semi supportata, Nome del driver: epic100

 Queste schede, basate sul chip 83c170 della SMC, sono completamente
 differenti da quelle basate sul TULIP.  Un nuovo driver � stato
 incluso nei kernel v2.0 e v2.2 per supportare queste schede.  Per
 ulteriori dettagli si veda:

 http://cesdis.gsfc.nasa.gov/linux/drivers/epic100.html



 5.35.8.  SMC 3008

 Stato: Non supportata.

 Queste schede a 8 bit sono basate sul Fujitsu MB86950, che � un'antica
 versione del MB86965 usato dal driver at1700 per Linux.  Russ dice che
 probabilmente si pu� metter su un driver guardando il codice at1700.c
 e il suo packet driver DOS per la scheda Tiara (tiara.asm). Non sono
 molto comuni.


 5.35.9.  SMC 3016

 Stato: Non Supportata.

 Queste sono scheda 8390 a 16 bit ad I/O mappato, molto simili ad una
 generica scheda NE2000.  Se si riescono ad ottenere le specifiche
 dalla SMC, allora il porting del driver NE2000 probabilmente sar�
 abbastanza facile.  Non sono molto comuni.


 5.35.10.  SMC-9000 / SMC 91c92/4

 Stato: Supportata, Nome del driver: smc9194

 La SMC9000 � una scheda VLB basata sul chip 91c92.  Il 91c92 sembra
 essere presente anche su un po' di schede di altre marche, ma �
 abbastanza poco comune.  Erik Stahlman ([email protected]) ha scritto questo
 driver presente nei kernel v2.0, ma non nei pi� vecchi kernel v1.2.
 Si dovrebbe essere in grado di mettere il driver nell'albero dei
 sorgenti v1.2 con poche difficolt�.


 5.35.11.  SMC 91c100

 Stato: Semi supportata, Nome del driver: smc9194

 Si pensa che il driver SMC 91c92 funzioni per le schede basate su
 questo chip 100Base-T, ma al momento la cosa non � stata verificata.


 5.36.  Texas Instruments



 5.36.1.  ThunderLAN

 Stato: Supportata, Nome del driver: tlan

 Questo driver gestisce i molti dispositivi Ethernet built-in della
 Compaq, compresi i gruppi NetFlex e Netelligent.  Supporta anche i
 prodotti Olicom 2183, 2185, 2325 e 2326.


 5.37.  Thomas Conrad





 5.37.1.  Thomas Conrad TC-5048


 Questa � un'altra scheda PCI basata sul chip 21040 della DEC.

 Si veda la sezione sul chip 21040 (``DEC 21040'') per maggiori
 informazioni.


 5.38.  VIA


 Probabilmente non si vedr� mai una scheda di rete VIA, in quanto la
 VIA costruisce diversi chip usati da altri per costruire le loro
 schede Ethernet.  Hanno un sito WWW a:

 http://www.via.com.tw/


 5.38.1.  VIA 86C926 Amazon

 Stato: Supportato, Nome del driver: ne, ne2k-pci (+8390)

 Questo chip � quanto offre la VIA come PCI-NE2000.  Si pu� scegliere
 tra il driver ne.c per ISA e PCI o il driver solo per PCI ne2k-pci.c.
 Si veda la sezione sul PCI-NE2000 per ulteriori informazioni.


 5.38.2.  VIA 86C100A Rhine II (and 3043 Rhine I)

 Stato: supportato, Nome del driver: via-rhine

 Questo driver relativamente nuovo pu� essere trovato negli attuali
 kernel 2.0 e 2.1.  � un miglioramento rispetto al chip NE2000 86C926
 nel fatto che supporta i trasferimenti bus master, ma gli stretti
 requisiti sull'allineamento al bit 32 del buffer limitano i benefici
 guadagnati da ci�.  Per maggiori dettagli e driver aggiornati si veda:

 http://cesdis.gsfc.nasa.gov/linux/drivers/via-rhine.html



 5.39.  Western Digital


 Si veda la sezione ``SMC'' per informazioni sulle schede SMC (la SMC
 ha comprato la divisione delle schede di rete della Western Digital
 molti anni fa).


 5.40.  Winbond


 La Winbond in realt� non costruisce e vende schede complete al
 pubblico, piuttosto costruisce soluzioni Ethernet su un unico chip che
 altre compagnie comprano e mettono nelle loro schede PCI con il loro
 nome che poi vendono nei negozi.


 5.40.1.  Winbond 89c840

 Stato: Semi supportato, Nome del driver: winbond-840

 Questo driver attualmente non � distribuito con il kernel, poich� � in
 fase di test.  � disponibile a:

 http://cesdis.gsfc.nasa.gov/linux/drivers/test/winbond-840.c


 5.40.2.  Winbond 89c940

 Stato: Supportato, Nome del driver: ne, ne2k-pci (+8390)

 Questo chip � uno dei due pi� comunemente presenti sulle schede ne2000
 PCI a basso costo vendute da un sacco di costruttori.  Si noti che
 questo � sempre un progetto vecchio di dieci anni adattato ad un bus
 PCI.  Le prestazioni non saranno tanto migliori rispetto a quelle
 dell'equivalente modello ISA.


 5.41.  Xircom


 Per lungo tempo, la Xircom non ha voluto rilasciare la informazioni di
 programmazione necessarie per scrivere un driver, a meno che non si
 firmasse per averle.  Apparentemente abbastanza utenti Linux li hanno
 subbissati di richieste di supporto per il driver (affermano di
 supportate tutti i pi� popolari sistemi operativi di rete...) e quindi
 hanno cambiato la loro politica e hanno permesso il rilascio di
 documentazione senza dover firmare un accordo di non rivelazione.  Ad
 alcuni hanno detto che avrebbero rilasciato il codice sorgente del
 driver SCO, mentre ad altri hanno detto che non forniscono pi�
 informazioni su prodotti `obsoleti' come i primi modelli PE.  Se si �
 interessati e si vogliono verificare da s� queste cose, si pu�
 contattare la Xircom al 1-800-874-7875, 1-800-438-4526 o
 +1-818-878-7600.


 5.41.1.  Xircom PE1, PE2, PE3-10B*

 Stato: Non supportate.

 Non per dare tante speranze, ma se si ha uno di questi adattatori per
 porta parallela, si pu� riuscire ad usarlo nell'emulatore DOS con i
 driver per DOS forniti dalla Xircom.  Si deve permettere a DOSEMU di
 accedere alla propria porta parallela e probabilmente si dovr� giocare
 un po' con SIG (Silly Interrupt Generator di DOSEMU).


 5.41.2.  Schede PCMCIA Xircom

 Stato: Semi-supportate, Nome del driver: ????

 Per alcune delle schede PCMCIA della Xircom esistono dei driver
 disponibili nel pacchetto PCMCIA di David Hinds.  Si veda in questo
 per informazioni pi� aggiornate.


 5.42.  Zenith



 5.42.1.  Z-Note

 Stato: Supportata, Nome del driver: znet

 L'adattatore di rete built-in Z-Note � basato su un i82593 dell'Intel
 ed usa due canali DMA.  Esiste un driver (sperimentale?)  nell'attuale
 versione del kernel.   Come tutti gli adattatori pocket e per
 notebook, quando si esegue make config lo si trova nella sezione
 `Pocket and portable adaptors'.  Si noti che il ThinkPad 300 dell'IBM
 � compatibile con Z-Note.
 5.43.  Znyx



 5.43.1.  Znyx ZX342 (DEC 21040 based)

 Stato: Supportata, Nome del driver: de4x5, tulip

 Si ha la scelta fra due driver per le schede basate su questo chip.
 C'� un driver DE425 scritto da David e il driver generico per 21040
 che ha scritto Donanld.

 Si noti che dal 1.1.91, David ha aggiunto una opzione di compilazione
 che pu� permettere alle schede non DEC (come quella della Znyx) di
 funzionare con il suo driver.  Si veda il file README.de4x5 per i
 dettagli.

 Si veda la sezione ``DEC 21040'' per maggiori informazioni su queste
 schede e la situazione attuale del driver.


 5.44.  Identificare una scheda sconosciuta


 Bene, e cos� l'amico del vicino del cugino di vostro zio ha un
 fratello che ha trovato una vecchia scheda Ethernet ISA in un case AT
 che usava come gabbia per criceti di suo figlio.  In qualche modo
 questa scheda vi � capitata tra le mani e la volete  usare con Linux,
 ma nessuno ha idea di che scheda sia e non c'� alcuna documentazione.

 Per prima cosa, si cerchi un qualsiasi numero del modello che potrebbe
 essere un indizio.  Qualsisi numero di modello che contiene 2000
 potrebbe essere un clone della NE2000.  Qualsiasi scheda con 8003 o
 8013 da qualche parte sar� una scheda Western/Digital WD80x3 o una SMC
 Elite o un clone di una di esse.


 5.44.1.  Identificare il Network Interface Controller

 Si cerchi il chip pi� grosso nella scheda. Sar� il network controller
 (NIC) e la maggior parte pu� essere identificata dal numero.  Se si sa
 quale NIC c'� sulla scheda, quanto segue pu� aiutare ad scoprire che
 scheda �.

 Probabilmente il NIC ancora pi� comune � il DP8390 della National
 Semiconductor, noto anche come NS32490, DP83901, DP83902, DP83905 e/o
 DP83907.  E questi sono solo quelli fatti dalla National! Altre
 compagnie, come la Winbond e la UMC, costruiscono cloni del DP8390 e
 del DP83905, come il Winbond 89c904 (clone del DP83905) e l'UMC 9090.
 Se la scheda ha su una qualche forma di 8390, allora � possibile che
 sia un clone della ne1000 o della ne2000.  Le seconde schede pi�
 comuni basate su 8390 sono le schede wd80x3 e cloni.  Le schede con un
 DP83905 possono essere configurate come una ne2000 o come una wd8013.
 Le versioni pi� nuove delle schede wd80x3 genuine e delle SMC Elite
 hanno un 83c690 al posto del DP8390 originale.  Le schede SMC Ultra
 hanno un 83c790 ed usano un driver leggermente diverso dalle schede
 wd80x3.  Le schede SMC EtherEZ hanno un 83c795 ed usano lo stesso
 driver della SMC Ulta.  Tutte le schede con BNC basate su una qualche
 versione di 8390 o di un suo clone solitamente avranno un chip DIP a
 16 pin 8392 (o un 83c692, o un ???392) molto vicino al connettore BNC.

 Un altro NIC comune presente sulle schede pi� vecchie � l'Intel
 i82586.  Le schede che hanno questo NIC includono le 3c505, 3c507,
 3c523, Intel EtherExpress-ISA, Microdyne Exos-205T e la Racal-Interlan
 NI5210.

 Il NIC LANCE originale dell'AMD era numerato AM7990 e le revisioni pi�
 nuove includono i 79c960, 79c961, 79c965, 79c970 e 79c974.  La maggior
 parte delle schede con uno di questi funzioner� con il driver LANCE di
 Linux, ad eccezione delle vecchie schede Racal-Interlan NI6510 che
 hanno il loro driver apposito.

 Le schede PCI pi� nuove che hanno un DEC 21040, 21041, 21140 o un
 numero simile sul NIC dovrebbero essere in grado di usare il driver
 tulip o il de4x5.

 Altre schede PCI che hanno un grosso chip marchiato RTL8029 o 89C940 o
 86C926 sono cloni ne2000 e il driver nelle versioni di Linux 2.0 e
 superiori dovrebbe automaticamente rilevarle al boot.


 5.44.2.  Identificare l'indirizzo Ethernet

 Ogni scheda Ethernet ha il suo indirizzo personale ed unico a sei
 byte.  I primi tre byte di quell'indirizzo sono gli stessi per ogni
 scheda fatta da un particolare costruttore.  Per esempio tutte le
 schede SMC partono con 00:00:c0.  Gli ultimi tre sono assegnati dal
 costruttore univocamente ad ogni scheda che produce.

 Se la propria scheda ha un etichetta che d� tutti i 6 byte del suo
 indirizzo si pu� risalire al costruttore dai primi tre.  Comunque �
 pi� comune vedere solo gli ultimi tre byte stampati su un'etichetta
 attaccata alla PROM che non dir� niente.

 Si pu� determinare a quale rivenditore � stato assegnato un
 determinato indirizzo dall'RFC 1340.  Apparentemente in giro ci sono
 anche elenchi pi� aggiornati.  Si provi a fare una ricerca WWW o FTP
 di EtherNet-codes o Ethernet-codes e qualcosa si trover�.


 5.44.3.  Suggerimenti per provare ad usare una scheda sconosciuta


 Se non si � ancora sicuri di che scheda sia ma si � un po' ristretta
 la cerchia delle possibilit�, allora si pu� compilare un kernel con
 una serie di driver al suo interno e vedere se uno di essi rileva
 automaticamente la scheda al boot.

 Se il kernel non rileva la scheda, potrebbe essere che la scheda non �
 configurata ad uno degli indirizzi che i driver controllano quando
 cercano una scheda.  Se questo � il caso, si pu� provare a scaricare
 scanport.tar.gz da un sito ftp di Linux e vedere se pu� scoprire a che
 indirizzo � configurata.  Scansiona lo spazio I/O ISA da 0x100 a 0x3ff
 cercando dispositivi che non sono registrati in /proc/ioports.  Se
 trova un dispositivo sconosciuto ad un qualche indirizzo particolare,
 si pu� esplicitamente indirizzare il controllo a quell'indirizzo con
 un comando ether= al boot.

 Se si � riusciti a far rilevare la scheda, allora solitamente si pu�
 scoprire cosa fanno i ponticelli combiandone uno alla volta e vedendo
 a quale I/O base e IRQ la scheda viene poi rilevata.  Le impostazioni
 dell'IRQ possono essere determinate anche seguendo le tracce sul retro
 della scheda da dove sono saldati i ponticelli.  Contando i contatti
 dorati nel retro della scheda partendo dalla parte della scheda con la
 linghetta di metallo si troveranno gli IRQ 9, 7, 6, 5, 4, 3, 10, 11,
 12, 15, 14 rispettivamente nei contatti 4, 21, 22, 23, 24, 25, 34, 35,
 36, 37, 38.  Le schede a 8 bit hanno solo fino al contatto 31.

 I ponticelli che sembra non facciano niente solitamente servono per
 selezionare l'indirizzo di memoria della ROM di boot opzionale.  Altri
 ponticelli posizionati nei pressi dei connettorei BNC o RJ-45 o AUI
 solitamente servono per selezionare il mezzo d'uscita.  Tipicamente
 questi sono anche vicino allo `scatolotto nero' del convertitore di
 tensione marchiato YCL, Valor o Fil-Mag.

 Un bella collezione di impostazioni di ponticelli per diverse schede
 pu� essere trovata a:

 Ethercard Settings <http://www.slug.org.au/NIC/>



 5.45.  Driver per i dispositivi non Ethernet


 Ci sono alcuni altri driver nei sorgenti di Linux che si presentano ai
 programmi di rete come dispositivi simil-Ethernet, anche se non sono
 veramente Ethernet.  Per completezza sono qui brevemente elencati.

 dummy.c -- Lo scopo di questo driver � di fornire un dispositivo al
 quale far puntare un instradamento, ma che non trasmette realmente
 pacchetti.

 eql.c -- Load Equalizer (Equalizzatore di carico), schiavizza pi�
 dispositivi (solitamente modem) e bilancia il carico di trasmissione
 tra essi presentandoli come un unico dispositivo ai programmi di rete.

 ibmtr.c -- IBM Token Ring, che non � veramente Ethernet.  Broken-Ring
 necessita dell'instramento source e di altre brutte cose.

 loopback.c -- Dispositivo loopback al quale vanno tutti i pacchetti
 destinati alla macchina e partenti da questa.  Essenzialmente sposta
 semplicemente il pacchetto dalla coda TX nella coda RX.

 pi2.c -- Interfacce PI e PI2 dell'Ottawa Amateur Radio Club.

 plip.c - Parallel Line Internet Protocol, permette a due computer di
 inviarsi pacchetti attraverso le porte parallele connesse in maniera
 point-to-point (punto a punto).

 ppp.c -- Point-to-Point Protocol (RFC1331), per la trasmissione dei
 datagrammi multiprotocollo su una connessione Point-to-Point Link
 (solitamente modem).

 slip.c -- Serial Line Internet Protocol, permette a due computer di
 inviarsi pacchetti attraverso le porte seriali (solitamente via modem)
 connesse in maniera point-to-point (punto a punto).

 tunnel.c -- Fornisce un tunnel IP attraverso il quale si pu�
 incanalare il traffico di rete in maniera trasparente tra le
 sottoreti.

 wavelan.c -- Un transceiver radio tipo Ethernet controllato da un
 coprocessore Intel 82586 usato su altre schede Ethernet come la Intel
 EtherExpress.


 6.  Cavi, coassiali, doppini intrecciati

 Se si sta mettendo su una nuova rete, si dovr� decidere se usare thin
 Ethernet (cavo coassiale RG58 con connettori BNC) o 10baseT (cavi tipo
 telco a doppini intrecciati con connettori `telefonici' RJ-45 a otto
 vie).  La vecchia thick Ethernet, con cavi RG-5 a N connettori, �
 obsoleta e si vede poco in giro.

 Si veda ``Tipi di cavi...'' per una panoramica introduttiva ai cavi.
 Si noti inoltre che la FAQ di comp.dcom.lans.ethernet contiene un
 sacco di informazioni utili sui cavi e robe simili.  Si faccia FTP a
 rtfm.mit.edu e si cerchi nella directory /pub/usenet-by-hierarchy/ la
 FAQ di quel newsgroup.


 6.1.  Thin Ethernet (thinnet)


 Il cavo thin Ethernet � abbastanza economico.  Se si vuole farsi da
 soli i cavi, l'RG58A a solid-core costa $0.27/m mentre l'RG58AU
 stranded  � a $0.45/m.  I connettori BNC twist-on costano meno di due
 dollari l'uno e altri pezzi vari sono attrettanto economici.  �
 essenziale terminare correttamente ciascun capo del cavo con
 terminatori da 50 Ohm, che costano due dollari alla coppia.  �
 altrettanto vitale che il cavo non sia formato da pi� spezzoni: il
 connettore a `T' dev'essere attaccato direttamente alle schede
 Ethernet.

 Ci sono due svantaggi principali ad usare la thinnet.  Il primo � che
 � limitata a 10Mb/sec: i 100Mb/sec richiedono il doppino intrecciato.
 Il secondo svantaggio che se si ha un grande anello di macchine
 connesse assieme e qualche testone interrompe l'anello staccando un
 cavo da un connettore a T, l'intera rete va gi� perch� vede
 un'impedenza infinita (circuito aperto) invece dei 50 Ohm richiesti
 come terminazione.  Si noti che si pu� rimuovere la T stessa dalla
 scheda senza uccidere l'intera sottorete, purch� non si stacchino i
 cavi dalla T.  Naturalmente questa cosa disturber� la macchina dalla
 quale si � tolto il connettore a T 8-) Se se si sta facendo una
 piccola rete di due macchine, sono ancora necessari sia il connettore
 a T che i terminatori da 50 Ohm: non si pu� semplicemente connettere
 le due macchine assieme!


 Ci sono anche dei simpatici sistemi di cavi che apparentemente
 sembrano un unico cavo, ma in realt� il cavo fa un giro da parte a
 parte dentro il rivestimento esterno, dando al cavo quella tipica
 sezione ovale.  Nel punto dove torna indietro l'anello � messo un
 connettore BNC che si pu� connettere alla propria scheda.   Quindi si
 ha l'equivalente di due cavi e un BNC a T, ma in questo caso �
 impossibile per l'utilizzatore rimuovere un cavo da un lato della T e
 disturbare la rete.



 6.2.  Doppino intrecciato (twisted pair)


 Le reti a doppini intrecciati necessitano di hub (concentratori)
 attivi, che costano attorno ai $50 e il costo reale del semplice cavo
 pu� essere pi� alto di quello necessario per la thinnet.  Si pu�
 tranquillamente ignorare quelli che dicono che si pu� usare il
 cablaggio telefonico gi� esistente visto che dove c'� � una rara
 installazione.

 D'altra parte, tutte le specifiche Ethernet a 100Mb/sec usano doppini
 intrecciati e sono usati pure nella maggior parte delle nuove
 installazioni.  Inoltre, Russ Nelson aggiunge che �Le nuove
 installazioni dovrebbero usare cavi di categoria 5.  Qualsiasi altra
 cosa spreca il proprio tempo, in quanto un 100Base-qualsiasi
 richieder� cavi categoria 5.�

 Se si sta solamente connettendo macchine, � possibile evitare l'uso di
 un hub, scambiando le coppie Rx e Tx (1-2 e 3-6).

 Se si guarda il connettore RJ-45 (come se lo si stesse connettendo
 nella propria bocca) con il gancetto di bloccaggio in alto, allora i
 pin sono numerati da 1 a 8 da sinistra verso destra.  L'uso dei pin �
 il seguente:


         Numero Pin              Assegnamento
         ----------              ------------
         1                       Output Data (+)
         2                       Output Data (-)
         3                       Input Data (+)
         4                       Riservato per l'uso telefonico
         5                       Riservato per l'uso telefonico
         6                       Input Data (-)
         7                       Riservato per l'uso telefonico
         8                       Riservato per l'uso telefonico



 Se si vuole fare un cavo, quanto segue vi torner� utile.  Le coppie di
 segnali differenziali devono essere nella stessa coppia intrecciata
 per ottenere la minima impendenza/perdita richiesta di un cavo UTP.
 Se si guarda la tabella precedente, si vedr� che 1+2 e 3+6 sono i due
 insiemi di coppie di segnali differenziali.  Non 1+3 e 2+6!!!!!!  A
 10MHz e basse distanze, si pu� ancora far qualcosa con questi errori.
 Ma non ci si pensi nemmeno lontanamente a 100Mhz.

 Per un normale cavo con terminazioni `A' e `B', si deve usare la
 mappatura diretta pin a pin, con l'ingresso e l'uscita che usano
 ciascuna una coppia di doppini intrecciati (per esigenze di
 impedenza). Questo significa che 1A va a 1B, 2A a 2B, 3A a 3B e 6A a
 6B. I cavetti che collegano 1A-1B e 2A-2B devono essere un doppino
 intrecciato. Ed anche i cavetti che collegano 3A-3B e 6A-6B devono
 essere un'altro doppino intrecciato.

 Ora se non si ha un hub e si vuole fare un `null cable', quel che si
 deve fare � rendere l'ingresso di `A' l'uscita di `B' e l'uscita di
 `A' l'ingresso di `B', senza cambiare la polarit�. Questo significa
 connettere 1A a 3B (out+ di A a in+ di B) e 2A a 6B (out- A a in- B).
 Queste due connessioni devono essere un doppino intrecciato.
 Trasportano quel che la scheda/spina `A' considera l'uscita e quel che
 � visto come ingresso dalla scheda/spina `B'. Poi si connetta 3A a 1B
 (in+ A a out+ B) e si connetta anche 6A a 2B (in- A a out- B). Anche
 queste due connessioni devono essere un doppino intrecciato.
 Trasportano quel che la scheda/spina `A' considera ingresso e quel che
 la scheda/spina `B' considera uscita.

 Quindi se si considera un normale cavo per avere un cavo `null', si
 tagli via uno dei capi, si scambino di posto i doppini intrecciati di
 Rx e Tx nella nuova spina e la si chiuda. Niente di complicato. Si
 deve semplicemente portare il segnale Tx di una scheda nel Rx
 dell'altra e viceversa.

 Si noti che prima che il 10BaseT fosse ratificato come standard,
 c'erano altri formati di rete che usavano connettori RJ-45 e lo stesso
 schema di connessione appena visto.  Esempi sono la LattiNet della
 SynOptics e la StarLAN dell'AT&T.  In alcuni casi (come con le prime
 schede 3c503) si potevano impostare dei ponticelli per far s� che la
 scheda dialogasse con hub di diverso tipo, ma la maggior parte delle
 schede progettate per questi vecchi tipi di reti non funzioneranno con
 le reti/hub 10BaseT (si noti che se la scheda ha anche una porta AUI,
 allora non c'� alcuna ragione per non usarla assieme con un
 transceiver da AUI a 10BaseT).


 6.3.  Thick Ethernet

 La thick Ethernet � praticamente obsoleta e solitamente � usata solo
 per mantenere la compatibilit� con un'installazione preesistente.  Si
 pu� fare uno strappo alle regole e connettere thick e thin Ethernet
 assieme con un connettore passivo N-to-BNC da 3 dollari, spesso la
 miglior soluzione per espandere una thicknet gi� esistente.  In questo
 caso una soluzione corretta (ma pi� costosa) sarebbe di usare un
 ripetitore (repeater).

 7.  Configurazione del software e diagnotici


 In molti casi, se la configurazione viene fatta via software e salvata
 poi in una EEPROM, si dovr� avviare DOS e usare il programma per DOS
 fornito dal rivenditore per impostare IRQ, I/O, indirizzo di memoria e
 altre robette della scheda.  D'altra parte � auspicabile che questa
 sia una cosa che si dovr� fare solo una volta.  Se non si ha il
 software per DOS della propria scheda, si provi a guardare nel sito
 WWW del produttore.  Se non si conosce il nome del sito si provi ad
 indovinarlo, per esempio `www.produttore.com' dove `produttore' � il
 nome del produttore della propria scheda.  Questa cosa funziona per la
 SMC, la 3Com e molti molti altri produttori.

 Per alcune schede esistono le versioni Linux delle utilit� di
 configurazione e sono qui elencate.  Donald ha scritto alcuni piccoli
 programmi per Linux di diagnostica per le schede.  La maggior parte di
 questi sono il prodotto finale di strumenti di debug che ha creato
 durante la scrittura dei diversi driver.  Non ci si aspettino
 interfacce a menu carine.  Per poterli usare nella maggioranza dei
 casi sar� necessario leggere il codice sorgente.  Anche se per la
 propria particolare scheda non esiste un diagnostico, si possono
 ottenere comunque alcune informazioni digitando semplicemente cat
 /proc/net/dev (assumendo che all'avvio la propria scheda sia stata
 almeno rilevata).

 In tutti i casi, si dovr� usare la maggior parte di questi programmi
 come root (per permettere l'I/O nelle porte) e prima di farlo �
 consigliabile disattivare la scheda Ethernet usando ifconfig eth0
 down.


 7.1.  Programmi di configurazione per le schede Ethernet



 7.1.1.  Schede WD80x3


 Per quanti hanno schede wd80x3, c'� il programma wdsetup che pu�
 essere trovato nel file wdsetup-0.6a.tar.gz nei siti ftp su Linux.
 Non � mantenuto attivamente e non � aggiornato da un po' di tempo.  Se
 nel proprio caso funziona, allora bene; se non funziona, si usi la
 versione DOS che si dovrebbe aver ricevuto con la scheda.  Se non si
 ha la versione DOS, si sar� felici di sapere che i dischetti
 aggiornati di configurazione e dei driver possono essere scaricati dal
 sito ftp della SMC.  Natualmente, si deve possedere una scheda con la
 EEPROM per usare questo programma.  Le vecchie, ma proprio vecchie,
 schede wd8003 e alcuni cloni del wd8013 per configurare la scheda
 usano dei ponticelli.


 7.1.2.  Schede Digital/DEC


 La scheda Digital EtherWorks 3 pu� essere configurata in maniera
 simile che con il programma DOS NICSETUP.EXE.  David C. Davies ha
 scritto, assieme al driver, questo progrmma e altri strumenti per la
 EtherWorks 3.  Si cerchi nella directory
 /pub/linux/system/Network/management nel sito FTP su Linux pi� vicino,
 il file chiamato ewrk3tools-X.XX.tar.gz.


 7.1.3.  Schede NE2000+ o AT/LANTIC


 Alcune implementazioni del DP83905 della National Semiconductor (come
 le AT/LANTIC e le NE2000+) sono configurabili via software (si noti
 che queste schede emulano anche una wd8013!).  Per configurare queste
 schede si pu� scaricare il file /pub/linux/setup/atlantic.c dal server
 ftp di Donald, cesdis.gsfc.nasa.gov.  Inoltre, con tutte queste schede
 sembra funzionare anche il programma per le schede DP83905 della
 Kingston, poich� non fa controlli sul tipo di rivenditore prima di
 permetterne l'uso.  Si segua l'URL seguente: Kingston Software
 <http://www.kingston.com/download/etherx/etherx.htm> e si scarichi
 20XX12.EXE e INFOSET.EXE.

 Si faccia attenzione quando si configurano schede NE2000+, poich�
 alcune impostazioni errate possono causare problemi.  Un esempio
 tipico � l'abilitazione accindentale della ROM di boot nella EEPROM
 (anche se la ROM non � installata) con una impostazione che va in
 conflitto con la scheda VGA.  Il risultato � che il computer
 semplicemente fa beep quando lo si accende e sullo schermo non succede
 niente.

 Solitamente si pu� risolvere questa situazione nel modo seguente.  Si
 rimuova la scheda dalla macchina e poi si riavvii e si entri nel menu
 di configurazione del BIOS.  Si cambi la voce `Display Adapter' in
 `Not Installed' e si imposti il disco di avvio di default in `A:' (il
 proprio lettore di floppy).  Si cambi anche la voce `Wait for F1 if
 any Error' in `Disabled'.  In questo modo, il computer dovrebbe
 avviarsi senza l'intervento dell'utente.  Ora si crei un dischetto DOS
 avviabile (`format a: /s /u') e si copi dentro il floppy il programma
 default.exe dell'archivio 20XX12.EXE suddetto.  Poi si digiti echo
 default > a:autoexec.bat in modo tale che il programma che reimposta i
 valori predefiniti della scheda sia eseguito automaticamente quando si
 avvia da questo dischetto.  Si spenga la macchina, si reinstalli la
 scheda ne2000+, si inserisca il nuovo dischetto di boot e la si
 riaccenda.  Probabilmente far� ancora beep, ma alla fine si dovrebbe
 vedere la lucetta del floppy che si accende quando finalmente fa il
 boot.  Si aspetti un paio di minuti che il floppy si fermi, il che
 indica che ha finito di eseguire il programma default.exe e poi si
 spenga il computer.  Dopo lo si riaccenda ancora e teoricamente si
 dovrebbe avere ancora un display che funziona, permettendo cos� di
 risistemare le impostazioni del BIOS e modificare i valori della
 EEPROM della scheda come si vuole.

 Si noti che se non si ha DOS sotto mano, si pu� fare tutto quello
 sopra con un dischetto di avvio di Linux che lancia automaticamente il
 programma atlantic di Donald (con le giuste opzioni d'avvio) invece
 che con un dischetto di avvio di DOS che lancia automaticamente il
 programma default.exe.


 7.1.4.  Schede 3Com


 La famiglia di schede Etherlink III della 3Com (p.es. 3c5x9) pu�
 essere configurata usando un'altra utilit� di configurazione di
 Donald.  Per configurarle si pu� scaricare il file
 /pub/linux/setup/3c5x9setup.c dal server ftp di Donald,
 cesdis.gsfc.nasa.gov (si noti che il programma DOS di configurazione
 3c5x9B pu� avere pi� opzioni pertinenti alla nuova serie ``B'' della
 famiglia Etherlink III).


 7.2.  Programmi diagnostici per schede Ethernet


 Tutti i programmi diagnostici scritti da Donald possono essere
 ottenuti da questo URL:

 Ethercard Diagnostics
 <ftp://cesdis.gsfc.nasa.gov/pub/linux/diag/index.html>

 Allied Telesis AT1700: si cerchi il file /pub/linux/diag/at1700.c su
 cesdis.gsfc.nasa.gov.

 Cabletron E21XX: si cerchi il file /pub/linux/diag/e21.c su
 cesdis.gsfc.nasa.gov.

 P PCLAN+: si cerchi il file /pub/linux/diag/hp+.c su
 cesdis.gsfc.nasa.gov.

 Intel EtherExpress: si cerchi il file /pub/linux/diag/eexpress.c su
 cesdis.gsfc.nasa.gov.

 Schede NE2000: si cerchi il file /pub/linux/diag/ne2k.c su
 cesdis.gsfc.nasa.gov.  C'� ancora una versione PCI per gli ormai
 comuni cloni della NE2000-PCI.

 RealTek (ATP) Pocket adaptor: si cerchi il file /pub/linux/diag/atp-
 diag.c su cesdis.gsfc.nasa.gov.

 Tutte le altre schede: si provi a digitare cat /proc/net/dev e dmesg
 per vedere quali informazioni utili possiede il kernel sulla scheda in
 oggetto.


 8.  Informazioni tecniche

 Queste informazioni saranno utili a quanto vogliono capire un po'
 meglio come funziona la loro scheda, oppure vogliono giocare con il
 driver o anche provare a fare il loro driver personale per una scheda
 che attualmente non � supportata.  Se non si cade in queste categorie,
 allora si pu� pure saltare questa sezione.


 8.1.  I/O programmato, memoria condivisa e DMA a confronto

 Se gi� si ricevono e inviano pacchetti back-to-back (NdT letteralmente
 ``uno dopo l'altro''), non si possono mettere altri bit nel cavo.
 Ogni scheda Ethernet moderna pu� ricevere pacchetti back-to-back.  I
 driver per Linux per DP8390 (wd80x3, SMC-Ultra, 3c503, ne2000, ecc.)
 arrivano abbastanza vicino all'invio di pacchetti back-to-back (il
 limite � dato dalla reale latenza degli interrupt) e l'hardware 3c509
 e AT1500 non ha problemi ad inviare automaticamente pacchetti back-to-
 back.

 Il bus ISA pu� fare 5.3MB/sec (42Mb/sec), che sembra pi� che
 sufficiente per una Ethernet a 10Mbps.  Nel caso di schede a 100Mpbs,
 chiaramente � necessario un bus pi� veloce per sfruttare la larghezza
 di banda della rete.


 8.1.1.  I/O programmato (Programmed I/O) (es. NE2000, 3c509)

 Pro: Non usa nessuna risorsa di sistema riservata, solo alcuni
 registri di I/O e non ha il limite dei 16M.

 Contro: Solitamente pi� bassa � la velocit� di trasferimento, pi� la
 CPU attende senza far niente, e l'accesso ai pacchetti interleaved �
 solitamente difficile se non impossibile.


 8.1.2.  Memoria condivisa (Shared memory) (es. WD80x3, SMC-Ultra,
 3c503)

 Pro: Pi� veloce e semplice dell'I/O programmato e inoltre permette
 l'accesso casuale ai pacchetti. Dove possibile, i driver per Linux
 calcolano il checksum dei pacchetti IP in ingresso non appena sono
 copiati fuori dalla scheda. Tale cosa risulta in un'ulteriore
 riduzione dell'uso della CPU rispetto ad una equivalente scheda PIO.

 Contro: Usa maggiore spazio di memoria (molto grande per gli utenti
 DOS, essenzialmente non problematico sotto Linux) e usa ancora
 parecchio la CPU.


 8.1.3.  Accesso diretto alla memoria (DMA) di tipo slave (normale)
 (non per Linux!)

 Pro: Libera la CPU durante il reale trasferimento dei dati.

 Contro: Il controllo delle condizioni al contorno, l'allocazione di
 buffer contigui e la programmazione dei registri DMA la rende la
 tecnica pi� lenta fra tutte.  Inoltre satura facilmente un canale DMA
 e richiede buffer allineati in memoria bassa.


 8.1.4.  Accesso diretto alla memoria (DMA) di tipo bus master (es.
 LANCE, DEC 21040)

 Pro: Libera la CPU durante il trasferimento dei dati, pu� legare
 assieme i buffer, nel bus ISA pu� richiede una piccola (nulla) perdita
 del tempo di CPU. La maggior parte dei driver per Linux bus-master
 usano lo schema `copybreak' nel quale i grossi pacchetti sono messi
 direttamente dalla scheda nel buffer di rete del kernel, e i pacchetti
 piccoli sono copiati invece dalla CPU che li carica in cache per le
 eleborazioni successive.

 Contro: (Applicabile solamente alle schede per bus ISA) Per la scheda
 sono necessari buffer in memoria bassa e di canali DMA. Qualsiasi
 dispositivo bus-master avr� problemi con altri dispositivi non bus-
 master che si appropriano del bus, come alcuni primitivi adattatori
 SCSI. Alcuni chipset delle schede madri mal progettati hanno problemi
 con il bus-master. Una ragione per non usare alcun tipo di dispositivo
 DMA � un processore 486 progettato come rimpiazzo di un 386: questi
 processori devono scaricare la loro cache ad ogni ciclo di DMA (fra
 questi ci sono Cx486DLC, Ti486DLC, Cx486SLC, Ti486SLC, ecc.)


 8.2.  Scrivere un driver


 La sola cosa che serve per usare una scheda Ethernet con Linux � il
 driver appropriato.  Per questo � essenziale che i costruttori
 rilascino le informazioni tecniche di programmazione al pubblico senza
 che qualcuno debba vendersi per vita per averle.  Un buon esempio
 sulla possibilit� di ottenere documentazione (oppure se non si sta
 scrivendo codice, sulla possibilit� che qualcun'altro scriver� quel
 driver di cui si ha veramente bisogno) � la disponibilit� del packet
 driver Crynwr (nato Clarkson). Russ Nelson guida questa operazione ed
 � stato molto d'aiuto nel supportare lo sviluppo dei driver per Linux.
 I net-surfer possono provare questo URL per vedere il software di
 Russ.


 Russ Nelson's Packet Drivers <http://www.crynwr.com/crynwr/home.html>

 Avuta la documentazione si pu� scrivere un driver per la propria
 scheda e usarlo per Linux (almeno in teoria).  Si tenga presente che
 alcuni dei vecchi hardware che erano stati pensati per macchine di
 tipo XT non funzioneranno molto bene in un ambiente multitasking come
 Linux.  L'uso di uno di questi comporter� non pochi problemi se la
 propria rete deve sostenere un traffico ragionevole.

 La maggior parte delle schede ha dei driver per le interfacce MS-DOS
 come NDIS o ODI, ma questi sono inutili per Linux.  Molti hanno
 suggerito di fare il link direttamente di questi o utilizzare una
 traduzione automatica, ma queste sono cose praticamente impossibili.
 I driver MS-DOS si aspettano di essere in modalit� a 16 bit e si
 basano su `interrupt software', cose che sono entrambe incompatibili
 con il kernel di Linux.  Questa incompatibilit� � in realt� una
 caratteristica di Linux, in quanto alcuni driver per Linux sono spesso
 decisamente migliori delle loro controparti MS-DOS. La serie `8390'
 dei driver, per esempio usa un buffer di trasmissione ping-pong, che
 ora � stato introdotto anche nel mondo MS-DOS.

 (Buffer Tx di tipo ping-pong significa usare almeno due buffer di
 pacchetti per i pacchetti da trasmettere.  Uno � caricato mentre la
 scheda sta trasmettendo l'altro.  Il suo contenuto viene poi trasmesso
 non appena � conclusa la trasmissione dell'altro e cos� via.  In
 questo modo, la maggior parte delle schede sono in grado di inviare
 continuamente pacchetti back-to-back nel cavo.)

 OK. Quindi si � deciso che si vuole scrivere un driver per la scheda
 Ethernet CippaLippa, poich� si possiedono le informazioni di
 programmazione e nessuno l'ha ancora fatto (... queste sono le due
 condizioni principali ;-) Si dovrebbe partire dallo scheletro per un
 driver di rete fornito assieme ai sorgenti di Linux.  Pu� essere
 trovato nel file /usr/src/linux/drivers/net/skeleton.c in tutti i
 kernel recenti.  Si dia un'occhiata anche alla Kernel Hackers Guide, a
 questo indirizzo: KHG
 <http://www.redhat.com:8080/HyperNews/get/khg.html>



 8.3.  Interfaccia dei driver verso il kernel


 Ecco alcune note sulle funzioni che si dovranno scrivere se si crea un
 nuovo driver.  Si leggano queste cose assieme allo scheletro del
 driver citato prima per aiutarsi a chiarire un po' le cose.


 8.3.1.  Probe (rilevamento)


 � chiamata all'avvio per controllare l'esistenza della scheda.  Meglio
 se si pu� farlo non intrusivamente leggendo dalla memoria, ecc.  Pu�
 anche leggere dalle porte I/O.  La scrittura iniziale nelle porte di
 I/O durante il probe non � una buona cosa in quanto pu� uccidere un
 altro dispositivo.  Una parte dell'inizializzazione del dispositivo �
 fatta qui (allocando lo spazio I/O, IRQ, riempendo i campi di
 dev->???, ecc).  Si deve sapere a quali porte di I/O o zone di memoria
 pu� essere configurata la scheda, come abilitare la memoria condivisa
 (se usata), come selezionare/abilitare la generazione degli interrupt,
 ecc.





 8.3.2.  Interrupt handler (gestore dell'interrupt)


 � chiamato dal kernel quando la scheda genera un interrupt.  Ha il
 compito di determinare perch� la scheda lo ha generato e comportarsi
 di conseguenza.  Le usuali condizioni di interrupt sono la ricezione
 di dati, il completamento della trasmissione, la segnalazione di
 condizioni d'errore.  Si deve conoscere ogni bit di stato
 dell'interrupt di una qualche importanza in modo da portersi
 comportare di conseguenza.


 8.3.3.  Funzione transmit


 � collegata a dev->hard_start_xmit() ed � chiamata dal kernel quando
 ci sono alcuni dati che il kernel vuole depositare nel dispositivo.
 Mette i dati nella scheda e avvia la trasmissione.  Si deve sapere
 come raccogliere i dati, come metterli dentro la scheda (copia della
 memoria condivisa, trasferimento PIO, DMA?) e il posto giusto dove
 metterli.  Poi si deve sapere come dire alla scheda di inviare i dati
 nel cavo e (possibilmente) sollevare un interrupt quando ha fatto.
 Quando l'hardware non pu� accettare ulteriori pacchetti dovrebbe
 impostare il flag dev->tbusy.  Quando � disponibile dello spazio,
 solitamente durante un interrupt per il completamento della
 trasmissione, dev->tbusy dovrebbe essere liberato e i livelli pi�
 elevati informati con mark_bh(INET_BH).


 8.3.4.  Funzione receive


 � chiamata dall'interrupt handler del kernel quando ci sono dei dati
 nella scheda.  Toglie i dati dalla scheda, li impacchetta in un
 sk_buff e informa il kernel che i dati sono l�, dimodoch� questo possa
 fare una netif_rx(sk_buff).  Si deve sapere come abilitare la
 generazione di un interrupt sulla ricezione di dati, come controllare
 qualsiasi bit di stato della ricezione e come togliere i dati dalla
 scheda (ancora memoria condivisa, PIO, DMA, ecc.).


 8.3.5.  Funzione open


 � collegata a dev->open ed � chiamata dagli strati di rete quando
 qualcuno fa ifconfig eth0 up per attivare il dispositivo ed abilitarlo
 per la Rx/Tx di dati.  Qualsiasi inizializzazione speciale che non
 viene fatta nella sequenza di probe (abilitare la generazione degli
 IRQ, ecc.) dovrebbe andare qui.


 8.3.6.  Funzione close (opzionale)


 Questa mette la scheda in uno stato decente quando qualcuno fa
 ifconfig eth0 down.  Dovrebbe liberare gli IRQ e i canali DMA se
 l'hardware lo permette e disabilitare qualsiasi cosa che possa far
 risparmiare corrente (come il transceiver).


 8.3.7.  Funzioni varie


 Cose come una funzione di reinizializzazione, cosicch� se le cose
 vanno male, il driver pu� provare, come ultima risorsa, a ripristinare
 la scheda.  Solitamente � fatto quando una trasmissione va in time out
 o cose simili.  Pu� essere utile anche una funzione per leggere i
 registri di statistica delle scheda (se ce li ha).


 8.4.  Informazioni tecniche dalla 3Com


 Se si � interessati a lavorare su un driver per una scheda 3Com, si
 possono ottenere informazioni tecniche direttamente dalla 3Com.
 Cameron � stato talmente gentile da spiegarci come averle:

 �Gli adattatori Ethernet della 3Com sono documentati per chi vuole
 scrivere un driver nei nostri `Technical Reference' (TR).  Questi
 manuali descrivono le interfacce di programmazione delle schede ma non
 parlano della diagnostica, programmi d'installazione, ecc. tutte
 quelle cose che interessano all'utilizzatore finale.

 I TR sono distribuiti dal dipartimento di marketing della Network
 Adapter Division.  Per far funzionare le cose in maniera efficiente,
 la distribuzione � centralizzata in una cosa detta `CardFacts'.
 CardFacts � un sistema telefonico automatizzato.  Se lo si chiama con
 un telefono a toni pu� inviare fax dove si richiede.  Per ottenere un
 TR, si chiami CardFacts al 408-727-7021.  Gli si chieda il
 ``Developer's Order Form'' (modulo d'ordine per sviluppatori),
 documento numero 9070.  Si tenga sotto mano il proprio numero di fax
 quando si chiama.  Si compili il modulo d'ordine e lo si invii via fax
 al 408-764-5004.  I manuali sono spediti con il servizio ``2nd Day''
 della Federal Express.

 Alcuni pensano che diamo via troppo facilmente i manuali e cercano
 prove per dire il sistema � troppo costoso e che occupa troppo tempo e
 sforzi.  Da tempo, i nostri clienti sono sempre stati contenti di
 questa cosa e non ci sono mai stati problemi nonostante le quantit� di
 richieste che riceviamo.  Abbiamo bisogno della loro continua
 cooperazione e riserbo per mantenere le cose cos�.�


 8.5.  Note sulle schede basate su PCnet / LANCE di AMD


 Il chip LANCE (Local Area Network Controller for Ethernet) era
 l'offerta originale dell'AMD e da allora � stato rimpiazzato dal chip
 `PCnet-ISA', noto anche come 79C960.  Si noti che il nome `LANCE' �
 stuck e alcuni ancora fanno riferimento ai nuovi chip con il vecchio
 nome.  Dave Roberts della Network Products Division di AMD � stato
 talmente gentile da fornire le seguenti informazioni riguardo questo
 chip:

 �Funzionalmente, � equivalente a una NE1500. L'insieme dei registri �
 indentico a quello del vecchi LANCE con le aggiunte dell'architettura
 1500/2100.  I vecchi driver per 1500/2100 funzioneranno anche con il
 PCnet-ISA.  L'architettura degli NE1500 e degli NE2100 in pratica � la
 stessa.  Inizialmente la Novell l'ha chiamata 2100, ma hanno poi
 provato a distinguere tra le schede per il coassiale e le 10Base-T.
 Qualsiasi cosa che era solamente 10Base-T � stata numerata
 nell'intervallo 1500.  Questa � la sola differenza.

 Molte compagnie offrono prodotti basati su PCnet-ISA, incluse HP,
 Racal-Datacom, Allied Telesis, Boca Research, Kingston Technology,
 ecc.  Le schede in pratica sono le stesse se non per il fatto che
 alcuni costruttori hanno aggiunte le caratteristiche `jumperless'
 (senza ponticelli) che permettono la configurazione via software.  La
 maggior parte non l'ha fatto.  L'AMD offre un progetto standard per
 una scheda che usa il chip PCnet-ISA e molti costruttori usano il
 nostro progetto senza modifiche.  Questo significa che chiunque voglia
 scrivere dei driver per la maggior parte delle schede basate su PCnet-
 ISA pu� semplicemente prendere il data-sheet dall'AMD.  Si chiami il
 nostro centro di distribuzione della documentazione al (800)222-9323 e
 si chieda del data sheet per il Am79C960, il chip PCnet-ISA.  �
 gratis.

 Un modo veloce per capire se la scheda � una di quelle basate sul
 progetto standard, � quello di osservarla.  Se � una standard,
 dovrebbe avere un grosso chip, un cristallo, una piccola PROM
 d'indirizzo IEEE, probabilmente un socket per una ROM di boot e un
 connettore (1, 2 o 3 a seconda dei mezzi supportati).  Si noti che se
 � una scheda per cavo coassiale, avr� anche un po' di roba per il
 trasceiver, ma dovrebbe essere nei pressi del connettore e ben
 distante dal PCnet-ISA.�

 Una nota per gli aspiranti hacker � che differenti implementazioni del
 LANCE effettuano il `restart' (riavvio) in modi diversi.  Alcune
 riprendono da dove sono state interrotte, mentre altre ripartono
 dall'inizio, come se fossero state inizializzate.


 8.6.  Multicast e modalit� promiscua


 Un'altra delle cose a cui ha lavorato Donald � l'implementazione degli
 ``agganci'' (hook) per il multicast e la modalit� promiscua
 (promiscuous mode). Tutti i driver ISA rilasciati (cio� non ALPHA) ora
 supportano la modalit� promiscua.

 Donald scrive: �Inizierei con il parlare della modalit� promiscua, che
 concettualmente � facile da implementare.  Per la maggior parte
 dell'hardware semplicemente si deve impostare un bit di registro e da
 allora si riceveranno tutti i pacchetti che passano su quel cavo.
 Beh, non � proprio cos� facile: per alcune schede si deve disabilitare
 la scheda (potenzialmente perdendo alcuni pacchetti), riconfigurarla e
 poi riabilitarla.  OK, visto che questo � facile, adesso passo a
 qualcosa che non � proprio cos� ovvia: il multicast.  Pu� essere fatto
 in due modi:


 1. Usando la modalit� promiscua e un filtro di pacchetti come il
    Berkeley packet filter (BPF).  Il BPF � un linguaggio stack di
    pattern matching (ricerca delle corrispondenze), dove si scrive un
    programma che raccoglie gli indirizzi ai quali si � interessati.
    Il suo vantaggio � che � molto generale e programmabile.  Lo
    svantaggio � che non c'� un metodo generale per il kernel per
    evitare di attivare la modalit� promiscua e far passare ogni
    pacchetto che attraversa il cavo su ognuno dei filtri di pacchetti
    registrati.  Si veda ``Il Berkeley Packet Filter'' per maggior
    informazioni.

 2. Usare il filtro multicast su scheda che hanno la maggior parte
    delle schede.

 Immagino che dovrei elencare quel poco che mettono a disposizione le
 schede o i chip:



 Chip/scheda  Promiscua  Filtro multicast
 -----------------------------------------
 Seeq8001/3c501  S�     Filtro binario (1)
 3Com/3c509      S�     Filtro binario (1)
 8390            S�     Hash a sei bit con Autodin II (2) (3)
 LANCE           S�     Hash a sei bit con Autodin II (2) (3)
 i82586          S�     Hash a sei bit con Hidden Autodin II (2) (4)

 1. Queste schede affermano di avere un filtro, ma � un semplice s�/no:
    �accetta tutti i pacchetti multicast� o �non accettare i pacchetti
    multicast�.

 2. AUTODIN II � il polimonio di CRC (codice ciclico a ridonadanza)
    standard di Ethernet.  In questo schema, degli indirizzi multicast
    viene calcolata l'hash e vengono poi ricercati in una tabella hash.
    Se � abilitato il bit corrispondente del pacchetto, allora questo �
    accettato.  I pacchetti Ethernet sono progettati in modo che
    l'hardware per fare questa cosa sia banale: semplicemente si
    memorizzano i sesti bit del circuito CRC (comunque necessario per
    il controllo degli errori) dopo i primi sei otteti (l'indirizzo di
    destinazione) e li si usa per indicizzare nella tabella hash (sei
    bit: una tabella a 64 bit).

 3. Questi chip usano la hash a sei bit e la tabella dev'essere
    calcolata e caricata dall'host.  Questo significa che il kernel
    deve contenere il codice per il CRC.

 4. Il 82586 usa la hash a sei bit internamente, ma calcola da solo la
    tabella di hast dall'elenco degli indirizzi multicast da accettare.

 Si noti che nessuno di questi chip fa un filtraggio perfetto e c'�
 ancora bisogno di un modulo a livello intermedio per fare il
 filtraggio finale.  Si noti pure che in tutti i casi si deve mantenere
 un'elenco completo degli indirizzi multicast accettati per ricalcolare
 la tabella di hash quando cambia.


 8.7.  Berkeley Packet Filter (BPF)

 L'idea diffusa fra gli sviluppatori � che le funzionalit� BPF non
 dovrebbero essere fornite dal kernel, ma dovrebbero essere in una
 libreria di compatibilit� (si spera poco usata).

 Per quelli che non lo conoscono, il BPF (Berkeley Packet Filter --
 filtro dei pacchetti di Berkeley) � un meccanismo per specificare agli
 strati di rete del kernel i pacchetti ai quali si � interessati. �
 implementato come un interprete specializzato di un linguaggio stack
 costruito dentro il codice di rete a basso livello. Un'applicazione
 passa un programma scritto in questo linguaggio al kernel ed il kernel
 esegue il programma su ciascun pacchetto in ingresso. Se il kernel ha
 pi� applicazioni BPF, ogni programma � eseguito su ogni pacchetto.

 Il problema � che � difficile dedurre dal programma di filtraggio dei
 pacchetti a quale tipo di pacchetti l'applicazione � veramente
 interessata, e quindi la soluzione generale � di eseguire sempre il
 filtro. Si immagini un programma che registra un programma BPF per
 raccogliere il flusso a bassa velocit� inviato ad un indirizzo
 multicast. La maggior parte delle schede hanno un filtro hardware per
 indirizzi multicast implementato come una tabella di hash a 64 voci
 che ignora i pacchetti multicast maggiormente non voluti. Quindi c'�
 la possibilit� di rendere questa operazione poco costosa. Ma con il
 BPF il kernel deve passare l'interfaccia in modalit� promiscua,
 ricevere _tutti_ i pacchetti e farli passare attraverso il filtro.
 Questa cosa funziona, ma quel che � difficile � darne conto al
 processo che ha richiesto i pacchetti.


 9.  Networking con computer portatili

 Ci sono diversi modi per mettere il proprio portatile in una rete. Si
 pu� usare il codice di SLIP (e andare alla velocit� delle porte
 seriali); si pu� prendere un portatile con gi� al suo interno uno slot
 PCMCIA; si pu� prendere un portatile con una docking station e
 attaccarci una scheda Ethernet ISA; oppure si pu� usare un adattatore
 Ethernet su porta parallela.


 9.1.  Usare SLIP

 Questa � la soluzione pi� economica, ma considerevoltemente la pi�
 difficoltosa. Inoltre non permetter� velocit� di trasmissione molto
 elevate. Poich� lo SLIP non centra con le schede Ethernet non sar�
 discusso ulteriormente qui. Si veda il NET-2 HOWTO.


 9.2.  Supporto PCMCIA

 Si provi a determinare esattamente l'hardware che si possiede (cio�
 costruttore della scheda, costruttore del chip del controller PCMCIA)
 e poi si chieda nel canale LAPTOPS. Non ci si aspetti che le cose sia
 poi cos� semplici.  Si dovranno fare un po' di cose a mano, applicare
 patch al kernel, ecc.  Forse un giorno si sar� in grado di scrivere
 semplicemente `make config' 8-)

 Al momento, i due chipset PCMCIA supportati sono il Databook TCIC/2 e
 l'Intel i82365.

 A tsx-11.mit.edu ci sono diversi programmi nella directory
 /pub/linux/packages/laptops/ che potrebbero tornare utili. Si va da
 driver per schede Ethernet PCMCIA a programmi che comunicano con il
 chip del controller PCMCIA. Si noti che questi driver sono solitamente
 legati ad uno specifico chip PCMCIA (l'Intel 82365 e il TCIC/2)

 Per le schede compatibili con NE2000, alcuni hanno avuto successo
 semplicemente configurando la scheda sotto DOS e poi avviando Linux
 dalla riga di comando del DOS con loadlin.

 La situazione sembra buona per quelli che vogliono il supporto PCMCIA,
 in quanto sono stati fatti dei progressi sostanziali. Il pioniere in
 questi sforzi � David Hinds. Il suo ultimo pacchetto per il supporto
 PCMCIA pu� essere ottenuto da:

 PCMCIA Package <ftp://cb-iris.stanford.edu/pub/pcmcia>

 Si cerchi un file tipo pcmcia-cs-X.Y.Z.tgz dove X.Y.Z sar� il numero
 dell'ultima versione. Questo sar� probabilmente depositato anche nel
 sito FTP tsx-11.mit.edu.

 Si noti che l'abilitatore PCMCIA di Donald funziona come processo a
 livello utente mentre quella di David Hinds � una soluzione a livello
 kernel. Si sar� meglio serviti dal pacchetto di David in quanto �
 maggiormente usato e in continuo sviluppo.


 9.3.  Schede Ethernet ISA nella docking station

 Le docking station per i portatili costano circa 250 dollari e
 forniscono due slot ISA a piena grandezza, due porte seriali e una
 porta parallela. La maggior parte delle docking station sono
 alimentate direttamente dalle batterie del portatile e solo alcune
 permettono l'aggiunta di batterie addizionali se si usano schede ISA
 corte. Si pu� cos� aggiungere una scheda Ethernet poco costosa e
 gioire delle prestazioni di una Ethernet a piena velocit�.


 9.4.  Adattatori pocket (su porta parallela)

 Anche gli adattori Ethernet `pocket' possono soddisfare le proprie
 necessit�. Si noti che la velocit� di trasferimento non sar� affatto
 elevata (forse picchi di 200kB/s?) a causa delle limitazioni
 dell'interfaccia su porta parallela.

 Inoltre ci si deve collegare alla presa di alimentazione sulla parete.
 Qualche volta si pu� evitare di attaccare l'adattatore alla presa,
 comprando o facendosi un cavo per prendere l'alimentazione dalla porta
 per la tastiera del portatile (si veda ``alimentazione dalla
 tastiera'').

 Si veda ``DE-600 / DE-620'' e ``RealTek'' per due adattatori pocket
 supportati.



 10.  Miscellanea


 Tutta quella roba che non ci stava bene da nessun'altra parte � stata
 messa qui.  Potrebbe non essere rilevante e potrebbe non essere
 d'interesse generale, ma � comunque qui.


 10.1.  Passare al kernel argomenti Ethernet


 Ci sono due comandi generici che possono essere passati al kernel al
 momento del boot: ether e reserve.  Questa cosa pu� essere fatta con
 LILO, loadlin o qualsiasi altra utilit� di boot che accetta 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

 Per maggiori informazioni sugli argomenti di boot (e un elenco
 completo) si veda il BootPrompt-HOWTO
 <http://metalab.unc.edu/mdw/HOWTO/BootPrompt-HOWTO.html>.


 10.1.1.  Il comando ether


 L'argomento ether= � usato in congiunzione a driver direttamente
 compilati dentro al kernel.  Non ha assolutamente alcun effetto su
 driver compilati come moduli.  Nella sua forma pi� generale, pu�
 essere qualcosa di simile:


      ether=IRQ,IND_BASE,PARAM_1,PARAM_2,NOME


 Tutti gli argomenti sono opzionali.  Il primo argomento non numerico �
 intrepretato come NOME.

 IRQ: ovvio.  Un valore di IRQ di `0' (solitamente il valore
 predefinito) significa autoIRQ.  � accidentale che l'impostazione
 dell'IRQ sia prima di quella dell'ind_base: questa cosa verr� corretta
 non appena cambier� qualcos'altro.

 IND_BASE: altrettanto ovvio.  Il valore `0' (solitamente quello
 predefinito) indica di rilevare una scheda nell'elenco di indirizzi
 spefici 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 rifemento 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 di LILO.  Il kernel 1.0 trattava le schede Ethernet
 basate su LANCE in modo speciale.  Gli argomenti di LILO erano
 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).


 10.1.2.  Il comando reserve


 Questo comando di lilo � usato proprio come il precedente `ether=',
 ovvero � 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
 dispositivo di controllare la presenza di dispositivi (auto probing)
 in regioni specifiche.  Ci� pu� essere dovuto ad hardware mal
 progettato che causa il congelamento del boot (come alcune schede
 Ethernet), ad hardware che viene mal identificato, ad hardware il cui
 stato � cambiato da un rilevamento precedente, o semplicemente ad
 hardware che non vuole essere inizializzato dal kernel.

 L'argomento di boot reserve indirizza questo problema specificando la
 regione di una porta I/O che non dovrebbe 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.  Sar� necessario usare questo comando solo quando c'�
 un problema o un caso particolare.

 Le porte I/O nella regione specificata sono protette dai controlli dei
 dispositivi.  Questa cosa si � resa necessaria quando alcuni driver si
 piantavano su una NE2000 o mal identificavano altri dispositivi come
 propri.  Un driver di dispositivo corretto non dovrebbe controllare
 una regione riservata a meno che qualche altro argomento di boot non
 specifici esplicitamente di farlo.  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 la regione 0x300-0x31f.

 Come al solito, c'� un limite di 11 parametri come in tutti i comandi
 di boot, quindi si possono specificare solo 5 regioni riservate per
 ciascun comando keyword.  Possono essere specificati pi� reserve se si
 hanno richieste insolitamente complicate.


 10.2.  Usare un driver Ethernet come modulo


 La maggior parte delle distribuzioni di Linux utilizzano ora dei
 kernel con pochissi driver al loro interno.  I driver sono 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 2.0) o `kmod' (nei 2.1)
 che a loro volta chiamano modprobe.

 La propria distribuzione pu� offrire uno strumento grafico carino per
 l'impostazione dei moduli Ethernet.  Se possibile prima si dovrebbe
 provare a usare quello.  La descrizione che segue fornisce le
 informazioni che stanno sotto a qualsiasi programma di configurazione
 e indica cosa quei programmi vanno a modificare.

 Le informazioni che controllano quali moduli sono usati e quali
 opzioni sono passate a ciascun modulo sono solitamente salvate nel
 file /etc/conf.modules.  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 le informazioni sui
 moduli.

 I moduli stessi sono tipicamente salvati 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 l� per vedere quale
 modulo corrisponde alla propria scheda.

 La prima cosa che ci deve essere nel proprio file conf.modules �
 qualcosa che dice a modprobe quale driver usare per l'interfaccia di
 rete eth0 (e per eth1 e per...).   Per questa cosa si dovr� usare il
 comando alias.  Per esempio, se si ha una scheda ISA EtherEZ della SMC
 che usa il modulo del driver smc-ultra.o, si deve creare alias per
 questo driver che corrisponda a eth0, aggiungendo la riga:


         alias eth0 smc-ultra



 L'altra cosa di cui si pu� aver bisogno � una riga options che indica
 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 avviser� (si veda
 dmesg) che l'auto rilevamento di una scheda ISA non � una buona idea.
 Per venir a capo di questo problema, si aggiunga un'altra riga che
 dice al modulo a quale indirizzo I/O base � configurata la scheda, ad
 esempio l'indirizzo esadecimale 0x280.


         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
 trovata nel file:

 /usr/src/linux/Documentation/networking/net-modules.txt

 Si raccomanda la sua lettura per trovare quali opzioni si possono
 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 unico
 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 tranceiver 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� fare ifconfig eth0 down (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.


 10.3.  Documentazione correlata


 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) al l'URL seguente:

 Usenet FAQs <ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/>

 Si pu� anche dare un'occhiata alla cosiddetta `Ethernet-HomePage', che
 � all'URL seguente:

 Ethernet-HomePage <http://wwwhost.ots.utexas.edu/ethernet/ethernet-
 home.html>



 10.4.  Liberatoria e copyright (in inglese)


 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-1997 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.


 10.5.  Chiusura


 Se in questo documento si � trovato un qualsiasi errore madornale o
 informazione non aggiornata, mi si mandi una e-mail.  � grande ed �
 facile non accorgersi di qualcosa.  Se si � inviata una mail per una
 modifica e non � stata inclusa nella versione successiva, non si esiti
 a scrivere ancora, in quanto potrebbe essersi persa tra la marea di
 SPAM e junk mail che ricevo.

 Grazie!

 Paul Gortmaker, [email protected]

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.