<!--

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

	By Paul Gortmaker.

	Modification Date: Aug 25, 2003

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

	History:

	o  About July '93 - I was looking for info for e'net support for
	   a notebook, and was browsing the files on Donald's ftp site
	   (was ftp.super.org then) - Donald had a bunch of informational
	   files scattered about, and while talking to him, he mentioned
	   that someday it would be good if all that info was rolled
	   into one document. The Howto project was just started, with
	   the NET-Howto being the first howto, (grown from all the
	   confusion of the big net-switch at 0.99pl10). I rolled all
	   Donald's info into one, added a bunch of info that I had
	   gleaned from postings, copied the general style of the
	   NET-Howto, and the first Ethernet-Howto hit the internet
	   sometime in August 93.

	o  About December 93, Donald hacked together a HTML version of
	   the Ethernet-Howto, but it didn't get much distribution, and
	   I only kept the ASCII version up to date.

	o  Spring 94, and the Ethernet-Howto gets published in the
	   Linux Bible  - 30 pages of a ~750 page book, published
	   by Linux System Labs.

	o  Donald moves jobs, and sets up a WWW home page with up-to-date
	   information on new linux drivers, and other ethernet news.
	   Look for the url contained in this document.

	o  A year (July 94) after its beginning, and the ugly tab+space
	   formatting is dead.  The last ASCII version that was maintained
	   by hand was called version 1.03, and dated June 22/94. Any ASCII
	   versions newer than that were generated from this SGML source.

	o  I sat on the converted doc until Oct 94 because of a bug in the
	   cross-referencing with HTML. A fix was to be forthcoming, but
	   didn't eventuate. I eventually found a work-around.

	o  Nov 95 sees a major reorganization, which puts the FAQ section
	   and all the interesting bits first. People never read more
	   than the first few pages anyway... :-)

	o  Oct 96 and linux v2.0 seems to have finally stabilized at
	   patch-21. Good time for an update of this. Nuke some of
	   the older documentation of bugs pertaining to the v1.0
	   and v1.1 kernels.

	o  Feb 97 adds a few updates and fixes, taking it to 2.0.28
	   and 2.1.24 repectively.

	o  Nov 97 - pre-2.0.31 and 2.1.6x, update for new LSL book.

	o  Feb 98 - 2.0.33 and 2.1.84, more minor updates, more old
	   cruft nuked.

	o  July 98 - 2.0.34/2.1.108, as above, and add more focus
	   on using modules as all distributions do so now.

	o  Nov 98 - 2.0.35/2.1.126, significant updates, add driver
	   name to status line to help module users (not released)

	o  May 99 - 2.0.36/2.2.7, delete lots more old cruft, add new
	   section on SMP issues, remove references to v2.1 series.

	o  Oct 00 - 2.2.17/2.4.0-test series. Lots of e-mailed updates,
	   cesdis is no longer the main driver site.

TODO:

	Change tags as required to move to DocBook format.

	Perhaps phase out all/any non-linux related info to reduce the
	size of this thing.  (Perhaps better than phasing it out would be
	to move it to a separate non-updated document?)  I've started
	by commenting out and deleting some such information.

This is the markup for the ILDP Italian Translation by Federico Lucifredi
-->

<!doctype linuxdoc system>

<article opts="italian">

<title>Linux Ethernet-HOWTO
<author>di Paul Gortmaker
<date>v2.9, 25 Agosto 2003
<abstract>
Questo è l'Ethernet Howto, una raccolta di informazioni su quali
dispositivi 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 <tt/ifconfig/ e <tt/route/,
che sono coperte in svariati altri materiali di documentazione Linux.
Traduzione fino al 1999 a cura di Lorenza Romano (<htmlurl
url="mailto:titti@dei.unipd.it" name="titti@dei.unipd.it">) e Giovanni
Bortolozzo (<htmlurl url="mailto:borto@pluto.linux.it"
name="borto@pluto.it">), dopo il 1999 a cura di Federico Lucifredi
(<htmlurl url="mailto:lucifred@fas.harvard.edu"
name="lucifred@fas.harvard.edu">); revisione a cura di Claudio Cattazzo
<htmlurl url="mailto:claudio@pluto.it" name="claudio@pluto.it">.
</abstract>

<toc>

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

L'Ethernet-Howto include dettagliate informazioni sul corrente livello di 
supporto per la maggior parte delle schede Ethernet pi&ugrave; comuni.
Sono trattati i comuni problemi di configurazione, problemi associati con
la scelta del driver giusto, ed il caricare e rendere funzionale detto driver.
Non vengono qui trattati i problemi che l'utente deve affrontare negli stadi 
seguenti del processo di configurazione (come la scelta di un indirizzo IP, il
routing e cos&igrave; via). Tali informazioni possono essere facilmente
reperite in altre parti della documentazione di Linux.

Ai tempi dell'infanzia di Linux, le vecchie schede di espansione basate sul
bus ISA erano la regola. Il bus ISA non dispone di una ragionevole ed
affidabile maniera di determinare quali schede siano installate, o che
configurazione vada usata con tali schede. Ci&ograve; risultava in un
pi&ugrave; grande coinvolgimento dell'utente nel fornire queste informazioni a
Linux, e gli utenti facevano riferimento a questo documento come una guida che
li assistesse in questo compito.

Fortunatamente, il nuovo bus PCI si trova in praticamente tutti i computer di
oggi, e al bus ISA non resta che raccogliere polvere nei vecchi 386 e 486 dei
tempi andati. I progettisti del bus PCI conoscevano la debolezza del bus ISA e
cos&igrave; hanno aggiunto funzionalit&agrave; che permettessero alla scheda
di comunicare produttore, modello e settaggi di configurazione da usare al
sistema.

Il tramonto del bus ISA ha drasticamente ridotto il coinvolgimento dell'utente
nella configurazione delle schede di rete. Di conseguenza, il tipico utente
Linux odierno non ha bisogno di fare riferimento a questa guida per assistenza.
Vi sono tuttavia sempre delle eccezzioni in cui le cose non funzionano come
dovrebbero, o dei problemi inaspettati che richiedono risoluzione. E,
ovviamente, esistono ancora parecchi vecchi computer ad architettura ISA che
continuano a lavorar duro macinando compiti ingrati nascosti nel fondo degli
armadi pi&ugrave; bui.

Questa revisione tratta i driver Ethernet inclusi coi kernel stabili fino alla
versione 2.4.21 compresa. Alcune caratteristiche del futuro kernel 2.6 vengono 
comunque menzionate.

Ethernet-Howto è scritto da:
<quote>
	Paul Gortmaker, <tt/p_gortmaker @ yahoo.com/
</quote>

La fonte principale di informazioni per la versione iniziale dell'
Ethernet-Howto, originariamente disponibile esclusivamente in formato ASCII:
<quote>
	Donald J. Becker, <tt/becker@cesdis.gsfc.nasa.gov/
</quote>

A cui dobbiamo anche la nostra gratitudine per aver scritto la grande maggioranza dei
driver attualmente disponibili su Linux per schede Ethernet. Grazie Donald!

Questo documento è Copyright (c) 1993-2003 di Paul Gortmaker.
Si, sono oramai dieci anni che io mantengo questo documento! 
Si vedano la liberatoria e le informazioni sulla copia alla fine di
questo documento (<ref id="copyright" name="copyright">) per
informazioni circa la ridistribuzione e le solite liberatorie legali come
"non siamo responsabili per ciò che riuscirete a rompere...".

<sect1>Nuove versioni di questo documento<label id="new-doc">
<p>

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

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

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

	<url url="ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/"
		name="Sunsite HOWTO Archive">

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.

<sect1>Come usare l'Ethernet-Howto<label id="using">
<p>
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 <em/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 <ref id="help" name="AIUTO - Non
funziona!"> è rivolta ai nuovi utenti di Linux e vi metterà nella
direzione giusta.

Tipicamente gli stessi problemi e quesiti sono posti <em/più e più/
volte da diverse persone. Può essere che il proprio problema specifico
sia una delle Frequently Asked Questions (domande
frequenti) e trovi risposta nella sezione FAQ di questo documento
(<ref id="faq" name="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 (<ref id="what-card" name="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
(<ref id="card-intro" name="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 (<ref id="tech-intro"
name="Informazioni tecniche">).

<sect1>Cosa devo fare per far funzionare una scheda Ethernet?
<p>
Nel modo pi&ugrave; conciso possibile, possiamo indicare che dovrete:
1) avere una scheda di espansione Ethernet o una scheda madre con supporto
Ethernet integrato, 2) determinare il produttore e modello della scheda
o del chip Ethernet integrato, 3) determinare se esiste un driver Linux per
questo modello di scheda o di chipset, 4) individuare e caricare detto driver,
5) controllare l'output di questo driver per verificare che abbia individuato 
questa scheda e 6) configurare i settaggi della vostra nuova interfaccia di
rete.

<sect1>AIUTO - Non funziona!<label id="help">
<p>

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 dell'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 ad usare l'utilità <tt>lspci</tt>
per ottenere informazioni sui dispositivi installati sul bus PCI del vostro
computer. Usare <tt>cat /proc/pci</tt> produce informazioni simili ma non
altrettanto complete. Per schede di tipo ISA, si veda la sezione di aiuto
sulle schede misteriose (cfr. <ref id="mystery" name="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 (<ref id="card-intro" name="Informazioni specifiche
su...">) che elenca in ordine alfabetico i produttori di schede, i
numeri identificativi dei modelli e se esiste o meno un driver per Linux.
Se la vostra scheda è catalogata come "Non supportata" ci si può praticamente
arrendere. 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ò <em/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 (<ref id="modules" name="Usare un
driver Ethernet come modulo">).

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 vi aiuterà nel 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 invece nulla 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 e una volta fatto il
login, si digiti <tt>dmesg | more</tt>. 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 <tt/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
(<ref id="faq" name="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 risulterà inizializzato correttamente e la scheda continuerà a
non essere utilizzabile. La maggior parte dei 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 <tt/ifconfig/ e <tt/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 maniere
diverse. (1) Si ha un messaggio di errore quando <tt/ifconfig/ tenta
di aprire il dispositivo per usarlo, del tipo "SIOCSFFLAGS: Try
again". (2) Il driver riporta messaggi d'errore su <tt/eth0/ (li si può
vedere usando <tt>dmesg | more</tt>) o strane incongruenze
ogniqualvolta prova a mandare o ricevere dati. (3) Digitando <tt>cat
/proc/net/dev</tt> appaiono numeri diversi da zero in una delle
colonne errs, drop, fifo, frame o carrier corrispondenti a
<tt/eth0/. (4) Digitando <tt>cat /proc/interrupts</tt> 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, <em/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 come la marca della scheda, la versione del
kernel, i messaggi del driver all'avvio, l'output di <tt>cat
/proc/net/dev</tt>, una chiara descrizione del problema e naturalmente
cosa si è già provato a fare per far funzionare le cose.

Vi 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. Ovviamente lo stesso criterio va seguito quando si invia notizia
di un problema - fornite sempre quante pi&ugrave; informazioni sia possibile.

<sect1>Tipi di cavo che la propria scheda dovrebbe
supportare<label id="cable-intro">
<p>
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 thinnet o cablaggio Ethernet sottile (cavo coassiale RG-58) con connettori
BNC (di metallo, da spingere e girare per chiudere) è chiamata tecnicamente
10Base2.

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.

Stanno diventando comuni anche moltissime schede Ethernet in una
versione "mista" (combo) che tipicamente costa solo &dollar;10-&dollar;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.

Installazioni aziendali estese useranno probabilmente 10BaseT
piuttosto che 10Base2. 10Base2 non offre alcuna possibilità di
aggiornamento a una 100Base-qualsiasi. 10base2 7egrave; una scelta accettabile
per hobbisti che vogliano costruire una rete locale quando l'aquisto di
un hub non &egrave; desiderabile per qualsiasivoglia motivo.

Si veda <ref id="cable" name="Cavi, coassiali,..."> per altre
informazioni riguardanti i diversi tipi di cavi Ethernet.

<sect>Domande frequenti<label id="faq">
<p>
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 <url
url="http://www.dejanews.com" name="Dejanews">.

<sect1>Come spiego a Linux che driver usare?<label id="what-driver">
<p>
Nella maggior parte delle distribuzioni Linux, i driver
esistono come moduli a caricamento dinamico, piccoli file binari
che vengono caricati dinamicamente dal sistema operativo a runtime.
Un modulo fornisce al sistema (pi&ugrave; appropriatamente, al kernel)
le informazioni necessarie sul come controllare una particolare
scheda Ethernet. Il nome del modulo da impiegare &egrave; elencato
nella intestazione della sezione dedicata alla vostra scheda in questo
documento. Una volta che si &egrave; a conoscenza del nome del modulo, 
lo si deve aggiungere al file <tt>/etc/modules.conf</tt> in modo che 
il kernel Linux sappia che modulo caricare per la vostra scheda. La
sintassi &egrave; solitamente come segue:

<verb>
	alias eth0 nome_del_modulo
	options nome_del_modulo optione1=valore1 optione2=valore2 ...
</verb>

Solitamente la riga di opzioni &egrave; necessaria solo per hardware
antiquato che si appoggia al bus ISA. In sistemi dotati di molteplici
schede Ethernet, linee addizionali per <tt>eth1</tt>, <tt>eth2</tt>,
e cos&igrave; via sono spesso necessarie.

I moduli sono solitamente collocati nella directory <tt>/lib/modules/</tt>,
che &egrave; solitamente ulteriormente suddivisa secondo le diverse versioni
del kernel (per determinare la versione del kernel che state eseguendo usate
<tt>uname -r</tt>) e il sottosistema di cui fanno parte (in questo caso si
tratta di <tt>net</tt>). I moduli sono posti qui dal curatore della
distribuzione o dal singolo utente quando viene eseguito il comando <tt>make
modules_install</tt> dopo la compilazione di un kernel personalizzato e
relativi moduli (si veda il kernel HOWTO per ulteriori dettagli sul come
compilare un kernel personalizzato secondo i vostri gusti).
    
Se decidete di ricompilare il vostro kernel, avete tra le vostre opzioni la
anche la possibilit&agrave; di compilare tutti i moduli direttamente nel kernel
piuttosto che crearli come moduli esterni. Quando si sceglie di far questo,
i driver riconosceranno le componenti hardware di loro competenza al momento
del boot. Opzioni possono essere passate ai moduli precompilati nel kernel
(si veda il BootPrompt Howto per ulteriori dettagli in merito) dalla riga di
comando. L'utente sceglie espressamente quali moduli incorporare nel kernel
durante l'esecuzione di del comando <tt>make config</tt> nel processo di
ricompilare il kernel (di nuovo, si faccia riferimento al kernel HOWTO per i
dettagli).

<sect1>Che scheda si dovrebbe acquistare per Linux?<label id="what-card">
<p>

La risposta a questa domanda dipende molto da cosa si intende
esattamente fare con la propria connessione di rete e quanto traffico
essa 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. Inoltre, alcune schede sono ora in 
grado di eseguire parte delle operazioni di checksum direttamente in
hardware, liberando la CPU da un ulteriore overhead. Per maggiori 
dettagli si faccia riferimento alla pagina seguente:

	<url url="http://www.uow.edu.au/~andrewm/zerocopy.html"
		name="Hardware Checksum/Zerocopy Page">

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.

<sect1>Driver alpha -- come procurarseli e come usarli<label id="alfa">
<p>
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" in fatto di driver può essere trovato sul sito Web di
Donald: <tt/www.scyld.com/. Qui le cose cambiano abbastanza frequentemente
perciò si cerchi attentamente. In
alternativa, per localizzare il driver che si sta cercando, può essere
più facile usare un browser WWW all'indirizzo:

<url url="http://www.scyld.com/network/" name="Don's Linux Network Home Page">

(ci si guardi da browser che danneggiano i file trasferiti silenzionsamente
sostituendo i punti di tabulazione nel sorgente con spazi -- se si è incerti
si ricorra ad ftp o almeno ad 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 <tt/make config/ è
"Prompt for development and/or incomplete code/drivers" (offri
codice o driver in fase di sviluppo o incompleti). Si dovrà
rispondere "Y" (sì) per richiedere l'inclusione di un qualche driver
alpha/sperimentale.

<sect1>Come usare più di una scheda Ethernet per macchina<label
id="two-card">
<p>
Cosa è necessario fare affinché Linux possa utilizzare due o pi&ugrave; schede
Ethernet?

La risposta a questo quesito dipende se si sta usando il
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 il sistema di un particolare utente vengono
caricati una volta che l'avvio del sistema è arrivato al punto tale da
poter accedere ai file dei moduli dei driver (contenuti di solito in
<tt>/lib/modules/</tt>).

Nel caso di schede PCI, i moduli/driver dovrebbero individuare automaticamente
tutte le schede supportate presenti nel sistema, vale a dire che l'utente
non &egrave; costretto a fornire nessuna configurazione (come l'indirizzo I/O
di base ed il numero di IRQ) tranne che in casi eccezzionali, come 
ad esempio quando si cerca di supportare hardware non conforme agli standard.

Alcuni dei primi kernel avevano un limite massimo di 16 schede Ethernet che 
potevano venire rilevate al momento del boot, ed alcuni driver modulari per
schede ISA avevano un limite di quattro schede supportate per ogni copia del
modulo caricata. Si pu&ograve; sempre caricare un altra copia dello stesso
modulo sotto un nome diverso per poter utilizzare altre quattro schede se
questo rappresenta un limite, oppure ricompilare il modulo con supporto per
tante schede quante si desideri.

<sect2>Con il Driver Come Modulo
<p>
Il rilevamento di una scheda non è una operazione affidabile sul bus 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
<tt>/etc/modules.conf</tt>.

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

<verb>
	alias eth0 ne
	alias eth1 ne
	options ne io=0x240,0x300
</verb>

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

Per poter gestire più schede, la maggior parte dei driver modulari ISA
sono in grado di accettare diversi valori di I/O separati da virgole, come
in questo esempio. Tuttavia, alcuni driver (forse più vecchi), come il modulo
3c501.o, al momento sono in grado di gestire solo una scheda per modulo
caricato. In tal caso si può caricare il modulo due volte per far
sì che entrambe le schede siano rilevate. Il file
<tt>/etc/modules.conf</tt> dovrebbe in questo caso presentarsi così:

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

In questo esempio l'opzione <tt/-o/ è stata usata per dare a ogni
istanza del modulo un nome univoco, poich&eacute; non è possibile caricare
due moduli con lo stesso nome. Viene anche usata l'opzione <tt/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 ci&ograve; non sarebbe realmente necessario).

Come esempio finale, si consideri un utente con una scheda 3c503 all'indirizzo 
<tt/0x350/ e una SMC Elite16 (wd8013) a <tt/0x280/. Si avr&agrave; la seguente
configurazione:

<verb>
	alias eth0 wd
	alias eth1 3c503
	options wd io=0x280
	options 3c503 io=0x350
</verb>

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

I moduli disponibili sono tipicamente memorizzati in
<tt>/lib/modules/`uname -r`/net</tt> dove il comando <tt/uname -r/
risponde con la versione del kernel (es. 2.0.34). Si controlli detta directory
per vedere quale modulo corrisponda alla propria scheda. Una volta che si hanno
le impostazioni corrette nel proprio file <tt/modules.conf/, si può
collaudare il tutto con:

<verb>
	modprobe ethN
	dmesg | tail
</verb>

dove 'N' è il numero dell'interfaccia Ethernet che si sta collaudando.
Si noti che il nome dell'interfaccia (<tt/ethX/) asssegnato al driver
dal kernel &egrave; indipendente dal nome usato sulla riga di alias. 
Per ulteriori dettagli si faccia riferimento alla sezione
<ref id="modules" name="Usare un driver Ethernet come modulo">.


<sect2>Con il Driver Compilato nel Kernel
<p>
Dato che il rilevamento automatico (probing, N.d.T.) di una scheda ISA
pu&ograve; mandare in crash la macchina, i kernel fino al 2.4 incluso,
effettuano per default la ricerca automatica di <em/una sola/ scheda Ethernet
su bus ISA. Dato che non vi sono pi&ugrave; distribuzioni con dei kernel
contenenti un gran numero di driver modulari ISA, tale restrizione non viene
pi&ugrave; imposta a partire dal kernel 2.6.
 
Nei kernel della serie 2.2 (e pi&ugrave; recenti), i processi di rilievo
automatico al boot sono stati separati in sicuri ed insicuri, in modo che
tutti quelli sicuri (ad esempio PCI e EISA) trovino automaticamente tutte
le loro schede. In sistemi con più di una scheda Ethernet di cui almeno una
su bus ISA, &egrave; ancora necessario fare una delle cose seguenti.

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 dei parametri al kernel, solitamente usando LILO. Il
rilevamento della seconda scheda può essere ottenuto con un semplice
parametro di boot come <tt/ether=0,0,eth1/. In questo caso <tt/eth0/
e <tt/eth1/ saranno assegnate nell'ordine in cui vengono rilevate le
schede durante il boot. Nel caso in cui, per esempio, si voglia che la scheda
a <tt/0x300/ sia <tt/eth0/ e quella a <tt/0x280/ sia <tt/eth1/, allora si
pu&ograve; usare:

<tscreen>
	LILO: linux ether=5,0x300,eth0 ether=15,0x280,eth1
</tscreen>

Il parametro <tt/ether=/ &egrave; in grado di accettare più della terna
composta da IRQ, indirizzo I/O di base e nome appena illustrata. Si veda la
sezione <ref id="lilo" name="Passare argomenti Ethernet..."> per la sintassi
completa, i parametri specifici delle schede ed alcune dritte su LILO.

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

<sect1>Il comando <tt/ether=/ non è servito a niente. Perché?
<p>
Come descritto sopra, il comando <tt/ether=/ funziona <em/solo/ per
driver compilati nel kernel. Adesso molte distribuzioni usano 
driver in forma modulare, perciò il comando <tt/ether=/ viene usato di rado
(parti della documentazione sono ancora state aggiornate per riportare questo
cambiamento). Se si vogliono usare delle opzioni per un driver Ethernet modulare
si <em/devono/ fare modifiche al file <tt>/etc/conf.modules</tt>.

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

<sect1>Problemi con schede NE1000/NE2000 (e cloni)<label id="ne2k-probs">
<p>
<bf/Problema:/ Una scheda PCI compatibile con NE2000 non viene rilevata
all'avvio del sistema usando una versione del kernel 2.0.x.

<bf/Causa:/
Il driver <tt/ne.c/, fino alla versione 2.0.30 del kernel, riconosce
solo il numero identificativo PCI delle schede compatibili basate su RealTek
8029. Da allora, molti altri produttori hanno distribuito schede PCI
compatibili con la NE2000 corredate di altri numeri identificativi PCI che il
driver riconosce.

<bf/Soluzione:/
La soluzione più semplice consiste nell'aggiornare il kernel di Linux
alla versione 2.0.31 (o più recente). Questa versione del kernel è al corrente
dei numeri identificativi di circa cinque chip diversi PCI/NE2000 e li rileva
automaticamente all'avvio o nella fase di caricamento del modulo. Inoltre, se
si aggiorna il kernel 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.

<bf/Problema:/
Una scheda PCI compatibile con NE2000 viene identificata come una ne1000 (a
8 bit!) all'avvio o quando si carica il modulo ne.o per la versione 2.0.x del
kernel, e di conseguenza non funziona.

<bf/Causa:/
Alcuni cloni PCI non implementano l'accesso byte wide (perciò non
sono realmente compatibili NE2000 al 100&percnt;). Ciò fa pensare
al sistema che esse siano schede NE1000.

<bf/Soluzione:/
È necessario aggiornare il kernel alla versione 2.0.31 (o più
recente) come descritto in precedenza. La nuova versione del driver
&egrave; stata aggiornata per tener conto di questo problema hardware.

<bf/Problema:/
Una scheda PCI compatibile NE2000 presenta prestazioni orribili, anche se si riduce la
dimensione della window come descritto nella sezione <ref
id="perf" name="Suggerimenti per le prestazioni">.

<bf/Causa:/
Le specifiche per il chip 8390 originale, progettato e
commercializzato più di dieci anni fa, indicavano che per ottenere la
massima affidabilità, era necessaria una lettura fittizia dal chip
prima di ogni operazione di scrittura. Il driver &egrave; in grado di far questo
ma tale funzionalit&agrave; è stata disabilitata per default sin dai tempi dei kernel 1.2.
Un utente ha riferito che riabilitare questa 'mis-feature' ha migliorato
le prestazioni ottenute con un clone economico NE2000 su bus PCI.

<bf/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 <tt>linux/drivers/net/</tt>, togliendo il commento
alla riga contenente <tt/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 <tt/ne2k-pci.c/).

<bf/Problema:/
Il driver <tt/ne2k-pci.c/ riporta messaggi di errore del tipo <tt/timeout waiting for Tx RDC/
con una scheda compatibile NE2000 su PCI e non funziona correttamente.

<bf/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 da
questo driver.

<bf/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 siano troppo stringenti per ottenere
operazioni affidabili. Altrimenti, l'uso del driver ISA/PCI <tt/ne.c/
(o la rimozione di <tt/#define USE_LONGIO/ dal driver <tt/ne2k-pci.c/)
dovrebbe permettere di usare la scheda.

<bf/Problema:/ Una scheda ISA Plug and Play NE2000 (per esempio
RealTek 8019) non viene rilevata.

<bf/Causa:/
Le specifiche originarie NE2000 (e perciò il driver per Linux NE2000 un tempo incluso
con il kernel) non supportano il Plug and Play.

<bf/Soluzione:/Si installi la versione 2.4 del kernel (o successive), che include
un driver NE2000 con supporto PnP, oppure si usi il disco di configurazione
DOS fornito con la scheda stessa per disabilitare PnP e per assegnare la scheda
ad uno specifico indirizzo I/O e IRQ. Si aggiunga una riga a
<tt>/etc/modules.conf</tt> del tipo <tt/options ne io=0xNNN/ dove
<tt/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 <tt/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. 

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

<bf/Causa:/ Ciò è collegato alla modifica appena menzionata. Dopo
la verifica iniziale che un 8390 è all'indirizzo di I/O rilevato, si
effettua la re inizializzazione (reset) della scheda. Quando la scheda ha
completato tale operazione, si suppone che essa confermi che il reset è
stato completato. La vostra scheda non si comporta così &egrave; il driver
di conseguenza assume che nessuna scheda NE sia presente.

<bf/Soluzione:/ Si può dire al driver che si possiede una scheda
scadente specificando al momento dell'avvio il valore esadecimale
<tt/0xbad/, solitamente non usato, per <tt/mem_end/.
Quando si usa <tt/0xbad/, si <em/deve/ anche fornire un I/O base
diverso da zero per la scheda. Per esempio, una scheda a <tt/0x340/
che non dichiara il completamento del reset dovrebbe essere configurata
nel modo seguente:

<tscreen>
	LILO: linux ether=0,0x340,0,0xbad,eth0
</tscreen>
Ciò permette che il rilevamento della scheda continui anche se la
propria scheda non effettua l'ACK del reset. Se si sta usando il
driver come modulo, allora si può usare l'opzione <tt/bad=0xbad/
nella stessa maniera in cui si indica l'indirizzo di I/O.

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

<bf/Causa:/ Questo problema è stato riportato per kernel a partire
dalla versione 1.1.57 fino a quella corrente. Sembra confinato a poche
schede clone configurabili in software. Apparentemente queste schede si aspettano
di essere inizializzate in qualche modo speciale.

<bf/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.

<bf/Problema:/
Una scheda Ethernet NE*000 a <tt/0x360/ non viene rilevata.

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

<bf/Soluzione:/ Si sposti la propria scheda ad un indirizzo come
<tt/0x280, 0x340, 0x320/ o si compili il kernel senza il supporto per la
stampante su porta parallela.

<bf/Problema:/ La rete "scompare" ogniqualvolta si stampa qualcosa
(NE2000).

<bf/Causa:/
Il problema è lo stesso appena esaminato, ma su di un kernel più vecchio
che non verifica la sovrapposizione delle regioni di I/O. Si usi la stessa
soluzione vista prima e ancor meglio si installi un nuovo kernel.

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

<bf/Causa:/ Prima di tutto, c'&egrave; 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
<tt/ox57/ nei byte 14 e 15 della PROM SA sulla scheda. La propria
scheda non ce l'ha -- essa ha invece 'yy zz'.

<bf/Soluzione:/
Ci sono due modi di aggirare l'ostacolo. Il più facile consiste
nell'usare un valore di mem_end <tt/0xbad/ come descritto sopra per il
problema 'no reset ack'. Ciò consentirà di bypassare il controllo
della signature della scheda, sempre che si fornisca anche un valore per
l'indirizzo I/O base diverso da zero. Questa soluzione non richiede la
ricompilazione 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: &quot;Galleria della Vergogna&quot;) intorno alla riga 42. Questo elenco
è usato per rilevare i cloni disgraziati. Per esempio, le schede DFI usano
"DFI" nei primi 3 byte della PROM al posto di usare <tt/0x57/ nei byte
14 e 15 (come dovrebbero invece fare).

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

<bf/Soluzione:/
Si cambi l'indirizzo base della propria NE2000 con qualcosa come
<tt/0x340/. In alternativa si può usare il parametro di boot
"reserve=" in combinazione con l'argomento "ether=" per tutelare
la scheda da rilievi di altri driver di dispositivi.

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

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

<bf/Causa:/
È lo stesso problema visto in precedenza, si cambi l'indirizzo
della scheda Ethernet o si usino gli argomenti di boot reserve/ether.

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

<bf/Causa:/
No, in realtà ciò avviene durante il rilevamento SCSI "silenzioso" ed
è lo stesso problema che si &egrave; appena visto.

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

<bf/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. Il dimenticarsi di eseguire lilo, ecc. può
portare all'avviamento del vecchio kernel (si guardi attentamente l'ora e la
data di compilazione riportati all'avvio). È un errore banale, ma lo abbiamo
compiuto tutti in passato. Ci si assicuri che il driver sia
effettivamente incluso nel nuovo kernel cercando nel file
<tt/System.map/ una voce come <tt/ne_probe/.

2) Si controllino attentamente i messaggi di avvio. Davvero non si accenna
mai al fatto che si sta facendo un rilevamento ne2k, ad esempio 'NE*000
probe at 0xNNN: not found (bla bla bla)' o fallisce proprio
silenziosamente? C'è una grossa differenza tra i due casi.
Si usi <tt>dmesg|more</tt> 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 <tt>cat /proc/ioports</tt> e si verifichi
che l'intero spazio di I/O richiesto dalla scheda sia libero. Se si
parte da <tt/0x300/, il driver n2ek richiederà <tt/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 è quello del driver lp che riserva
<tt/0x378/ o il secondo canale IDE che riserva <tt/0x376/, il che
impedisce al driver ne il rilevamento in <tt/0x360-0x380/.

4) In maniera simile a quanto appena menzionato, si controlli <tt>/proc/interrupts</tt>.
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 dal fallimento silenzioso del driver,
allora lo si modifichi aggiungendo alcune chiamate a printk() alla procedura di rilevamento.
Per esempio nel driver ne2k si potrebbero aggiungere/rimuovere righe
(contrassegnate rispettivamente con un '+' o '-') in
<tt>linux/drivers/net/ne.c</tt> come dal seguente esempio:

<code>
    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;
+    }
</code>

La procedura di rilevamento produrrà ora messaggi di output per ogni indirizzo di porta
che esamina e si potrà capire se l'indirizzo della propria scheda è
stato rilevato o meno.

6) Ci si può anche procurare il diagnostico ne2k nel sito ftp di Don
(gi&agrave; citato nell'howto) e vedere se è in grado di rilevare la propria
scheda dopo che si è avviato Linux. Si usi l'opzione '<tt/-p 0xNNN/'
per dirgli dove cercare la scheda (l'indirizzo di default è <tt/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:

<code>
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.
</code>

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

L'output risultante quando non c'è nessuna scheda installata a
<tt/0x300/ sarà simile al seguente:

<code>
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.
</code>

I valori <tt/0xff/ compaiono poiché quello è il valore restituito
quando si legge una porta di I/O libera. Se qualche altro tipo di
hardware si trova nella regione rilevata, si possono vedere dei
valori diversi da <tt/0xff/.

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 fornito con la scheda. Può essere che
eseguano 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:

<tscreen>
	A:> ne2000 0x60 10 0x300
</tscreen>

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.

<sect1>Problemi con le schede SMC Ultra/EtherEZ e WD80*3 <label id="8013-probs">
<p>

<bf/Problema:/
Si ricevono messaggi come il seguente:

<verb>
	eth0: bogus packet size: 65531, status=0xff, nxpg=0xff
</verb>

<bf/Causa:/
C'è un problema di memoria condivisa.

<bf/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 <tt/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.

<bf/Problema:/
La scheda SMC EtherEZ non funziona nella modalità a memoria non
condivisa (PIO).

<bf/Causa:/
Le versioni più vecchie del driver Ultra supportavano la scheda solo
nella modalità a memoria condivisa.

<bf/Soluzione:/
Il driver incluso con il kernel a partire dalla versione 2.0 supporta anche la
modalità ad I/O programmato. Si aggiorni alla versione 2.0 (o più
recente) del kernel.

<bf/Problema:/
Le vecchie wd8003 e/o le wd8013 configurabili con jumpers hanno sempre
l'IRQ sbagliato.

<bf/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.

<bf/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).

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

<bf/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 sballati riportati.

<bf/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.

<sect1>Problemi con le schede 3Com<label id="3com-probs">
<p>
<bf/Problema:/
La 3c503 si sceglie l'IRQ N, ma questo serve ad un qualche altro
dispositivo che ha bisogno dello stesso IRQ (per esempio il driver del CDROM,
il modem, ecc.). Si può risolvere la cosa senza ricompilare il kernel?

<bf/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 <tt/ifconfig/.

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

Ciò che segue imposta IRQ 9, indirizzo I/O di base <tt/0x300/, &lt;valori
ignorati&gt; e if_port &num;1 (il transceiver esterno).

<tscreen>
	io=0x300 irq=9 xcvr=1
</tscreen>

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

<tscreen>
      LILO: linux ether=9,0x300,0,1,eth0
</tscreen>

Ciò che segue imposta l'IRQ3, la ricerca della locazione base,
&lt;valori ignorati&gt; e il transceiver di default if_port &num;0 (il
transceiver interno).

<tscreen>
      LILO: linux ether=3,0,0,0,eth0
</tscreen>

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

<bf/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 fa parte del precedente insieme, si otterrà il messaggio
di errore suindicato.
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}.

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

<bf/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?

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

<tscreen>
	LILO: linux ether=0,0,0,1,eth0
</tscreen>

dovrebbe funzionare per i driver compilati nel kernel.

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

<sect1>FAQ non specifiche ad una particolare scheda
<p>

<sect2>Linux e schede Ethernet ISA di tipo Plug and Play
<p>

Per ottenere i migliori risultati (e la minor scocciatura)) si
raccomanda di usare il programma (di solito DOS) fornito con la
propria scheda per disabilitare il meccanismo ISA-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
<tt/io=/ in <tt>/etc/modules.conf</tt>. Può darsi che si debba anche
entrare nel BIOS/CMOS setup e contrassegnare l'IRQ come Legacy-ISA al
posto di ISA-PnP (se il proprio computer ha questa opzione).

Si noti che non è necessario avere il 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 pussono anche scaricare gratuitamente OpenDOS e FreeDOS.

Se si necessita per compatibilità con un altro sistema
operativo che sia abilitato il meccanismo ISA-PnP, allora dovrete prendere
provvedimenti diversi a seconda della versione del kernel che state usando.
Con i kernel 2.2.x e precedenti si dovr&agrave; usare 
il pacchetto isapnptools che provveder&agrave; a 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 <tt/io=/.

Per i kernel 2.4.x e seguenti, supporto per il meccanismo ISA-PnP pu&ograve;
essere compilato direttamente nel kernel e se il vostro driver fa uso di questi 
meccanismi, la vostra scheda sar&agrave; configurata con un indirizzo I/O di base 
ed una linea IRQ disponibili senza bisogno di nessun intervento da parte vostra.
Si <em>eviti</em> di usare le applicazioni del pacchetto isapnptools ed il supporto
per ISA-PnP contenuto nel kernel allo stesso tempo - sarebbe una pessima idea!

Alcuni sistemi possiedono una opzione BIOS 'enable PnP OS' (or similare), ma
questa opzione non ha nulla a che vedere con l'hardware ISA-PnP. Si legga di seguito
se si desidera avere maggiori dettagli in merito. 

<sect2>un sistema PCI rileva la scheda ma il driver non riesce ad autoconfigurarsi (PnP OS)
<p>
Alcuni BIOS PCI potrebbero non abilitare tutte le schede PCI
all'accensione, specialmente se è attivata l'opzione "PNP OS"
del BIOS. Questa cosiddetta opzione è stata creata per supportare la versione
corrente di Windows che utilizza ancora alcuni driver in real mode. Si
disabiliti questa opzione oppure si provi ad aggiornare il sistema con un
driver più recente che abbia la capacit&agrave; di abilitare una scheda
disabilitata.

Si noti che i kernel della serie 2.4 supportano meglio l'uso di questa
opzione - nello specifico, voi dovreste poter usare questa opzione ed il 
kernel o i driver dovrebbero essere in grado di abilitare le schede da soli.

<sect2>In un sistema PCI, tutte le schede vengono rilevate ma due non funzionano 
<p>
La prima versione della specifica PCI permetteva ad alcuni slot di essere
designati come bus master mentre altri (non bus master) venivano designati come
slave. Per evitare i problemi causati da utenti che mettevano schede bus master
in slot slave, la seconda versione della specifica indicava che tutti gli slot
devono essere in grado di operare come bus master. Ciononostante, la maggior
parte dei chipset PCI possiedono solo quattro pin BM, per cui se voi 
avete una scheda madre con 5 slot, e pi&ugrave; che probabile che due slot
condividano lo stesso pin BM! Questo permette alla scheda madre di soddisfare i
requisiti della seconda specifica (ma certo non l'intento dei suoi autori).
Per cui, se avete parecchie schede e due di loro si rifiutano di funzionare, &egrave;
possibile che stiano condividendo lo stesso pin BM.
	
<sect2>Il mio sistema ha <tt>/etc/conf.modules</tt> e non <tt>/etc/modules.conf</tt>.
<p>
Distribuzioni pi&ugrave; stagionate avranno ancora <tt>conf.modules</tt> e non
<tt>modules.conf</tt>, che &egrave; un nome pi&ugrave; sensato. Le pi&ugrave; recenti
utilità si aspettano il nuovo nome, un fatto che dovete tener presente quando 
aggiornate un vecchio sistema.

<sect2>La scheda Ethernet non viene rilevata all'avvio
<p>
Di solito la causa di questo &egrave; che si sta utilizzando un kernel che non
include il supporto specifico per la propria scheda. Per un kernel modulare
ciò tipicamente significa che non si è richiesto il caricamento del modulo di
cui si ha bisogno.

Se si sta usando un kernel modulare come quelli installati dalla maggior parte
delle distribuzioni Linux, allora si provi ad usare l'utilità di configurazione
della distribuzione per selezionare il modulo/driver della propria scheda. Per
le schede ISA è buona norma determinare l'indirizzo I/O della scheda e
aggiungerlo come opzione (ad esempio <tt/io=0x340/) se l'utilità di
configurazione permette di indicare delle opzioni. Se la vostra distribuzione
non include alcuna utilità di configurazione allora si dovrà aggiungere il
nome corretto del modulo (e le sue opzioni) al file
<tt>/etc/modules.conf</tt> -- si veda <tt/man modprobe/ per maggiori dettagli.

Un'altra causa comune è la presenza di un altro dispositivo che utilizza 
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 <tt/0x300/ ed usa 32 byte allora il driver richiederà la
regione <tt/0x300-0x31f/. Se un qualsiasi altro dispositivo ha
registrato anche solo una porta all'interno di quell'intervallo,
il rilevamento non avrà luogo a quell'indirizzo e il driver continuerà
silenziosamente con il prossimo indirizzo fra quelli da testare. Quindi,
a boot completato, si faccia un <tt>cat /proc/ioports</tt> per verificare
che l'intero spazio d'I/O che la scheda richiede sia libero.

Un altro tipo di problema consiste nell'avere la propria scheda impostata dai
ponticelli a un indirizzo di I/O che non viene controllato per default. L'elenco
degli indirizzi controllati da ogni driver &egrave; facilmente reperibile giusto
dopo i commenti iniziali nel sorgente del driver stesso. Anche se l'impostazione
I/O della propria scheda non è nell'elenco degli indirizzi controllati, la si può
fornire al kernel durante il boot (per i driver compilati nel kernel) con il
parametro <tt/ether=/ come descritto in <ref id="lilo" name="Passare argomenti Ethernet...">.
I driver modulari possono fare uso dell'opzione <tt/io=/ in <tt>/etc/modules.conf</tt>
per specificare un indirizzo che non è testato per default.

<sect2>Il driver dichiara <tt>unresolved symbol ei_open</tt> e non viene caricato
<p>
State utilizzando una delle molte schede basate sul chip 8390 (o un suo clone).
Il driver per tali schede &egrave; composto da due parti - la parte che voi avete
cercato di caricare senza successo (come ad esempio <tt>ne2k-pci.o, ne.o, wd.o, smc-ultra.o</tt>),
e la parte dedicata al chip 8390. Questi driver vengono marcati con <em/(+8390)/
accanto al nome del modulo nella lista di informazioni specifiche per ogni produttore
(<ref id="card-intro" name="Informazioni specifiche su...">).

Si deve fare in modo che il modulo <tt>8390.o</tt> venga caricato <em/prima/ del
caricamento della seconda meta del driver, che in questo modo avr&agrave; a sua
disposizione tutte le funzioni necessarie.

Cause possibili includono: (1)aver dimenticato di eseguire depmod dopo aver
installato un nuovo kernel e relativi moduli cosicch&eacute; le varie relazioni
di dipendenza tra moduli come questa vengano gestite automaticamente; (2)l'uso di
<tt/insmod/ al posto di <tt/modprobe/, dato che insmod non controlla se esistono dei
vincoli di ordine nel caricamento dei moduli; (3) il fatto che il modulo <tt/8390.o/
non sia nella sua directory accanto all'altra met&agrave; del driver come dovrebbe.

<sect2><tt/ifconfig/ mostra un indirizzo di I/O sbagliato per la scheda
<p>
No, non lo fa, lo si sta solamente interpretando in modo sbagliato.
Questo <em/non/ è un bug e i numeri riportati sono corretti.
Si da il caso che in alcune schede basate su 8390 (wd80x3,
smc-ultra, ecc.) il chip 8390 in realtà risieda ad un offset
rispetto alla prima porta di I/O assegnata. Questo è il valore
salvato in <tt/dev->base_addr/ ed è ciò che <tt/ifconfig/ riporta.
Se si vuole vedere l'intero intervallo di porte che la propria
scheda usa, allora si usi <tt>cat /proc/ioports</tt> che risponder&agrave; con i
numeri che ci si aspettava.

<sect2>Le schede ISA a memoria condivisa non funzionano in un sistema PCI (<tt/0xffff/)
<p>
Questo problema solitamente si presenta come una lunga serie di letture di
valori <tt/0xffff/. Nessun tipo di scheda a memoria condivisa
potrà mai funzionare in un sistema PCI se il BIOS ed i valori nella CMOS non sono
stati prima settati correttamente. Il BIOS deve essere impostato per permettere
l'accesso in memoria condivisa dal bus ISA alla regione di memoria che
la propria scheda sta cercando di usare. Se non si sa quali impostazioni
siano appropriate allora si chieda al proprio fornitore o al locale esperto di computer.
Nei i BIOS AMI c'è solitamente una sezione "Plug and Play" dove si trovano
impostazioni come "ISA Shared Memory Size" e "ISA Shared Memory Base".
Per schede come la wd8013 e la SMC Ultra, si modifichi la dimensione predefinita da
"Disabled" a 16kB e si indichi l'indirizzo della memoria condivisa della propria
scheda come indirizzo di base.

<sect2>Sembra che la scheda invii dati ma non riceve niente
<p>
Si faccia un <tt>cat /proc/interrupts</tt>, il totale aggiornato del
numero di eventi di interrupt generati dalla propria scheda sarà
incluso nell'output. Se tale numero &egrave; 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 (indipendentemente dal fatto che l'altro dispositivo
abbia o meno un driver installato/disponibile). Si cambi l'IRQ di uno dei
due dispositivi con un IRQ ancora libero.

<sect2>Supporto per Asynchronous Transfer Mode (ATM)
<p>
Werner Almesberger sta lavorando al supporto ATM per Linux. Sta
lavorando con la scheda ENI155p della Efficient Networks (<url
url="http://www.efficient.com/" name="Efficient Networks">) e la
scheda ZN1221 della Zeitnet (<url url="http://www.zeitnet.com/"
name="Zeitnet">).

Werner dice 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:

<url url="http://lrcwww.epfl.ch/linux-atm/" name="Linux ATM Support">

<sect2>Supporto per Gigabit Ethernet
<p>
C'è un qualche supporto per gigabit Ethernet sotto Linux?

Si, al momento c'&egrave; ne sono diversi. Uno dei principali sviluppatori
di Linux in ambito networking ha recentemente valutato le prestazioni delle
schede dotate di driver Linux come segue: 1) Intel E1000, 2) Tigon/Acenic,
3) SysKonnect sk-98xx, 4) Tigon3/bcm57xx. Questo era lo stato delle cose
nel marzo del 2002 ed &egrave; ovviamente una situazione in evoluzione.

<sect2>Supporto FDDI
<p>
C'è supporto per FDDI sotto Linux?

Sì. Larry Stefani ha scritto un driver per il kernel 2.0 usando le schede
DEFEA (FDDI EISA) e DEFPA (FDDI PCI) della Digital che &egrave; stato
incluso nel kernel 2.0.24. Al momento attuale non sono supportate altre
schede.

<sect2>Supporto Full Duplex
<p>

Il Full Duplex mi darà 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,
esso può mantenere la connessione occupata in entrambe le direzioni.
Non esistono cose come 10BASE-2 o 10BASE-5 full duplex. Il full
duplex funziona disabilitando il rilevamento delle collisione
nell'adattatore, e questo è il motivo per cui non lo si può fare con
un cavo coassiale; la LAN in questo modo non funzionerebbe. Lo standard
10BASE-T (interfaccia RJ45) usa cavi separati per la trasmissione
e la ricezione ed è così possibile utilizzare 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 non ci si deve aspettare un incremento delle
prestazioni di un fattore 2. Che il full duplex sia o meno supportato, la cosa
dipende dalla scheda e forse anche dal driver. Alcune schede
possono fare 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 utenti che facciano serio uso della rete noteranno la
differenza tra le due modalità.

<sect2>Schede Ethernet per Linux su macchine SMP
<p>
Se si &egrave; fatta la spesa per un computer multi processore (MP)
allora si compri anche una buona scheda Ethernet. Per i kernel 2.0
questo non è veramente necessario, ma lo è sicuramente per quelli 2.2.
La maggior parte delle schede più vecchie non intelligenti
(vale a dire disegnate per bus ISA in PIO e memoria condivisa) non furono mai
pensate considerando in alcun modo l'uso con macchina multiprocessore.
L'executive summary è di comperare una scheda intelligente di progettazione
moderna e assicurarsi che il driver sia stato scritto (o aggiornato)
per gestire il funzionamento in contesto MP (le parole chiave qui sono "progettazione
moderna": le NE2000 PCI sono semplicemente un progetto di 10 anni fa
adattato a un bus moderno). La presenza del testo <tt/spin_lock/ nei
sorgenti del driver è un buona indicazione che il driver è stato
scritto per operare in contesto MP. Si legga di seguito per i dettagli
completi sul perché di dovrebbe acquistare una buona scheda per l'uso
in ambiente MP (e cosa accade se non lo si fa).

Nei kernel 2.0, solo un processore alla volta poteva entrare "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 attorno a tutto il kernel che permetteva l'accesso
ad un solo processore alla volta. In questo modo si sa che non si avranno
mai due processori che provano a cambiare la stessa cosa allo stesso tempo!).

Lo svantaggio nel permettere ad un solo processore alla volta di entrare
in modalità kernel è che si ottengono delle prestazioni degne di una macchina
MP solamente se si eseguono programmi indipendenti e che fanno gran uso di operazioni
di calcolo. Se i programmi fanno un sacco di input/output (I/O) come ad esempio
il leggere e scrivere 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 degradano rapidamente
verso quelle di una macchina a singolo processore.

Poiché questa situazione è chiaramente inferiore al caso ideale (specialmente
per server di file/WWW, router, e cos&igrave; via) i kernel 2.2 hanno un lock
più granulare. Ciò significa che più di un processore alla volta può
operare 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 del disco.

Con tutto questo bene in mente, ecco le insidie: il locking più
granulare 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 statistiche di funzionamento della scheda per il comando
<tt>cat	/proc/net/dev</tt>). Oops, le statistiche della propria scheda
sono state appena inviate attraverso il cavo, mentre invece si
sono ricevuti i dati al posto delle statistiche. La scheda è stata
un po' confusa dalla richiesta di fare due (o più!) cose allo stesso
tempo ed è anche probabile che mandi in crash la macchina mentre
ci prova.

Quindi il driver che funzionava benissimo su di una macchina con CPU singola
non è più abbastanza buono e necessita di essere aggiornato con dei lock che
controllino l'accesso alla scheda cosicché i tre processi di ricezione,
trasmissione e manipolazione dei dati di configurazione siano serializzati
sufficentemente da poter permettere alla scheda di funzionare stabilmente.
La faccenda preoccupante è che un driver non ancora aggiornato con lock per
operazioni stabili in contesto MP sembrerà probabilmente funzionare su macchine
MP in presenza di un leggero carico di rete, ma provocherà il crash della macchina
o come minimo esibirà uno strano comportamento quando due (o più!) processori
proveranno a fare più di una di queste tre operazioni nello stesso momento.

Un driver Ethernet aggiornato per uso su di macchine MP richiederà (come minimo) un lock
attorno al driver che limiti l'accesso ai punti d'ingresso dal
kernel nel driver alla maniera di "uno alla volta, prego". Con
tale modifica, le operazioni saranno serializzate cosicché l'hardware
sottostante dovrebbe venire trattato come se fosse usato in una
macchina UP, e quindi dovrebbe essere stabile. Lo svantaggio di questa soluzione è
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 (anche se su scala più piccola), ovvero
si può avere un solo processore alla volta che usa la scheda.
&lsqb;Nota tecnica: L'impatto sulle prestazioni può anche
includere un incremento nelle latenze degli interrupt se i lock
che è necessario aggiungere sono del tipo <tt/irqsave/ e sono
tenuti per un lungo periodo di tempo.&rsqb;

Possibili miglioramenti a questa situazione possono essere ottenuti in
due modi. Si può provare a minimizzare il tempo che intercorre tra quando si richiede
il lock e quando lo si rilascia, e/o si può implementare un locking
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).

tuttavia, per le più vecchie schede	non intelligenti che non sono mai
state progettate pensando all'uso in ambito MP, potrebbe non essere
possibile realizzare nessuno di questi miglioramenti.

Ancora pi&ugrave; &egrave; il fatto che le schede non intelligenti
tipicamente richiedano che il processore sposti dati tra la scheda e
la memoria del computer, per cui nel caso peggiore il lock sarà mantenuto
per tutto il tempo necessario a spostare ciascun pacchetto da 1.5kB sul bus ISA.

Le più moderne schede intelligenti tipicamente spostano i dati
direttamente da e per la memoria del computer senza nessun aiuto da
parte del un processore. Questo &egrave; un grande vantaggio, 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 a richiedere meno spesso un unico grosso lock attorno all'intero
driver.

<sect2>Schede Ethernet per Linux su piattaforma Alpha/AXP e bus PCI
<p>

Dalla versione 2.0 del kernel, i soli 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 elencati nella pagina Web di Donald poiché
sono stati scritti con la portabilit&agrave; tra diverse architetture in mente.

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

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

<item>sostituire tutte le dereferenziazioni di puntatori nella memoria di I/O
(da 640k a 1MB) con le appropriate chiamate readb() writeb()
readl() writel(), come mostrato nel seguente esempio.
</itemize>

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

<itemize>
<item>sostituire tutte le chiamate memcpy() che hanno la memoria I/O
come sorgente o destinazione con le appropriate
<tt/memcpy_fromio()/ o <tt/memcpy_toio()/.
</itemize>

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

<sect2>Ethernet per Linux su hardware SUN/Sparc
<p>
Per le informazioni più aggiornate sull'hardware Sparc, si visiti il
seguente sito:

<url url="http://www.geog.ubc.ca/sparc" name="Linux Sparc">

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

I problemi riguardati il porting dei driver PCI su piattaforma Sparc
sono simili a quelli citati in precedenza per la piattaforma AXP. Inoltre
ci possono essere un po' di questione relative all'ordine dei byte, poiché
gli Sparc sono big endian mentre gli AXP e gli ix86 sono little endian.

<sect2>Ethernet per Linux su altro hardware
<p>
Ci sono parecchie altre piattaforme hardware sulle quali può girare
Linux, come Atari/Amiga (m68k). Come nel caso del port per Sparc è meglio
controllare nel sito ufficiale del port di Linux per la relativa piattaforma
e vedere cosa è supportato al momento (sono benvenuti link ai relativi siti -- inviatemeli!)

<sect2>Connettere 10 o 100 BaseT senza un hub
<p>
Si possono connettere assieme sistemi basati su 10/100BaseT (RJ45) senza
un hub?

Senza altri dispositivi o marchingegni si possono collegare 2
macchine (ma non di più) usando un cavo crossover. Tuttavia, alcune delle
recenti schede autonegozianti con pi&ugrave; fronzoli potrebbero non
riuscire a raccapezzarsi in un tale ambiente. E <em/no/, non si può metter su
un hub semplicemente incrociando un po' di fili assieme.
È praticamente impossibile produrre bene il segnale di collisione senza
creare un hub a tutti gli effetti.

<sect2>SIOCSIFxxx: No such device
<p>
Ricevo un sacco di messaggi 'SIOCSIFxxx: No such device' durante il boot,
seguiti da un 'SIOCADDRT: Network is unreachable'. Cosa c'è che
non va?

Il proprio dispositivo Ethernet non è stato rilevato al boot o
al caricamento del modulo e quando vengono eseguiti <tt/ifconfig/ e
<tt/route/ essi non trovano nessun dispositivo con cui operare. Si usi
<tt>dmesg | more</tt> per rivedere i messaggi di boot e vedere se
c'è un qualche messaggio riguardante il rilevamento della scheda Ethernet.

<sect2>SIOCSFFLAGS: Try again
<p>
Ottengo il messaggio di errore 'SIOCSFFLAGS: Try again' quando eseguo 'ifconfig'. Eh?

Qualche altro dispositivo si è preso l'IRQ che la propria scheda Ethernet
vuole 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 finito. Esempi di questo sono alcuni schede
audio, porte seriali, driver per floppy disk, ecc. Si può
usare il comando <tt>cat /proc/interrupts</tt> per vedere quali interrupt
sono al momento <em/in uso/. La maggior parte dei driver per
schede Ethernet su 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.

<sect2>Usando 'ifconfig' e Link di tipo UNSPEC con indirizzo hardware 00:00:00:00:00:00
<p>
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 succede 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 quindi non ha importanza pratica se ifconfig non può leggerlo.

Si possono ricevere strane informazioni se il programma <tt/ifconfig/
che si sta usando è molto più vecchio del proprio kernel.

<sect2>Enorme numero di errori in RX e TX
<p>
Quando eseguo ifconfig senza alcun argomento, mi dice che ho un
enorme numero di errori sia in pacchetti ricevuti che
trasmessi, ma tutto sembra funzionare bene. Cosa c'è che non va?

Si guardi di nuovo. Dice <tt/RX packets/ <em/grande numero/ <bf/PAUSE/
<tt/errors 0/ <bf/PAUSE/ <tt/dropped 0/ <bf/PAUSE/ <tt/overrun 0/.
Ed &egrave; pi&ugrave; o meno la stessa cosa per la colonna <tt/TX/.
Quindi i grandi numeri che si vedono sono il numero totale di pacchetti
che la propria macchina ha ricevuto e trasmesso. Se si &egrave; ancora
confusi da questa cosa, si provi invece ad usare <tt>cat /proc/net/dev</tt>.

<sect2>Voci in <tt>/dev/</tt> per le schede Ethernet
<p>
Ho /dev/eth0 come link (collegamento) a /dev/xxx. È giusto?

Contrariamente a ciò che probabilmente vi &egrave; stato detto, i file in /dev/* non vengono
utilizzati. Si può cancellare qualsiasi <tt>/dev/wd0, /dev/ne0</tt> e simili voci.

<sect2>Accesso a basso livello al dispositivo Ethernet
<p>
Come posso accedere a basso livello al dispositivo Ethernet in Linux,
senza passare attraverso TCP/IP e famiglia?

<code>
	int s=socket(AF_INET,SOCK_PACKET,htons(ETH_P_ALL));
</code>

Questo codice vi consente di avere un socket che riceve qualsiasi tipo di
protocollo. Si facciano chiamate a <tt/recvfrom()/ su 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 dati grezzi attraverso chiamate a <tt/sendto()/.
Naturalmente per fare entrambe le cose si deve avere l'accesso come root.

<sect>Suggerimenti per migliorare le prestazioni<label id="perf">
<p>
Ecco qua un po' di trucchi da usare se si soffre di problemi di
basso throughput Ethernet o per guadagnare un pochino di velocità nei
trasferimenti ftp.

Il programma <tt/ttcp.c/ è un buon test per misurare la velocità di
throughput. Un altro modo comunemente usato è di fare un <tt>ftp> get
grosso_file /dev/null</tt> dove	<tt/grosso_file/ è &gt;1MB e
risiede nel buffer della macchina in trasmissione (si faccia il 'get' almeno
due volte, poiché la prima volta si caricherà la cache del buffer
nella macchina in 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 <tt>/dev/null</tt>
piuttosto che al disco.

<sect1>Concetti generali
<p>
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 dove mettere i nuovi pacchetti.

In questo caso o si perdono (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 ritrasmissione e degradando seriamente le
prestazioni fino ad un fattore di 5!

Le schede con a bordo più memoria sono in grado di bufferizzare
più pacchetti e quindi gestire grossi picchi di traffico (burst)
back-to-back senza perdere nessun pacchetto. D'altra canto questo significa
che la scheda non necessita di una cos&igrave; bassa latenza 
nell'estrazione dei pacchetti dal buffer da parte del computer 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 per Linux riserva 3kB del buffer per due
buffer di trasmissione, 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).

<sect1>Schede ISA e velocità del bus ISA
<p>
Come menzionato in precedenza, se i pacchetti vengono rimossi abbastanza
velocemente dalla scheda allora la condizione di drop/overrun non
si verificherà anche se la dimensione del buffer per i pacchetti in arrivo è
ridotta. Il fattore che determina la frequenza con la quale i
pacchetti vengono rimossi dalla scheda e messi nella memoria del
computer corrisponde alla velocità del percorso dati che collega le due,
ovverosia la velocità del bus ISA (ma 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 setup della CMOS, 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 è
vincolati dalle 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.

<code>
	Velocità bus ISA (MHz)     Rx TTCP (kB/s)
	----------------------    --------------
	6.7                       740
	13.4                      970
	20.0                      1030
	26.7                      1075
</code>

Voglio vedere chi riesce a far meglio di 1075kB/s con una
<em/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 è bloccata
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.

<sect1>Impostare la finestra TCP di ricezione (TCP Rx Window)
<p>

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 dei 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 <tt/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 o gateway sono abbastanza 'bufferizzati' da non avere
problemi. Un esempio d'uso potrebbe essere:

<code>
	route add <qualcosa> ... window <dim_fin>
</code>

dove <tt/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 possono
verificare le condizioni operative con <tt>cat /proc/net/dev</tt>,
che elencher&agrave; il numero di drop/overrun verificatisi.

<sect1>Incrementare le prestazioni NFS
<p>
Alcuni utenti hanno osservato che l'uso di una scheda a 8 bit con client NFS
causa prestazioni peggiori di quanto previsto quando vengono usati
pacchetti di 8kB (la dimensione nativa Sun).

Una possibile causa di questo potrebbe essere la
differente dimensione del buffer a bordo tra schede a 8 e 16
bit. La dimensione massima di un pacchetto Ethernet è di approssimativamente 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. Il fatto che le schede a 8 bit
necessitano di un ulteriore ciclo di bus ISA per ogni
trasferimento non aiuta. Quel che si <em/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 svuotato più
velocemente. Ho scoperto che una vecchia scheda WD8003E a 8MHz
(senza altro carico di sistema) può sostenere un traffico notevolei 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 un 1kB per i pacchetti NFS e si usa come minimo una scheda ISA a 16 bit,
si riscontrerà un incremento significativo nel passare a pacchetti NFS di 4kB
(o addirittura 8kB).

<sect>Informazioni specifiche su produttori e modelli<label id="card-intro">
<p>
Di seguito sono elencate molte schede in ordine alfabetico secondo
il nome del produttore e il nome/sigla identificativa del prodotto.
Accanto all'identificativo di ciascuna scheda, si vedr&agrave; indicato "Supportata",
"Semi supportata", "Obsoleta", "Rimossa" oppure "Non supportata".

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

Semi supportata significa che esiste un driver, ma si verifica almeno una
delle condizioni seguenti: (1) Il driver e/o l'hardware ha dei bug
che possono provocare prestazioni scadenti, perdita di connessione
e persino crash del sistema; (2) Il driver è nuovo e la scheda è poco comune e
quindi il driver non è stato collaudato molto e il suo autore ha
quindi ricevuto poco feedback sul suo funzionamento. Ovviamente la condizione (2) è preferibile alla
(1) e la descrizione di ciascuna scheda/driver dovrebbe chiarire quale
delle due condizioni sia applicabile. In entrambi i casi, probabilmente
sarà necessario rispondere 'Y' (sì) alla domanda "Prompt for development and/or
incomplete code/drivers?" quando si lancia <tt/make config/ per poter poi utilizzare questi
driver.

Obsoleta significa che un driver esiste e che la scheda era probabilmente considerata
una volta come semi-supportata. Tuttavia, a causa di mancanza di interesse,
utenti e supporto, il driver &egrave; risaputo essere non pi&ugrave; funzionante.
Il driver stesso viene ancora incluso nel kernel, ma &egrave; disabilitato
nel menu delle opzioni di configurazione. In generale il piano &egrave; che
se un driver marcato come obsoleto non viene aggiornato durante il seguente
ciclo di sviluppo del kernel, esso verr&agrave; rimosso completamente. Solitamente
un driver indicato come obsoleto richiede solamente una rinfrescata per adattarsi
a cambiamenti introdotti nell'interfaccia per driver del kernel o ad altri cambiamenti
simili nelle API del kernel.

Rimossa significa che un driver che era ad un tempo obsoleto (vedi sopra)
&egrave; stato rimosso dal sorgente per il kernel corrente a causa della mancanza
generale di interesse nell'aggiornarlo. Nulla impedisce a qualcuno di recuperare
il sorgente per il driver da una versione precedente del kernel e, dopo aver
provveduto ai necessari cambiamenti, usarlo.

Non supportata significa invece che attualmente non è disponibile
alcun driver per quella scheda. Ciò può essere dovuto alla mancanza
di interesse in hardware che è 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.
Quindi ci si consideri cautelati perché può succedere che si trovi una
scheda segnata come semi-supportata che nel caso in questione
funziona perfettamente (il che è ottima cosa) esattamente come si pu&ograve;
incappare in una scheda indicata come supportata che in realtà da origine ad
una serie infinita di problemi (il che non è proprio un bene) sulla vostra macchina.

Dopo lo stato, &egrave; elencato il nome che il driver ha nel kernel di Linux.
Questo è anche il nome del modulo del driver che andrebbe eventualmente utilizzato
nella voce <tt/alias eth0 nome_driver/ nel file di configurazione dei moduli
<tt>/etc/modules.conf</tt>.

<sect1>3Com<label id="3com">
<p>
Se non si è sicuri di cosa sia la propria scheda, ma si pensa che sia
una scheda 3Com, probabilmente lo si può scoprire dall'assembly number
della scheda. La 3Com ha un documento 'Identifying 3Com Adapters By
Assembly Number' (ref 24500002) che molto probabilmente farà al
vostro caso per chiarire le cose. Si controlli anche i siti Web ed FTP
<tt/www.3Com.com/ di 3com per informazioni e strumenti che possano 
risultavi utili (ivi inclusa la documentazione tecnica sulle schede
rilasciata in formato PDF).

<sect2>3c501<label id="3c501">
<p>
Stato: Semi supportata, Nome del Driver: 3c501

Questa obsoleta scheda a 8 bit dell'età della pietra è veramente
troppo "demente" per poter essere utilizzata, 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, come non può ricevere un pacchetto mentre sta
caricando un pacchetto da trasmettere. Questo non era un problema in reti
composte da due 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, il DMA non viene usato, l'autoprobe ricerca solo agli
indirizzi <tt/0x280/ e a <tt/0x300/ e il livello di debug è impostato con il
terzo argomento al momento del boot.

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

<sect2>EtherLink II, 3c503, 3c503/16<label id="3c503">
<p>
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 su disable (disabilitato) 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à ad I/O
programmato a meno che non se ne abbia bisogno per compatibilità con
un altro sistema operativo installato sullo stesso computer.

La linea IRQ della 3c503 è impostata dal software, con nessun
aiuto da parte della EEPROM. Diversamente dal driver MS-DOS,
quello per Linux ha funzionalità di autoIRQ e adotta la prima linea IRQ
libera nell'insieme {5,2/9,3,4}, selezionandola ogni volta che la scheda è
configurata con ifconfig. 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
nella sezione <ref id="3com-probs" name="Problemi con...">.

Se si intende usare questo driver come modulo caricabile probabilmente
si dovrebbe fare riferimento alla sezione <ref id="modules" name="Usare un driver Ethernet come modulo">
per informazioni specifiche sui moduli.

<sect2>Etherlink Plus 3c505<label id="3c505">
<p>
Stato: Semi supportata, Nome del driver: 3c505

Queste schede usano il chip i82586, ma non ci sono poi tante schede di questo tipo in giro.
Il driver viene incluso nel kernel standard, ma &egrave; dichiarato come driver alpha.
Si veda la sezione <ref id="alfa" name="Driver alpha"> per importanti
informazioni sull'uso con Linux di driver Ethernet in alpha testing.

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

<sect2>Etherlink-16 3c507<label id="3c507">
<p>
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
alpha. Si veda la sezione <ref id="alfa" name="Driver
alpha"> per importanti informazioni sull'uso con Linux di
driver Ethernet in alpha testing.

<sect2>Etherlink III, 3c509 / 3c509B<label id="3c509">
<p>
Stato: Supportata, Nome del driver: 3c509

Questa scheda era piuttosto economica e aveva buone prestazioni per essere
una ISA senza bus-master. Gli svantaggi erano che la 3c509 originale
richiedeva 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 trasferimenti in PIO mode, analogamente a una
scheda ne2000 e quindi, in confronto, una scheda a memoria condivisa
come una wd8013 sarà più efficiente.

La 3c509 originale aveva un buffer per pacchetti troppo ridotto (4kB totali,
2kB in ricezione, 2k in trasmissione), cosicché qualche volta il driver perdeva dei
pacchetti se gli interrupt venivano mascherati troppo a lungo. Per
minimizzare questo problema, si può provare a non mascherare gli
interrupt durante i trasferimenti dai dischi IDE (si veda <em/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 di memoria e il buffer può
essere diviso in 4/4, 5/3 o 6/2 per ricezione e trasmissione. Questa impostazione è
modificabile con l'utilità di configurazione DOS ed è salvata nella
EEPROM. Questo dovrebbe alleviare il problema della 3c509 originale.

Gli utilizzatori della 3c509B dovrebbero usare l'utilità DOS
fornita con la scheda per disabilitare il supporto <em/plug and play/ <em/e/
per impostare il tipo di uscita di cui si ha bisogno. Il driver per
Linux attualmente <em/non/ supporta la l'autodetect dell'uscita utilizzata,
quindi si <em/deve/ selezionare 10Base-T, 10Base-2 oppure AUI. Si
noti che se si disabilita completamente il PnP, si dovrebbe uscire dall'utilità
di configurazione e far seguire un hard reset della macchina per assicurarsi che
i nuovi settaggi abbiano avuto effetto.

Alcuni chiedono delucidazioni sulle impostazioni "Server or
Workstation" e "Highest Modem Speed" presenti nella utilità di
configurazione sotto DOS. Questi settaggi in effetti non cambiano nulla
in hardware e sono solo dei consigli per il driver DOS. Il driver di Linux
non ha bisogno ne fa uso questi parametri. Infine, non si abiliti la modalita EISA 
su questa scheda ISA a meno che non si disponga effettivamente di una macchina
EISA, o si potrebbe finire a cercare di recuperare una macchina EISA solo
per poter riportare la scheda in modalita ISA!

La scheda con il più basso indirizzo
Ethernet hardware alla fin fine sarà <em/sempre/ la <tt/eth0/ in una configurazione
con pi&ugrave; 3c509. Questa cosa non dovrebbe preoccupare nessuno, tranne coloro
che vogliano assegnare un indirizzo hardware da 6 byte a una particolare
interfaccia. 

Se quest'ultima cosa vi preoccupa veramente, si dia un'occhiata
all'ultimo driver di Donald, in quanto si può essere in grado di usare
il valore <tt/0x3c509/ nei campi di indirizzo di memoria non utilizzati
per ordinare il rilevamento ed adattarlo alle proprie particolari necessità.

<sect2>3c515<label id="cork">
<p>
Stato: Supportata, Nome del driver: 3c515

Questa scheda, nome in codice "CorkScrew", è la scheda a 100Mbps ISA
offerta dalla 3COM, ma si noti che non &egrave; possibile raggiungere 
la piena velocit&agrave; di 100Mbps su di un bus ISA.

<sect2>3c523<label id="3c523">
<p>
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. 

<sect2>3c527 Etherlink MC/32<label id="3c527">
<p>
Stato: Semi supportata, Nome del driver: 3c527

Sì, un'altra scheda MCA basata sul chip i82586. No, non riscuote molto interesse.
Se si è impelagati con l'MCA si avr&agrave; probabilmente maggior fortuna con la 3c529,
dato che usa il collaudato core 3c509.

<sect2>3c529<label id="3c529">
<p>
Stato: Supportata, Nome del driver: 3c509

Questa scheda in realtà usa lo stesso chipset della 3c509. Degli utenti
hanno effettivamente utilizzato questa scheda su macchine MCA.

<sect2>3c556
<p>
Stato: Supportata, Nome del driver: 3c59x

	Una interfaccia mini PCI usata in parecchi laptop IBM e HP, altres&igrave; conosciuta
    come un 'laptop tornado'.

<sect2>3c562
<p>
Stato: Supportata, Nome del driver: 3c589_cs

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 Linux
condividano lo stesso interrupt. C'è il supporto per alcuni nuovi
registri e un po' per la condivisione degli interrupt hardware. 

Grazie ancora a Cameron per aver fornito a David Hinds un campione di
questo prodotto e la relativa documentazione.

<sect2>3c575
<p>
Stato: Supportata, Nome del driver: 3c59x

Si noti che per supportare questo dispositivo cardbus in vecchi kernel 
2.2 si doveva usare 3c575_cb.c, che poteva essere recuperato nel package
pcmcia_cs.

<sect2>3c579<label id="3c579">
<p>
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 è proprio impressionante. 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.

<sect2>3c589 / 3c589B<label id="3c589">
<p>
Stato: Semi-supportata, Nome del driver: 3c589_cs

Molti utenti stanno usando questa scheda PCMCIA da un po' di tempo.
La "B" nel nome significa la stessa cosa che nel caso della 3c509.

<sect2>3c590 / 3c595<label id="vortex">
<p>
Stato: Supportate, Nome del driver: 3c59x

Queste schede "Vortex" sono per macchine a bus PCI: la 590 era il prodotto di
3Com a 10Mbps mentre la 595 era il prodotto per il segmento di mercato a 100Mbps.
Si noti inoltre che si può usare la 595 come una 590 (cioè in modalità a
10Mbps). La linea 3c59x &egrave; stata rimpiazzata dalla 3c9xx da parecchio tempo,
e di conseguenza queste schede vengono considerate piuttosto obsolete.

Si noti che in giro si sono due diverse schede 3c590: i primi modelli
avevano 32kB di memoria sulla scheda mentre gli ultimi modelli hanno solo
8kB di memoria. La 3c595 ha 64kB, in quanto non si può andare molto lontano con
soli 8kB a 100Mbps!

<sect2>3c592 / 3c597
<p>
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.

<sect2>3c900 / 3c905 / 3c905B / 3c905C / 3c905CX
<p>
Status: Supportate, Nome del driver Name: 3c59x

Queste schede (altrimenti note come 'Boomerang' o EtherLink III XL)
sono state rilasciate per sostituire le schede 3c590/3c595, e supporto
aggiuntivo &egrave; stato inserito nel driver vortex/3c59x. Il driver incluso
in versioni del kernel pi&ugrave; vecchie potrebbe non supportare le
ultime revisioni di queste schede, in qual caso si potrebbe aver bisogno
di driver aggiornati.

Si noti che la 3c905C ha funzionalit&agrave; di checksum a bordo (in hardware),
cosa che riduce il carico di lavoro della CPU.

<sect2>3c985 (Gigabit acenic, Tigon2)
<p>
Stato: Supportata, Nome del driver: acenic

Questo driver supporta diverse altre schede Gigabit oltre al modello 3Com.

<sect2>3c996 (Gigabit broadcom, Tigon3)
<p>
	Stato: Supportata, Nome del driver: tg3, bcm5700(vecchio driver)

    Questo driver supporta svariate altre schede Gigabit oltre al
    modello di 3com. Il driver <tt/tg3/ &egrave; una riscrittura completa
    a cura di un gruppo di diversi sviluppatori Linux fatta nel
    tentativo di produrre un driver migliore di quellodel produttore <tt/bcm5700/.

<sect1>Accton<label id="accton">
<p>

<sect2>Accton MPX
<p>
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.

<sect2>Accton EN1203, EN1207, EtherDuo-PCI
<p>
Stato: Supportata, Nome del driver: de4x5, tulip o 8139too

Sembra che ci siano state diverse revisioni della EN1207 (da A a D), di cui
la A, B e C basate sul chipset tulip e la D basata sul chip Realtek 8139, che
richiede quindi un driver diverso.

Come per qualsiasi acquisto, la si dovrebbe provare assicurandosi
di poterla restituire nel caso non la possiate usare sul vostro sistema.

<sect2>Accton EN2209 Parallel Port Adaptor (EtherPocket)
<p>
Stato: Semi supportata, Nome del driver: ?

Era disponibile un driver per questi adattatori su porta parallela per i
kernel 2.0 e 2.1. La sua ultima locazione conosciuta era:

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

<sect2>Accton EN2212 PCMCIA Card
<p>
Stato: Supportata, Nome del driver: pcnet_cs

<sect1>Adaptec
<p>
    Si noti che le pi&ugrave; vecchie schede Adaptec a 32 bit usavano un 
    clone del chipset tulip.

<sect2>Adaptec DuraLAN/Starfire, 64bit ANA-6922
<p>
	Stato: Supportata, Nome del driver: starfire

<sect1>Allied Telesyn/Telesis<label id="allied-telesis">
<p>

<sect2>AT1500<label id="at-1500">
<p>
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. Queste 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 nella sezione <ref id="lance" name="AMD LANCE">.

<sect2>AT1700<label id="at1700">
<p>
Stato: Supportata, Nome del driver: at1700

Si noti che per accedere a questo driver durante il <tt/make config/
si deve ancora rispondere 'Y' alla domanda iniziale "Prompt for
development and/or incomplete code/drivers?" durante la compilazione.
Ciò è dovuto semplicemente allo poco feedback avuto sulla stabilità del driver a
causa della relativa rarità della scheda. Se si hanno problemi con il
driver distribuito assieme al kernel, un driver alternativo &egrave; reperibile a:

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

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.

Il chip Fujitsu utilizzato nella AT1700 ha un difetto di
progettazione: può essere reinizializzato completamente solo
togliendo alimentazione alla macchina. Premendo solamente
il pulsante di reset non si inizializza l'interfaccia del bus. Questo non
sarebbe un grosso problema, se non fosse per il fatto che la scheda può
essere rilevata con certezza solo quando è stata reinizializzata. La
soluzione è di spegnere la macchina se il kernel ha problemi a rilevare l'AT1700.

<sect2>AT2400<label id="at2400">
<p>
	Stato: Supportata, Nome del driver: ne, ne2k-pci (+8390)

	Ancora un altra scheda compatibile con la NE2000 PCI. Questa &egrave; basata
	sul chip RealTek 8029.

<sect2>AT2450<label id="at2450">
<p>
Stato: Supportata, Nome del driver: pcnet32

Questa è la versione PCI della AT1500 e non soffre dei problemi che ha
la scheda 79c970 PCI della Boca. Informazioni sulla selezione del DMA
e la numerazione del chip possono essere trovate nella sezione <ref
id="lance" name="AMD LANCE">.

<sect2>AT2500
<p>
Stato: Supportata, Nome del driver: 8139too, rtl8139(vecchio driver)

Questa scheda usa il chip 8139 della RealTek. Si veda la sezione
<ref id="rtl8139" name="RealTek 8139">.

<sect2>AT2540FX<label id="at2540">
<p>
Stato: Semi supportata, Nome del driver: eepro100

Questa scheda usa il chip i82557 e quindi potrebbe/dovrebbe funzionare con
il driver eepro100. Se la si prova a far questo si è invitati ad inviare un
rapporto in merito cosicché queste informazioni possano essere aggiornate.

<sect1>AMD / Advanced Micro Devices<label id="amd">
<p>

Carl Ching dell'AMD è stato talmente gentile da fornire una descrizione
molto dettagliata di tutti i prodotti Ethernet dell'AMD rilevanti per questo documento, 
il che mi hanno aiutato a chiarire un po' questa sezione.

<sect2>AMD LANCE (7990, 79C960/961/961A, PCnet-ISA)<label id="lance">
<p>
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
sulla 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 <ref id="at-1500" name="AT1500">) e la NE1500/2100 (si
veda la sezione <ref id="ne1500" name="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 necessario, il 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 piena 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 apparizione del messaggio 'busmaster arbitration
failure'. Questo accade quando il driver LANCE non può accedere
al bus dopo che è passato un ragionevole intervallo di tempo (50us).
Questo solitamente indica che l'implementazione del bus-master della scheda
madre ha dei problemi o che qualche altro dispositivo sta intasando il bus,
oppure che c'è un conflitto di canale DMA. Se il proprio BIOS include
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 la scheda solo in questi
indirizzi: <tt/0x300, 0x320, 0x340, 0x360/ e che qualsiasi indirizzo
fornito con l'argomento di boot <tt/ether=/ viene ignorato
silenziosamente (questo problema verrà corretto). 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, vengono usati dei 'bounce-buffer'
in memoria bassa (vale a dire che qualsiasi dato sopra il 16 MB è
copiato dentro un buffer sotto i 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 <ref id="ether" name="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 è l'eccezione: su questa scheda è facile
leggere i valori impostati nella EEPROM per IRQ e DMA.

<sect2>AMD 79C901 (Home PNA PHY)
<p>
Stato: Supportata, Nome del driver: sis900

Il file <tt>sis900.txt</tt> incluso con i kernel 2.4 afferma che
"la AM79C901 HomePNA PHY non &egrave; stato testato per esteso e 
potrebbero esserci dei driver nel cambio al volo del transceiver",
per cui si potrebbe voler controllare questo file se si usa un
kernel pi&ugrave; recente.

<sect2>AMD 79C965 (PCnet-32)<label id="pcnet-32">
<p>
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 <tt/lance.c/ standard, è disponibile anche
una versione a 32 bit (<tt/pcnet32.c/) che non si preoccupa mai delle
limitazioni ai 16 MB associate con il bus ISA.

<sect2>AMD 79C970/970A (PCnet-PCI)<label id="pcnet-pci">
<p>
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 il kernel abilitando il supporto
PCI. La 970A aggiunge al progetto originale il supporto full duplex
ed 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.

<sect2>AMD 79C971 (PCnet-FAST)
<p>
Stato: Supportata, Nome del driver: pcnet32

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

<sect2>AMD 79C972 (PCnet-FAST+)
<p>
Stato: Supportata, Nome del driver: pcnet32

Si &egrave; ricevuto conferma che questa scheda funziona proprio come la 971.

<sect2>AMD 79C974 (PCnet-SCSI)
<p>
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 quanto sia supportata la parte SCSI del chip:
questo è l'<em/Ethernet-HowTo/, non lo SCSI-HowTo.

<sect1>Ansel Communications<label id="ansel">
<p>

<sect2>AC3200 EISA
<p>
Stato: Semi-supportata, Nome del driver: ac3200

Questa scheda EISA &egrave; basata sul comune chip 8390 utilizzato anche
nelle schede ne200 e nella wd80x3.
Si noti che per accedere a questo driver durante il <tt/make config/
si deve rispondere 'Y' alla domanda iniziale "Prompt for
development and/or incomplete code/drivers?" durante la compilazione
del kernel. Questo è semplicemente dovuto al poco feedback ricevuto
dagli utenti sulla stabilità del driver a causa della relativa rarità
della scheda. Non si &egrave; ricevuto molto riscontro su questo driver
nonostante esso sia stato incluso nel kernel a partire dalla versione 1.1.25.

<sect1>Apricot
<p>

<sect2>Apricot Xen-II On Board Ethernet
<p>
Stato: Semi supportata, Nome del driver: apricot

Questa scheda Ethernet on board usa un chip i82596 bus-master. Può
essere collocata solamente all'indirizzo di I/O <tt/0x300/ e guardando
nei sorgenti del driver, sembra anche che l'IRQ sia fissato in hardware al 10.

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

<sect1>Arcnet<label id="arcnet">
<p>
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 dotati di schede Arcnet.

Un vantaggio di Arcnet è che tutte le schede hanno la medesima
interfaccia cosicché un unico driver funziona per tutte. Queste schede hanno
gestione degli errori integrata e quindi si può supporre che non perdano mai
pacchetti (ottimo per il traffico UDP!). Si noti che il driver arcnet usa
arc0 come suo nome invece del consueto eth0 dei dispositivi Ethernet.

Nel kernel standard ci sono file d'informazione sull'impostazione dei
ponticelli, suggerimenti generali e indicazione di dove inviare bug reports.

Sembra che il driver funzioni anche con le schede ARCnet a 100Mbs!

<sect1>Boca Research<label id="boca">
<p>

Sì, non producono solo schede seriali multiporta. :-)

<sect2>Boca BEN400
<p>
	Stato: Supportata, Nome del driver: ne (+8390)

	Apparently this is a NE2000 clone, using a VIA VT86C916 chip.

<sect2>Boca BEN (ISA, VLB, PCI)<label id="boca-ben">
<p>
Stato: Supportata, Nome del driver: lance, pcnet32

Questa schede sono basate sui chip PCnet dell'AMD.
Molti utenti hanno avuto un sacco di problemi con queste schede VLB/PCI. Sembra
che il problema sia dovuto alla mancata installazione di alcuni condensatori
nel progetto di Boca che AMD aveva raccomandato (i precedenti modelli ISA
non sono affetti da questo problema).

La Boca offriva una 'warranty repair' (ripazione in garanzia) per
i possessori di tali schede che consisteva nell'aggiunta di un
condensatore, ma sembra che la cosa non abbia funzionato al 100% per
la maggior parte delle persone, sebbene abbia aiutato alcuni. Queste
schede sono ora cos&igrave; vecchie che non vale la pena di disturbarsi
a provare.

Per ulteriori informazioni generali sui chip della AMD si veda la sezione
<ref id="lance" name="AMD LANCE">.

<sect1>Broadcom
<p>

<sect2>Broadcom Tigon2
<p>
	Stato: Supportata, Nome del driver: acenic

<sect2>Broadcom Tigon3
<p>
	Status: Supportata, Nome del driver: tg3

<sect1>Cabletron<label id="ctron">
<p>

Mancato rilascio di informazioni necessarie alla programmazione delle loro
schede da parte di Cabletron quando i driver furono sviluppati per queste
schede &egrave; risultata in un livello di supporto per queste schede 
inferiore a quello che si sarebbe potuto altrimenti ottenere.

Apparentemente la Cabletron ha cambiato la sua politica riguardo le
informazioni per la programmazione (come la Xircom). Comunque, a questo
punto, c'è una richiesta minima per driver modificati o aggiornati per
le vecchie schede E20xx e E21xx.

<sect2>E10**, E10**-x, E20**, E20**-x<label id="e10xx">
<p>
Stato: Semi supportate, Nome del driver: ne (+8390)

Queste sono praticamente dei cloni del3a serie NEx000 che dovrebbero
funzionare con i driver standard NEx000, grazie a una verifica
specifica per dispositivi Cabletron durante il rilevamento. 

<sect2>E2100<label id="e2100">
<p>
Stato: Semi supportata, Nome del driver: e2100 (+8390)

La E2100 &egrave; un orrido progetto. Ogniqualvolta mappa la sua memoria
condivisa durante un trasferimento di pacchetti, la mappa
in <em/un'intera regione di 128K/!  Ciò significa che
in quella regione <em/non si può/ usare con sicurezza un
altro dispositivo gestito a memoria condivisa, nemmeno un'altra
E2100. La scheda funzionerà senza problemi per maggior parte del tempo,
ma una volta ogni tanto il problema vi pungoler&agrave; (questo problema
può essere evitato disabilitando gli interrupt mentre si trasferiscono i
pacchetti, ma quasi certamente si perderanno dei battiti del clock).
Inoltre, se si commette un errore programmando la scheda o si ferma la
macchina proprio al momento sbagliato, nemmeno il pulsante di reset potrà
salvarvi. Si <em/deve/ spegnere la macchina e <em/lasciarla/ spenta per
almeno 30 secondi.

La selezione del tipo di cavo è automatica, ma volendo la si può forzare con
i bit meno significativi del parametro dev-&gt;mem_end. Se veda <ref
id="ether" name="PARAM_2">. Gli utilizzatori di driver modulari possono
specificare un valore <tt/xcvr=N/ come <tt/options/ nel file
<tt>/etc/modules.conf</tt>.

Inoltre, non si scambi la E2100 per un clone della NE2100.
La E2100 è una NetSemi DP8390 a memoria a condivisa approssimativamente
simile alla terribile WD8013, mentre la NE2100 (e la NE1500) usano
un design AMD LANCE con bus-mastering.

Se si ha intenzione di usare questo driver come modulo caricabile
probabilmente si dovrebbe leggere la sezione
<ref id="modules" name="Usare un driver Ethernet come modulo"> per
informazioni specifiche sull'uso di driver modulari.

<sect2>E22**<label id="e2200">
<p>
Stato: Semi supportata, Nome del driver: lance

Secondo le informazioni contenute in un bollettino tecnico della Cabletron,
queste schede usano il chip PC-Net dell'AMD (si veda <ref id="lance"
name="AMD PC-Net">) e dovrebbero quindi funzionare con il driver
lance generico.

<sect1>Cogent
<p>

<sect2>EM100-ISA/EISA
<p>
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 deve ancora essere verificata.

<sect2>Cogent eMASTER+, EM100-PCI, EM400, EM960, EM964
<p>
Stato: Supportate, Nome del driver: de4x5, tulip

Queste schede sono un'altra implementazione del DEC 21040 e quindi
si spera che funzionino 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 <ref id="dec-21040" name="DEC 21040"> per maggiori informazioni
su queste schede e la situazione di supporto attuale.

<sect1>Compaq
<p>
La Compaq non è veramente un costruttore di schede Ethernet,
ma un sacco di loro sistemi hanno controller Ethernet integrati nella scheda madre.

<sect2>Compaq Deskpro / Compaq XL (Embedded AMD Chip)
<p>
Stato: Supportati, Nome del driver: pcnet32

Le macchine 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 piazzi 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 viene mai rilevata e
non &egrave; nemmeno usabile (altro effetto: non funziona nemmeno il mouse).
Il modo per aggirare questo problema (come descritto approfonditamente in
http://www-c724.uibk.ac.at/XL/) è di avviare il sistema in 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 funzionante che conosco. Il driver semplicemente
si limita a spostare la directory PCI nel posto dov'è di solito (e dove Linux la può
trovare).»

L'utilità DOS <tt>movepci.exe</tt> dovrebbe essere reperibile
nel package di supporto <tt>SP1599.EXE</tt> se si avesse bisgno 
di una copia.

Altre informazioni a carattere generico sui chip AMD possono essere reperite nella
sezione <ref id="lance" name="AMD LANCE">.

<sect2>Compaq Nettelligent/NetFlex (Embedded ThunderLAN Chip)
<p>
Stato: Supportata, Nome del driver: tlan

Questi sistemi usano un chip ThunderLAN della Texas Instruments.
Informazioni sul driver ThunderLAN possono essere trovare nella sezione
 <ref id="tlan" name="ThunderLAN">.

<sect2>Compaq PCI card
<p>
	Stato: Supportata, nome del driver: eepro100

    Si controlli la scheda: se ha numero di parte 323551-821 e/o un chip 
    Intel 82558 allora &egrave; un altra scheda basata sull'Intel EEPro100.

<sect1>Danpex
<p>

<sect2>Danpex EN9400
<p>
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 la sezione <ref id="dec-21040" name="DEC 21040"> per maggiori
informazioni su queste schede e la corrente situazione di supporto del driver.

<sect1>Davicom
<p>

<sect2>Davicom DM9102
<p>
Stato: Supportata, Nome del Driver: tulip, dmfe

Questo &egrave; praticamente un clone del chip tulip e di conseguenza 
&egrave; possibile utilizzare per questa scheda il driver tulip o il driver
dmfe del produttore. L'approccio comune &egrave; di provare prima con il 
driver tulip, e solo in seguito di provare con il driver dmfe, che sembra essere
la scelta migliore solo per schede molto vecchie.

<sect1>D-Link<label id="d-link">
<p>

<sect2>DE-100, DE-200, DE-220-T, DE-250<label id="de-100">
<p>
Stato: Supportata, Nome del driver: ne (+8390)

Alcune delle prime schede D-Link non avevano la sequenza di identificazione
<tt/0x57/ nella PROM, ma il driver ne2000 ne è al corrente. Per quanto
riguarda le schede configurabili via software, si può scaricare il
programma di setup dal sito <tt/www.dlink.com/. Si noti che esistono
anche schede della Digital (DEC) chiamate DE100 e DE200, ma che la somiglianza
finisce qui.

<sect2>DE-520<label id="de-520">
<p>
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 <ref id="lance" name="AMD
LANCE">.

<sect2>DE-528
<p>
Stato: Supportata, Nome del driver: ne, ne2k-pci (+8390)

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

<sect2>DE-530<label id="de-530">
<p>
Stato: Supportata, Nome del driver: de4x5, tulip

Questa è un'implementazione generica del chip DEC 21040 e ci è stato riferito
che funziona con il driver generico tulip per il 21040.
Si noti che questa scheda NON &egrave;la DFE530.

Si veda la sezione <ref id="dec-21040" name="DEC 21040"> per maggiori
informazioni su queste schede e sullo stato attuale del driver.

<sect2>DE-600<label id="de-600">
<p>
Stato: Supportata, Nome del driver: de600

La DE600 &egrave; una vecchia interfaccia Ethernet per porta parallela
destinata tipicamente all'uso di utenti laptop.

Ci si aspetti una velocità di trasferimento di circa 180kb/s da questo dispositivo.
Si dovrebbe leggere il file README.DLINK nei sorgenti del kernel.

Si noti che il nome del device da passare a <tt/ifconfig/ <em/ora/
è <tt/eth0/ e non più il <tt/dl0/ usato in precedenza.

<sect2>DE-620<label id="de-620">
<p>
Stato: Supportata, Nome del driver: de620

Analoga alla DE-600, ma con due formati d'uscita. Si vedano le informazioni precedenti
sulla DE-600.

<sect2>DE-650<label id="de-650">
<p>
Stato: Semi supportata, Nome del driver: pcnet

Alcuni utenti hanno usato questa scheda PCMCIA da qualche
tempo nei loro computer portatili. In pratica è un design basato sul chip 8390,
come la NE2000. Si suppone anche che la scheda PCMCIA della LinkSys
e la IC-Card Ethernet siano dei cloni della DE-650. 

<sect2>DFE-530TX
<p>
Stato: Supportata, Nome del driver: via-rhine

Un altra scheda costruita sul chipset VIA Rhine. Schede di costruzione pi&ugrave;
utilizzano il RhineII (si veda la sezione <ref id="rhine" name="VIA Rhine">).
Non si confonda questa scheda con la DE-530 che invece basata sul chipset
tulip o con la DFE-530+ che invece &egrave; una 8139.

<sect2>DFE-530TX+, DFE-538TX
<p>
Stato: Supportata, Nome del driver: 8139too, rtl8139 (vecchio driver)

Questa scheda usa il chipset RealTek 8139, si faccia riferimento alla sezione
<ref id="rtl8139" name="RealTek 8139">

<sect2>DFE-550TX
<p>
Stato: Supportata, Nome del driver: sundance

<sect2>DFE-570TX
<p>
Stato: Supportata, Nome del driver: tulip

Questa &egrave; una scheda tulip (DS1143) a quattro porte.

<sect2>DFE-580TX
<p>
Stato Supportata, Nome del driver: sundance

<sect2>DGE-500T
<p>
Stato: Supportata, Nome del driver: ns83820

<sect2>DGE-550T
<p>
Stato: Supportata, Nome del driver: dl2k

<sect1>DFI<label id="dfi">
<p>

<sect2>DFINET-300 e DFINET-400<label id="dfi-300">
<p>
Stato: Supportate, Nome del driver: ne (+8390)

Queste due sono altri terribili cloni della scheda NE2000, che
usano 'DFI' come identificativo nei primi 3 byte della PROM, invece di usare <tt/0x57/
nei byte 14 e 15, che è quello che tutte le schede NE1000 e
NE2000 dovrebbero fare (la 300 è un pseudo-clone della NE1000 a 8 bit mentre la 400 è
una cattiva imitazione della NE2000).

<sect1>Digital / DEC<label id="dec">
<p>

<sect2>DEPCA, DE100/1, DE200/1/2, DE210, DE422<label id="dec-200">
<p>
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 e che queste schede
sono tutte basate sul chip LANCE dell'AMD. Si faccia riferimento alla sezione
<ref id="lance" name="AMD LANCE"> per maggiori informazioni. Si possono
usate sino ad un massimo di due schede ISA sullo stesso sistema, poiché esse possono
essere installare solamente  agli indirizzi di I/O base <tt/0x300/ e
<tt/0x200/. Se si intende farlo, si leggano le note nel file sorgente
del driver <tt/depca.c/ nell'albero dei sorgenti del kernel standard.

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

<sect2>Digital EtherWorks 3 (DE203, DE204, DE205)<label id="dec-ewrk3">
<p>
Stato: Supportata, Nome del driver: ewrk3

Queste schede usano un chip proprietario della DEC, invece del chip
LANCE utilizzato in schede precedenti come la DE200. Queste schede
supportano sia la memoria condivisa che l'I/O programmato, sebbene
si subisca un calo di prestazioni del 50&percnt; 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 <tt/ewrk3.c/ e nel file
<tt/README.ewrk3/. Ambedue i file sono nella distribuzione standard
del kernel. Questo driver include supporto per le CPU Alpha,
giusto 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
cos&igrave; via. Gli smanettoni vadano a 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 <tt/NICSETUP.EXE/) ed
altri strumenti, che possono essere trovati in praticamente tutti i
siti FTP di Linux nella directory
<tt>/pub/Linux/system/Network/management</tt> (si cerchi il file
<tt/ewrk3tools-X.XX.tar.gz/).

<sect2>DE425 EISA, DE434, DE435, DE500  <label id="dec-eisa">
<p>
Stato: Supportate, Nome del driver: de4x5, tulip

Queste schede si basano sul chip 21040 menzionato di seguito, in particolare  la
DE500 usa il chip 21140 per fornire connessioni Ethernet a 10/100Mbs.
Si deve legga la sezione seguente sul chip 21040 per ulteriori
informazioni. Esistono alcune opzioni da passare in compilazione
per le schede non DEC che usano questo driver. Si veda il file
<tt/README.de4x5/ per i dettagli.

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

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

<sect2>DEC 21040, 21041, 2114x, Tulip <label id="dec-21040">
<p>
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 bus PCI ma
sembra che questi chip non vengano pi&ugrave; prodotti da quando
Intel ha acquisito la divisione semiconduttori di Digital e ha
deciso di preferire la propria linea di chip Ethernet.

Per le schede basate su questo chip è possibile scegliere
tra <em/due/ driver. C'è il driver DE425 discusso in
precedenza e driver generico 'tulip' per il 21040.

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

«Non c'è alcuna garanzia che il 'tulip.c' o il 'de4x5.c' funzionino
con una qualsiasi scheda basata sulla famiglia DC2114x oltre a quelle per cui
sono stati scritti. PERCH&Eacute;??  Perché c'è un registro, il
General Purpose Register (CSR12) che (1) nel DC21140A è programmabile
da qualsiasi produttore di schede e tutti lo fanno in maniera diversa e (2) nei
DC21142/3 c'è ora un registro di controllo SIA (alla maniera della DC21041).
L'unico barlume di speranza è che si riesca a decodificare la SROM
per aiutare nell'impostazione del driver. Comunque, questa non è una
soluzione garantita in quanto alcuni produttori (per esempio nel caso della
scheda SMC 9332) non seguono le raccomandazioni di Digital Semiconductor sul
formato di programmazione della SROM.»

In termini non tecnici, ciò significa che se non si è sicuri che una
scheda sconosciuta con un chip DC2114x funzionerà con i driver per
Linux, e quindi ci si assicuri di poterla restituire dove la
si è comprata <em/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
supporta lo standard 100Base-T e funziona con i driver per Linux per il
chip 21040. Per usare il driver <tt/de4x5/ di David con una scheda
non DEC, si deve guardare il file <tt/README.de4x5/ per i dettagli.

Se si hanno problemi con il tulip driver, si pu&ograve; provarne
la versione più recente dal sito ftp/WWW di Donald.

	<url url="http://www.scyld.com/network"
		name="Tulip Driver">

All'URL precedente c'&egrave; anche un elenco (non esaustivo) delle diverse
schede e produttori che usano il chip 21040.

<sect1>Farallon
<p>
La Farallon vende le schede e i transceiver EtherWave. Questi
dispositivi permettono di concatenare diversi dispositivi 10baseT.

<sect2>Farallon Etherwave
<p>
Stato: Supportato, Nome del driver: 3c509

Ci &egrave; stato riportato che questo dispositivo &egrave; un clone del 3c509 che
include il transceiver EtherWave. La gente l'ha usato con successo
sotto Linux con l'attuale driver 3c509. Queste schede sono troppo costose per l'uso
comune, ma sono una utilissima opzione in casi speciali. I prezzi degli
hublet partono da &dollar;125, e l'Etherwave aggiunge
&dollar;75-&dollar;100 al prezzo della scheda <!-- worth
	it if you have pulled one wire too few, but not if you are two
	network drops short.-->
    
<sect2>Farallon PCI 593
<p>
Stato: Supportata, Nome del driver: de4x5, tulip

Ci &egrave; stato riferito che questa scheda &egrave; stata rilevata dal driver
<tt>de4x5</tt>.

<sect1>Fujitsu
<p>
Diversamente da molti sviluppatori di chip Ethernet, la Fujitsu ha prodotto
e venduto anche alcune schede di rete basate sui loro chip.

<sect2>Fujitsu FMV-181/182/183/184
<p>
Stato: Supportato, Nome del driver: at1700, fmv18x(vecchio driver)

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.

I kernel precedenti usavano usavano il driver <tt/fmv18x/ ma il supporto per
queste schede &egrave; stato aggiunto al driver <tt/at1700/ e cos&igrave; il 
vecchio driver &egrave; stato progressivamente ritirato.

	Older kernels used the driver <tt/fmv18x/ but support for
	these cards was added to the <tt/at1700/ driver and so
	the former has been phased out.

<sect1>Hewlett Packard<label id="hp">
<p>

<sect2>HP Night Director+ 10/100
<p>

Stato: Supportata, Nome del driver: pcnet32

Apparentemente queste schede usano il chip AMD 79C972.

<sect2>27245A<label id="hp-27245a">
<p>
Stato: Supportata, Nome del diver: hp (+8390)

Una 10BaseT a 8 bit basata sul 8390, non è raccomandata per tutte quelle
ragioni caratteristiche delle schede a 8 bit. 

<sect2>HP EtherTwist, PC Lan+ (27247, 27248, 27252A, 27269B)
<p>
Stato: Supportate, Nome del driver: hp+ (+8390)

La HP PC Lan+ è diversa dalla scheda HP PC Lan standard e può essere fatta
funzionare in modalità PIO come una ne2000, o in modalità a memoria
condivisa come una wd8013.

<sect2>HP-J2405A
<p>
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 socket per il boot PROM. 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) è stato incluso grazie alle informazioni fornite da Glenn
Talbott dell'HP.

<sect2>HP-Vectra On Board Ethernet
<p>
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 <ref id="lance" name="AMD LANCE">.

<sect2>Schede HP 10/100 VG Any Lan (27248B, J2573, J2577, J2585, J970, J973)
<p>
Stato: Supportate, Nome del driver: hp100

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

<sect2>HP NetServer 10/100TX PCI (D5013A)
<p>
Stato: Supportata, Nome del driver: eepro100

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

<sect1>IBM / International Business Machines<label id="ibm">
<p>

<sect2>IBM Thinkpad 300<label id="thinkpad-300">
<p>
Stato: Obsoleta, Nome del driver: znet

Questa scheda &egrave; basata sul chip Intel 82593 ed il relativo driver &egrave;
stato dichiarato obsoleto nei kernel della serie 2.4.

<sect2>IBM Credit Card Adaptor for Ethernet
<p>
Stato: Semi-supportato, Nome del driver: pcnet_cs

<sect2>IBM 10/100 EtherJet PCI
<p>
Stato: Supportata, Nome del driver: eepro100

Questa scheda &egrave; stata indicata come compatibile a livello di driver
con la Intel EtherExpress Pro 100.

<sect2>IBM Token Ring
<p>
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 source routing per token ring. Ed &egrave; proprio la scrittura di
queste ultime che richiederebbe il pi&ugrave; grande impegno.

L'iniziale sviluppo dei driver &egrave; stato fatto con schede IBM Token Ring
per bus ISA e MCA ed &egrave; stato testato con una scheda MCA 16/4 Megabit Token
Ring, ma dovrebbe funzionare con altre schede basate sul chipset Tropic.

<sect1>Schede Ethernet ICL
<p>

<sect2>ICL EtherTeam 16i/32
<p>
Stato: Supportata, Nome del driver: eth16i

Questo Driver Supporta sia la versione ISA (16i) che la versione EISA (32) della scheda
ed usa il chip MB86965 della Fujitsu, usato anche nelle schede at1700.

<sect1>Schede Ethernet Intel<label id="intel">
<p>
Si noti che la nomenclatura delle diverse schede Intel è ambigua e
quanto meno tende a confondere. Se si hanno dubbi, si veda il numero <tt/i8xxxx/
sul chip principale della scheda oppure, per le schede PCI, si usino
le informazioni PCI contenute nella directory <tt>/proc</tt> e poi le si
confronti con i numeri qui elencati. Infine, una pagina nell'area dedicata
alle reti sul sito http://support.intel.com risulta spesso d'aiuto se non
si riesce ad identificare la scheda di cui si &egrave; in possesso.

<sect2>Ether Express
<p>
Stato: Supportata, Nome del driver: eexpress

Questa scheda usa il chip i82586 dell'Intel. Le prime versioni di questo
driver (nei kernel 1.2) erano classificate come sperimentali e non
funzionavano bene per la maggior parte degli utenti. Il driver nei kernel 2.0
sembra funzionare molto meglio per coloro che lo hanno provato, sebbene il
driver sia ancora indicato come 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 rallentamento
di rimpiazzare nel driver tutti gli <tt/outb/ con <tt/outb_p/ sembra aver funzionato
per almeno un utente. Si controlli inoltre che la dimensione del buffer in RAM
indicata dal driver corrisponda con quanto riportato dall'utilità di Intel.

<sect2>Ether Express PRO/10 (PRO/10+)
<p>
Stato: Supportata, Nome del driver: eepro

Bao Chau Ha ha scritto un driver per queste schede che era incluso nei primi
kernel 1.3.x e può funzionare anche con alcuni sistemi Ethernet integrati
della Compaq basati sul chip i82595. Potrebbe essere necessario usare l'utilità
fornita con la scheda per disabilitare la funzionalit&agrave; plug and play
qualora questo fosse necessario.

<sect2>Ether Express PRO/10 PCI (EISA)
<p>
Stato: Semi supportata, Nome del driver: ? (distribuito separatamente)

Esiste un driver per la versione PCI di queste schede che viene distribuito
separatamente dai kernel di default. Queste schede usano il chip d'interfaccia
PCI PLX9036 ed un LAN controller chip i82596 della Intel. Se la propria scheda
usa invece il chip i82557, allora <tt/non/ si possiede questa scheda ma piuttosto
la versione discussa di seguito e quindi si deve invece usare il driver EEPro100.

Si può ottenere il driver sperimentale per la scheda PCI PRO/10 assieme alle
relative istruzioni per usarlo a:

<url url="http://www.ultranet.com/~stalba/eep10pci.html" name="EEPro10 Driver">

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 rilevamento usati nei due casi.

<sect2>Ether Express PRO 10/100B<label id="eepro100">
<p>
Stato: Supportata, Nome del driver: e100 o eepro100

Il driver e100 &egrave; stato rilasciato da Intel, mentre il driver eepro100
&egrave; stato scritto da Donald.
Si noti che il driver eepro100 <em/non/ funzionerà con le vecchie schede
100A. I numeri dei chip elencati nel driver sono i82557, i82558, i82559, i82801
e circa 25 altri ID PCI. Per aggiornamenti del driver e/o supporto sul driver, si veda

	<url url="http://www.scyld.com/network"
		name="EEPro-100B Page">

<sect2>E1000 Gigabit
<p>
Stato: Supportata, Nome del driver: e1000

<sect1>Kingston
<p>
La Kingston produce diverse schede, tra cui schede basate su NE2000+, AMD
PCnet e DEC tulip. La maggior parte di queste schede dovrebbe
funzionare bene con i rispetti driver. Si faccia riferimento alla <url
url="http://www.kingston.com" name="pagina web della Kingston">

<sect1>LinkSys
<p>
La LinkSys ha prodotto un numero di diversi cloni NE2000, alcune delle quali sono
schede ISA semplici, altre ISA plug-and-play e altre ancora sono cloni PCI della
ne2000 basati su uno dei chip PCI ne2000 supportati. Ci sono semplicemente troppi
modelli per elencarli tutti qui. Il loro sito &egrave; <tt>www.linksys.com</tt>

<sect2>Schede LinkSys Etherfast 10/100.
<p>
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 mentre la terza revisione usava un chip
Linksys 82c19 e la quarta usa il chip Comet di AMDtek. Il supporto
per le ultime tre varianti &egrave; stato aggiunto al driver tulip standard e potrebbe
essere necessario aggiornare i vostri driver a seconda di quanto vecchi essi siano.

Ulteriori informazioni sul PNIC sono disponibili sul sito

	<tt>http://www.scyld.com/network</tt>

Altre informazioni sulle diverse versioni di queste schede possono
essere trovate nella pagina WWW della LinkSys gi&agrave; menzionata in
precedenza.

<sect2>LinkSys Pocket Ethernet Adapter Plus (PEAEPP)
<p>
Stato: Supportata, Nome del driver: de620

Questo è un clone (o supposto tale) nel DE-620 e si dice funzioni bene
con il corrispondente driver. Si veda la sezione <ref id="de-620" name="DE-620">
per maggiori informazioni.

<sect2>LinkSys PCMCIA Adaptor
<p>
Stato: Supportato, Nome del driver: pcnet_cs

Questa è una versione rimarchiata del DE-650.

<sect1>Microdyne (Eagle)
<p>
Eagle Technology (un tempo anche conosciuta sotto il nome di Novell cards) &egrave;
stata acquisita da Microdyne. Se non potete trovare qui la vostra scheda, controllate
la sezione di questo documento dedicata a Novell. Mentre Microdyne non &egrave; pi&ugrave;
sul mercato con schede di rete, c'&egrave; ancora un po' di materiale relativo ai loro
prodotti di rete sul loro sito <tt/ftp.microdyne.com/. 

<sect2>Microdyne Exos 205T
<p>
Stato: Semi supportata, Nome del driver: ?

Un'altra scheda basata sul chip i82586. Dirk Niggemann
<tt/dirk-n@dircon.co.uk/ ha scritto un driver che lui classifica
come "pre-alpha" e vorrebbe che la gente testasse. Gli si scriva
per maggiori dettagli.

<sect1>Mylex
<p>

La Mylex può essere raggiunta ai seguenti numeri, nel caso qualcuno
voglia chieder loro qualcosa.

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

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

<sect2>Mylex LNE390A, LNE390B
<p>
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.

<sect2>Mylex LNP101
<p>
Stato: Supportata, Nome del driver: de4x5, tulip

Questa è una scheda PCI basata sul chip 21040 della DEC. Pu&ograve; essere
selezionata 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 (<ref id="dec-21040" name="DEC 21040">)
per maggiori informazioni.

<sect2>Mylex LNP104
<p>
Stato: Semi supportata, Nome del driver: de4x5, tulip

La LNP104 usa il chip 21050 della DEC per gestire <em/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).

<sect1>Myson
<p>
	
<sect2>Myson MTD-8xx 10/100 PCI
<p>
Stato: Supportata, Nome del driver: fealnx

Sembra che le schede vendute con il marchio Surecom EP-320X-S includano
anche loro questo chip.

<sect1>National Semiconductor
<p>
National Semiconductor &egrave; un produttore di microchip, non di schede di rete.
Dei terzi acquistano il loro chipset, li saldano su un pezzo di fibra di vetro con
altre schifezze, scrivono il loro nome sul tutto e ve lo rivendono.

<sect2>NS8390, DP8390, DP83905 etc.
<p>
Stato: Supportata, Nome del driver: 8390

L'infame chip 8390, reperibile in uno zilione di schede ISA, e clonato da diversi
altri produttori di chip. Si noti che il file <tt/8390.o/ non contiene un driver 
completo in se, ma va usato in congiunzione con un altro driver che conosce la
modalit&agrave; di interfacciamento tra l'8390 ed il bus del computer. Esempi di
questa seconda met&agrave; del driver sono <tt/wd.o/, <tt/3c503.o/, <tt/smc-ultra.o/,
<tt/ne2k-pci.o/ e cos&igrave; via.

<sect2>DP83800 with DP83840
<p>
Stato: Not Supportata.

Si veda la sezione per la NE 10/100 di seguito.

<sect2>DP83815/83816
<p>
Stato: Supportata, Nome del driver: natsemi

	<tt>http://www.scyld.com/network/natsemi.html</tt>

	Questo driver &egrave; reperibile con i kernel 2.4 e seguenti.

<sect2>NS83820, DP83820
<p>
Stato: Supportato, Nome del driver: ns83820

L'83820 &egrave; una scheda a 64 bit da 10/100/1000 Mbps per il bus PCI, e
la 83821 &egrave; la corrispondente versione a 32 bit (ma sembra che le due
siano in effetti identiche e che la EEPROM sia incaricata di definire la 
larghezza dell'uscita dati.
Esattamente come nel caso del chip 8390, solitamente non si incappa in
questo numero se non si guardano i chip sulla scheda.

<sect1>Novell Ethernet, NExxxx e cloni associati<label id="novell">
<p>

Il prefisso 'NE' sta per Novell Ethernet. La Novell ha seguito il
progetto più economico del databook della National Semiconductor e ha venduto
i diritti di produzione a Eagle (che ha anche lanciato?), solo per immettere
sul mercato schede Ethernet a prezzi ragionevoli (la ormai onnipresente scheda NE2000).

<sect2>NE1000, NE2000<label id="ne2k">
<p>
Stato: Supportata, Nome del driver: ne (+8390)

ne2000 è oramai divenuto il nome generico per un design essenziale basato
sul chip 8390 della National Semiconductor. Queste schede usano I/O programmato
piuttosto che memoria condivisa, il che comporta maggiore
facilità di installazione ma prestazioni un po' più basse ed alcuni
problemi. Alcuni dei problemi più comuni con le schede NE2000 sono
elencati nella sezione <ref id="ne2k-probs" name="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 <tt/0x300/, perché praticamente <em/tutti/ i driver
di dispositivo cercano lì durante il boot. Alcuni cloni NE2000 scadenti non
la prendono bene ad essere pungolati in aree sbagliate e risponderanno
bloccando la macchina. Inoltre anche <tt/0x320/ non va bene perché i
driver SCSI rilevano all'indirizzo <tt/0x330/.

Donald ha scritto un progamma di diagnostica per NE2000 (ne2k.c)
che va bene per tutte le schede ne2000. Si veda la sezione
<ref id="diag" name="Programmi diagnostici"> per maggiori
informazioni.

Se si intende usare questo driver come modulo caricabile nel kernel probabilmente
si dovrebbe fare riferimento alla sezione <ref id="modules" name="Usare un driver Ethernet come modulo">
per informazioni specifiche sui moduli.

<sect2>NE2000-PCI (RealTek/Winbond/Compex)<label id="ne2k-pci">
<p>
Stato: Supportata, Nome del driver: ne, ne2k-pci (+8390)

Sì, che ci si creda o no, c'e' gente che sta facendo schede PCI basate sul
progetto dell'interfaccia 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 2.0 ha il supporto per rilevare automaticamente tutte
queste schede ed usarle (se si sta usando un kernel 2.0.34 o più
vecchio, lo si dovrebbe aggiornare per assicurarsi che la propria
scheda venga rilevata). Ci sono ora due driver tra cui scegliere:
l'originale driver ISA/PCI <tt/ne.c/ o quello relativamente nuovo solo
PCI <tt/ne2k-pci.c/.

Per usare il driver ISA/PCI originale si deve rispondere 'Y' all'opzione 'Other
ISA cards' quando si lancia <tt/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 lontanamente 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 vengono spostati da e per la scheda in blocchi più grandi, e 
senza alcuna pausa tra un'operazione e l'altra come le vecchie NE2000
ISA invece richiedono per operare in maniera affidabile. Il risultato è un
driver più efficiente, ma non ci si esalti troppo in quanto le
differenze non saranno ovvie sotto carichi di traffico normale (se si
desidera veramente la massima efficenza unitamente ad un basso utilizzo
della CPU, allora una NE2000 PCI è semplicemente una pessima scelta).
Aggiornamenti del driver e ulteriori informazioni possono essere
trovate nel sito:

	<tt>http://www.scyld.com/network</tt>

Se si possiede una scheda PCI NE2000 che <em/non/ viene rilevata dalla
versione più recente del driver, si contatti il maintainer del
driver NE2000 elencato nel file <tt>/usr/src/linux/MAINTAINERS</tt>
includendo l'output di <tt>cat /proc/pci</tt> e <tt>dmesg</tt>
dimodoché possa aggiungere il supporto per la vostra scheda.

Si noti inoltre che diversi prodottori di schede sono noti per
l'aver etichettato come 'NE2000 Compatible' dei prodotti che sono
in effetti completamente differenti (e.g. PCNet-PCI o RealTek 8139).
Se si è in dubbio si confronti il numero del chip principale della scheda
con quelli elencati in questo documento.

<sect2>NE-10/100
<p>
Stato: Non supportata.

Queste sono schede ISA a 100Mbps basate sui chip DP83800 e
DP83840 della National Semiconductor. Al momento non c'è alcun
driver che le supporta né nessuno ha ancora dichiarato di star lavorando su
un driver. Apparentemente non è disponibile documentazione sul
chip ad eccezione di un file PDF che non fornisce abbastanza dettagli
per poter scrivere un driver.

<sect2>NE1500, NE2100<label id="ne1500">
<p>
Stato: Supportate, Nome del driver: lance

Queste schede usano il chip LANCE 7990 originale dell'AMD e sono quindi
supportate dal driver lance di Linux. I cloni NE2100 più recenti
usano il chip aggiornato PCnet-ISA dell'AMD.

Alcune delle prime versioni del driver lance avevano problemi nel
determinare la linea IRQ attraverso autoIRQ	nelle schede
Novell/Eagle 7990. Si spera che questo problema sia ora stato corretto, ma se
non lo fosse, allora si specifichi l'IRQ usando LILO e ci si informi del
fatto che il problema ancora sussiste.

Informazioni sulla selezione del DMA e la numerazione del chip possono
essere trovate nella sezione <ref id="lance" name="AMD LANCE">.

<sect2>NE/2 MCA
<p>
Stato: Semi supportata, Nome del driver: ne2

Ci sono state alcune schede NE2000 microchannel prodotte da diverse
compagnie. Questo driver, disponibile nei kernel 2.2, rileverà le
seguenti schede MCA: Novell Ethernet Adapter NE/2, Compex ENET-16 MC/P
e Arco Ethernet Adapter AE/2.

<sect2>NE3200<label id="ne3200">
<p>
Stato: Non supportata

Anche se non c'&egrave; un driver per questa scheda nel kernel corrente (2.4),
Rask Ingemann Lambertsen ha sperimentato con una vecchia macchina
EISA ed aveva rilasciato un prototipo di driver sul seguente sito:

	<tt>http://vip.cybercity.dk/~ccc94453/linux/ne3200/</tt>

<sect2>NE3210<label id="ne3210">
<p>
Stato: Supportata, Nome del driver: ne3210 (+8390)

Questa scheda EISA è completamente diversa dalla NE3200, essendo basata
sul chip 8390 della National Semiconductor. Si pu&ograve; reperire il driver 
tra i sorgenti del kernel 2.2. Ci si assicuri di impostare un indirizzo
della memoria condivisa al di sotto del primo MB o al di sopra dell'indirizzo
più alto della RAM fisica installata nella macchina.

<sect2>NE4100
<p>
Stato: Supportata, Nome del Driver: pcnet_cs

<sect2>NE5500
<p>
Stato: Supportata, Nome del driver: pcnet32

Queste sono delle schede basate sul chip PCnet-PCI ('970A) dell'AMD.
Maggiori informazioni sulle schede basate su LANCE/PCnet
possono essere trovate nella sezione <ref id="lance" name="AMD LANCE">.

<sect1>Netgear
<p>

<sect2>Netgear FA-311
<p>
Status: Supportata, Nome del Driver: natsemi

<sect2>Netgear GA-620
<p>
Status: Supportata, Nome del Driver: acenic

<sect2>Netgear GA-621
<p>
Status: Supportata, Nome del Driver: ns83820

<sect1>Proteon
<p>

<sect2>Proteon P1370-EA
<p>
Stato: Supportata, Nome del driver: ne (+8390)

Sembra che questa sia un clone NE2000, e funziona bene con Linux.

<sect2>Proteon P1670-EA
<p>
Stato: Supportata, Nome del driver: de4x5, tulip

Questa è un'altra scheda PCI basata sul chip Tulip della DEC, e si dice che
funzioni bene con Linux.

Si veda la sezione sul chip 21040 (<ref id="dec-21040" name="DEC
21040">) per maggiori informazioni sul driver.

<sect1>Pure Data
<p>

<sect2>PDUC8028, PDI8023
<p>
Stato: Supportata, Nome del driver: wd (+8390)

Le serie di schede PDUC8028 e PDI8023 della Pure Data sono 'quasi cloni'
delle schede wd80x3 e c'&egrave; del codice scritto specificamente
per verificare la loro eventuale presenza in <tt/wd.c/.

<sect1>Racal-Interlan
<p>

La Racal Interlan può essere raggiunta via WWW a
<tt/www.interlan.com/. Credo che in passato fosse conosciuta anche
con il nome di MiCom-Interlan.

<sect2>ES3210
<p>
Stato: Semi supportata, Nome del driver: es3210

Questa è una scheda EISA a memoria condivisa basata sul chip 8390. Con il
kernel 2.2 è distribuito un driver sperimentale che si dice funzioni
bene, ma il rilevamento in EISA dell'IRQ e dell'indirizzo della memoria
condivisa non sembra funzionare bene con (almeno) le prime revisioni
della scheda (comunque questo problema non è ristretto al solo mondo
Linux...). In questo scenario, si devono fornire manualmente le informazioni
necessarie al driver. Per esempio, per una scheda all'IRQ 5 e memoria condivisa all'indirizzo
<tt/0xd0000/ che usa un driver modulare, si aggiunga <tt/options es3210
irq=5 mem=0xd0000/ a <tt>/etc/modules.conf</tt>. Oppure, con il driver
compilato nel kernel, all'avvio si passino i parametri <tt/ether=5,0,0xd0000,eth0/.
L'indirizzo I/O di base viene rilevato automaticamente e quindi si dovrebbe usare il
valore 0.

<sect2>NI5010
<p>
Stato: Semi supportata, Nome del driver: ni5010

Un tempo ci si doveva procurare separatamente il driver per queste
vecchie schede a 8 bit della MiCom-Interlan, ma ora viene distribuito con
i kernel 2.2 come driver sperimentale.

<sect2>NI5210
<p>
Stato: Semi supportata, Nome del driver: ni52

Anche questa scheda usa uno dei chip della Intel. Michael Hipp ha
scritto un driver che viene ora incluso nel kernel standard come
driver 'alpha'. Michael vorrebbe ricevere commenti dagli utenti che
posseggono questa scheda. Si veda la sezione <ref id="alfa" name="Driver
sperimentali"> per importanti informazioni sull'uso dei driver Ethernet sperimentali.

<sect2>NI6510 (non EB)<label id="ni65xx">
<p>
Stato: Semi supportata, Nome del driver: ni65

Esiste anche un driver per la NI6510 (basata su chip LANCE) ed è stato
anche questo scritto da Michael Hipp. Come l'altro, anche questo è un driver sperimentale.
Per qualche ragione questa scheda non è compatibile con il driver LANCE
generico. Si veda la sezione <ref id="alfa" name="Driver
sperimentali"> per importanti informazioni sull'uso dei
driver Ethernet sperimentali.

<sect2>EtherBlaster (aka NI6510EB)
<p>
Stato: Supportata, Nome del driver: lance

A partire dal kernel 1.2.23, al driver LANCE generico è stato aggiunto un
controllo per il valore (signature) <tt/0x52, 0x44/ specifica della NI6510EB.
Alcuni hanno riferito che questa firma non è la stessa per
tutte le schede NI6510EB, il che fa sì che il driver LANCE non rilevi
sempre questa scheda. Se questo succede, si può sostituire il controllo di detto valore (circa alla
riga 322 in lance.c) a printk() cosicché vengano stampati i valori per la
propria scheda, valori che poi si potr&agrave; usare come default invece di <tt/0x52, 0x44/.

Usando il driver lance, probabilmente queste schede dovrebbero essere
usate in modalità 'alte prestazioni' e non in compatibilità NI6510.

<sect1>RealTek
<p>

<sect2>Adattatore pocket RealTek RTL8002/8012 (AT-Lan-Tec)<label id="aep-100">
<p>
Stato: Supportato, Nome del driver: atp

Questo è un adattatore pocket generico a basso costo, venduto dalla
AT-Lan-Tec e (probabilmente) da diversi altri produttori. Nel kernel
standard è incluso un driver che lo supporta. 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 <tt/ifconfig/ <em/non/ era <tt/eth0/ bensì <tt/atp0/.

<sect2>RealTek 8008
<p>
Stato: Supportata, Nome del driver: ne, wd (+8390)

&Egrave; stato riferito che questo chip si comporta in maniera similare all'
AT/LANTIC in quanto pu&ograve; essere configurato per operare sia in
modalit&agrave; ne/PIO che wd/MMIO impiegando il software fornito dal produttore
(SET8008R).

<sect2>RealTek 8009
<p>
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 Web della RealTek
(<tt>http://www.realtek.com.tw</tt>) o via FTP dallo stesso sito può
essere scaricato il programma <tt/rset8009.exe/.

<sect2>RealTek 8019
<p>
Stato: Supportata, Nome del driver: ne (+8390)

Questa è la versione Plug and Pray ("innesta e prega", N.d.T.) 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 <tt/io=0xNNN/ a <tt>/etc/modules.conf</tt>). Dal
sito WWW della RealTek (<tt>http://www.realtek.com.tw</tt>) o via FTP
dallo stesso sito può essere scaricato il programma <tt/rset8009.exe/.

<sect2>RealTek 8029
<p>
Stato: Supportata, Nome del driver: ne, ne2k-pci (+8390)

Questa è una implementazione PCI a singolo chip di un clone
NE2000. Diversi produttori vendono schede basate su questo chip. Si
veda la sezione <ref id="ne2k-pci" name="NE2000-PCI"> per
informazioni sull'uso di una qualsiasi di queste schede. Si noti che
questo è un design di più di 10 anni fa banalmente adattato al
bus PCI. Le prestazioni non saranno molto migliori rispetto a quelle
dell'equivalente modello ISA.

<sect2>RealTek 8129/8139<label id="rtl8139">
<p>
Stato: Supportate, Nome del driver: 8139too, rtl8139 (vecchio driver)

Una soluzione Ethernet PCI a chip singolo della RealTek. Un driver
per le schede basate su questo chip è stato incluso nella release
2.0.34 del kernel Linux. In kernel recenti, il driver principale per questa 
scheda va sotto il nome <tt>8139too</tt>. Nei kernel precedenti, il driver
per queste schede si chiamava <tt>rtl8139</tt> e solitamente era necessario
rispondere 'Y' quando veniva richiesto se si desiderava accesso ai driver
sperimentali.

<sect1>Sager
<p>

<sect2>Sager NP943
<p>
Stato: Semi supportata, Nome del driver: 3c501

Questa è semplicemente un clone della 3c501, con un diverso prefisso
S.A. in PROM. Suppongo che sia talmente demente quanto la 3c501
originale. Il driver cerca l'ID della NP943 e poi la tratta
semplicemente come un 3c501. Si veda la sezione <ref id="3c501"
name="3Com 3c501"> per tutte le ragioni per le quali non si
deve proprio usare una di queste schede.

<sect1>Schneider &amp; Koch
<p>

<sect2>SK G16
<p>
Stato: Obsoleta, Nome del driver: sk_g16

Questo driver era gi&agrave; stato incluso nei kernel 1.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 (la 7990). Ancora una volta, sembra che pure questa scheda non funzioni
con il driver LANCE generico.

Questo driver &egrave; diventato obsoleto a partire dai kernel 2.4.

<sect1>SEEQ
<p>

<sect2>SEEQ 8005
<p>
Stato: Supportata, Nome del driver: seeq8005

Nel driver sono incluse pochissime informazioni
su questa scheda e quindi ci sono pure poche informazioni da includere qui.
Se si hanno domande, probabilmente la cosa migliore è di scrivere all'autore
del driver come elencato nel sorgente del driver.

Questo driver &egrave; diventato obsoleto a partire dai kernel 2.4.

<sect1>SiS (Silicon Integrated Systems) 
<p>
SiS produceva chipset per schede madri gi&agrave; nell'era del processore 386
(come il mitico 'el cheapo', N.d.T.), ed adesso producono anche alcuni chip Ethernet,
anch'essi alquanto popolari.

<sect2> SiS 900 (7016, 630E, 962)
<p>
Stato: supportata, Nome del driver: sis900
	
Questo dispositivo pu&ograve; essere incontrato sia come scheda di espansione a se
stante che come dispositivo integrato nella scheda madre. Il driver &egrave; stato
disponibile a partire dagli ultimi kernel 2.2.

<sect1>SMC (Standard Microsystems Corp.) <label id="smc">
<p>

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: <tt/techsupt@ccmail.west.smc.com/. Sito FTP:
	<tt/ftp.smc.com/.
	Sito Web: <url url="http://www.smc.com" name="SMC">.

<sect2>WD8003, SMC Elite
<p>
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 il risparmio solo se destinato ad un uso
leggero in termini di traffico di rete.
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 questo fallisce, il
driver assegna l'IRQ 5 senza dir niente. Dal sito FTP della SMC si
possono scaricare i dischetti di configurazione/driver. Si noti che
alcune delle versioni più recenti del programma 'SuperDisk' della SMC
falliranno nel rilevare le schede veramente vecchie senza EEPROM. Il
file <tt/SMCDSK46.EXE/ sembra essere in generale una buona scelta.
Inoltre le impostazioni dei ponticelli per tutte le schede SMC si
possono reperire in un file testo ASCII nel summenzionato archivio.
L'ultima (migliore?) versione può essere ottenuta da <tt/ftp.smc.com/.

Poiché questo sono in pratica analoghe alle loro controparti a 16 bit
(WD8013 / SMC Elite16), si dovrebbero consultare le sezioni successive per
maggiori informazioni.

<sect2>WD8013, SMC Elite16<label id="8013">
<p>
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 Semiconductor presente nelle prime schede. Il progetto a
memoria condivisa rende queste schede un po' più veloci delle schede
PIO, specialmente con pacchetti di dimensioni notevoli. Più importante, dal punto
di 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 incappa nel il registro dati dell'I/O
programmato che pianta la macchina durante la scansione al boot.

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

Le schede con a bordo dimensioni di memoria non standard le possono
specificare all'avvio (o come opzione in <tt>/etc/modules.conf</tt>
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. Ad 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 (con I/O=0x280 e IRQ 9) al seguente parametro di avvio:
<code>
	LILO: linux ether=9,0x280,0xd0000,0xd8000,eth0
</code>

Si veda anche la sezione <ref id="8013-probs" name="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 consultare la sezione <ref id="modules" name="Usare un driver
Ethernet come modulo"> per informazioni specifiche sui moduli.

<sect2>SMC Elite Ultra<label id="ultra">
<p>
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 all'83c690. Sebbene possieda una
modalità simile alle schede SMC più vecchie, la scheda non è completamente
compatibile con i vecchi driver WD80*3. Tuttavia, 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 <em/sembra/ una 8013, si suppone che il
controllo per la Ultra la individui prima che il controllo per la wd8013
abbia la possibilità di identificarla 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 in dischi SCSI
utilizzati attraverso un adattatore host aha-154X. Questo problema
colpisce 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 driver. Il driver Ultra attuale
si protegge da questo problema abilitando la memoria condivisa solo durante lo scambio
di dati con la scheda. Ci si assicuri che la propria
versione del kernel sia almeno la 1.1.84 e che la versione riportata
dal driver al boot sia almeno <tt/smc-ultra.c:v1.12/, altrimenti
si è vulnerabili a questo problema.

Se si intende usare questo driver come modulo caricabile probabilmente
si dovrebbe consultare la sezione <ref id="modules" name="Usare un driver
Ethernet come modulo"> per informazioni specifiche sui moduli.

<sect2>SMC Elite Ultra32 EISA<label id="ultra32">
<p>
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 della serie 2.0 che
della serie 2.2. Grazie a Leonard Zubkoff per aver acquistato alcune di
queste schede dimodoché sia stato possibile aggiungerne il
supporto a Linux.

<sect2>SMC EtherEZ (8416)
<p>
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à <em/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 Web/FTP) per disabilitare il PnP e
attivare la modalità a memoria condivisa. Si vedano le
informazioni precedenti per alcune note sul driver Ultra.

Per i kernel 1.2, la scheda deve essere configurata per l'uso a
memoria condivisa. Comunque i kernel 2.0 possono usare la scheda
sia in modalità a memoria condivisa che a I/O programmato. La modalità a
memoria condivisa è leggermente più veloce e usa anche meno
risorse di CPU.

<sect2>SMC EtherPower PCI (8432)<label id="smc-pci">
<p>
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 <tt/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 nei sorgenti del kernel corrente.

Si veda la sezione <ref id="dec-21040" name="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
<em/prima/ di pagarla.

<sect2>SMC EtherPower II PCI (9432)<label id="smc-pci-II">
<p>
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 2.0 e 2.2 per supportare queste schede. Per
ulteriori dettagli si veda:

	<tt>http://www.scyld.com/network</tt>

<sect2>SMC 1211TX 10/100
<p>
Stato: Semi supportata, Nome del driver: 8139too, rtl8139 (vecchio driver)

Sembra che SMC non sia pi&ugrave; la stessa compagnia che ha rilasciato
schede come la Ultra e la EPIC. La divisione che si occupa del design di chip 
si chiama ora SMSC e d'ora in poi vedremo il nome SMC attaccato su schede 
destinate al mercato economico come questa - una Realtek 8139 con una EEPROM 
modificata.

<sect2>SMC 3008
<p>
Stato: Non supportata.

Queste schede a 8 bit sono basate sul chip Fujitsu MB86950, che è un'antica
versione del MB86965 riconosciuto dal driver at1700 per Linux. Russ dice
che probabilmente si può mettere insieme un driver a partire dal codice
at1700.c e il suo packet driver DOS per la scheda Tiara
(tiara.asm). Queste schede non sono molto comuni.

<sect2>SMC 3016
<p>
Stato: Non Supportata.

Queste sono schede 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. Queste schede non sono molto comuni.

<sect2>SMC-9000 / SMC 91c92/4
<p>
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 è
piuttosto poco comune.

<sect2>SMC 91c100
<p>
Stato: Semi supportata, Nome del driver: smc9194

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

<sect2>SMC 9452TX/9462TX
<p>
Stato: Supportata, Nome del driver: ns83820

<sect1>Sundance
<p>

<sect2>Sundance ST201, Alta
<p>
Stato: Supportata, Nome del driver: sundance

Il chip Sundance Alta viene utilizzato su schede OEM (Original Equipment Manufacturer, N.d.T.),
utilizza trasferimenti in bus-master, pu&ograve; trasmettere e ricevere in buffer
allineati in modo arbitrario ed ha un hash di multicasting a 4 elementi. Tutte le
versioni di questo chip hanno controllo di flusso in hardware e stati ACPI di alimentazione.

<sect1>SysKonnect
<p>

<sect2>SysKonnect sk-98xx Gigabit Ethernet
<p>
Stato: Supportata, Nome del driver: sk98

I primi report indicano che questo chipset ha un problema con i 
checksum di trasmissione, il che riduce un poco le prestazioni.

<sect1>Texas Instruments
<p>

<sect2>ThunderLAN<label id="tlan">
<p>
Stato: Supportata, Nome del driver: tlan

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

<sect1>Thomas Conrad
<p>

<sect2>Thomas Conrad TC-5048
<p>

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

Si veda la sezione sul chip 21040 (<ref id="dec-21040"
name="DEC 21040">) per maggiori informazioni.

<sect1>VIA
<p>

Probabilmente non si avr&agrave; a che fare con una scheda di rete VIA, in quanto la
VIA costruisce diversi chip usati da altri per costruire le loro
schede Ethernet. Il loro sito Web &egrave; il seguente:

	<tt>http://www.via.com.tw/</tt>

<sect2>VIA 86C926 Amazon
<p>
Stato: Supportato, Nome del driver: ne, ne2k-pci (+8390)

Questo chip è la soluzione VIA compatibile PCI-NE2000. Si può
scegliere tra il driver <tt/ne.c/ per ISA e PCI o il driver
solo PCI <tt/ne2k-pci.c/. Si veda la sezione sulle schede PCI-NE2000
per ulteriori informazioni.

<sect2>VIA 86C100A Rhine II (and 3043 Rhine I)<label id="rhine">
<p>
Stato: supportato, Nome del driver: via-rhine

Questo driver relativamente nuovo &egrave; incluso 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 a 32 bit del buffer limitano
i benefici conseguenti. Per maggiori dettagli e driver
aggiornati si veda:

<tt>http://www.scyld.com/network</tt>

<sect1>Western Digital
<p>

Si veda la sezione <ref id="smc" name="SMC"> per informazioni sulle
schede SMC (la SMC ha comprato la divisione schede di rete
della Western Digital molti anni fa).

<sect1>Winbond
<p>

La Winbond in realtà non fabbrica schede complete da vendere al
pubblico, piuttosto costruisce soluzioni Ethernet su un singolo chip
che altre compagnie possono acquistare ed usare nelle schede PCI poi
vendute sotto i loro rispettivi marchi.
Alcuni programmi di setup e supporto tecnico sono disponibili sul sito:

	<tt>http://www.winbond.com.tw</tt>

<sect2>Winbond 89c840
<p>
Stato: Supportato, Nome del driver: winbond-840

Questo chip &egrave; stato descritto come il 'figlio mutante di una NE2000
ed un clone Tulip' -- si vedano le note del driver per ulteriori dettagli.
Questo driver supporta anche il chip TX9882 presente nella Compex RL100-ATX.

<sect2>Winbond 89c904, 89c905, 89c906
<p>
Stato: Supportato, Nome del driver: ne (+8390)

Questi sono i chip Winbond compatibili con NE2000 per bus ISA a 10 Mbps. I programmi
di setup sono disponibili sul sito della Winbond.

<sect2>Winbond 89c940
<p>
Stato: Supportata, 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 produttori. Si noti che
questo è sempre un progetto vecchio pi&ugrave; di dieci anni adattato per il bus
PCI. Le prestazioni non saranno tanto migliori rispetto a quelle
dell'equivalente modello ISA.

<sect1>Xircom<label id="xircom">
<p>

Per lungo tempo, la Xircom non ha voluto rilasciare la informazioni di
programmazione necessarie per scrivere un driver, a meno che non si
firmasse un accordo di confidenzialit&agrave; rigidissimo per averle.
Apparentemente abbastanza utenti Linux li hanno subissati di richieste
per un driver (dichiarano di supportate tutti i più popolari
sistemi operativi di rete...) da far alterare la loro politica in materia e
permettere il rilascio di documentazione senza dover firmare un
accordo di confidenzialit&agrave;. Ad alcuni &egrave; stato detto che sarebbe
stato rilasciato il codice sorgente del driver SCO, mentre ad altri hanno detto
che non vengono pi&ugrave; fornite informazioni su prodotti 'obsoleti' come i
primi modelli PE. Se si è interessati e si vuole verificare personalmente come
stanno le cose, si può contattare la Xircom ai numeri 1-800-874-7875, 1-800-438-4526 o
+1-818-878-7600.

<sect2>Xircom PE1, PE2, PE3-10B*
<p>
Stato: Non supportate.

Non per darvi tante speranze, ma se avete uno di questi adattatori per
porta parallela, si può forse riuscire ad usarlo nell'emulatore DOS con i
driver per DOS forniti dalla Xircom. Si deve permettere a DOSEMU di
accedere alla porta parallela e probabilmente si dovrà smanettare
un po' con SIG (il Silly Interrupt Generator di DOSEMU).

<sect2>Xircom CE, CEM, CE2, CE3
<p>
Stato: Supportata, Nome del driver: xirc2ps_cs

Secondo il driver, sono supportate le schede CE2, CE IIps, RE-10, 
CEM28, CEM33, CE33, CEM56, CE3-100, CE3B, RE-100, REM10BT e la 
REM56G-100.

<sect2>Xircom CBE-100
<p>
Stato: Supportata, Nome del driver: xircom_tulip_cb

Una implementazione simile al design tulip su CardBus.

<sect1>Zenith<label id="zenith">
<p>

<sect2>Z-Note<label id="z-note">
<p>
Stato: Obsoleta, Nome del driver: znet

L'adattatore di rete built-in Z-Note è basato su un i82593 dell'Intel
ed usa <em/due/ canali DMA. Si noti che il ThinkPad 300
dell'IBM è compatibile con Z-Note.

<sect1>Znyx<label id="zynx">
<p>

<sect2>Znyx ZX342 (DEC 21040 based)
<p>
Stato: Supportata, Nome del driver: de4x5, tulip

Si ha la scelta fra <em/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 Donald.

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 <tt/README.de4x5/ per i
dettagli.

Si veda la sezione <ref id="dec-21040" name="DEC 21040"> per maggiori
informazioni su queste schede e la situazione corrente del driver.

<sect1>Identificare una scheda sconosciuta<label id="mystery">
<p>

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 di modello che potrebbe
costituire un indizio. Qualsiasi numero di modello contenente il numero 2000
sar&agrave; probabilmente 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 queste.

<sect2>Identificare il Network Interface Controller
<p>
Si cerchi il chip più grosso sulla scheda. Questo sarà il network controller
(NIC) e la maggior parte può essere identificata dal numero di parte. Se si sa
quale NIC c'è sulla scheda, quanto segue può aiutare a scoprire quale sia la scheda.

Probabilmente il NIC ISA 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 è
probabile che sia un clone della ne1000 o della ne2000. Il secondo tipo di
schede più comuni basate su 8390 sono le schede wd80x3 e i loro cloni. Le
schede con un DP83905 possono essere configurate per funzionare come una ne2000
<em/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 Ultra. Tutte le schede
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 ne2k-pci dovrebbe automaticamente
rilevarle al boot.

<sect2>Identificare l'indirizzo Ethernet
<p>
Ogni scheda Ethernet ha un suo unico indirizzo a sei
byte. I primi tre byte di quell'indirizzo sono gli stessi per ogni
scheda fatta da un particolare produttore. Per esempio tutte le
schede SMC hanno indirizzi che iniziano con il prefisso con <tt/00:00:c0/.
Gli ultimi tre byte dell'indirizzo vengono invece assegnati
dal produttore in modo che ogni scheda venduta abbia un indirizzo diverso
da tutte le altre.

Se la propria scheda ha un etichetta che indica tutti i 6 byte del suo
indirizzo, si può risalire al costruttore dai primi tre. Tuttavia, è
più comune il vedere solo gli ultimi tre byte stampati su un'etichetta
attaccata sulla PROM, il che non ci dice niente.

Si può determinare a quale produttore è stato assegnato un
determinato indirizzo dall'RFC 1340. Apparentemente in giro ci sono
anche elenchi più aggiornati. Si provi a fare una ricerca sul Web o in FTP
per <tt/EtherNet-codes/ o <tt/Ethernet-codes/ e qualcosa salter&agrave; fuori.

<sect2>Identificare la scheda a partire dal numero di FCC ID
<p>

Come parte del processo di certificazione che una scheda deve tipicamente 
passare prima di essere vendibile all'utente finale, essa deve venire
testata dalla FCC, e durante questo processo essa riceve un identificativo FCC
che dovrebbe essere stampato da qualche parte sulla scheda. Per esempio, una
scheda con sovrastampato il valore <tt>FCC ID: J158013EWC</tt> risulta poi
essere una SMC/WD8013-EWC. Alcuni siti Web come <tt>www.driverguide.com</tt>
e <tt>drdriver.com</tt> fanno uso degli identificativi FCC per fornire aiuto
agli utenti nell'identificazione delle schede pi&ugrave; oscure. La FCC
stessa mette a disposizione uno strumento di ricerca che pu&ograve; risultare
utile all'indirizzo Web seguente:

	<url url=" http://www.fcc.gov/oet/fccid" name="FCC IDs">

<sect2>Suggerimenti per provare ad usare una scheda sconosciuta
<p>

Se non si è ancora sicuri di che scheda si tratti 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 sia
configurata ad uno degli indirizzi che i driver controllano quando
cercano una scheda di quel tipo. Se questo è il caso, si può provare a
scaricare <tt/scanport.tar.gz/ da un archivio ftp dedicato a Linux e vedere
se può scoprire a che indirizzo la scheda è piazzata. Questo strumento esamina
lo spazio di I/O del bus ISA a partire da <tt/0x100/ e fino a <tt/0x3ff/
cercando dispositivi che non siano registrati in <tt>/proc/ioports</tt>. Se
trova un dispositivo sconosciuto a qualche indirizzo specifico, si può
esplicitamente indirizzare il rilevamento a quell'indirizzo con il parametro
<tt/ether=/ al boot.

Se si è riusciti a far rilevare la scheda, allora solitamente si può
scoprire a cosa servano i ponticelli spostandone 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 staffa 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 sembrano non servire a 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:

	<url url="http://www.slug.org.au/NIC/" name="Ethercard Settings">

<sect1>Driver per i dispositivi non Ethernet
<p>

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

<tt/dummy.c/ -- Lo scopo di questo driver è di fornire un dispositivo
al quale far puntare il routing, ma che realmente non trasmette
pacchetti.

<tt/eql.c/ -- Load Equalizer (Equalizzatore di carico), asservisce
più dispositivi (solitamente modem) e bilancia il carico di
trasmissione su di essi presentandoli come un unico dispositivo ai
programmi di rete.

<tt/ibmtr.c/ -- IBM Token Ring, che non è proprio Ethernet.
Broken-Ring richiede source routing ed altre brutte cose.

<tt/loopback.c/ -- Dispositivo loopback al quale vanno tutti i
pacchetti destinati alla vostra macchina partenti da questa stessa.
Essenzialmente si limita a spostare il pacchetto dalla coda TX
nella coda RX.

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

<tt/plip.c/ - Parallel Line Internet Protocol, permette a due computer
di inviarsi pacchetti attraverso due porte parallele connesse in
modalit&agrave; point-to-point.

<tt/ppp.c/ -- Point-to-Point Protocol (RFC1331, 1548, 1661), per la trasmissione
di datagrammi multiprotocollo su una connessione Point-to-Point
(solitamente modem).

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

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

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

<sect>Cavi, coassiali, doppini intrecciati<label id="cable">
<p>
Se si sta mettendo su una nuova rete, si utilizzer&agrave; probabilmente
cablaggio di tipo Cat5 per 10/100BaseT (cavi tipo telco a doppini intrecciati
con connettori 'telefonici' RJ-45 a otto vie). Se vi capita di incappare in un
po di vecchi cavi 10Base2 thin Ethernet (coassiale RG58 con connettori BNC),
si pu&ograve; decidere di riciclarli in una piccola rete casalinga. La vecchia
thick Ethernet, con cavi RG-5 a N connettori, è veramente obsoleta e si vede
ormai poco in giro.

Si veda la sezione <ref id="cable-intro" name="Tipi di cavi..."> per una
panoramica introduttiva sui cavi. Si noti inoltre che la FAQ di
<em/comp.dcom.lans.ethernet/ contiene un sacco di informazioni utili sui
cavi e materiali collegati. Ci si connetta in FTP a rtfm.mit.edu e si cerchi nella
directory <tt>/pub/usenet-by-hierarchy/</tt> la FAQ di quel
newsgroup.

<sect1>Thin Ethernet (thinnet)<label id="bnc">
<p>

<!--
Il cavo thin Ethernet è abbastanza economico. Se si vuole farsi da
soli i cavi, l'RG58A a solid-core costa &dollar;0.27/m mentre l'RG58AU
stranded  è a &dollar;0.45/m. I connettori BNC twist-on costano meno
di due dollari l'uno e altri pezzi vari sono altrettanto economici.
È essenziale terminare correttamente ciascun capo del cavo con
terminatori da 50 Ohm, che costano due dollari alla coppia. 
-->

Thinnet &egrave; decisamente obsoleta ormai, ma va ancora bene per qualcuno 
che sta smanettando con una piccola rete o che vuole costruire una rete per casa.
Ci sono due svantaggi principali ad usare thinnet. Il primo è che
si è limitati 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 giunzione a T . E se se si sta facendo una
piccola rete di due macchine, sono <em/ancora/ necessari sia il
connettore a T che i terminatori da 50 Ohm: <em/non si può/
semplicemente connettere le due macchine assieme! Inoltre e necessario che il
vostro cavo non abbia 'appendici': il connettore a T deve essere collegato
direttamente alle schede.

<sect1>Doppino intrecciato (twisted pair)<label id="utp">
<p>

Le reti a doppini intrecciati necessitano di hub (concentratori)
attivi, che costano attorno ai &dollar;50. Si può
tranquillamente ignorare quelli che dicono che si può usare il
cablaggio telefonico già esistente visto che è una rara circostanza.

D'altra parte, tutte le specifiche Ethernet a 100Mb/sec usano doppini
intrecciati e sono usati pure nella maggior parte delle nuove
installazioni in uffici. I cavi devono essere di categoria 5. Qualsiasi installazione 
con cavi di specifica inferiore al Cat 5 &egrave; inutile.

Se si sta solamente connettendo due macchine, è possibile evitare l'uso di
un hub, acquistando o fabbricando uno speciale cavo cross-over (detto anche null cable),
ma si tenga presente che alcune schede cercano di rilevare le funzionalit&agrave; di
autonegotiation e di conseguenza si aspettano di star parlando con un hub e non con
un altra scheda e quindi potrebbero non funzionare in questa configurazione.
</sect>

<sect>Configurazione del software e diagnotici<label id="utils">
<p>

Per le pi&ugrave; vecchie (o le pi&ugrave; economiche) schede ISA, i settaggi
della scheda erano controllati da piccoli ponticelli (jumpers) di contatto neri
piazzati su file di pin. Con l'aumento delle capacit&agrave; delle schede, questi
settaggi sono stati spostati in ambito elettronico piuttosto che fisico e l'utente 
&egrave; ora in grado di di immagazzinare la configurazione prescelta in nella memoria
non volatile integrata nella scheda. Un programma fornito dal produttore pu&ograve;
essere impiegato dall'utente per alterare questa configurazione, eliminando il bisogno di
aprire il computer solo per riconfigurare una scheda.

Nella maggior parte dei casi, se la configurazione viene fatta in software e salvata
poi in una EEPROM, si dovrà avviare il DOS e usare il programma per DOS
fornito dal rivenditore per impostare IRQ, I/O, indirizzo di
memoria e quant'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
cercare nel sito Web 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 <em/molti/ altri produttori.

Per alcune schede esistono le versioni Linux delle utilità di
configurazione e sono qui elencate. Donald ha scritto alcuni piccoli
programmi 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
Fantasiose interfacce a menu. Per poterli usare, nella maggioranza dei
casi sarà necessario leggerene il codice sorgente. Anche se per la
propria particolare scheda non esiste un diagnostico, si possono
ottenere comunque alcune informazioni digitando semplicemente <tt>cat
/proc/net/dev</tt> (assumendo che all'avvio la propria scheda sia
stata almeno rilevata).

In ogni caso, si dovrà usare la maggior parte di questi programmi
come root (per permettere l'accesso alle porte di I/O) e prima di farlo è
consigliabile disattivare la scheda Ethernet usando il comando
<tt/ifconfig eth0 down/.

<sect1>Programmi di configurazione per le schede Ethernet<label id="config">
<p>

<sect2>Schede WD80x3
<p>

Per quanti hanno schede wd80x3, c'è il programma <tt/wdsetup/ che può
essere reperito nell'archivio <tt/wdsetup-0.6a.tar.gz/ nei siti ftp dedicati a
Linux. Non è mantenuto attivamente e non è aggiornato da un bel po' di
tempo. Se nel vostro caso funziona, allora bene. Altrimenti, 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. Naturalmente, si <em/deve/ possedere una scheda
con la EEPROM per poter usare questo programma. Le vecchie, ma proprio
<em/vecchie/, schede wd8003 e alcuni vecchi cloni wd8013 usano dei ponticelli
per configurare la scheda.

<sect2>Schede Digital/DEC
<p>

La scheda Digital EtherWorks 3 può essere configurata in maniera
simile con il programma DOS <tt/NICSETUP.EXE/. David C. Davies ha
scritto questo programma e altri strumenti per la EtherWorks 3 oltre al
driver stesso. Si cerchi il file <tt/ewrk3tools-X.XX.tar.gz/ nella directory 
<tt>/pub/linux/system/Network/management</tt> sul sito FTP dedicato a Linux
a cui fate riferimento.

<sect2>Schede NE2000+ o AT/LANTIC
<p>

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 di setup <tt>atlantic.c</tt>
dal server ftp di Donald, <tt/www.scyld.com/. Inoltre, con tutte queste schede sembra
funzionino anche i programmi per le schede DP83905 della Kingston,
poiché non controllano che l'indirizzo hardware sia specifico produttore all'avvio.
Si vada all'URL seguente: <url url="http://www.kingston.com/download/etherx/etherx.htm"
name="Kingston"> e si scarichino <tt/20XX12.EXE/ e <tt/INFOSET.EXE/.

Si faccia attenzione quando si configurano schede NE2000+, poiché alcune
impostazioni errate possono causare problemi. Un esempio tipico è
l'abilitazione accidentale 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 ci si può togliere d'impiccio nel modo seguente:
si rimuova la scheda dalla macchina, si riavvii e si entri nel
menu di configurazione del BIOS. Si modifichi la voce 'Display Adapter'
in 'Not Installed' e si imposti 'A:' (il vostro floppy drive) come disco
di avvio di default. Si modifichi 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 di sistema
DOS ('format a: /s /u') e ci si copi dentro il floppy il programma
<tt/default.exe/ dell'archivio <tt/20XX12.EXE/ suddetto. Quindi si
digiti <tt>echo default > a:autoexec.bat</tt> in modo tale che il
programma che reimposta i valori predefiniti della scheda sia
eseguito automaticamente quando si avvia il sistema 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 <tt/default.exe/ e poi si spenga il computer. Una volta riacceso
il computer un ultima volta, si dovrebbe avere di nuovo un display che
funziona, permettendo così di risistemare le impostazioni del BIOS e
modificare i valori della EEPROM della scheda come si desideri.

Si noti che se non si ha DOS sotto mano, si può eseguire quanto sopra descritto
 con un dischetto di avvio di Linux che lancia automaticamente il
programma <tt/atlantic/ di Donald (con le giuste opzioni d'avvio)
invece che con un dischetto di avvio di DOS che lancia automaticamente
il programma <tt/default.exe/.

<sect2>Schede 3Com
<p>

La famiglia di schede Etherlink III della 3Com (p.es. 3c5x9) può essere
configurata usando un'altra utilità di configurazione di Donald. Si può
scaricare il file <tt>3c5x9setup.c</tt> dal server ftp di Donald,
<tt/www.scyld.com/ to (si noti che il programma DOS di
configurazione 3c5x9B può avere più opzioni pertinenti alla nuova
serie "B" della famiglia Etherlink III).


<sect1>Programmi diagnostici per schede Ethernet<label id="diag">
<p>

Tutti i programmi diagnostici scritti da Donald possono essere
ottenuti visitando il suo sito web:

<url url="http://www.scyld.com/network" name="Ethercard Diagnostics">

Allied Telesis AT1700 -- <tt>at1700.c</tt> 

Cabletron E21XX -- <tt>e21.c</tt> 

HP PCLAN+ -- <tt>hp+.c</tt> 

Intel EtherExpress -- <tt>eexpress.c</tt>

PCI NE2000 cards -- <tt>ne2k-pci-diag.c</tt>

ISA NE2000 cards -- <tt>ne2k.c</tt>

RealTek (ATP) Pocket adaptor <tt>atp-diag.c</tt>

Tutte le altre schede: si provi a usare i comandi <tt>cat /proc/net/dev</tt>
e <tt/dmesg/ per vedere quali informazioni utili possiede il kernel
sulla scheda in questione.

<sect>Informazioni tecniche<label id="tech-intro">
<p>
Queste informazioni saranno utili a quanto vogliono capire un po'
meglio come funziona la loro scheda, oppure vogliono smanettare con il
driver. Se non si rientra in queste categorie, allora si può anche
considerare di saltare questa sezione.

<sect1>I/O programmato, memoria condivisa e DMA a confronto<label id="data-xfer">
<p>
Se già si &egrave; in grado di ricevere e inviare pacchetti back-to-back,
allora non si possono immettere pi&ugrave; bit di cos&igrave; 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.

<sect2>Programmed I/O (I/O Programmato) (es. NE2000, 3c509)
<p>
Pro: Non usa nessuna risorsa di sistema limitata, solo alcuni
     registri di I/O e non ha un limite a 16M.

Contro: Solitamente più bassa è la velocità di trasferimento, più la
        CPU attende senza far niente, e l'accesso ai pacchetti
        in modalit&agrave; interleaved è solitamente difficile se non impossibile.

<sect2>Shared memory (Memoria Condivisa) (es. WD80x3, SMC-Ultra, 3c503)
<p>
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 vengono
     copiati dalla scheda, il che risulta in un'ulteriore
     riduzione dell'uso della CPU rispetto ad una equivalente scheda PIO.

Contro: Usa pi&ugrave; memoria (un grosso "contro" per utenti
        DOS, ma sostanzialmente non un problema sotto Linux) e blocca comunque
        la CPU.

<sect2>DMA (Accesso diretto alla memoria) in bus mastering (es. LANCE, DEC 21040) <label id="master">
<p>
Pro: Libera la CPU durante il trasferimento dei dati, può collegare
     assieme buffer separati, col bus ISA richiede pochissimo tempo della CPU
     (praticamente nulla). La maggior parte dei driver per Linux in bus-mastering usano
     lo schema 'copybreak' nel quale i grossi pacchetti vengono messi
     direttamente dalla scheda nel buffer di rete del kernel, e i pacchetti
     piccoli vengono invece copiati dalla CPU che li carica in cache per le
     elaborazioni successive.

Contro:(Applicabile solamente alle schede ISA) Per la scheda
       sono necessari buffer in memoria bassa e un canale di 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 per scheda madre mal progettati
       hanno problemi con il bus-mastering di schede ISA.

<sect1>Implicazioni della Larghezza di Bus per le Prestazioni
<p>
Il bus ISA può raggiungere i 5.3MB/sec (42Mb/sec), il che sembra più che
adeguato per una Ethernet a 10Mbps. Nel caso di schede a 100Mbps,
chiaramente è necessario un bus più veloce per sfruttare la
larghezza di banda della rete.

<sect2> Schede ISA a 8 e 16 Bit
<p>
Vi risulter&agrave; probabilmente difficile riuscire a comprare una scheda
Ethernet per bus ISA di questi tempi, ma potreste anche riuscire a recuperare
una scheda obsoleta o un fondo di magazzino per scopi di networking casalingo.
Se proprio volete cedere al fascino del passato, potete persino utilizzare una
vecchia scheda a ISA a mezzo slot (8 bit), ma siete avvertiti che la maggior
parte di queste schede sono per 10Base-2.

Alcune schede a 8 bit che sono in grado di darvi prestazioni adeguate per
traffici leggeri o medi sono la wd8003, la 3c503 e la ne1000. La 3c501 ha
delle prestazioni disastrose, e questi poveri reperti dei tempi dell'XT, vecchi
di 15 anni, dovrebbero essere evitati - Inviateli invece a chi li colleziona.

La banda passante del bus a 8 bit non limita le prestazioni pi&ugrave; di tanto,
tanto che potete aspettarvi di ottenere dai 500 agli 800kB/s in un download FTP
con una scheda wd8003 installata su di un bus ISA veloce e su di una macchina
(relativamente) veloce. Se il vostro traffico &egrave; diretto altrove, allora
il collo di bottiglia della connessione sar&agrave; da un altra parte e l'unica
differenza di velocit&agrave; che voi noterete riguarder&agrave; il vostro traffico
locale.

<sect2>Schede Ethernet a 32 Bit per bus PCI (e VLB/EISA)
<p>
Ovviamente una interfaccia a 32 bit verso il computer &egrave; un requisito per
reti a 100Mbps e oltre. Se state pensando di adottare GigE, allora i 133 megabyte
al secondo del bus PCI costituiranno ancora il vostro limite.

Ma un pi&ugrave; vecchio network a 10Mbps non ha veramente bisogno di una interfaccia
a 32 bit. Si veda la sezione <ref id="data-xfer" name="I/O programmato, memoria condivisa...">
sul perch&eacute; avere una scheda Ethernet da 10Mbps montata su di un bus ISA a 8Mhz
non costituisca in realt&agrave; un limite. Anche se l'avere una scheda lenta su di un
bus veloce non sar&agrave; all'origine di trasferimenti di dati pi&ugrave; veloci, solitamente
essa causer&agrave; meno carico sulla CPU, il che &egrave; sempre un bene su sistemi multiutente.

<sect1>Impatto sulle prestazioni di Zero Copy
<p>
Come i dati vengono ricevuti o inviati, voi potete facilmente immaginarveli
mentre essi vengono copiati dall'applicazione nella memoria del kernel e da quest'ultima
nella memoria della scheda. Tutto questo movimento di dati richiede tempo e risorse. Come
accennato in precedenza nella sezione sul Bus Mastering DMA, una scheda ben disegnata pu&ograve;
ridurre tutto questo copiar di dati, e il caso ideale sarebbe ovviamente "Zero Copy". 
Su alcune schede PCI moderne, Zero Copy diventa possibile semplicemente indicando alla scheda
dove si trovano i dati ed essenzialmente dicendogli "prenditeli da te". Se si desiderano massime
prestazioni in condizioni di poco traffico, allora si controlli che sia l'hardware che il driver
supportino funzionamento in "Zero Copy".

<sect1>Impatto sulle Prestazioni dei Checksum in Hardware
<p>
Non c'&egrave; garanzia che i vostri dati viaggeranno dal computer A al computer B
senza venire corrotti. Per essere sicuri che i dati siano inalterati, il mittente
somma tutti i numeri che costituiscono i dati da inviare, e allega a questi il checksum
calcolato. Il destinatario ricalcola questo checksum e controlla che coincida con quello
ricevuto insieme ai dati. Se i due non corrispondono, il destinatario sa che i dati sono
stati corrotti e scarter&agrave; il pacchetto ricevuto  e relativi dati alterati. 

Calcolare queste somme richiede tempo e costituisce un ulteriore carico sulla CPU
del computer. Alcune delle migliori schede hanno circuiti in hardware per calcolare
i checksum di ricezione e di trasmissione senza disturbare il processore principale.

Quelle schede che richiedono copia dei dati non traggono gran vantaggio dai 
checksum in hardware, dato che l'operazione di somma pu&ograve; essere combinata
con l'operazione di copia con una minima differenza di lavoro per il processore.
Di conseguenza, checksum di trasmissione in hardware vengono usati solo in 
situazioni di zero copy (come ad esempio un applicazione che chiama <tt>sendfile()</tt>),
e checksum hardware di ricezione sono al momento attuale ben pi&ugrave; utili.

Si noti che un computer di prestazioni ragionevoli pu&ograve; saturare una connessione
100BaseT anche se deve calcolare i checksum in CPU e compiere operazioni di copia,
per cui zero copy e checksum hardware risultano comunque solamente in un ridotto uso
della CPU, si dovrebbe esaminare uno scenario GigE per vedere un aumento di prestazioni
in rete.

<sect1>Impatto sulle Prestazioni del NAPI (Rx interrupt mitigation)
<p>
Quando una scheda riceve un pacchetto dalla rete, solitamente la scheda
richiama l'attenzione del processore con un interrupt. La CPU determina 
che dispositivo ha causato l'interrupt e quindi esegue l'handler d'interrupt
incluso nel driver della scheda, che a sua volta rileva lo stato di interrupt
della scheda per determinare che cosa la scheda volesse e, in questo caso, 
usa la funzione di ricezione dati inclusa nel driver e (finalmente), termina.

Adesso immaginatevi di stare continuamente ricevendo un sacco di dati, diciamo diecimila 
pacchetti al secondo, su un qualche server. Potete immaginarvi che la rincorsa di
richieste di servizio per interrupt analoghe a quanto appena descritto causi un certo
overhead, ed infatti un sacco di tempo del processore pu&ograve; essere facilmente risparmiato
semplicemente sospendendo la generazione di interrupt e rimanendo nella funzione di
ricezione del driver, dato che pi&ugrave; o meno sa di dover servire un flusso di lavoro
costante. Quest'idea sostanzialmente costituisce NAPI. 

A partire dai kernel 2.6, alcuni driver hanno un opzione di configurazione per abilitare
NAPI. Un poco di documentazione al riguardo &egrave; inclusa nella directory 
<tt>Documentation/networking</tt> del kernel.

<sect>Miscellanea<label id="misc">
<p>

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

<sect1>Buffer FIFO di Trasmissione ed Errori di Underrun
<p>
Donald ha scritto una bella descrizione di che cosa sia un buffer FIFO
di trasmissione e di cosa succede quando si verifica un errore. Eccola a voi:

Nei casi in cui l'hardware lo supporta, i miei driver includono codice per
ottimizzare il comportamento della FIFO di trasmissione. Un tipico chip Ethernet ha una FIFO
di trasmissione che contiene i dati arrivati dal bus prima che questi vengano
trasmessi sul cavo. La maniera in cui questa FIFO viene gestita &egrave; importante
per le prestazioni.

Idealmente, si dovrebbe voler iniziare a trasmettere non appena il primo
pacchetto in trasmissione arriva sul chip. Il "Tx FIFO threshold" &egrave;
un parametro che specifica di iniziare a trasmettere quando N byte sono arrivati
al NIC. Inizialmente, questo parametro &egrave; settato per una configurazione
tipica, ma se una scheda video o un controller SCSI stanno causando dei prolungati
picchi di traffico PCI, il chip NIC esaurir&agrave; i dati nel suo buffer di trasmissione
prima di poter accedere di nuovo al bus, e questo causa una FIFO underrun.

Il driver risponde ad una FIFO underrun incrementando il "Tx FIFO threshold", e se
questo succede un numero sufficiente di volte il chip finir&agrave; per operare
in modalit&agrave; store-and-forward, vale a dire che la trasmissione di un pacchetto 
non avr&agrave; inizio sino a quando esso non sia stato completamente trasferito al NIC.

Alcuni progetti, come l'Adaptec Starfire, compiono un passo ulteriore e forniscono
un segnale che la FIFO ha quasi esaurito i dati. Questo permette al driver di 
configurare questo settaggio senza rischiare un errore di trasmissione.

Dovrebbe essere piuttosto raro l'incontrare pi&ugrave; di uno o due FIFO underrun:
o il chip ha un settaggio del "Tx FIFO threshold" che permette poche scelte oppure
il driver aumenta questo valore in grossi passi per mantenere i picchi di traffico
PCI contenuti dai loro limiti naturali.

<sect1>Passare al kernel argomenti Ethernet<label id="lilo">
<p>

Ci sono due comandi generici che possono essere passati al kernel al
momento del boot: <tt/ether/ e <tt/reserve/. Si pu&ograve; far questo
con LILO, loadlin o qualsiasi altra utilità di boot che accetti
argomenti opzionali.

Per esempio, se il comando fosse 'blah' e si aspettasse 3 argomenti
(diciamo 123, 456 e 789) allora con LILO si potrebbe usare:

<tt>LILO: linux blah=123,456,789</tt>

Questi parametri di boot possono essere resi permanenti cosicch&eacute; non
si debba reinserirli ogni volta. Solitamente questo richiede solamente
l'inserimento di una riga come <tt>append="blah=123,456,789"</tt> all'inizio
del vostro <tt>/etc/lilo.conf</tt>. Si veda la documentazione di LILO per
ulteriori dettagli.

Per maggiori informazioni sui parametri di boot (e un elenco completo) si veda il
<url url="http://metalab.unc.edu/mdw/HOWTO/BootPrompt-HOWTO.html" name="BootPrompt-HOWTO">.

<sect2>Il parametro <tt/ether/<label id="ether">
<p>

Il parametro <tt/ether=/ viene usato in congiunzione con i driver direttamente
compilati nel kernel. <em/Non ha assolutamente alcun effetto/
su driver modulari. Nella sua forma più generale, può
somigliare a qualcosa come quel che segue:

<tscreen>
	ether=IRQ,IND_BASE,PARAM_1,PARAM_2,NOME
</tscreen>

Tutti gli argomenti sono opzionali. Il primo argomento non numerico è
interpretato come NOME.

<bf/IRQ:/ ovvio. Un valore di '0' (solitamente il valore
predefinito) indica di usare autoIRQ. È accidentale che l'impostazione
dell'IRQ sia prima di quella dell'ind_base: questo verrà corretto
non appena cambia anche qualcos'altro.

<bf/IND_BASE:/ altrettanto ovvio. Il valore '0' (solitamente quello
predefinito) indica di rilevare una scheda nell'elenco di indirizzi
specifici per quella scheda.

<bf/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.

<bf/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.

<bf/NOME:/
Seleziona il dispositivo di rete a cui fa riferimento il valore. Il
kernel standard usa i nomi 'eth0', 'eth1', 'eth2' e 'eth3' per le
schede Ethernet attaccate sul bus e 'atp0' per gli adattatori
Ethernet 'pocket' su porta parallela. Il driver arcnet come nome usa 'arc0'.
L'impostazione predefinita è per il rilevamento di un'unica
scheda Ethernet, la 'eth0'. L'abilitazione di più schede è possibile
solamente impostando esplicitamente il loro indirizzo base usando
questi parametri per LILO. Il kernel 1.0 trattava le schede Ethernet
basate su LANCE in modo speciale. Gli argomenti di LILO venivano sempre
ignorati e alle schede LANCE erano sempre assegnati i nomi 'eth&lt;n&gt;'
partendo da 'eth0'. Ulteriori schede Ethernet non
LANCE dovevano essere esplicitamente assegnate a 'eth&lt;n+1&gt;', e
il rilevamento standard di 'eth0' doveva essere disabilitato con qualcosa
di simile a 'ether=0,-1,eth0' (sì, questo è un bug).

<sect2>Il comando <tt/reserve/<label id="reserve">
<p>

Questo comando di lilo viene usato proprio come il precedente 'ether=',
ovvero viene accodato al nome di avvio selezionato in lilo.conf.

<tscreen>
	reserve=IO-base,estensione{,IO-base,estensione...}
</tscreen>

In alcune macchine può essere necessario impedire ai driver di 
controllare la presenza di dispositivi (auto-probing) in regioni specifiche.
Ciò può essere dovuto ad hardware mal progettato che causa il <em/blocco/ del boot
(come alcune schede Ethernet), ad hardware che viene mal identificato, ad hardware il cui
stato è stato modificato da un rilevamento precedente, o semplicemente ad hardware
che non vuole essere inizializzato dal kernel.

L'argomento di boot <tt/reserve/ indirizza questo problema
specificando una regione di porte di I/O che non deve essere
controllata. Tale regione viene riservata nella tabella di
registrazione delle porte del kernel come se vi si fosse già rilevato
un dispositivo. Si noti che questo meccanismo non dovrebbe essere
necessario nella maggior parte della macchine a meno che non si sia
riscontrato un problema (o di avere a che fare con un caso particolare).

Le porte I/O nella regione specificata vengono protette dai controlli per la ricerca dei
dispositivi. Questo si è reso necessario per gestire i casi in cui alcuni driver si
piantavano su di una NE2000 o erroneamente identificavano altri dispositivi come propri.
Un driver di dispositivo correttamente scritto non dovrebbe controllare una regione riservata
a meno che qualche altro argomento di boot non specifici esplicitamente di far questo.
La maggior parte dei driver ignora la tabella di registrazione delle porte se gli viene
passato un indirizzo specifico.

Per esempio, la riga di boot

<tscreen>
	LILO: linux  reserve=0x300,32  ether=0,0x300,eth0
</tscreen>

impedisce a tutti i device driver, tranne a quelli della scheda
Ethernet, di controllare se un dispositivo &egrave; presente nella regione 0x300-0x31f.

Come al solito per i comandi di boot, c'è un limite di 11 parametri, quindi si
possono specificare solo 5 regioni riservate per ciascun comando <tt/reserve/.
Possono essere specificati più <tt/reserve/ se si hanno richieste insolitamente
complicate da descrivere.

<sect1>Usare un driver Ethernet come modulo<label id="modules">
<p>

La maggior parte delle distribuzioni di Linux utilizzano ora dei
kernel con pochissimi driver al loro interno. I driver vengono ora piuttosto
forniti come gruppo di moduli indipendenti caricabili dinamicamente.
Questi driver modulari sono tipicamente caricati
dall'amministratore con il comando <tt/modprobe(8)/ o in alcuni casi
sono automaticamente caricati dal kernel attraverso 'kerneld' (nei
kernel 2.0) o 'kmod' (nei kernel 2.1) che a loro volta chiamano <tt/modprobe/.

La vostra distribuzione può offrire un comodo strumento grafico
per la configurazione dei moduli Ethernet. Se possibile prima si dovrebbe
provare a usare quello. La descrizione che segue descrive che cosa
sta dietro a qualsiasi programma di configurazione e indica cosa quei programmi
vadano a modificare.

Le informazioni che indicano quali moduli vengono usati e quali
opzioni vengono passate a ciascun modulo vengono solitamente salvate nel
file <tt>/etc/modules.conf</tt>. Le due opzioni principali di
interesse per le schede Ethernet che saranno usate in questo file sono
<tt/alias/ e <tt/options/. Il comando <tt/modprobe/ consulta questo
file per informazioni sui moduli.

I moduli stessi sono tipicamente collocati in una directory chiamata
<tt>/lib/modules/`uname -r`/net</tt> dove il comando <tt/uname -r/
restituisce la versione del kernel (e.g. 2.0.34). Si può andare li
per vedere quale modulo corrisponda alla propria scheda.

La prima cosa che ci deve essere nel file <tt/modules.conf/ è
una riga che indichi a <tt/modprobe/ quale driver usare per l'interfaccia
di rete <tt/eth0/ (e per <tt/eth1/ e per...). Per fare questo si
dovrà usare il comando <tt/alias/. Per esempio, se si ha una scheda
ISA EtherEZ della SMC che usa il driver modulare <tt/smc-ultra.o/,
si deve creare un <tt/alias/ per questo driver che corrisponda a
<tt/eth0/, aggiungendo la riga:

<verb>
	alias eth0 smc-ultra
</verb>

Nota Importante: l'alias summenzionato viene usato solo dalle utilità per
i moduli per convertire un nome di device generico (come ad esempio <tt/eth0/)
nel nome specifico del modulo del driver. Quando il driver viene caricato non
vede mai questo alias: invece, esso si limita a scegliere il primo nome libero
(<tt/ethN/ per N=0,1,2,...). Quindi, se pi&ugrave; di un modulo Ethernet viene
caricato, l'<tt/ethN/ assegnato al driver dal kernel pu&ograve; non
corrispondere con quello assegnatogli dall'alias, a seconda dell'ordine in cui
i moduli vengono caricati. Se dovete assicurarvi che una specifica scheda
venga assegnata un indirizzo IP specifico, allora si legga l'indirizzo della
hardware della scheda e si assegni l'indirizzo IP a seconda di quello. Se
state scrivendo un vostro shell script per far questo, potete limitarvi a
fare il parsing dell'output di ifconfig, altrimenti in C potete usare la
chiamata

<tt>ioctl(ethfd, SIOCGIFHWADDR, &amp;ifreq)</tt>.

L'altra cosa di cui si può aver bisogno è una riga <tt/options/ che
indichi quali opzioni devono essere usate con un particolare modulo (o
alias di modulo). Continuando con l'esempio di prima, se si usa
solamente la riga <tt/alias/ con nessuna riga <tt/options/, il kernel vi
avviserà (si veda <tt/dmesg/) che l'auto rilevamento di una scheda ISA
non è una buona idea. Per eliminare questo problema, si
aggiunga un'altra riga che indica al modulo a quale indirizzo I/O base è
collocata la scheda, ad esempio perl'indirizzo esadecimale <tt/0x280/ si usi

<verb>
	options smc-ultra io=0x280
</verb>

La maggior parte dei moduli ISA accettano parametri come <tt/io=0x340/
e <tt/irq=12/ sulla riga di comando di <tt/insmod/. Fornire questi
parametri è <em/RICHIESTO/ o almeno <em/CALDAMENTE CONSIGLIATO/ per
evitare il rilevamento della scheda. Diversamente dai dispositivi PCI e
EISA, non c'è alcun modo sicuro per fare l'auto rilevamento della
maggior parte dei dispositivi ISA e quindi lo si dovrebbe evitare
quando si usa un driver come modulo.

Un elenco di tutte le opzioni che ciascun modulo accetta può essere
reperita nel file:

<tt>/usr/src/linux/Documentation/networking/net-modules.txt</tt>

Si raccomanda la sua lettura per scoprire quali opzioni si possano
usare con la propria scheda. Si noti che alcuni moduli supportano
un elenco di valori separati da virgola. Solitamente questo è il caso
di moduli che sono in grado di gestire più dispositivi con un unica copia del
modulo, come tutti i driver basati su 8390 e il driver PLIP. Per
esempio:

<code>
	options 3c503 io=0x280,0x300,0x330,0x350 xcvr=0,1,0,1
</code>

Con la riga precedente si avrà un unico modulo che controlla quattro
schede 3c503, con la scheda 2 e 4 che usano il transceiver esterno.
Non si aggiungano spazi attorno a '=' o alle virgole.

Si noti inoltre che un modulo <em/occupato/ non può essere rimosso.
Ciò significa che si dovrà usare <tt/ifconfig eth0 down/ (per disattivare
la scheda Ethernet) prima di rimuovere il modulo.

Il comando <tt/lsmod/ mostrerà quali moduli sono caricati e se sono in
uso, mentre il comando <tt/rmmod/ può essere usato per rimuoverli.

<sect1>Documentazione correlata
<p>

La maggior parte dei queste informazioni provengono da messaggi che ho
salvato dai gruppi comp.os.linux, che si sono dimostrati una
insostituibile fonte di informazioni. Altre informazioni utili
provengono da un gruppo di piccoli file di Donald stesso.
Naturalmente, se si sta impostando una scheda Ethernet, allora sarà
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
<em/comp.dcom.lans.ethernet/ e/o
<em/comp.sys.ibm.pc.hardware.networking/. Gli archivi dei newsgroup
come quelli a <tt/dejanews.com/ possono essere una insostituibile
fonte di informazioni. Si possono prendere le FAQ da RTFM (che
conserva tutte le FAQ dei newsgroup) all'URL seguente:

<url url="ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/" name="Usenet FAQs">

Si può anche dare un'occhiata alla cosiddetta 'Ethernet-HomePage', che
è all'URL seguente:

<url url="http://wwwhost.ots.utexas.edu/ethernet/ethernet-home.html"
name="Ethernet-HomePage">


<sect1>Liberatoria e copyright (in originale inglese)<label id="copyright">
<p>
    This document is <em/not/ gospel. However, it is probably the most
	up to date info that you will be able to find. Nobody is responsible
	for what happens to your hardware but yourself. If your ethercard
	or any other hardware goes up in smoke (...nearly impossible!)
	we take no responsibility. ie. THE AUTHORS ARE NOT RESPONSIBLE
	FOR ANY DAMAGES INCURRED DUE TO ACTIONS TAKEN BASED ON THE
	INFORMATION INCLUDED IN THIS DOCUMENT.

	This document is Copyright (c) 1993-2000 by Paul Gortmaker.
	Permission is granted to make and distribute verbatim copies
	of this manual provided the copyright notice and this permission
	notice are preserved on all copies.

	Permission is granted to copy and distribute modified versions
	of this document under the conditions for verbatim copying,
	provided that this copyright notice is included exactly as in
	the original, and that the entire resulting derived work is
	distributed under the terms of a permission notice identical
	to this one.

	Permission is granted to copy and distribute translations
	of this document into another language, under the above
	conditions for modified versions.

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

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

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

Grazie!

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