Linux Ethernet-HOWTO di Paul Gortmaker v2.9, 25 Agosto 2003 Questo è l'Ethernet Howto, una raccolta di informazioni su quali dis­ positivi Ethernet possono essere usati con Linux e su come configu­ rarli. Si noti che questo Howto si concentra sull'aspetto hardware e sui driver a basso livello delle schede Ethernet e non tratta l'aspetto software di cose come ifconfig e route, che sono coperte in svariati altri materiali di documentazione Linux. Traduzione fino al 1999 a cura di Lorenza Romano (titti@dei.unipd.it) e Giovanni Bor­ tolozzo (borto@pluto.it), dopo il 1999 a cura di Federico Lucifredi (lucifred@fas.harvard.edu); revisione a cura di Claudio Cattazzo clau­ dio@pluto.it. ______________________________________________________________________ Indice Generale 1. Introduzione 1.1 Nuove versioni di questo documento 1.2 Come usare l'Ethernet-Howto 1.3 Cosa devo fare per far funzionare una scheda Ethernet? 1.4 AIUTO - Non funziona! 1.5 Tipi di cavo che la propria scheda dovrebbe supportare 2. Domande frequenti 2.1 Come spiego a Linux che driver usare? 2.2 Che scheda si dovrebbe acquistare per Linux? 2.3 Driver alpha -- come procurarseli e come usarli 2.4 Come usare più di una scheda Ethernet per macchina 2.4.1 Con il Driver Come Modulo 2.4.2 Con il Driver Compilato nel Kernel 2.5 Il comando ether= non è servito a niente. Perché? 2.6 Problemi con schede NE1000/NE2000 (e cloni) 2.7 Problemi con le schede SMC Ultra/EtherEZ e WD80*3 2.8 Problemi con le schede 3Com 2.9 FAQ non specifiche ad una particolare scheda 2.9.1 Linux e schede Ethernet ISA di tipo Plug and Play 2.9.2 un sistema PCI rileva la scheda ma il driver non riesce ad autoconfigurarsi (PnP OS) 2.9.3 In un sistema PCI, tutte le schede vengono rilevate ma due non funzionano 2.9.4 Il mio sistema ha /etc/conf.modules e non /etc/modules.conf. 2.9.5 La scheda Ethernet non viene rilevata all'avvio 2.9.6 Il driver dichiara unresolved symbol ei_open e non viene caricato 2.9.7 ifconfig mostra un indirizzo di I/O sbagliato per la scheda 2.9.8 Le schede ISA a memoria condivisa non funzionano in un sistema PCI (0xffff) 2.9.9 Sembra che la scheda invii dati ma non riceve niente 2.9.10 Supporto per Asynchronous Transfer Mode (ATM) 2.9.11 Supporto per Gigabit Ethernet 2.9.12 Supporto FDDI 2.9.13 Supporto Full Duplex 2.9.14 Schede Ethernet per Linux su macchine SMP 2.9.15 Schede Ethernet per Linux su piattaforma Alpha/AXP e bus PCI 2.9.16 Ethernet per Linux su hardware SUN/Sparc 2.9.17 Ethernet per Linux su altro hardware 2.9.18 Connettere 10 o 100 BaseT senza un hub 2.9.19 SIOCSIFxxx: No such device 2.9.20 SIOCSFFLAGS: Try again 2.9.21 Usando 'ifconfig' e Link di tipo UNSPEC con indirizzo hardware 00:00:00:00:00:00 2.9.22 Enorme numero di errori in RX e TX 2.9.23 Voci in /dev/ per le schede Ethernet 2.9.24 Accesso a basso livello al dispositivo Ethernet 3. Suggerimenti per migliorare le prestazioni 3.1 Concetti generali 3.2 Schede ISA e velocità del bus ISA 3.3 Impostare la finestra TCP di ricezione (TCP Rx Window) 3.4 Incrementare le prestazioni NFS 4. Informazioni specifiche su produttori e modelli 4.1 3Com 4.1.1 3c501 4.1.2 EtherLink II, 3c503, 3c503/16 4.1.3 Etherlink Plus 3c505 4.1.4 Etherlink-16 3c507 4.1.5 Etherlink III, 3c509 / 3c509B 4.1.6 3c515 4.1.7 3c523 4.1.8 3c527 Etherlink MC/32 4.1.9 3c529 4.1.10 3c556 4.1.11 3c562 4.1.12 3c575 4.1.13 3c579 4.1.14 3c589 / 3c589B 4.1.15 3c590 / 3c595 4.1.16 3c592 / 3c597 4.1.17 3c900 / 3c905 / 3c905B / 3c905C / 3c905CX 4.1.18 3c985 (Gigabit acenic, Tigon2) 4.1.19 3c996 (Gigabit broadcom, Tigon3) 4.2 Accton 4.2.1 Accton MPX 4.2.2 Accton EN1203, EN1207, EtherDuo-PCI 4.2.3 Accton EN2209 Parallel Port Adaptor (EtherPocket) 4.2.4 Accton EN2212 PCMCIA Card 4.3 Adaptec 4.3.1 Adaptec DuraLAN/Starfire, 64bit ANA-6922 4.4 Allied Telesyn/Telesis 4.4.1 AT1500 4.4.2 AT1700 4.4.3 AT2400 4.4.4 AT2450 4.4.5 AT2500 4.4.6 AT2540FX 4.5 AMD / Advanced Micro Devices 4.5.1 AMD LANCE (7990, 79C960/961/961A, PCnet-ISA) 4.5.2 AMD 79C901 (Home PNA PHY) 4.5.3 AMD 79C965 (PCnet-32) 4.5.4 AMD 79C970/970A (PCnet-PCI) 4.5.5 AMD 79C971 (PCnet-FAST) 4.5.6 AMD 79C972 (PCnet-FAST+) 4.5.7 AMD 79C974 (PCnet-SCSI) 4.6 Ansel Communications 4.6.1 AC3200 EISA 4.7 Apricot 4.7.1 Apricot Xen-II On Board Ethernet 4.8 Arcnet 4.9 Boca Research 4.9.1 Boca BEN400 4.9.2 Boca BEN (ISA, VLB, PCI) 4.10 Broadcom 4.10.1 Broadcom Tigon2 4.10.2 Broadcom Tigon3 4.11 Cabletron 4.11.1 E10**, E10**-x, E20**, E20**-x 4.11.2 E2100 4.11.3 E22** 4.12 Cogent 4.12.1 EM100-ISA/EISA 4.12.2 Cogent eMASTER+, EM100-PCI, EM400, EM960, EM964 4.13 Compaq 4.13.1 Compaq Deskpro / Compaq XL (Embedded AMD Chip) 4.13.2 Compaq Nettelligent/NetFlex (Embedded ThunderLAN Chip) 4.13.3 Compaq PCI card 4.14 Danpex 4.14.1 Danpex EN9400 4.15 Davicom 4.15.1 Davicom DM9102 4.16 D-Link 4.16.1 DE-100, DE-200, DE-220-T, DE-250 4.16.2 DE-520 4.16.3 DE-528 4.16.4 DE-530 4.16.5 DE-600 4.16.6 DE-620 4.16.7 DE-650 4.16.8 DFE-530TX 4.16.9 DFE-530TX+, DFE-538TX 4.16.10 DFE-550TX 4.16.11 DFE-570TX 4.16.12 DFE-580TX 4.16.13 DGE-500T 4.16.14 DGE-550T 4.17 DFI 4.17.1 DFINET-300 e DFINET-400 4.18 Digital / DEC 4.18.1 DEPCA, DE100/1, DE200/1/2, DE210, DE422 4.18.2 Digital EtherWorks 3 (DE203, DE204, DE205) 4.18.3 DE425 EISA, DE434, DE435, DE500 4.18.4 DEC 21040, 21041, 2114x, Tulip 4.19 Farallon 4.19.1 Farallon Etherwave 4.19.2 Farallon PCI 593 4.20 Fujitsu 4.20.1 Fujitsu FMV-181/182/183/184 4.21 Hewlett Packard 4.21.1 HP Night Director+ 10/100 4.21.2 27245A 4.21.3 HP EtherTwist, PC Lan+ (27247, 27248, 27252A, 27269B) 4.21.4 HP-J2405A 4.21.5 HP-Vectra On Board Ethernet 4.21.6 Schede HP 10/100 VG Any Lan (27248B, J2573, J2577, J2585, J970, J973) 4.21.7 HP NetServer 10/100TX PCI (D5013A) 4.22 IBM / International Business Machines 4.22.1 IBM Thinkpad 300 4.22.2 IBM Credit Card Adaptor for Ethernet 4.22.3 IBM 10/100 EtherJet PCI 4.22.4 IBM Token Ring 4.23 Schede Ethernet ICL 4.23.1 ICL EtherTeam 16i/32 4.24 Schede Ethernet Intel 4.24.1 Ether Express 4.24.2 Ether Express PRO/10 (PRO/10+) 4.24.3 Ether Express PRO/10 PCI (EISA) 4.24.4 Ether Express PRO 10/100B 4.24.5 E1000 Gigabit 4.25 Kingston 4.26 LinkSys 4.26.1 Schede LinkSys Etherfast 10/100. 4.26.2 LinkSys Pocket Ethernet Adapter Plus (PEAEPP) 4.26.3 LinkSys PCMCIA Adaptor 4.27 Microdyne (Eagle) 4.27.1 Microdyne Exos 205T 4.28 Mylex 4.28.1 Mylex LNE390A, LNE390B 4.28.2 Mylex LNP101 4.28.3 Mylex LNP104 4.29 Myson 4.29.1 Myson MTD-8xx 10/100 PCI 4.30 National Semiconductor 4.30.1 NS8390, DP8390, DP83905 etc. 4.30.2 DP83800 with DP83840 4.30.3 DP83815/83816 4.30.4 NS83820, DP83820 4.31 Novell Ethernet, NExxxx e cloni associati 4.31.1 NE1000, NE2000 4.31.2 NE2000-PCI (RealTek/Winbond/Compex) 4.31.3 NE-10/100 4.31.4 NE1500, NE2100 4.31.5 NE/2 MCA 4.31.6 NE3200 4.31.7 NE3210 4.31.8 NE4100 4.31.9 NE5500 4.32 Netgear 4.32.1 Netgear FA-311 4.32.2 Netgear GA-620 4.32.3 Netgear GA-621 4.33 Proteon 4.33.1 Proteon P1370-EA 4.33.2 Proteon P1670-EA 4.34 Pure Data 4.34.1 PDUC8028, PDI8023 4.35 Racal-Interlan 4.35.1 ES3210 4.35.2 NI5010 4.35.3 NI5210 4.35.4 NI6510 (non EB) 4.35.5 EtherBlaster (aka NI6510EB) 4.36 RealTek 4.36.1 Adattatore pocket RealTek RTL8002/8012 (AT-Lan-Tec) 4.36.2 RealTek 8008 4.36.3 RealTek 8009 4.36.4 RealTek 8019 4.36.5 RealTek 8029 4.36.6 RealTek 8129/8139 4.37 Sager 4.37.1 Sager NP943 4.38 Schneider & Koch 4.38.1 SK G16 4.39 SEEQ 4.39.1 SEEQ 8005 4.40 SiS (Silicon Integrated Systems) 4.40.1 SiS 900 (7016, 630E, 962) 4.41 SMC (Standard Microsystems Corp.) 4.41.1 WD8003, SMC Elite 4.41.2 WD8013, SMC Elite16 4.41.3 SMC Elite Ultra 4.41.4 SMC Elite Ultra32 EISA 4.41.5 SMC EtherEZ (8416) 4.41.6 SMC EtherPower PCI (8432) 4.41.7 SMC EtherPower II PCI (9432) 4.41.8 SMC 1211TX 10/100 4.41.9 SMC 3008 4.41.10 SMC 3016 4.41.11 SMC-9000 / SMC 91c92/4 4.41.12 SMC 91c100 4.41.13 SMC 9452TX/9462TX 4.42 Sundance 4.42.1 Sundance ST201, Alta 4.43 SysKonnect 4.43.1 SysKonnect sk-98xx Gigabit Ethernet 4.44 Texas Instruments 4.44.1 ThunderLAN 4.45 Thomas Conrad 4.45.1 Thomas Conrad TC-5048 4.46 VIA 4.46.1 VIA 86C926 Amazon 4.46.2 VIA 86C100A Rhine II (and 3043 Rhine I) 4.47 Western Digital 4.48 Winbond 4.48.1 Winbond 89c840 4.48.2 Winbond 89c904, 89c905, 89c906 4.48.3 Winbond 89c940 4.49 Xircom 4.49.1 Xircom PE1, PE2, PE3-10B* 4.49.2 Xircom CE, CEM, CE2, CE3 4.49.3 Xircom CBE-100 4.50 Zenith 4.50.1 Z-Note 4.51 Znyx 4.51.1 Znyx ZX342 (DEC 21040 based) 4.52 Identificare una scheda sconosciuta 4.52.1 Identificare il Network Interface Controller 4.52.2 Identificare l'indirizzo Ethernet 4.52.3 Identificare la scheda a partire dal numero di FCC ID 4.52.4 Suggerimenti per provare ad usare una scheda sconosciuta 4.53 Driver per i dispositivi non Ethernet 5. Cavi, coassiali, doppini intrecciati 5.1 Thin Ethernet (thinnet) 5.2 Doppino intrecciato (twisted pair) 6. Configurazione del software e diagnotici 6.1 Programmi di configurazione per le schede Ethernet 6.1.1 Schede WD80x3 6.1.2 Schede Digital/DEC 6.1.3 Schede NE2000+ o AT/LANTIC 6.1.4 Schede 3Com 6.2 Programmi diagnostici per schede Ethernet 7. Informazioni tecniche 7.1 I/O programmato, memoria condivisa e DMA a confronto 7.1.1 Programmed I/O (I/O Programmato) (es. NE2000, 3c509) 7.1.2 Shared memory (Memoria Condivisa) (es. WD80x3, SMC-Ultra, 3c503) 7.1.3 DMA (Accesso diretto alla memoria) in bus mastering (es. LANCE, DEC 21040) 7.2 Implicazioni della Larghezza di Bus per le Prestazioni 7.2.1 Schede ISA a 8 e 16 Bit 7.2.2 Schede Ethernet a 32 Bit per bus PCI (e VLB/EISA) 7.3 Impatto sulle prestazioni di Zero Copy 7.4 Impatto sulle Prestazioni dei Checksum in Hardware 7.5 Impatto sulle Prestazioni del NAPI (Rx interrupt mitigation) 8. Miscellanea 8.1 Buffer FIFO di Trasmissione ed Errori di Underrun 8.2 Passare al kernel argomenti Ethernet 8.2.1 Il parametro ether 8.2.2 Il comando reserve 8.3 Usare un driver Ethernet come modulo 8.4 Documentazione correlata 8.5 Liberatoria e copyright (in originale inglese) 8.6 Chiusura ______________________________________________________________________ 1. Introduzione L'Ethernet-Howto include dettagliate informazioni sul corrente livello di supporto per la maggior parte delle schede Ethernet più 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ì 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ò risultava in un più 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ì hanno aggiunto funzionalità 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ù 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: Paul Gortmaker, p_gortmaker @ yahoo.com La fonte principale di informazioni per la versione iniziale dell' Ethernet-Howto, originariamente disponibile esclusivamente in formato ASCII: Donald J. Becker, becker@cesdis.gsfc.nasa.gov 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 (``copyright'') per informazioni circa la ridistribuzione e le solite liberatorie legali come "non siamo responsabili per ciò che riuscirete a rompere...". 1.1. Nuove versioni di questo documento Nuove versioni di questo documento possono essere reperite all'indirizzo: Ethernet-HOWTO o per chi desidera usare FTP e/o procurarsi formati non HTML: 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. 1.2. Come usare l'Ethernet-Howto Poiché questa guida sta diventando sempre più grande, probabilmente non si vuole sprecare il resto del pomeriggio leggendola per intero. E la buona notizia è che non la si deve leggere tutta. Le versioni HTML e Postscript/dvi hanno un indice che aiuterà senz'altro a trovare ciò di cui si ha bisogno molto più velocemente. Può essere che si stia leggendo questo documento perché non si riesce a far funzionare le cose e non si sa cosa controllare o verificare. La sezione ``AIUTO - Non funziona!'' è rivolta ai nuovi utenti di Linux e vi metterà nella direzione giusta. Tipicamente gli stessi problemi e quesiti sono posti più e più volte da diverse persone. Può essere che il proprio problema specifico sia una delle Frequently Asked Questions (domande frequenti) e trovi risposta nella sezione FAQ di questo documento (``Sezione FAQ''). Tutti dovrebbero dare un'occhiata a questa sezione prima di inviare una richiesta di aiuto. Se non si possiede una scheda Ethernet, allora si dovrà in primo luogo scegliere una scheda (``Che scheda si dovrebbe acquistare...''). Se si possiede già una scheda Ethernet, ma non si è sicuri di poterla usare con Linux, allora si dovrà leggere la sezione che contiene informazioni specifiche su ogni produttore e le relative schede (``Informazioni specifiche su...''). Se si è interessati ad alcuni degli aspetti tecnici dei driver dei dispositivi per Linux, allora si può dare una scorsa alla sezione contenente questo tipo di informazioni (``Informazioni tecniche''). 1.3. Cosa devo fare per far funzionare una scheda Ethernet? Nel modo più 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. 1.4. AIUTO - Non funziona! Okay, niente panico. Questa sezione vi condurrà per mano nel processo che consente di far funzionare le cose anche se non si hanno precedenti conoscenze di Linux o 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à lspci per ottenere informazioni sui dispositivi installati sul bus PCI del vostro computer. Usare cat /proc/pci produce informazioni simili ma non altrettanto complete. Per schede di tipo ISA, si veda la sezione di aiuto sulle schede misteriose (cfr. ``Identificare una scheda sconosciuta''). Ora che si sa che tipo di scheda si possiede, si leggano da cima a fondo i dettagli a essa relativi nella sezione sulle specifiche delle schede (``Informazioni specifiche su...'') che elenca in ordine alfabetico i produttori di schede, i numeri identificativi dei modelli e se 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ò non significa che esso sia compreso in ogni kernel (il kernel è il nucleo del sistema operativo, la prima cosa caricata all'avvio e contiene, tra le altre cose, i driver per le diverse parti hardware). A seconda di chi ha prodotto la particolare distribuzione di Linux che si sta usando ci possono essere solo alcuni kernel precompilati e un grosso insieme di driver sotto forma di piccoli moduli separati, oppure un sacco di kernel, che coprono un enorme insieme di combinazioni di driver incorporati. Molte distribuzioni di Linux adesso contengono un gruppo di piccoli moduli, i diversi driver. I moduli necessari tipicamente vengono caricati in un secondo tempo nel processo di avvio o su richiesta non appena serve un driver per accedere ad un particolare dispositivo. Occorrerà inserire questo modulo nel kernel dopo che è stato avviato. Si vedano le informazioni fornite con la propria distribuzione sull'installazione e l'uso dei moduli, oltre alla sezione sui moduli in questo documento (``Usare 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 dmesg | more. Questo permetterà di rivedere i messaggi che il kernel ha fatto scorrere sullo schermo durante il processo di avvio. Se la scheda è stata rilevata si dovrebbe vedere da qualche parte in quell'elenco, un messaggio del driver della propria scheda che inizia con eth0 e cita il nome del driver e i parametri hardware per i quali è stata configurata (configurazione degli interrupt, indirizzo delle porte di input/output, ecc.). Nota: Linux all'avvio elenca tutte le schede PCI installate nel sistema, senza badare ai driver disponibili, non si scambi questo per la rilevazione dei driver che avviene più tardi. Se non si vede un messaggio di identificazione del driver di questo tipo, allora il driver non ha rilevato la propria scheda e questo è il motivo per il quale le cose non funzionano. Si vedano le FAQ (``Sezione FAQ'') per il da farsi se la propria scheda non viene rilevata. Nel caso si possieda una scheda NE2000 compatibile, nella sezione FAQ vi sono anche alcuni suggerimenti specifici per fare in modo che la scheda venga rilevata. Se la scheda viene rilevata ma il messaggio di rilevamento riporta un errore di qualche tipo, come un conflitto di risorsa, probabilmente il driver non 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 ifconfig e route e dettagli su come fare queste cose sono esaurientemente descritti nel Network HowTo e nella "Network Administrator Guide". Probabilmente entrambi si trovano nel CD-ROM che si è usato per l'installazione. Un errore di configurazione hardware si ha quando un qualche conflitto di risorsa o errore di configurazione (che il driver non ha rilevato in fase di avvio) impedisce alla scheda di funzionare correttamente. Ciò può essere osservato in parecchie maniere diverse. (1) Si ha un messaggio di errore quando ifconfig tenta di aprire il dispositivo per usarlo, del tipo "SIOCSFFLAGS: Try again". (2) Il driver riporta messaggi d'errore su eth0 (li si può vedere usando dmesg | more) o strane incongruenze ogniqualvolta prova a mandare o ricevere dati. (3) Digitando cat /proc/net/dev appaiono numeri diversi da zero in una delle colonne errs, drop, fifo, frame o carrier corrispondenti a eth0. (4) Digitando cat /proc/interrupts appare un numero di interrupt nullo per la scheda. Anche la maggior parte dei tipici errori di configurazione hardware sono discussi nella sezione FAQ. Bene, se si è arrivati a questo punto e le cose non funzionano ancora, si legga la sezione FAQ di questo documento, si legga la sezione sulle specifiche dei produttori che descrive la propria scheda, e se ancora non funziona allora si dovrebbe riccorrere all'invio di una richiesta di aiuto ad un opportuno newsgroup. Se si invia la richiesta, si descrivano dettagliatamente tutte le informazioni del caso come la marca della scheda, la versione del kernel, i messaggi del driver all'avvio, l'output di cat /proc/net/dev, una chiara descrizione del problema e naturalmente cosa si è già provato a fare per far funzionare le cose. 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ù informazioni sia possibile. 1.5. Tipi di cavo che la propria scheda dovrebbe supportare 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 $10-$20 in più. Queste schede hanno incorporato sia il transceiver per il doppino intrecciato (twisted pair) che per thinnet, consentendo di cambiare idea in seguito. 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 è desiderabile per qualsiasivoglia motivo. Si veda ``Cavi, coassiali,...'' per altre informazioni riguardanti i diversi tipi di cavi Ethernet. 2. Domande frequenti Ecco alcuni dei quesiti posti più frequentemente a proposito dell'uso di Linux con una connessione Ethernet. Alcuni dei quesiti più specifici sono classificati in "base al costruttore". Può essere che il quesito per il quale si ha bisogno di una risposta sia già stato posto da qualcun altro (e abbia trovato risposta!), perciò anche se non si trova la risposta qui, probabilmente si può trovare ciò che di cui si ha bisogno in un archivio di news come Dejanews . 2.1. Come spiego a Linux che driver usare? 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ù appropriatamente, al kernel) le informazioni necessarie sul come controllare una particolare scheda Ethernet. Il nome del modulo da impiegare è elencato nella intestazione della sezione dedicata alla vostra scheda in questo documento. Una volta che si è a conoscenza del nome del modulo, lo si deve aggiungere al file /etc/modules.conf in modo che il kernel Linux sappia che modulo caricare per la vostra scheda. La sintassi è solitamente come segue: alias eth0 nome_del_modulo options nome_del_modulo optione1=valore1 optione2=valore2 ... Solitamente la riga di opzioni è necessaria solo per hardware antiquato che si appoggia al bus ISA. In sistemi dotati di molteplici schede Ethernet, linee addizionali per eth1, eth2, e così via sono spesso necessarie. I moduli sono solitamente collocati nella directory /lib/modules/, che è solitamente ulteriormente suddivisa secondo le diverse versioni del kernel (per determinare la versione del kernel che state eseguendo usate uname -r) e il sottosistema di cui fanno parte (in questo caso si tratta di net). I moduli sono posti qui dal curatore della distribuzione o dal singolo utente quando viene eseguito il comando make modules_install 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à 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 make config nel processo di ricompilare il kernel (di nuovo, si faccia riferimento al kernel HOWTO per i dettagli). 2.2. Che scheda si dovrebbe acquistare per Linux? La risposta a questa domanda dipende molto da cosa si intende esattamente fare con la propria connessione di rete e quanto traffico 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: 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. 2.3. Driver alpha -- come procurarseli e come usarli Ho sentito che è disponibile un driver aggiornato oppure un driver preliminare o alpha (sperimentale) per la mia scheda. Dove posso procurarmelo? Il "più nuovo dei nuovi" in fatto di driver può essere trovato sul sito Web di Donald: 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: 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 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. 2.4. Come usare più di una scheda Ethernet per macchina Cosa è necessario fare affinché Linux possa utilizzare due o più 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 /lib/modules/). 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 è 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ò 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. 2.4.1. Con il Driver Come Modulo 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 /etc/modules.conf. Come esempio si consideri un utente che ha due schede ISA NE2000, una a 0x300 ed una a 0x240, le righe da mettere nel file /etc/modules.conf sono le seguenti: alias eth0 ne alias eth1 ne options ne io=0x240,0x300 Se l'amministratore (o il kernel) fa un modprobe eth0 oppure un modprobe eth1 allora dovrebbe essere caricato il driver ne.o sia per eth0 che per eth1. Inoltre quando viene caricato il modulo ne.o, dovrebbe esserlo con le opzioni io=0x240,0x300 cosicché il driver sa dove cercare le schede. Si noti che 0x è importante, cose del tipo 300h, comunemente usate nel mondo DOS, non funzionano. Cambiando l'ordine di 0x240 e 0x300 si cambierà quale scheda fisica finirà in eth0 e quale in eth1. Per 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 /etc/modules.conf dovrebbe in questo caso presentarsi così: alias eth0 3c501 alias eth1 3c501 options eth0 -o 3c501-0 io=0x280 irq=5 options eth1 -o 3c501-1 io=0x300 irq=7 In questo esempio l'opzione -o è stata usata per dare a ogni istanza del modulo un nome univoco, poiché non è possibile caricare due moduli con lo stesso nome. Viene anche usata l'opzione irq= per specificare la configurazione IRQ hardware della scheda (questo metodo può essere usato anche con moduli che accettano valori di I/O separati da virgole, ma è meno efficiente poiché il modulo finisce per essere caricato due volte anche se ciò non sarebbe realmente necessario). Come esempio finale, si consideri un utente con una scheda 3c503 all'indirizzo 0x350 e una SMC Elite16 (wd8013) a 0x280. Si avrà la seguente configurazione: alias eth0 wd alias eth1 3c503 options wd io=0x280 options 3c503 io=0x350 Per le schede PCI, tipicamente sono necessarie solamente le righe alias per correlare le interfacce ethN con l'appropriato nome del driver, poiché l'indirizzo I/O di base di una scheda PCI può essere rilevato in modo sicuro. I moduli disponibili sono tipicamente memorizzati in /lib/modules/`uname -r`/net dove il comando uname -r 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 modules.conf, si può collaudare il tutto con: modprobe ethN dmesg | tail dove 'N' è il numero dell'interfaccia Ethernet che si sta collaudando. Si noti che il nome dell'interfaccia (ethX) asssegnato al driver dal kernel è indipendente dal nome usato sulla riga di alias. Per ulteriori dettagli si faccia riferimento alla sezione ``Usare un driver Ethernet come modulo''. 2.4.2. Con il Driver Compilato nel Kernel Dato che il rilevamento automatico (probing, N.d.T.) di una scheda ISA può mandare in crash la macchina, i kernel fino al 2.4 incluso, effettuano per default la ricerca automatica di una sola scheda Ethernet su bus ISA. Dato che non vi sono più distribuzioni con dei kernel contenenti un gran numero di driver modulari ISA, tale restrizione non viene più imposta a partire dal kernel 2.6. Nei kernel della serie 2.2 (e più 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, è 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 ether=0,0,eth1. In questo caso eth0 e 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 0x300 sia eth0 e quella a 0x280 sia eth1, allora si può usare: LILO: linux ether=5,0x300,eth0 ether=15,0x280,eth1 Il parametro ether= è in grado di accettare più della terna composta da IRQ, indirizzo I/O di base e nome appena illustrata. Si veda la sezione ``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 Space.c e sostituire la voce 0xffe0 per l'indirizzo I/O con uno zero. La voce 0xffe0 dice di non effettuare la ricerca automatica per quel dispositivo -- rimpiazzandola con uno zero si abiliterà l'autorilevamento di quel dispositivo. 2.5. Il comando ether= non è servito a niente. Perché? Come descritto sopra, il comando ether= funziona solo per driver compilati nel kernel. Adesso molte distribuzioni usano driver in forma modulare, perciò il comando 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 devono fare modifiche al file /etc/conf.modules. Se si sta usando un driver compilato nel kernel e si è aggiunto un comando ether= al proprio file di configurazione LILO, si noti che esso non avrà effetto fino a che non si riesegue lilo per installare il file di configurazione aggiornato. 2.6. Problemi con schede NE1000/NE2000 (e cloni) Problema: Una scheda PCI compatibile con NE2000 non viene rilevata all'avvio del sistema usando una versione del kernel 2.0.x. Causa: Il driver 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. 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. 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. Causa: Alcuni cloni PCI non implementano l'accesso byte wide (perciò non sono realmente compatibili NE2000 al 100%). Ciò fa pensare al sistema che esse siano schede NE1000. Soluzione: È necessario aggiornare il kernel alla versione 2.0.31 (o più recente) come descritto in precedenza. La nuova versione del driver è stata aggiornata per tener conto di questo problema hardware. Problema: Una scheda PCI compatibile NE2000 presenta prestazioni orribili, anche se si riduce la dimensione della window come descritto nella sezione ``Suggerimenti per le prestazioni''. 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 è in grado di far questo ma tale funzionalità è 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. Soluzione: Visto che questa soluzione è stata riportata da una sola persona, non ci si illuda troppo. La riabilitazione della lettura prima della scrittura si ottiene semplicemente modificando il file del driver in linux/drivers/net/, togliendo il commento alla riga contenente NE_RW_BUGFIX e poi ricompilando il kernel o il modulo come al solito. Se funziona si invii una e-mail che descrive la differenza di prestazioni e il tipo di scheda/chip che si possiede (la stessa cosa può essere fatta anche per il driver ne2k-pci.c). Problema: Il driver ne2k-pci.c riporta messaggi di errore del tipo timeout waiting for Tx RDC con una scheda compatibile NE2000 su PCI e non funziona correttamente. 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. 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 ne.c (o la rimozione di #define USE_LONGIO dal driver ne2k-pci.c) dovrebbe permettere di usare la scheda. Problema: Una scheda ISA Plug and Play NE2000 (per esempio RealTek 8019) non viene rilevata. Causa: Le specifiche originarie NE2000 (e perciò il driver per Linux NE2000 un tempo incluso con il kernel) non supportano il Plug and Play. 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 /etc/modules.conf del tipo options ne io=0xNNN dove 0xNNN è l'indirizzo di I/O in formato esadecimale a cui la scheda è stata assegnata (ciò assume che si stia usando un driver modulare; se non è così si usi all'avvio un argomento ether=0,0xNNN,eth0). Può accadere anche che si debba entrare nel BIOS/CMOS setup e contrassegnare l'IRQ come Legacy-ISA al posto di PnP. Problema: Un driver NE*000 riporta 'not found (no reset ack)' durante il rilevamento compiuto all'avvio. 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ì è il driver di conseguenza assume che nessuna scheda NE sia presente. Soluzione: Si può dire al driver che si possiede una scheda scadente specificando al momento dell'avvio il valore esadecimale 0xbad, solitamente non usato, per mem_end. Quando si usa 0xbad, si deve anche fornire un I/O base diverso da zero per la scheda. Per esempio, una scheda a 0x340 che non dichiara il completamento del reset dovrebbe essere configurata nel modo seguente: LILO: linux ether=0,0x340,0,0xbad,eth0 Ciò permette che il rilevamento della scheda continui anche se la pro­ pria scheda non effettua l'ACK del reset. Se si sta usando il driver come modulo, allora si può usare l'opzione bad=0xbad nella stessa maniera in cui si indica l'indirizzo di I/O. Problema: Una scheda NE*000 blocca la macchina al primo accesso alla rete. Causa: Questo problema è stato riportato per kernel a partire dalla versione 1.1.57 fino a quella corrente. Sembra confinato a poche schede clone configurabili in software. Apparentemente queste schede si aspettano di essere inizializzate in qualche modo speciale. Soluzione: Diverse persone hanno riferito che l'esecuzione del programma DOS di configurazione software e/o l'uso del driver per DOS forniti con la scheda prima di fare il boot "a caldo" di Linux (cioé usando loadlin o con il "saluto a tre dita" (CTRL-ALT-CANC)) consente alla scheda di funzionare. Ciò indicherebbe che queste schede necessitano di essere inizializzate in un modo particolare, leggermente diverso da ciò che fa l'attuale driver per Linux. Problema: Una scheda Ethernet NE*000 a 0x360 non viene rilevata. Causa: La propria scheda ha uno spazio degli indirizzi di I/O ampio 0x20, il che la fa entrare in collisione con la porta parallela a 0x378. Altri dispositivi che possono essere lì sono il secondo controller del floppy (se presente) a 0x370 o il controller secondario IDE a 0x376--0x377. Se la/le porta/e sono già assegnate ad un altro driver, il kernel non consente al driver di tentare il rilevamento. Soluzione: Si sposti la propria scheda ad un indirizzo come 0x280, 0x340, 0x320 o si compili il kernel senza il supporto per la stampante su porta parallela. Problema: La rete "scompare" ogniqualvolta si stampa qualcosa (NE2000). 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. Problema: NE*000 ethercard probe at 0xNNN: 00 00 C5 ... not found. (invalid signature yy zz) Causa: Prima di tutto, c'è una scheda NE1000 o NE2000 all'indirizzo 0xNNN? Se sì, l'indirizzo hardware riportato ha l'aria di essere uno valido? Se sì, allora si possiede un clone NE*000 disgraziato. Si suppone che tutti i cloni NE*000 abbiano il valore ox57 nei byte 14 e 15 della PROM SA sulla scheda. La propria scheda non ce l'ha -- essa ha invece 'yy zz'. Soluzione: Ci sono due modi di aggirare l'ostacolo. Il più facile consiste nell'usare un valore di mem_end 0xbad come descritto sopra per il problema 'no reset ack'. Ciò consentirà di bypassare il controllo della 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: "Galleria della Vergogna") 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 0x57 nei byte 14 e 15 (come dovrebbero invece fare). Problema: La macchina si blocca durante l'avvio giusto dopo il messaggio '8390...' oppure 'WD....'. La rimozione della NE2000 risolve il problema. Soluzione: Si cambi l'indirizzo base della propria NE2000 con qualcosa come 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. 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. Problema: La macchina si blocca all'avvio durante il rilevamento SCSI. Causa: È lo stesso problema visto in precedenza, si cambi l'indirizzo della scheda Ethernet o si usino gli argomenti di boot reserve/ether. Problema: La macchina si blocca all'avvio durante il rilevamento della scheda sonora. Causa: No, in realtà ciò avviene durante il rilevamento SCSI "silenzioso" ed è lo stesso problema che si è appena visto. Problema: NE2000 non rilevata all'avvio -- nessun tipo di messaggio. Soluzione: Non esiste una "soluzione magica" visto che possono essere parecchie le cause per cui non è stata rilevata. Il seguente elenco dovrebbe aiutare a risolvere i possibili problemi. 1) Si compili un nuovo kernel che includa solo i driver dei dispositivi di cui si ha bisogno. Si verifichi che si stia davvero avviando il kernel nuovo. 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 System.map una voce come 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 dmesg|more per rivedere i messaggi di avvio dopo aver fatto il login o si digiti Shift-PgUp per scorrere il contenuto dello schermo dopo che l'avvio si è completato e appare il prompt del login. 3) Dopo l'avvio si esegua un cat /proc/ioports e si verifichi che l'intero spazio di I/O richiesto dalla scheda sia libero. Se si parte da 0x300, il driver n2ek richiederà 0x300-0x31f. Se un qualsiasi altro driver di dispositivo ha occupato anche solo una porta da qualche parte in quell'intervallo, il rilevamento non avrà luogo a quell'indirizzo e continuerà silenziosamente al prossimo degli indirizzi rilevati. Un caso frequente è quello del driver lp che riserva 0x378 o il secondo canale IDE che riserva 0x376, il che impedisce al driver ne il rilevamento in 0x360-0x380. 4) In maniera simile a quanto appena menzionato, si controlli /proc/interrupts. Ci si assicuri che nessun altro dispositivo abbia occupato l'interrupt per il quale è stata impostata la scheda. In questo caso, il rilevamento avviene e il driver Ethernet protesta rumorosamente all'avvio perché non riesce a ottenere la linea IRQ desiderata. 5) Se si è ancora perplessi 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 linux/drivers/net/ne.c come dal seguente esempio: ______________________________________________________________________ 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; + } ______________________________________________________________________ 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à citato nell'howto) e vedere se è in grado di rilevare la propria scheda dopo che si è avviato Linux. Si usi l'opzione '-p 0xNNN' per dirgli dove cercare la scheda (l'indirizzo di default è 0x300 e non va a guardare da nessun'altra parte a differenza del rilevamento all'avvio). L'output risultante quando trova una scheda sarà qualcosa del tipo: ______________________________________________________________________ Checking the ethercard at 0x300. Register 0x0d (0x30d) is 00 Passed initial NE2000 probe, value 00. 8390 registers: 0a 00 00 00 63 00 00 00 01 00 30 01 00 00 00 00 SA PROM 0: 00 00 00 00 c0 c0 b0 b0 05 05 65 65 05 05 20 20 SA PROM 0x10: 00 00 07 07 0d 0d 01 01 14 14 02 02 57 57 57 57 NE2000 found at 0x300, using start page 0x40 and end page 0x80. ______________________________________________________________________ I propri valori register e PROM saranno probabilmente diversi. Si noti che tutti i valori PROM sono duplicati in una scheda a 16 bit, l'indirizzo Ethernet (00:00:c0:b0:05:65) appare nella prima riga e la firma ripetuta 0x57 appare alla fine della PROM. L'output risultante quando non c'è nessuna scheda installata a 0x300 sarà simile al seguente: ______________________________________________________________________ Checking the ethercard at 0x300. Register 0x0d (0x30d) is ff Failed initial NE2000 probe, value ff. 8390 registers: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff SA PROM 0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff SA PROM 0x10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Invalid signature found, wordlength 2. ______________________________________________________________________ I valori 0xff 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 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: A:> ne2000 0x60 10 0x300 Gli argomenti sono: il vettore degli interrupt software, l'IRQ hardware e l'I/O base. Lo si può trovare in un qualsiasi archivio msdos nel file pktdrv11.zip. La versione attuale può essere più recente della 11. 2.7. Problemi con le schede SMC Ultra/EtherEZ e WD80*3 Problema: Si ricevono messaggi come il seguente: eth0: bogus packet size: 65531, status=0xff, nxpg=0xff Causa: C'è un problema di memoria condivisa. Soluzione: La causa più comune è dovuta a macchine PCI che non sono configurate per mappare dispositivi nella memoria ISA. Perciò si finisce per leggere la RAM del PC (tutti valori 0xff) invece della RAM della scheda che contiene i dati provenienti dal pacchetto ricevuto. Altri tipici problemi facili da risolvere sono: i conflitti di scheda, avere la cache o la "shadow ROM" abilitata per quella regione o avere il proprio bus ISA che va ad una velocità superiore agli 8 MHz. Si trovano anche un numero sorprendente di guasti di memoria sulle schede Ethernet, perciò si esegua un programma di diagnostica nel caso in cui se ne possieda uno per la propria scheda. Problema: La scheda SMC EtherEZ non funziona nella modalità a memoria non condivisa (PIO). Causa: Le versioni più vecchie del driver Ultra supportavano la scheda solo nella modalità a memoria condivisa. Soluzione: Il driver 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. Problema: Le vecchie wd8003 e/o le wd8013 configurabili con jumpers hanno sempre l'IRQ sbagliato. Causa: Le vecchie schede wd8003 e i cloni wd8013 configurabili con i ponticelli non possiedono la EEPROM dalla quale il driver può leggere l'impostazione dell'IRQ. Se il driver non è in grado di leggere l'IRQ allora esso prova a scoprirlo automaticamente con auto-IRQ. Se l'auto- IRQ restituisce il valore zero, il driver non fa altro che assegnare IRQ 5 a una scheda a 8 bit o IRQ 10 a una scheda a 16 bit. Soluzione: Si eviti il codice di auto-IRQ e si comunichi al kernel qual è l'IRQ per il quale la scheda è stata configurata nel proprio file di configurazione dei moduli (o mediante una argomento di boot per i driver compilati nel kernel). Problema: La scheda SMC Ultra è rilevata come wd8013, ma l'IRQ e l'indirizzo base della memoria condivisa sono sbagliati. Causa: La scheda Ultra assomiglia molto a una wd8013 e se il driver Ultra non è presente nel kernel, il driver wd può scambiare la Ultra per una wd8013. Il rilevamento della Ultra avviene prima del rilevamento della wd perciò questo di solito non accade. La Ultra memorizza l'IRQ e l'indirizzo base della memoria in un modo diverso nella EPROM, da cui i valori sballati riportati. Soluzione: Si ricompili il kernel con solo i driver di cui si ha bisogno. Se si ha una commistione di schede ultra e wd nella stessa macchina e si stanno usando i moduli allora si carichi per primo il modulo ultra. 2.8. Problemi con le schede 3Com 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? Soluzione: Il driver della 3c503 cerca una linea di IRQ libera nell'ordine {5, 9/2, 3, 4} e dovrebbe scegliere una linea che nessuno sta usando. Il driver decide quando la scheda è attivata con ifconfig. Se si sta usando un driver modulare, si possono usare dei parametri del modulo per impostare svariate cose, incluso il valore dell'IRQ. Ciò che segue imposta IRQ 9, indirizzo I/O di base 0x300, e if_port #1 (il transceiver esterno). io=0x300 irq=9 xcvr=1 In alternativa, se il driver è compilato nel kernel, è possibile fissare gli stessi valori all'avvio passando i parametri attraverso LILO. LILO: linux ether=9,0x300,0,1,eth0 Ciò che segue imposta l'IRQ3, la ricerca della locazione base, e il transceiver di default if_port #0 (il transceiver interno). LILO: linux ether=3,0,0,0,eth0 Problema: 3c503: configured interrupt X invalid, will use autoIRQ. Causa: La sheda 3c503 può usare solo uno degli IRQ{5, 2/9, 3, 4} (solo queste linee sono connesse alla scheda). Se si passa un valore di IRQ che non 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}. Soluzione: Si usi uno degli IRQ validi elencati sopra oppure si abiliti l'autoIRQ ma senza specificare la linea IRQ in alcun modo. Problema: I driver per la 3c503 forniti non utilizzano la porta AUI (thicknet). Come si può optare per essa al posto della porta thinnet di default? Soluzione: La porta 3c503 AUI può essere selezionata al momento dell'avvio per i driver compilati nel kernel e 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->rmem_start, cosicché un parametro all'avvio tipo: LILO: linux ether=0,0,0,1,eth0 dovrebbe funzionare per i driver compilati nel kernel. Per specificare la porta AUI se invece si carica il driver come un modulo è sufficiente aggiungere xcvr=1 alla riga delle opzioni del modulo insieme con i propri valori di I/O e IRQ. 2.9. FAQ non specifiche ad una particolare scheda 2.9.1. Linux e schede Ethernet ISA di tipo Plug and Play 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 io= in /etc/modules.conf. 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à usare il pacchetto isapnptools che provvederà 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 io=. Per i kernel 2.4.x e seguenti, supporto per il meccanismo ISA-PnP può essere compilato direttamente nel kernel e se il vostro driver fa uso di questi meccanismi, la vostra scheda sarà configurata con un indirizzo I/O di base ed una linea IRQ disponibili senza bisogno di nessun intervento da parte vostra. Si eviti 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. 2.9.2. un sistema PCI rileva la scheda ma il driver non riesce ad autoconfigurarsi (PnP OS) 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à 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. 2.9.3. In un sistema PCI, tutte le schede vengono rilevate ma due non funzionano 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ù 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, è possibile che stiano condividendo lo stesso pin BM. 2.9.4. Il mio sistema ha /etc/conf.modules e non /etc/modules.conf . Distribuzioni più stagionate avranno ancora conf.modules e non modules.conf, che è un nome più sensato. Le più recenti utilità si aspettano il nuovo nome, un fatto che dovete tener presente quando aggiornate un vecchio sistema. 2.9.5. La scheda Ethernet non viene rilevata all'avvio Di solito la causa di questo è 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 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 /etc/modules.conf -- si veda 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 0x300 ed usa 32 byte allora il driver richiederà la regione 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 cat /proc/ioports 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 è 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 ether= come descritto in ``Passare argomenti Ethernet...''. I driver modulari possono fare uso dell'opzione io= in /etc/modules.conf per specificare un indirizzo che non è testato per default. 2.9.6. Il driver dichiara unresolved symbol ei_open e non viene car­ icato State utilizzando una delle molte schede basate sul chip 8390 (o un suo clone). Il driver per tali schede è composto da due parti - la parte che voi avete cercato di caricare senza successo (come ad esempio ne2k-pci.o, ne.o, wd.o, smc-ultra.o), e la parte dedicata al chip 8390. Questi driver vengono marcati con (+8390) accanto al nome del modulo nella lista di informazioni specifiche per ogni produttore (``Informazioni specifiche su...''). Si deve fare in modo che il modulo 8390.o venga caricato prima del caricamento della seconda meta del driver, che in questo modo avrà 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é le varie relazioni di dipendenza tra moduli come questa vengano gestite automaticamente; (2)l'uso di insmod al posto di modprobe, dato che insmod non controlla se esistono dei vincoli di ordine nel caricamento dei moduli; (3) il fatto che il modulo 8390.o non sia nella sua directory accanto all'altra metà del driver come dovrebbe. 2.9.7. ifconfig mostra un indirizzo di I/O sbagliato per la scheda No, non lo fa, lo si sta solamente interpretando in modo sbagliato. Questo 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 dev->base_addr ed è ciò che ifconfig riporta. Se si vuole vedere l'intero intervallo di porte che la propria scheda usa, allora si usi cat /proc/ioports che risponderà con i numeri che ci si aspettava. 2.9.8. Le schede ISA a memoria condivisa non funzionano in un sistema PCI ( 0xffff ) Questo problema solitamente si presenta come una lunga serie di letture di valori 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. 2.9.9. Sembra che la scheda invii dati ma non riceve niente Si faccia un cat /proc/interrupts, il totale aggiornato del numero di eventi di interrupt generati dalla propria scheda sarà incluso nell'output. Se tale numero è 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. 2.9.10. Supporto per Asynchronous Transfer Mode (ATM) Werner Almesberger sta lavorando al supporto ATM per Linux. Sta lavorando con la scheda ENI155p della Efficient Networks (Efficient Networks ) e la scheda ZN1221 della Zeitnet (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: Linux ATM Support 2.9.11. Supporto per Gigabit Ethernet C'è un qualche supporto per gigabit Ethernet sotto Linux? Si, al momento c'è 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 è ovviamente una situazione in evoluzione. 2.9.12. Supporto FDDI 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 è stato incluso nel kernel 2.0.24. Al momento attuale non sono supportate altre schede. 2.9.13. Supporto Full Duplex 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à. 2.9.14. Schede Ethernet per Linux su macchine SMP Se si è 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 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ì 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 cat /proc/net/dev). 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. [Nota tecnica: L'impatto sulle prestazioni può anche includere un incremento nelle latenze degli interrupt se i lock che è necessario aggiungere sono del tipo irqsave e sono tenuti per un lungo periodo di tempo.] Possibili miglioramenti a questa situazione possono essere 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ù è 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 è 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. 2.9.15. Schede Ethernet per Linux su piattaforma Alpha/AXP e bus PCI 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à 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: · moltiplicare tutti i valori relativi ai jiffies per HZ/100 per tener conte del diverso valore di HZ che usa l'Alpha. (timeout=2; diventa timeout=2*HZ/100;) · sostituire 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. ______________________________________________________________________ - int *mem_base = (int *)dev->mem_start; - mem_base[0] = 0xba5eba5e; + unsigned long mem_base = dev->mem_start; + writel(0xba5eba5e, mem_base); ______________________________________________________________________ · sostituire tutte le chiamate memcpy() che hanno la memoria I/O come sorgente o destinazione con le appropriate memcpy_fromio() o memcpy_toio(). I dettagli sulla gestione degli accessi alla memoria in maniera indipendente dall'architettura sono documentati nel file linux/Documentation/IO-mapping.txt incluso con kernel recenti. 2.9.16. Ethernet per Linux su hardware SUN/Sparc Per le informazioni più aggiornate sull'hardware Sparc, si visiti il seguente sito: 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 hw di 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. 2.9.17. Ethernet per Linux su altro hardware 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!) 2.9.18. Connettere 10 o 100 BaseT senza un hub 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ù fronzoli potrebbero non riuscire a raccapezzarsi in un tale ambiente. E 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. 2.9.19. SIOCSIFxxx: No such device 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 ifconfig e route essi non trovano nessun dispositivo con cui operare. Si usi dmesg | more per rivedere i messaggi di boot e vedere se c'è un qualche messaggio riguardante il rilevamento della scheda Ethernet. 2.9.20. SIOCSFFLAGS: Try again 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 cat /proc/interrupts per vedere quali interrupt sono al momento 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. 2.9.21. Usando 'ifconfig' e Link di tipo UNSPEC con indirizzo hard­ ware 00:00:00:00:00:00 Quando eseguo ifconfig senza alcun argomento, mi dice che LINK è UNSPEC (invece di 10Mbs Ethernet) e dice anche che il mio indirizzo hardware è di tutti zeri. Questo 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 ifconfig che si sta usando è molto più vecchio del proprio kernel. 2.9.22. Enorme numero di errori in RX e TX 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 RX packets grande numero PAUSE errors 0 PAUSE dropped 0 PAUSE overrun 0. Ed è più o meno la stessa cosa per la colonna TX. Quindi i grandi numeri che si vedono sono il numero totale di pacchetti che la propria macchina ha ricevuto e trasmesso. Se si è ancora confusi da questa cosa, si provi invece ad usare cat /proc/net/dev. 2.9.23. Voci in /dev/ per le schede Ethernet Ho /dev/eth0 come link (collegamento) a /dev/xxx. È giusto? Contrariamente a ciò che probabilmente vi è stato detto, i file in /dev/* non vengono utilizzati. Si può cancellare qualsiasi /dev/wd0, /dev/ne0 e simili voci. 2.9.24. Accesso a basso livello al dispositivo Ethernet Come posso accedere a basso livello al dispositivo Ethernet in Linux, senza passare attraverso TCP/IP e famiglia? ______________________________________________________________________ int s=socket(AF_INET,SOCK_PACKET,htons(ETH_P_ALL)); ______________________________________________________________________ Questo codice vi consente di avere un socket che riceve qualsiasi tipo di protocollo. Si facciano chiamate a 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 sendto(). Naturalmente per fare entrambe le cose si deve avere l'accesso come root. 3. Suggerimenti per migliorare le prestazioni 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 ttcp.c è un buon test per misurare la velocità di throughput. Un altro modo comunemente usato è di fare un ftp> get grosso_file /dev/null dove grosso_file è >1MB e risiede nel buffer 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 /dev/null piuttosto che al disco. 3.1. Concetti generali Anche una scheda a 8 bit è in grado di ricevere pacchetti back-to-back (uno dietro l'altro) senza alcun problema. Le difficoltà nascono quando il computer non riesce a estrarre i pacchetti ricevuti dalla scheda abbastanza velocemente da far spazio ai pacchetti in arrivo. Se il computer non libera abbastanza velocemente la memoria della scheda dai pacchetti già ricevuti, la scheda non avrà spazio 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ì 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). 3.2. Schede ISA e velocità del bus ISA 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. ______________________________________________________________________ Velocità bus ISA (MHz) Rx TTCP (kB/s) ---------------------- -------------- 6.7 740 13.4 970 20.0 1030 26.7 1075 ______________________________________________________________________ Voglio vedere chi riesce a far meglio di 1075kB/s con una qualsiasi scheda Ethernet a 10Mb/s usando TCP/IP. Comunque, non ci si aspetti che qualsiasi sistema funzioni a velocità del bus ISA molto elevate. La maggior parte dei sistemi non funzioneranno correttamente a velocità superiori a 13MHz (inoltre, in alcuni sistemi PCI la velocità del bus ISA è 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. 3.3. Impostare la finestra TCP di ricezione (TCP Rx Window) Ancora una volta, le schede con poca memoria RAM a bordo e percorsi dati tra la scheda e la memoria del computer relativamente lenti avranno 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 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: ______________________________________________________________________ route add ... window ______________________________________________________________________ dove dim_fin è la dimensione della finestra che si vuole usare (in byte). Una scheda 3c503 a 8 bit su un bus ISA che va a 8Mhz o meno dovrebbe funzionare bene con una dimensione della finestra di circa 4kB. Una finestra troppo grande causerà drop e overrun dei pacchetti e una riduzione drastica del throughput. Si possono verificare le condizioni operative con cat /proc/net/dev, che elencherà il numero di drop/overrun verificatisi. 3.4. Incrementare le prestazioni NFS 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 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). 4. Informazioni specifiche su produttori e modelli 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à 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 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 è risaputo essere non più funzionante. Il driver stesso viene ancora incluso nel kernel, ma è disabilitato nel menu delle opzioni di configurazione. In generale il piano è che se un driver marcato come obsoleto non viene aggiornato durante il seguente ciclo di sviluppo del kernel, esso verrà 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) è 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ò 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, è 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 alias eth0 nome_driver nel file di configurazione dei moduli /etc/modules.conf. 4.1. 3Com Se non si è sicuri di cosa sia la propria scheda, ma si pensa che sia una scheda 3Com, probabilmente lo si può scoprire 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 www.3Com.com di 3com per informazioni e strumenti che possano risultavi utili (ivi inclusa la documentazione tecnica sulle schede rilasciata in formato PDF). 4.1.1. 3c501 Stato: Semi supportata, Nome del Driver: 3c501 Questa obsoleta scheda a 8 bit dell'età della pietra è veramente troppo "demente" per poter essere 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 0x280 e a 0x300 e il livello di debug è impostato con il terzo argomento al momento del boot. Ancora una volta, l'uso della 3c501 è vivamente sconsigliato! Ancora di più con un kernel con l'IP multicast, dato che ci si inchioderà mentre si ascoltano tutti i pacchetti multicast. Si vedano i commenti in cima al codice sorgente per ulteriori dettagli. 4.1.2. EtherLink II, 3c503, 3c503/16 Stato: Supportata, Nome del driver: 3c503 (+8390) La 3c503 non ha un "EEPROM setup" e quindi non è necessario eseguire nessun programma di diagnostica/setup prima di usare la scheda con Linux. L'indirizzo della memoria condivisa della 3c503 è impostato usando i ponticelli in comune con l'indirizzo della PROM di boot. Ciò confonde molta gente che ha familiarità con altre schede ISA, dove di solito si lascia sempre il ponticello impostato 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 ``Problemi con...''. Se si intende usare questo driver come modulo caricabile probabilmente si dovrebbe fare riferimento alla sezione ``Usare un driver Ethernet come modulo'' per informazioni specifiche sui moduli. 4.1.3. Etherlink Plus 3c505 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 è dichiarato come driver alpha. Si veda la sezione ``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 /usr/src/linux/drivers/net/README.3c505, che elenca diverse opzioni che si possono abilitare o disabilitare. 4.1.4. Etherlink-16 3c507 Stato: Semi supportata, Nome del driver: 3c507 Questa scheda usa uno dei chip Intel e lo sviluppo del driver è strettamente legato allo sviluppo del driver per la Ether Express dell'Intel. Il driver è incluso nel kernel standard, ma come driver alpha. Si veda la sezione ``Driver alpha'' per importanti informazioni sull'uso con Linux di driver Ethernet in alpha testing. 4.1.5. Etherlink III, 3c509 / 3c509B 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 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 plug and play e per impostare il tipo di uscita di cui si ha bisogno. Il driver per Linux attualmente non supporta la l'autodetect dell'uscita utilizzata, quindi si 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à sempre la eth0 in una configurazione con più 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 0x3c509 nei campi di indirizzo di memoria non utilizzati per ordinare il rilevamento ed adattarlo alle proprie particolari necessità. 4.1.6. 3c515 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 è possibile raggiungere la piena velocità di 100Mbps su di un bus ISA. 4.1.7. 3c523 Stato: Semi supportata, Nome del driver: 3c523 Questa scheda su bus MCA usa l'i82586. Chris Beauregard ha modificato il driver ni52 per farlo funzionare con queste schede. 4.1.8. 3c527 Etherlink MC/32 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à probabilmente maggior fortuna con la 3c529, dato che usa il collaudato core 3c509. 4.1.9. 3c529 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. 4.1.10. 3c556 Stato: Supportata, Nome del driver: 3c59x Una interfaccia mini PCI usata in parecchi laptop IBM e HP, altresì conosciuta come un 'laptop tornado'. 4.1.11. 3c562 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. 4.1.12. 3c575 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. 4.1.13. 3c579 Stato: Supportata, Nome del driver: 3c509 La versione EISA della 509. La versione EISA attuale usa lo stesso chip a 16 bit invece che un interfaccia a 32 bit, quindi l'incremento di prestazioni non è 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. 4.1.14. 3c589 / 3c589B 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. 4.1.15. 3c590 / 3c595 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 è 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! 4.1.16. 3c592 / 3c597 Stato: Supportate, Nome del driver: 3c59x Queste sono le versioni EISA della serie di schede 3c59x. Le 3c592/3c597 (altrimenti note come Demon) dovrebbero funzionare con il driver vortex discusso in precedenza. 4.1.17. 3c900 / 3c905 / 3c905B / 3c905C / 3c905CX 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 è stato inserito nel driver vortex/3c59x. Il driver incluso in versioni del kernel più 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à di checksum a bordo (in hardware), cosa che riduce il carico di lavoro della CPU. 4.1.18. 3c985 (Gigabit acenic, Tigon2) Stato: Supportata, Nome del driver: acenic Questo driver supporta diverse altre schede Gigabit oltre al modello 3Com. 4.1.19. 3c996 (Gigabit broadcom, Tigon3) Stato: Supportata, Nome del driver: tg3, bcm5700(vecchio driver) Questo driver supporta svariate altre schede Gigabit oltre al modello di 3com. Il driver tg3 è una riscrittura completa a cura di un gruppo di diversi sviluppatori Linux fatta nel tentativo di produrre un driver migliore di quellodel produttore bcm5700. 4.2. Accton 4.2.1. Accton MPX Stato: Supportata, Nome del driver: ne (+8390) Non ci si faccia ingannare dal nome. Questa è una scheda compatibile con la NE2000 e dovrebbe funzionare con il driver ne2000. 4.2.2. Accton EN1203, EN1207, EtherDuo-PCI 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. 4.2.3. Accton EN2209 Parallel Port Adaptor (EtherPocket) 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: http://www.unix-ag.uni-siegen.de/~nils/accton_linux.html 4.2.4. Accton EN2212 PCMCIA Card Stato: Supportata, Nome del driver: pcnet_cs 4.3. Adaptec Si noti che le più vecchie schede Adaptec a 32 bit usavano un clone del chipset tulip. 4.3.1. Adaptec DuraLAN/Starfire, 64bit ANA-6922 Stato: Supportata, Nome del driver: starfire 4.4. Allied Telesyn/Telesis 4.4.1. AT1500 Stato: Supportata, Nome del driver: lance Questa è una serie di schede Ethernet a bassa costo che usa la versione 79C960 del chip LANCE dell'AMD. 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 ``AMD LANCE''. 4.4.2. AT1700 Stato: Supportata, Nome del driver: at1700 Si noti che per accedere a questo driver durante il make config si deve ancora rispondere 'Y' alla domanda iniziale "Prompt for development and/or incomplete code/drivers?" 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 è reperibile a: http://www.cc.hit-u.ac.jp/nagoya/at1700/ La serie di schede Ethernet AT1700 della Allied Telesis sono basate sul chip MB86965 della Fujitsu. Questo chip usa un'interfaccia ad I/O programmato e una coppia di buffer di trasmissione di dimensione fissa. Ciò permette l'invio back-to-back di piccoli gruppi di pacchetti, con una breve pausa durante lo scambio dei buffer. 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. 4.4.3. AT2400 Stato: Supportata, Nome del driver: ne, ne2k-pci (+8390) Ancora un altra scheda compatibile con la NE2000 PCI. Questa è basata sul chip RealTek 8029. 4.4.4. AT2450 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 ``AMD LANCE''. 4.4.5. AT2500 Stato: Supportata, Nome del driver: 8139too, rtl8139(vecchio driver) Questa scheda usa il chip 8139 della RealTek. Si veda la sezione ``RealTek 8139''. 4.4.6. AT2540FX 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. 4.5. AMD / Advanced Micro Devices 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. 4.5.1. AMD LANCE (7990, 79C960/961/961A, PCnet-ISA) Stato: Supportata, Nome del driver: lance In realtà non ci sono schede Ethernet dell'AMD. Probabilmente si sta leggendo questa sezione perché le sole cose che si possono leggere 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 ``AT1500'') e la NE1500/2100 (si veda la sezione ``NE1500'') usano questi chip. Il 7990/79c90 è stato da tempo rimpiazzato da nuove versioni. Il 79C960 (detto anche PCnet-ISA) essenzialmente contiene il nucleo della 79c90, assieme a tutto l'altro hardware di supporto 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: 0x300, 0x320, 0x340, 0x360 e che qualsiasi indirizzo fornito con l'argomento di boot 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 ``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. 4.5.2. AMD 79C901 (Home PNA PHY) Stato: Supportata, Nome del driver: sis900 Il file sis900.txt incluso con i kernel 2.4 afferma che "la AM79C901 HomePNA PHY non è 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ù recente. 4.5.3. AMD 79C965 (PCnet-32) Stato: Supportata, Nome del driver: pcnet32 Questa è la PCnet-32: una versione bus-master a 32 bit del chip LANCE originale per sistemi VL-bus e local bus. Sebbene questi chip possano funzionare con il driver lance.c standard, è disponibile anche una versione a 32 bit (pcnet32.c) che non si preoccupa mai delle limitazioni ai 16 MB associate con il bus ISA. 4.5.4. AMD 79C970/970A (PCnet-PCI) Stato: Supportata, Nome del driver: pcnet32 Questa è la PCnet-PCI: simile alla PCnet-32, ma progettata per i sistemi basati su bus PCI. Si vedano le informazioni sulla PCnet-32. Si noti che è necessario compilare 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. 4.5.5. AMD 79C971 (PCnet-FAST) 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. 4.5.6. AMD 79C972 (PCnet-FAST+) Stato: Supportata, Nome del driver: pcnet32 Si è ricevuto conferma che questa scheda funziona proprio come la 971. 4.5.7. AMD 79C974 (PCnet-SCSI) Stato: Supportata, Nome del driver: pcnet32 Questa è la PCnet-SCSI, che in pratica viene trattata come una '\970 dal punto di vista Ethernet. Si vedano anche le informazioni precedenti. Non mi si chieda quanto sia supportata la parte SCSI del chip: questo è l'Ethernet-HowTo, non lo SCSI-HowTo. 4.6. Ansel Communications 4.6.1. AC3200 EISA Stato: Semi-supportata, Nome del driver: ac3200 Questa scheda EISA è basata sul comune chip 8390 utilizzato anche nelle schede ne200 e nella wd80x3. Si noti che per accedere a questo driver durante il 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 è ricevuto molto riscontro su questo driver nonostante esso sia stato incluso nel kernel a partire dalla versione 1.1.25. 4.7. Apricot 4.7.1. Apricot Xen-II On Board Ethernet Stato: Semi supportata, Nome del driver: apricot Questa scheda Ethernet on board usa un chip i82596 bus-master. Può essere collocata solamente all'indirizzo di I/O 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 0x300 fosse una NIC apricot. Da allora l'indirizzo hardware è verificato per evitare questi falsi rilievi. 4.8. Arcnet Stato: Supportata, Nome del driver: arcnet (arc-rimi, com90xx, com20020) Con il costo ormai veramente basso e le migliori prestazioni di Ethernet, è possibile che molti posti diano via gratis il loro hardware Arcnet, il che risulta in un sacco di sistemi domestici 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! 4.9. Boca Research Sì, non producono solo schede seriali multiporta. :-) 4.9.1. Boca BEN400 Stato: Supportata, Nome del driver: ne (+8390) Apparently this is a NE2000 clone, using a VIA VT86C916 chip. 4.9.2. Boca BEN (ISA, VLB, PCI) 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ì vecchie che non vale la pena di disturbarsi a provare. Per ulteriori informazioni generali sui chip della AMD si veda la sezione ``AMD LANCE''. 4.10. Broadcom 4.10.1. Broadcom Tigon2 Stato: Supportata, Nome del driver: acenic 4.10.2. Broadcom Tigon3 Status: Supportata, Nome del driver: tg3 4.11. Cabletron Mancato rilascio di informazioni necessarie alla programmazione delle loro schede da parte di Cabletron quando i driver furono sviluppati per queste schede è 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. 4.11.1. E10**, E10**-x, E20**, E20**-x 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. 4.11.2. E2100 Stato: Semi supportata, Nome del driver: e2100 (+8390) La E2100 è un orrido progetto. Ogniqualvolta mappa la sua memoria condivisa durante un trasferimento di pacchetti, la mappa in un'intera regione di 128K! Ciò significa che in quella regione non si può usare con sicurezza un altro dispositivo gestito a memoria condivisa, nemmeno un'altra E2100. La scheda funzionerà senza problemi per maggior parte del tempo, ma una volta ogni tanto il problema vi pungolerà (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 deve spegnere la macchina e 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->mem_end. Se veda ``PARAM_2''. Gli utilizzatori di driver modulari possono specificare un valore xcvr=N come options nel file /etc/modules.conf. 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 ``Usare un driver Ethernet come modulo'' per informazioni specifiche sull'uso di driver modulari. 4.11.3. E22** 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 ``AMD PC-Net'') e dovrebbero quindi funzionare con il driver lance generico. 4.12. Cogent 4.12.1. EM100-ISA/EISA Stato: semi supportata, Nome del driver: smc9194 Queste schede usano il chip SMC 91c100 e potrebbero funzionare con il driver per SMC 91c92, ma la cosa deve ancora essere verificata. 4.12.2. Cogent eMASTER+, EM100-PCI, EM400, EM960, EM964 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 ``DEC 21040'' per maggiori informazioni su queste schede e la situazione di supporto attuale. 4.13. Compaq La Compaq non è veramente un costruttore di schede Ethernet, ma un sacco di loro sistemi hanno controller Ethernet integrati nella scheda madre. 4.13.1. Compaq Deskpro / Compaq XL (Embedded AMD Chip) 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 è 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 movepci.exe dovrebbe essere reperibile nel package di supporto SP1599.EXE se si avesse bisgno di una copia. Altre informazioni a carattere generico sui chip AMD possono essere reperite nella sezione ``AMD LANCE''. 4.13.2. Compaq Nettelligent/NetFlex (Embedded ThunderLAN Chip) Stato: Supportata, Nome del driver: tlan Questi sistemi usano un chip ThunderLAN della Texas Instruments. Informazioni sul driver ThunderLAN possono essere trovare nella sezione ``ThunderLAN''. 4.13.3. Compaq PCI card Stato: Supportata, nome del driver: eepro100 Si controlli la scheda: se ha numero di parte 323551-821 e/o un chip Intel 82558 allora è un altra scheda basata sull'Intel EEPro100. 4.14. Danpex 4.14.1. Danpex EN9400 Stato: Supportata, Nome del driver: de4x5, tulip Ecco un'altra scheda basata sul chip 21040 della DEC, che si dice funzioni bene e che costa relativamente poco. Si veda la sezione ``DEC 21040'' per maggiori informazioni su queste schede e la corrente situazione di supporto del driver. 4.15. Davicom 4.15.1. Davicom DM9102 Stato: Supportata, Nome del Driver: tulip, dmfe Questo è praticamente un clone del chip tulip e di conseguenza è possibile utilizzare per questa scheda il driver tulip o il driver dmfe del produttore. L'approccio comune è 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. 4.16. D-Link 4.16.1. DE-100, DE-200, DE-220-T, DE-250 Stato: Supportata, Nome del driver: ne (+8390) Alcune delle prime schede D-Link non avevano la sequenza di identificazione 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 www.dlink.com. Si noti che esistono anche schede della Digital (DEC) chiamate DE100 e DE200, ma che la somiglianza finisce qui. 4.16.2. DE-520 Stato: Supportata, Nome del driver: pcnet32 Questa è una scheda PCI che usa la versione PCI del chip LANCE dell'AMD. Informazioni sulla selezione del DMA e la numerazione del chip possono essere trovate nella sezione ``AMD LANCE''. 4.16.3. DE-528 Stato: Supportata, Nome del driver: ne, ne2k-pci (+8390) Apparentemente la D-Link ha cominciato a produrre anche cloni PCI della NE2000. 4.16.4. DE-530 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 èla DFE530. Si veda la sezione ``DEC 21040'' per maggiori informazioni su queste schede e sullo stato attuale del driver. 4.16.5. DE-600 Stato: Supportata, Nome del driver: de600 La DE600 è 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 ifconfig ora è eth0 e non più il dl0 usato in precedenza. 4.16.6. DE-620 Stato: Supportata, Nome del driver: de620 Analoga alla DE-600, ma con due formati d'uscita. Si vedano le informazioni precedenti sulla DE-600. 4.16.7. DE-650 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. 4.16.8. DFE-530TX Stato: Supportata, Nome del driver: via-rhine Un altra scheda costruita sul chipset VIA Rhine. Schede di costruzione più utilizzano il RhineII (si veda la sezione ``VIA Rhine''). Non si confonda questa scheda con la DE-530 che invece basata sul chipset tulip o con la DFE-530+ che invece è una 8139. 4.16.9. DFE-530TX+, DFE-538TX Stato: Supportata, Nome del driver: 8139too, rtl8139 (vecchio driver) Questa scheda usa il chipset RealTek 8139, si faccia riferimento alla sezione ``RealTek 8139'' 4.16.10. DFE-550TX Stato: Supportata, Nome del driver: sundance 4.16.11. DFE-570TX Stato: Supportata, Nome del driver: tulip Questa è una scheda tulip (DS1143) a quattro porte. 4.16.12. DFE-580TX Stato Supportata, Nome del driver: sundance 4.16.13. DGE-500T Stato: Supportata, Nome del driver: ns83820 4.16.14. DGE-550T Stato: Supportata, Nome del driver: dl2k 4.17. DFI 4.17.1. DFINET-300 e DFINET-400 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 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). 4.18. Digital / DEC 4.18.1. DEPCA, DE100/1, DE200/1/2, DE210, DE422 Stato: Supportate, Nome del driver: depca Nel file sorgente 'depca.c' è inclusa della documentazione che comprende informazioni su come usare più di una di queste schede in una macchina. Si noti che la DE422 è una scheda EISA e che queste schede sono tutte basate sul chip LANCE dell'AMD. Si faccia riferimento alla sezione ``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 0x300 e 0x200. Se si intende farlo, si leggano le note nel file sorgente del driver depca.c nell'albero dei sorgenti del kernel standard. Questo driver funzionerà anche su macchine basate su CPU Alpha e ci sono diverse ioctl() con le quali l'utente può smanettare. 4.18.2. Digital EtherWorks 3 (DE203, DE204, DE205) Stato: Supportata, Nome del driver: ewrk3 Queste schede usano un chip proprietario della DEC, invece del chip LANCE utilizzato 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% se si usa la modalità PIO. La dimensione della memoria condivisa può essere impostata a 2kB, 32kB o 64kB, ma con questo driver sono state testate solamente le prime due dimensioni. David dice che le prestazioni sono virtualmente identiche tra il modo a 2kB e quello a 32kB. Maggiori informazioni (tra cui l'uso del driver come modulo caricabile) sono presenti all'inizio del file sorgente ewrk3.c e nel file 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ì 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 NICSETUP.EXE) ed altri strumenti, che possono essere trovati in praticamente tutti i siti FTP di Linux nella directory /pub/Linux/system/Network/management (si cerchi il file ewrk3tools-X.XX.tar.gz). 4.18.3. DE425 EISA, DE434, DE435, DE500 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 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. 4.18.4. DEC 21040, 21041, 2114x, Tulip Stato: Supportate, Nome del driver: de4x5, tulip Il DEC 21040 è una soluzione Ethernet bus-mastering in un unico chip, simile al chip PCnet dell'AMD. Il 21040 è progettato specificatamente per l'architettura bus PCI ma sembra che questi chip non vengano più 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 due driver. C'è il driver DE425 discusso in precedenza e driver generico 'tulip' per il 21040. Attenzione: Sebbene la propria scheda possa essere basata su questo chip, nel proprio 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É?? 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 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 de4x5 di David con una scheda non DEC, si deve guardare il file README.de4x5 per i dettagli. Se si hanno problemi con il tulip driver, si può provarne la versione più recente dal sito ftp/WWW di Donald. Tulip Driver All'URL precedente c'è anche un elenco (non esaustivo) delle diverse schede e produttori che usano il chip 21040. 4.19. Farallon La Farallon vende le schede e i transceiver EtherWave. Questi dispositivi permettono di concatenare diversi dispositivi 10baseT. 4.19.1. Farallon Etherwave Stato: Supportato, Nome del driver: 3c509 Ci è stato riportato che questo dispositivo è 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 $125, e l'Etherwave aggiunge $75-$100 al prezzo della scheda 4.19.2. Farallon PCI 593 Stato: Supportata, Nome del driver: de4x5, tulip Ci è stato riferito che questa scheda è stata rilevata dal driver de4x5. 4.20. Fujitsu Diversamente da molti sviluppatori di chip Ethernet, la Fujitsu ha prodotto e venduto anche alcune schede di rete basate sui loro chip. 4.20.1. Fujitsu FMV-181/182/183/184 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 fmv18x ma il supporto per queste schede è stato aggiunto al driver at1700 e così il vecchio driver è stato progressivamente ritirato. Older kernels used the driver fmv18x but support for these cards was added to the at1700 driver and so the former has been phased out. 4.21. Hewlett Packard 4.21.1. HP Night Director+ 10/100 Stato: Supportata, Nome del driver: pcnet32 Apparentemente queste schede usano il chip AMD 79C972. 4.21.2. 27245A 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. 4.21.3. HP EtherTwist, PC Lan+ (27247, 27248, 27252A, 27269B) 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. 4.21.4. HP-J2405A Stato: Supportata, Nome del driver: lance Queste schede costano meno e sono un po' più veloci delle 27247/27252A, ma mancano di alcune caratteristiche quali AUI, la connettività ThinLAN e il 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. 4.21.5. HP-Vectra On Board Ethernet Stato: Supportata, Nome del driver: lance L'HP-Vectra ha un chip PCnet dell'AMD sulla piastra madre. Informazioni sulla selezione del DMA e la numerazione del chip possono essere trovate nella sezione ``AMD LANCE''. 4.21.6. Schede HP 10/100 VG Any Lan (27248B, J2573, J2577, J2585, J970, J973) Stato: Supportate, Nome del driver: hp100 Questo driver supporta anche alcuni dei prodotti VG della Compex. Poiché il driver supporta sia schede ISA che EISA e PCI, quando si esegue make config sui sorgenti del kernel lo si trova nella sezione relativa alle schede ISA. 4.21.7. HP NetServer 10/100TX PCI (D5013A) 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. 4.22. IBM / International Business Machines 4.22.1. IBM Thinkpad 300 Stato: Obsoleta, Nome del driver: znet Questa scheda è basata sul chip Intel 82593 ed il relativo driver è stato dichiarato obsoleto nei kernel della serie 2.4. 4.22.2. IBM Credit Card Adaptor for Ethernet Stato: Semi-supportato, Nome del driver: pcnet_cs 4.22.3. IBM 10/100 EtherJet PCI Stato: Supportata, Nome del driver: eepro100 Questa scheda è stata indicata come compatibile a livello di driver con la Intel EtherExpress Pro 100. 4.22.4. IBM Token Ring Stato: Semi supportata, Nome del driver: ibmtr Il supporto per il token ring richiede molto più che la sola scrittura di un driver per i dispositivi. Richiede anche la scrittura delle routine di source routing per token ring. Ed è proprio la scrittura di queste ultime che richiederebbe il più grande impegno. L'iniziale sviluppo dei driver è stato fatto con schede IBM Token Ring per bus ISA e MCA ed è stato testato con una scheda MCA 16/4 Megabit Token Ring, ma dovrebbe funzionare con altre schede basate sul chipset Tropic. 4.23. Schede Ethernet ICL 4.23.1. ICL EtherTeam 16i/32 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. 4.24. Schede Ethernet Intel Si noti che la nomenclatura delle diverse schede Intel è ambigua e quanto meno tende a confondere. Se si hanno dubbi, si veda il numero i8xxxx sul chip principale della scheda oppure, per le schede PCI, si usino le informazioni PCI contenute nella directory /proc 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 è in possesso. 4.24.1. Ether Express 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 outb con 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. 4.24.2. Ether Express PRO/10 (PRO/10+) 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à plug and play qualora questo fosse necessario. 4.24.3. Ether Express PRO/10 PCI (EISA) 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 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: 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. 4.24.4. Ether Express PRO 10/100B Stato: Supportata, Nome del driver: e100 o eepro100 Il driver e100 è stato rilasciato da Intel, mentre il driver eepro100 è stato scritto da Donald. Si noti che il driver eepro100 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 EEPro-100B Page 4.24.5. E1000 Gigabit Stato: Supportata, Nome del driver: e1000 4.25. Kingston 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 pagina web della Kingston 4.26. LinkSys 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 è www.linksys.com 4.26.1. Schede LinkSys Etherfast 10/100. Stato: Supportate, Nome del driver: tulip Si noti che queste schede sono state sottoposte a parecchie 'revisioni' (ovvero sono stati usati diversi chip) tutte sotto lo stesso nome. La prima usava il chip della DEC. La seconda revisione usava il PNIC 82c168 PCI della Lite-On 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 è 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 http://www.scyld.com/network Altre informazioni sulle diverse versioni di queste schede possono essere trovate nella pagina WWW della LinkSys già menzionata in precedenza. 4.26.2. LinkSys Pocket Ethernet Adapter Plus (PEAEPP) Stato: Supportata, Nome del driver: de620 Questo è un clone (o supposto tale) nel DE-620 e si dice funzioni bene con il corrispondente driver. Si veda la sezione ``DE-620'' per maggiori informazioni. 4.26.3. LinkSys PCMCIA Adaptor Stato: Supportato, Nome del driver: pcnet_cs Questa è una versione rimarchiata del DE-650. 4.27. Microdyne (Eagle) Eagle Technology (un tempo anche conosciuta sotto il nome di Novell cards) è stata acquisita da Microdyne. Se non potete trovare qui la vostra scheda, controllate la sezione di questo documento dedicata a Novell. Mentre Microdyne non è più sul mercato con schede di rete, c'è ancora un po' di materiale relativo ai loro prodotti di rete sul loro sito ftp.microdyne.com. 4.27.1. Microdyne Exos 205T Stato: Semi supportata, Nome del driver: ? Un'altra scheda basata sul chip i82586. Dirk Niggemann 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. 4.28. Mylex La Mylex può essere raggiunta ai seguenti numeri, nel caso qualcuno voglia chieder loro qualcosa. MYLEX CORPORATION, Fremont Sales: 800-77-MYLEX, (510) 796-6100 FAX: (510) 745-8016. Hanno anche un sito web: Mylex WWW Site 4.28.1. Mylex LNE390A, LNE390B Stato: Supportata, Nome del driver: lne390 (+8390) Queste sono delle schede EISA piuttosto vecchie che fanno uso di un'implementazione a memoria condivisa simile alla wd80x3. Nella serie attuale 2.1.x del kernel è presente un driver per queste schede. Ci si assicuri di impostare l'indirizzo della memoria condivisa sotto il primo MB o oltre il più alto indirizzo della memoria RAM fisicamente installata nella macchina. 4.28.2. Mylex LNP101 Stato: Supportata, Nome del driver: de4x5, tulip Questa è una scheda PCI basata sul chip 21040 della DEC. Può 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 (``DEC 21040'') per maggiori informazioni. 4.28.3. Mylex LNP104 Stato: Semi supportata, Nome del driver: de4x5, tulip La LNP104 usa il chip 21050 della DEC per gestire quattro porte 10BaseT indipendenti. Dovrebbe funzionare con i driver 21040 recenti che sanno come condividere gli IRQ, ma nessuno ha ancora riportato di averci provato (a quanto ne so). 4.29. Myson 4.29.1. Myson MTD-8xx 10/100 PCI Stato: Supportata, Nome del driver: fealnx Sembra che le schede vendute con il marchio Surecom EP-320X-S includano anche loro questo chip. 4.30. National Semiconductor National Semiconductor è 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. 4.30.1. NS8390, DP8390, DP83905 etc. 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 8390.o non contiene un driver completo in se, ma va usato in congiunzione con un altro driver che conosce la modalità di interfacciamento tra l'8390 ed il bus del computer. Esempi di questa seconda metà del driver sono wd.o, 3c503.o, smc-ultra.o, ne2k-pci.o e così via. 4.30.2. DP83800 with DP83840 Stato: Not Supportata. Si veda la sezione per la NE 10/100 di seguito. 4.30.3. DP83815/83816 Stato: Supportata, Nome del driver: natsemi http://www.scyld.com/network/natsemi.html Questo driver è reperibile con i kernel 2.4 e seguenti. 4.30.4. NS83820, DP83820 Stato: Supportato, Nome del driver: ns83820 L'83820 è una scheda a 64 bit da 10/100/1000 Mbps per il bus PCI, e la 83821 è 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. 4.31. Novell Ethernet, NExxxx e cloni associati 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). 4.31.1. NE1000, NE2000 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 ``Problemi con...''. Alcuni cloni della NE2000 usano il chip 'AT/LANTic' 83905 della National Semiconductor, che offre una modalità a memoria condivisa simile a quella della wd8013 e la configurazione via software della EEPROM. La modalità a memoria condivisa permette un minor utilizzo della CPU (cioè è più efficiente) rispetto alla modalità ad I/O programmato. In generale non è una buona idea mettere un clone della NE2000 all'indirizzo I/O 0x300, perché praticamente tutti i driver di dispositivo cercano lì durante il boot. Alcuni cloni NE2000 scadenti non la prendono bene ad essere pungolati in aree sbagliate e risponderanno bloccando la macchina. Inoltre anche 0x320 non va bene perché i driver SCSI rilevano all'indirizzo 0x330. Donald ha scritto un progamma di diagnostica per NE2000 (ne2k.c) che va bene per tutte le schede ne2000. Si veda la sezione ``Programmi diagnostici'' per maggiori informazioni. Se si intende usare questo driver come modulo caricabile nel kernel probabilmente si dovrebbe fare riferimento alla sezione ``Usare un driver Ethernet come modulo'' per informazioni specifiche sui moduli. 4.31.2. NE2000-PCI (RealTek/Winbond/Compex) 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 ne.c o quello relativamente nuovo solo PCI ne2k-pci.c. Per usare il driver ISA/PCI originale si deve rispondere 'Y' all'opzione 'Other ISA cards' quando si lancia make config perché in realtà si sta usando lo stesso driver NE2000 che usano le schede ISA (la qual cosa dovrebbe suggerire che queste schede non sono 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: http://www.scyld.com/network Se si possiede una scheda PCI NE2000 che non viene rilevata dalla versione più recente del driver, si contatti il maintainer del driver NE2000 elencato nel file /usr/src/linux/MAINTAINERS includendo l'output di cat /proc/pci e dmesg 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. 4.31.3. NE-10/100 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. 4.31.4. NE1500, NE2100 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 ``AMD LANCE''. 4.31.5. NE/2 MCA 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. 4.31.6. NE3200 Stato: Non supportata Anche se non c'è 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: http://vip.cybercity.dk/~ccc94453/linux/ne3200/ 4.31.7. NE3210 Stato: Supportata, Nome del driver: ne3210 (+8390) Questa scheda EISA è completamente diversa dalla NE3200, essendo basata sul chip 8390 della National Semiconductor. Si può 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. 4.31.8. NE4100 Stato: Supportata, Nome del Driver: pcnet_cs 4.31.9. NE5500 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 ``AMD LANCE''. 4.32. Netgear 4.32.1. Netgear FA-311 Status: Supportata, Nome del Driver: natsemi 4.32.2. Netgear GA-620 Status: Supportata, Nome del Driver: acenic 4.32.3. Netgear GA-621 Status: Supportata, Nome del Driver: ns83820 4.33. Proteon 4.33.1. Proteon P1370-EA Stato: Supportata, Nome del driver: ne (+8390) Sembra che questa sia un clone NE2000, e funziona bene con Linux. 4.33.2. Proteon P1670-EA 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 (``DEC 21040'') per maggiori informazioni sul driver. 4.34. Pure Data 4.34.1. PDUC8028, PDI8023 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'è del codice scritto specificamente per verificare la loro eventuale presenza in wd.c. 4.35. Racal-Interlan La Racal Interlan può essere raggiunta via WWW a www.interlan.com. Credo che in passato fosse conosciuta anche con il nome di MiCom- Interlan. 4.35.1. ES3210 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 0xd0000 che usa un driver modulare, si aggiunga options es3210 irq=5 mem=0xd0000 a /etc/modules.conf. Oppure, con il driver compilato nel kernel, all'avvio si passino i parametri ether=5,0,0xd0000,eth0. L'indirizzo I/O di base viene rilevato automaticamente e quindi si dovrebbe usare il valore 0. 4.35.2. NI5010 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. 4.35.3. NI5210 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 ``Driver sperimentali'' per importanti informazioni sull'uso dei driver Ethernet sperimentali. 4.35.4. NI6510 (non EB) 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 ``Driver sperimentali'' per importanti informazioni sull'uso dei driver Ethernet sperimentali. 4.35.5. EtherBlaster (aka NI6510EB) 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) 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à usare come default invece di 0x52, 0x44. Usando il driver lance, probabilmente queste schede dovrebbero essere usate in modalità 'alte prestazioni' e non in compatibilità NI6510. 4.36. RealTek 4.36.1. Adattatore pocket RealTek RTL8002/8012 (AT-Lan-Tec) 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 ifconfig non era eth0 bensì atp0. 4.36.2. RealTek 8008 Stato: Supportata, Nome del driver: ne, wd (+8390) È stato riferito che questo chip si comporta in maniera similare all' AT/LANTIC in quanto può essere configurato per operare sia in modalità ne/PIO che wd/MMIO impiegando il software fornito dal produttore (SET8008R). 4.36.3. RealTek 8009 Stato: Supportata, Nome del driver: ne (+8390) Questa è un clone ISA della NE2000 e si dice funzioni bene con il driver NE2000 di Linux. Dal sito Web della RealTek (http://www.realtek.com.tw) o via FTP dallo stesso sito può essere scaricato il programma rset8009.exe. 4.36.4. RealTek 8019 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 io=0xNNN a /etc/modules.conf). Dal sito WWW della RealTek (http://www.realtek.com.tw) o via FTP dallo stesso sito può essere scaricato il programma rset8009.exe. 4.36.5. RealTek 8029 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 ``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. 4.36.6. RealTek 8129/8139 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 8139too. Nei kernel precedenti, il driver per queste schede si chiamava rtl8139 e solitamente era necessario rispondere 'Y' quando veniva richiesto se si desiderava accesso ai driver sperimentali. 4.37. Sager 4.37.1. Sager NP943 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 ``3Com 3c501'' per tutte le ragioni per le quali non si deve proprio usare una di queste schede. 4.38. Schneider & Koch 4.38.1. SK G16 Stato: Obsoleta, Nome del driver: sk_g16 Questo driver era già 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 è diventato obsoleto a partire dai kernel 2.4. 4.39. SEEQ 4.39.1. SEEQ 8005 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 è diventato obsoleto a partire dai kernel 2.4. 4.40. SiS (Silicon Integrated Systems) SiS produceva chipset per schede madri già nell'era del processore 386 (come il mitico 'el cheapo', N.d.T.), ed adesso producono anche alcuni chip Ethernet, anch'essi alquanto popolari. 4.40.1. SiS 900 (7016, 630E, 962) Stato: supportata, Nome del driver: sis900 Questo dispositivo può essere incontrato sia come scheda di espansione a se stante che come dispositivo integrato nella scheda madre. Il driver è stato disponibile a partire dagli ultimi kernel 2.2. 4.41. SMC (Standard Microsystems Corp.) La divisione Ethernet della Western Digital è stata acquisita dalla SMC molti anni fa, quando la wd8003 e wd8013 erano i prodotti di punta. Da allora la SMC ha continuato a fare schede ISA basate sull'8390 (Elite16, Ultra, EtherEZ) e ha aggiunto alla gamma anche diversi prodotti PCI. Informazioni per contattare la SMC: SMC / Standard Microsystems Corp., 80 Arkay Drive, Hauppage, New York, 11788, USA. Supporto tecnico telefonico: 800-992-4762 (USA) o 800-433-5345 (Canada) o 516-435-6250 (Altri nazioni). Richieste di documentazione: 800-SMC-4-YOU (USA) o 800-833-4-SMC (Canada) o 516-435-6255 (Altre nazioni). Supporto tecnico via E-mail: techsupt@ccmail.west.smc.com. Sito FTP: ftp.smc.com. Sito Web: SMC . 4.41.1. WD8003, SMC Elite Stato: Supportate, Nome del driver: wd (+8390) Queste sono le versioni ad 8 bit della scheda. Il chip 8003 a 8 bit è leggermente meno costoso, ma vale 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 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 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. 4.41.2. WD8013, SMC Elite16 Stato: Supportate, Nome del driver: wd (+8390) Negli anni sono stati aggiunti al progetto altri registri e una EEPROM (le prime schede wd8003 sono apparse circa 10 anni fa!). I cloni solitamente vanno sotto il nome '8013' e tipicamente usano un progetto senza EEPROM (con i ponticelli). Gli ultimi modelli delle schede SMC montano un chip 83c690 della SMC invece dell'originale DP8390 della National 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 /etc/modules.conf 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: ______________________________________________________________________ LILO: linux ether=9,0x280,0xd0000,0xd8000,eth0 ______________________________________________________________________ Si veda anche la sezione ``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 ``Usare un driver Ethernet come modulo'' per informazioni specifiche sui moduli. 4.41.3. SMC Elite Ultra Stato: Supportata, Nome del driver: smc-ultra (+8390) Questa scheda Ethernet è basata sul chip 83c790 della SMC che ha un po' di nuove caratteristiche rispetto 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 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 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 ``Usare un driver Ethernet come modulo'' per informazioni specifiche sui moduli. 4.41.4. SMC Elite Ultra32 EISA Stato: Supportata, Nome del driver: smc-ultra32 (+8390) Questa scheda EISA ha molto in comune con la sua controparte ISA. Un driver funzionante (e stabile) è incluso sia nei kernel 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. 4.41.5. SMC EtherEZ (8416) Stato: Supportata, Nome del driver: smc-ultra (+8390) Questa scheda usa il chip 83c795 della SMC e supporta le specifiche Plug 'n Play. Ha anche una modalità SMC Ultra compatibile, che le permette di essere usata con il driver Ultra per Linux. Per migliori risultati si usi il programma fornito dalla SMC (disponibile nel loro sito 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. 4.41.6. SMC EtherPower PCI (8432) Stato: Supportata, Nome del driver: de4x5, tulip NB: La EtherPower II è una scheda completamente diversa. Si veda sotto! Queste schede sono un'implementazione base del 21040 della DEC, cioè un unico grosso chip e una coppia di transceiver. Donald ha usato una di queste schede per lo sviluppo del driver 21040 generico (meglio noto come tulip.c). Grazie a Duke Kamstra, ancora una volta, per aver fornito una scheda sulla quale fare lo sviluppo. Alcune delle ultime revisioni di questa scheda usano il più recente chip 21041 della DEC, che può causare problemi con versioni più vecchie del driver tulip. Se si hanno problemi ci si assicuri di usare l'ultima versione del driver, che potrebbe non essere ancora stata inclusa nei sorgenti del kernel corrente. Si veda la sezione ``DEC 21040'' per ulteriori dettagli sull'uso di una di queste schede e sullo stato attuale del driver. Apparentemente, l'ultima revisione delle scheda, la EtherPower-II usa il chip 9432. Al momento non è chiaro se questa funzionerà con il driver attuale. Come sempre, se non si è sicuri, si verifichi di poter restituire la scheda se non funziona con il driver per Linux prima di pagarla. 4.41.7. SMC EtherPower II PCI (9432) Stato: Semi supportata, Nome del driver: epic100 Queste schede, basate sul chip 83c170 della SMC, sono completamente differenti da quelle basate sul Tulip. Un nuovo driver è stato incluso nei kernel 2.0 e 2.2 per supportare queste schede. Per ulteriori dettagli si veda: http://www.scyld.com/network 4.41.8. SMC 1211TX 10/100 Stato: Semi supportata, Nome del driver: 8139too, rtl8139 (vecchio driver) Sembra che SMC non sia più 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. 4.41.9. SMC 3008 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. 4.41.10. SMC 3016 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. 4.41.11. SMC-9000 / SMC 91c92/4 Stato: Supportata, Nome del driver: smc9194 La SMC9000 è una scheda VLB basata sul chip 91c92. Il 91c92 sembra essere presente anche su un po' di schede di altre marche, ma è piuttosto poco comune. 4.41.12. SMC 91c100 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. 4.41.13. SMC 9452TX/9462TX Stato: Supportata, Nome del driver: ns83820 4.42. Sundance 4.42.1. Sundance ST201, Alta 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ò 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. 4.43. SysKonnect 4.43.1. SysKonnect sk-98xx Gigabit Ethernet 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. 4.44. Texas Instruments 4.44.1. ThunderLAN 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. 4.45. Thomas Conrad 4.45.1. Thomas Conrad TC-5048 Questa è un'altra scheda PCI basata sul chip 21040 della DEC. Si veda la sezione sul chip 21040 (``DEC 21040'') per maggiori informazioni. 4.46. VIA Probabilmente non si avrà 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 è il seguente: http://www.via.com.tw/ 4.46.1. VIA 86C926 Amazon Stato: Supportato, Nome del driver: ne, ne2k-pci (+8390) Questo chip è la soluzione VIA compatibile PCI-NE2000. Si può scegliere tra il driver ne.c per ISA e PCI o il driver solo PCI ne2k- pci.c. Si veda la sezione sulle schede PCI-NE2000 per ulteriori informazioni. 4.46.2. VIA 86C100A Rhine II (and 3043 Rhine I) Stato: supportato, Nome del driver: via-rhine Questo driver relativamente nuovo è 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: http://www.scyld.com/network 4.47. Western Digital Si veda la sezione ``SMC'' per informazioni sulle schede SMC (la SMC ha comprato la divisione schede di rete della Western Digital molti anni fa). 4.48. Winbond 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: http://www.winbond.com.tw 4.48.1. Winbond 89c840 Stato: Supportato, Nome del driver: winbond-840 Questo chip è 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. 4.48.2. Winbond 89c904, 89c905, 89c906 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. 4.48.3. Winbond 89c940 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ù di dieci anni adattato per il bus PCI. Le prestazioni non saranno tanto migliori rispetto a quelle dell'equivalente modello ISA. 4.49. Xircom Per lungo tempo, la Xircom non ha voluto rilasciare la informazioni di programmazione necessarie per scrivere un driver, a meno che non si firmasse un accordo di confidenzialità 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à. Ad alcuni è stato detto che sarebbe stato rilasciato il codice sorgente del driver SCO, mentre ad altri hanno detto che non vengono più 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. 4.49.1. Xircom PE1, PE2, PE3-10B* 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). 4.49.2. Xircom CE, CEM, CE2, CE3 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. 4.49.3. Xircom CBE-100 Stato: Supportata, Nome del driver: xircom_tulip_cb Una implementazione simile al design tulip su CardBus. 4.50. Zenith 4.50.1. Z-Note Stato: Obsoleta, Nome del driver: znet L'adattatore di rete built-in Z-Note è basato su un i82593 dell'Intel ed usa due canali DMA. Si noti che il ThinkPad 300 dell'IBM è compatibile con Z-Note. 4.51. Znyx 4.51.1. Znyx ZX342 (DEC 21040 based) Stato: Supportata, Nome del driver: de4x5, tulip Si ha la scelta fra due driver per le schede basate su questo chip. C'è un driver DE425 scritto da David e il driver generico per 21040 che ha scritto 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 README.de4x5 per i dettagli. Si veda la sezione ``DEC 21040'' per maggiori informazioni su queste schede e la situazione corrente del driver. 4.52. Identificare una scheda sconosciuta Bene, e così l'amico del vicino del cugino di vostro zio ha un fratello che ha trovato una vecchia scheda Ethernet ISA in un case AT che usava come gabbia per criceti di suo figlio. In qualche modo questa scheda vi è capitata tra le mani e la volete usare con Linux, ma nessuno ha idea di che scheda sia e non c'è alcuna documentazione. Per prima cosa, si cerchi un qualsiasi numero di modello che potrebbe costituire un indizio. Qualsiasi numero di modello contenente il numero 2000 sarà 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. 4.52.1. Identificare il Network Interface Controller 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 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. 4.52.2. Identificare l'indirizzo Ethernet 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 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 EtherNet-codes o Ethernet-codes e qualcosa salterà fuori. 4.52.3. Identificare la scheda a partire dal numero di FCC ID 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 FCC ID: J158013EWC risulta poi essere una SMC/WD8013-EWC. Alcuni siti Web come www.driverguide.com e drdriver.com fanno uso degli identificativi FCC per fornire aiuto agli utenti nell'identificazione delle schede più oscure. La FCC stessa mette a disposizione uno strumento di ricerca che può risultare utile all'indirizzo Web seguente: FCC IDs < http://www.fcc.gov/oet/fccid> 4.52.4. Suggerimenti per provare ad usare una scheda sconosciuta 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 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 0x100 e fino a 0x3ff cercando dispositivi che non siano registrati in /proc/ioports. Se trova un dispositivo sconosciuto a qualche indirizzo specifico, si può esplicitamente indirizzare il rilevamento a quell'indirizzo con il parametro 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: Ethercard Settings 4.53. Driver per i dispositivi non Ethernet Ci sono alcuni altri driver nei sorgenti di Linux che si presentano ai programmi di rete come dispositivi simil-Ethernet, anche se non sono veramente Ethernet. Per completezza sono qui brevemente elencati. dummy.c -- Lo scopo di questo driver è di fornire un dispositivo al quale far puntare il routing, ma che realmente non trasmette pacchetti. 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. ibmtr.c -- IBM Token Ring, che non è proprio Ethernet. Broken-Ring richiede source routing ed altre brutte cose. 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. pi2.c -- Interfacce PI e PI2 dell'Ottawa Amateur Radio Club. plip.c - Parallel Line Internet Protocol, permette a due computer di inviarsi pacchetti attraverso due porte parallele connesse in modalità point-to-point. ppp.c -- Point-to-Point Protocol (RFC1331, 1548, 1661), per la trasmissione di datagrammi multiprotocollo su una connessione Point- to-Point (solitamente modem). 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. tunnel.c -- Fornisce un tunnel IP attraverso il quale si può incanalare il traffico di rete in maniera trasparente tra le sottoreti. wavelan.c -- Un transceiver radio tipo Ethernet controllato da un coprocessore Intel 82586 usato su altre schede Ethernet come ad esempio la Intel EtherExpress. 5. Cavi, coassiali, doppini intrecciati Se si sta mettendo su una nuova rete, si utilizzerà 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ò 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 ``Tipi di cavi...'' per una panoramica introduttiva sui cavi. Si noti inoltre che la FAQ di 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 /pub/usenet-by-hierarchy/ la FAQ di quel newsgroup. 5.1. Thin Ethernet (thinnet) Thinnet è 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 ancora necessari sia il connettore a T che i terminatori da 50 Ohm: 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. 5.2. Doppino intrecciato (twisted pair) Le reti a doppini intrecciati necessitano di hub (concentratori) attivi, che costano attorno ai $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 è 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à 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. 6. Configurazione del software e diagnotici Per le più vecchie (o le più 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à delle schede, questi settaggi sono stati spostati in ambito elettronico piuttosto che fisico e l'utente è ora in grado di di immagazzinare la configurazione prescelta in nella memoria non volatile integrata nella scheda. Un programma fornito dal produttore può 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 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 cat /proc/net/dev (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 ifconfig eth0 down. 6.1. Programmi di configurazione per le schede Ethernet 6.1.1. Schede WD80x3 Per quanti hanno schede wd80x3, c'è il programma wdsetup che può essere reperito nell'archivio 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 deve possedere una scheda con la EEPROM per poter usare questo programma. Le vecchie, ma proprio vecchie, schede wd8003 e alcuni vecchi cloni wd8013 usano dei ponticelli per configurare la scheda. 6.1.2. Schede Digital/DEC La scheda Digital EtherWorks 3 può essere configurata in maniera simile con il programma DOS NICSETUP.EXE. David C. Davies ha scritto questo programma e altri strumenti per la EtherWorks 3 oltre al driver stesso. Si cerchi il file ewrk3tools-X.XX.tar.gz nella directory /pub/linux/system/Network/management sul sito FTP dedicato a Linux a cui fate riferimento. 6.1.3. Schede NE2000+ o AT/LANTIC Alcune implementazioni del DP83905 della National Semiconductor (come le AT/LANTIC e le NE2000+) sono configurabili via software (si noti che queste schede emulano anche una wd8013!). Per configurare queste schede si può scaricare il file di setup atlantic.c dal server ftp di Donald, 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: Kingston e si scarichino 20XX12.EXE e INFOSET.EXE. Si faccia attenzione quando si configurano schede NE2000+, poiché alcune impostazioni errate possono causare problemi. Un esempio tipico è l'abilitazione 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 default.exe dell'archivio 20XX12.EXE suddetto. Quindi si digiti echo default > a:autoexec.bat in modo tale che il programma che reimposta i valori predefiniti della scheda sia eseguito automaticamente quando si avvia 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 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 atlantic di Donald (con le giuste opzioni d'avvio) invece che con un dischetto di avvio di DOS che lancia automaticamente il programma default.exe. 6.1.4. Schede 3Com La famiglia di schede Etherlink III della 3Com (p.es. 3c5x9) può essere configurata usando un'altra utilità di configurazione di Donald. Si può scaricare il file 3c5x9setup.c dal server ftp di Donald, 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). 6.2. Programmi diagnostici per schede Ethernet Tutti i programmi diagnostici scritti da Donald possono essere ottenuti visitando il suo sito web: Ethercard Diagnostics Allied Telesis AT1700 -- at1700.c Cabletron E21XX -- e21.c HP PCLAN+ -- hp+.c Intel EtherExpress -- eexpress.c PCI NE2000 cards -- ne2k-pci-diag.c ISA NE2000 cards -- ne2k.c RealTek (ATP) Pocket adaptor atp-diag.c Tutte le altre schede: si provi a usare i comandi cat /proc/net/dev e dmesg per vedere quali informazioni utili possiede il kernel sulla scheda in questione. 7. Informazioni tecniche 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. 7.1. I/O programmato, memoria condivisa e DMA a confronto Se già si è in grado di ricevere e inviare pacchetti back-to-back, allora non si possono immettere più bit di così 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. 7.1.1. Programmed I/O (I/O Programmato) (es. NE2000, 3c509) 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à interleaved è solitamente difficile se non impossibile. 7.1.2. Shared memory (Memoria Condivisa) (es. WD80x3, SMC-Ultra, 3c503) Pro: Più veloce e semplice dell'I/O programmato e inoltre permette l'accesso casuale ai pacchetti. Dove possibile, i driver per Linux calcolano il checksum dei pacchetti IP in ingresso non appena vengono copiati dalla scheda, il che risulta in un'ulteriore riduzione dell'uso della CPU rispetto ad una equivalente scheda PIO. Contro: Usa più memoria (un grosso "contro" per utenti DOS, ma sostanzialmente non un problema sotto Linux) e blocca comunque la CPU. 7.1.3. DMA (Accesso diretto alla memoria) in bus mastering (es. LANCE, DEC 21040) 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. 7.2. Implicazioni della Larghezza di Bus per le Prestazioni 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. 7.2.1. Schede ISA a 8 e 16 Bit Vi risulterà 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ù 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 è diretto altrove, allora il collo di bottiglia della connessione sarà da un altra parte e l'unica differenza di velocità che voi noterete riguarderà il vostro traffico locale. 7.2.2. Schede Ethernet a 32 Bit per bus PCI (e VLB/EISA) Ovviamente una interfaccia a 32 bit verso il computer è 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ù vecchio network a 10Mbps non ha veramente bisogno di una interfaccia a 32 bit. Si veda la sezione ``I/O programmato, memoria condivisa...'' sul perché avere una scheda Ethernet da 10Mbps montata su di un bus ISA a 8Mhz non costituisca in realtà un limite. Anche se l'avere una scheda lenta su di un bus veloce non sarà all'origine di trasferimenti di dati più veloci, solitamente essa causerà meno carico sulla CPU, il che è sempre un bene su sistemi multiutente. 7.3. Impatto sulle prestazioni di Zero Copy 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ò 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". 7.4. Impatto sulle Prestazioni dei Checksum in Hardware Non c'è 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à 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ò 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 sendfile()), e checksum hardware di ricezione sono al momento attuale ben più utili. Si noti che un computer di prestazioni ragionevoli può 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. 7.5. Impatto sulle Prestazioni del NAPI (Rx interrupt mitigation) 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ò essere facilmente risparmiato semplicemente sospendendo la generazione di interrupt e rimanendo nella funzione di ricezione del driver, dato che più 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 è inclusa nella directory Documentation/networking del kernel. 8. Miscellanea 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. 8.1. Buffer FIFO di Trasmissione ed Errori di Underrun Donald ha scritto una bella descrizione di che cosa sia un buffer FIFO di trasmissione e di cosa succede quando si verifica un errore. Eccola a voi: Nei casi in cui l'hardware lo supporta, i miei driver includono codice per ottimizzare il comportamento della FIFO di trasmissione. Un tipico chip Ethernet ha una FIFO di trasmissione che contiene i dati arrivati dal bus prima che questi vengano trasmessi sul cavo. La maniera in cui questa FIFO viene gestita è importante per le prestazioni. Idealmente, si dovrebbe voler iniziare a trasmettere non appena il primo pacchetto in trasmissione arriva sul chip. Il "Tx FIFO threshold" è un parametro che specifica di iniziare a trasmettere quando N byte sono arrivati al NIC. Inizialmente, questo parametro è settato per una configurazione tipica, ma se una scheda video o un controller SCSI stanno causando dei prolungati picchi di traffico PCI, il chip NIC esaurirà i dati nel suo buffer di trasmissione prima di poter accedere di nuovo al bus, e questo causa una FIFO underrun. Il driver risponde ad una FIFO underrun incrementando il "Tx FIFO threshold", e se questo succede un numero sufficiente di volte il chip finirà per operare in modalità store-and-forward, vale a dire che la trasmissione di un pacchetto non avrà inizio sino a quando esso non sia stato completamente trasferito al NIC. Alcuni progetti, come l'Adaptec Starfire, compiono un passo ulteriore e forniscono un segnale che la FIFO ha quasi esaurito i dati. Questo permette al driver di configurare questo settaggio senza rischiare un errore di trasmissione. Dovrebbe essere piuttosto raro l'incontrare più di uno o due FIFO underrun: o il chip ha un settaggio del "Tx FIFO threshold" che permette poche scelte oppure il driver aumenta questo valore in grossi passi per mantenere i picchi di traffico PCI contenuti dai loro limiti naturali. 8.2. Passare al kernel argomenti Ethernet Ci sono due comandi generici che possono essere passati al kernel al momento del boot: ether e reserve. Si può far questo con LILO, loadlin o qualsiasi altra utilità di boot che accetti argomenti opzionali. Per esempio, se il comando fosse 'blah' e si aspettasse 3 argomenti (diciamo 123, 456 e 789) allora con LILO si potrebbe usare: LILO: linux blah=123,456,789 Questi parametri di boot possono essere resi permanenti cosicché non si debba reinserirli ogni volta. Solitamente questo richiede solamente l'inserimento di una riga come append="blah=123,456,789" all'inizio del vostro /etc/lilo.conf. Si veda la documentazione di LILO per ulteriori dettagli. Per maggiori informazioni sui parametri di boot (e un elenco completo) si veda il BootPrompt-HOWTO . 8.2.1. Il parametro ether Il parametro ether= viene usato in congiunzione con i driver direttamente compilati nel kernel. Non ha assolutamente alcun effetto su driver modulari. Nella sua forma più generale, può somigliare a qualcosa come quel che segue: ether=IRQ,IND_BASE,PARAM_1,PARAM_2,NOME Tutti gli argomenti sono opzionali. Il primo argomento non numerico è interpretato come NOME. IRQ: ovvio. Un valore di '0' (solitamente il valore predefinito) indica di usare autoIRQ. È accidentale che l'impostazione dell'IRQ sia prima di quella dell'ind_base: questo verrà corretto non appena cambia anche qualcos'altro. IND_BASE: altrettanto ovvio. Il valore '0' (solitamente quello predefinito) indica di rilevare una scheda nell'elenco di indirizzi specifici per quella scheda. PARAM_1: Originariamente usato come valore per ridefinire l'indirizzo iniziale della memoria per una scheda Ethernet a memoria condivisa, come la WD80*3. Alcuni driver usano i 4 bit meno significativi di questo valore per impostare il livello dei messaggi di debug. 0: predefinito, 1-7: livello 1..7 (con 7 si ottiene il massimo della verbosità), 8: livello 0 (nessun messaggio). Inoltre, il driver LANCE usa i 4 bit meno significativi di questo valore per selezionare il canale DMA. Altrimenti usa auto-DMA. PARAM_2: Il driver 3c503 usa questo valore per selezionare tra il transceiver interno ed esterno. 0: predefinito/interno, 1: AUI esterno. La scheda E21XX della Cabletron usa i 4 bit meno significativi di PARAM_2 per selezionare il mezzo d'uscita. Altrimenti lo rileva automaticamente. NOME: Seleziona il dispositivo di rete a cui fa riferimento il valore. Il kernel standard usa i nomi 'eth0', 'eth1', 'eth2' e 'eth3' per le schede Ethernet attaccate sul bus e 'atp0' per gli adattatori Ethernet 'pocket' su porta parallela. Il driver arcnet come nome usa 'arc0'. L'impostazione predefinita è per il rilevamento di un'unica scheda Ethernet, la 'eth0'. L'abilitazione di più schede è possibile solamente impostando esplicitamente il loro indirizzo base usando questi parametri per LILO. Il kernel 1.0 trattava le schede Ethernet basate su LANCE in modo speciale. Gli argomenti di LILO venivano sempre ignorati e alle schede LANCE erano sempre assegnati i nomi 'eth' partendo da 'eth0'. Ulteriori schede Ethernet non LANCE dovevano essere esplicitamente assegnate a 'eth', e il rilevamento standard di 'eth0' doveva essere disabilitato con qualcosa di simile a 'ether=0,-1,eth0' (sì, questo è un bug). 8.2.2. Il comando reserve Questo comando di lilo viene usato proprio come il precedente 'ether=', ovvero viene accodato al nome di avvio selezionato in lilo.conf. reserve=IO-base,estensione{,IO-base,estensione...} In alcune macchine può essere necessario impedire ai driver di controllare la presenza di dispositivi (auto-probing) in regioni specifiche. Ciò può essere dovuto ad hardware mal progettato che causa il blocco del boot (come alcune schede Ethernet), ad hardware che viene mal identificato, ad hardware il cui stato è stato modificato da un rilevamento precedente, o semplicemente ad hardware che non vuole essere inizializzato dal kernel. L'argomento di boot reserve indirizza questo problema specificando una regione di porte di I/O che non deve essere controllata. Tale regione viene riservata nella tabella di registrazione delle porte del kernel come se vi si fosse già rilevato un dispositivo. Si noti che questo meccanismo non dovrebbe essere necessario nella maggior parte della macchine a meno che non si sia riscontrato un problema (o di avere a che fare con un caso particolare). Le porte I/O nella regione specificata vengono protette dai controlli per la ricerca dei dispositivi. Questo si è reso necessario per gestire i casi in cui alcuni driver si piantavano su di una NE2000 o erroneamente identificavano altri dispositivi come propri. Un driver di dispositivo correttamente scritto non dovrebbe controllare una regione riservata a meno che qualche altro argomento di boot non specifici esplicitamente di far questo. La maggior parte dei driver ignora la tabella di registrazione delle porte se gli viene passato un indirizzo specifico. Per esempio, la riga di boot LILO: linux reserve=0x300,32 ether=0,0x300,eth0 impedisce a tutti i device driver, tranne a quelli della scheda Ethernet, di controllare se un dispositivo è presente nella regione 0x300-0x31f. Come al solito per i comandi di boot, c'è un limite di 11 parametri, quindi si possono specificare solo 5 regioni riservate per ciascun comando reserve. Possono essere specificati più reserve se si hanno richieste insolitamente complicate da descrivere. 8.3. Usare un driver Ethernet come modulo La maggior parte delle distribuzioni di Linux utilizzano ora dei kernel con pochissimi driver al loro interno. I driver vengono ora piuttosto forniti come gruppo di moduli indipendenti caricabili dinamicamente. Questi driver modulari sono tipicamente caricati dall'amministratore con il comando modprobe(8) o in alcuni casi sono automaticamente caricati dal kernel attraverso 'kerneld' (nei kernel 2.0) o 'kmod' (nei kernel 2.1) che a loro volta chiamano modprobe. La vostra distribuzione può offrire un comodo strumento grafico per la configurazione dei moduli Ethernet. Se possibile prima si dovrebbe provare a usare quello. La descrizione che segue descrive che cosa sta dietro a qualsiasi programma di configurazione e indica cosa quei programmi vadano a modificare. Le informazioni che indicano quali moduli vengono usati e quali opzioni vengono passate a ciascun modulo vengono solitamente salvate nel file /etc/modules.conf. Le due opzioni principali di interesse per le schede Ethernet che saranno usate in questo file sono alias e options. Il comando modprobe consulta questo file per informazioni sui moduli. I moduli stessi sono tipicamente collocati in una directory chiamata /lib/modules/`uname -r`/net dove il comando uname -r restituisce la versione del kernel (e.g. 2.0.34). Si può andare li per vedere quale modulo corrisponda alla propria scheda. La prima cosa che ci deve essere nel file modules.conf è una riga che indichi a modprobe quale driver usare per l'interfaccia di rete eth0 (e per eth1 e per...). Per fare questo si dovrà usare il comando alias. Per esempio, se si ha una scheda ISA EtherEZ della SMC che usa il driver modulare smc-ultra.o, si deve creare un alias per questo driver che corrisponda a eth0, aggiungendo la riga: alias eth0 smc-ultra Nota Importante: l'alias summenzionato viene usato solo dalle utilità per i moduli per convertire un nome di device generico (come ad esempio eth0) nel nome specifico del modulo del driver. Quando il driver viene caricato non vede mai questo alias: invece, esso si limita a scegliere il primo nome libero (ethN per N=0,1,2,...). Quindi, se più di un modulo Ethernet viene caricato, l'ethN assegnato al driver dal kernel può non corrispondere con quello assegnatogli dall'alias, a seconda dell'ordine in cui i moduli vengono caricati. Se dovete assicurarvi che una specifica scheda venga assegnata un indirizzo IP specifico, allora si legga l'indirizzo della hardware della scheda e si assegni l'indirizzo IP a seconda di quello. Se state scrivendo un vostro shell script per far questo, potete limitarvi a fare il parsing dell'output di ifconfig, altrimenti in C potete usare la chiamata ioctl(ethfd, SIOCGIFHWADDR, &ifreq). L'altra cosa di cui si può aver bisogno è una riga options che indichi quali opzioni devono essere usate con un particolare modulo (o alias di modulo). Continuando con l'esempio di prima, se si usa solamente la riga alias con nessuna riga options, il kernel vi avviserà (si veda dmesg) che l'auto rilevamento di una scheda ISA non è una buona idea. Per eliminare questo problema, si aggiunga un'altra riga che indica al modulo a quale indirizzo I/O base è collocata la scheda, ad esempio perl'indirizzo esadecimale 0x280 si usi options smc-ultra io=0x280 La maggior parte dei moduli ISA accettano parametri come io=0x340 e irq=12 sulla riga di comando di insmod. Fornire questi parametri è RICHIESTO o almeno CALDAMENTE CONSIGLIATO per evitare il rilevamento della scheda. Diversamente dai dispositivi PCI e EISA, non c'è alcun modo sicuro per fare l'auto rilevamento della maggior parte dei dispositivi ISA e quindi lo si dovrebbe evitare quando si usa un driver come modulo. Un elenco di tutte le opzioni che ciascun modulo accetta può essere reperita nel file: /usr/src/linux/Documentation/networking/net-modules.txt Si raccomanda la sua lettura per scoprire quali opzioni si possano usare con la propria scheda. Si noti che alcuni moduli supportano un elenco di valori separati da virgola. Solitamente questo è il caso di moduli che sono in grado di gestire più dispositivi con un unica copia del modulo, come tutti i driver basati su 8390 e il driver PLIP. Per esempio: ______________________________________________________________________ options 3c503 io=0x280,0x300,0x330,0x350 xcvr=0,1,0,1 ______________________________________________________________________ Con la riga precedente si avrà un unico modulo che controlla quattro schede 3c503, con la scheda 2 e 4 che usano il transceiver esterno. Non si aggiungano spazi attorno a '=' o alle virgole. Si noti inoltre che un modulo occupato non può essere rimosso. Ciò significa che si dovrà usare ifconfig eth0 down (per disattivare la scheda Ethernet) prima di rimuovere il modulo. Il comando lsmod mostrerà quali moduli sono caricati e se sono in uso, mentre il comando rmmod può essere usato per rimuoverli. 8.4. Documentazione correlata La maggior parte dei queste informazioni provengono da messaggi che ho salvato dai gruppi comp.os.linux, che si sono dimostrati una insostituibile fonte di informazioni. Altre informazioni utili provengono da un gruppo di piccoli file di Donald stesso. Naturalmente, se si sta impostando una scheda Ethernet, allora sarà bene leggere il NET-2 Howto in modo che si possa realmente configurare il software che la userà. Inoltre, se ci si diverte a fare un po' l'hacker, si possono sempre trovare alcune informazioni addizionali nei file sorgente dei driver. Solitamente prima che cominci il codice c'è sempre un paragrafo o due che descrive i punti importanti. A quanti cercano informazioni che non sono in alcun modo specifiche su Linux (per esempio, cos'è 10BaseT, cos'è AUI, cosa fa un hub, ecc.) suggerisco caldamente di rivolgersi a newsgroup come comp.dcom.lans.ethernet e/o comp.sys.ibm.pc.hardware.networking. Gli archivi dei newsgroup come quelli a dejanews.com possono essere una insostituibile fonte di informazioni. Si possono prendere le FAQ da RTFM (che conserva tutte le FAQ dei newsgroup) all'URL seguente: Usenet FAQs Si può anche dare un'occhiata alla cosiddetta 'Ethernet-HomePage', che è all'URL seguente: Ethernet-HomePage 8.5. Liberatoria e copyright (in originale inglese) This document is not gospel. However, it is probably the most up to date info that you will be able to find. Nobody is responsible for what happens to your hardware but yourself. If your ethercard or any other hardware goes up in smoke (...nearly impossible!) we take no responsibility. ie. THE AUTHORS ARE NOT RESPONSIBLE FOR ANY DAMAGES INCURRED DUE TO ACTIONS TAKEN BASED ON THE INFORMATION INCLUDED IN THIS DOCUMENT. This document is Copyright (c) 1993-2000 by Paul Gortmaker. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this document under the conditions for verbatim copying, provided that this copyright notice is included exactly as in the original, and that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this document into another language, under the above conditions for modified versions. A hint to people considering doing a translation. First, translate the SGML source (available via FTP from the HowTo main site) so that you can then generate other output formats. Be sure to keep a copy of the original English SGML source that you translated from! When an updated HowTo is released, get the new SGML source for that version, and then a simple diff -u old.sgml new.sgml will show you exactly what has changed so that you can easily incorporate those changes into your translated SMGL source without having to re-read or re-translate everything. If you are intending to incorporate this document into a published work, please make contact (via e-mail) so that you can be supplied with the most up to date information available. In the past, out of date versions of the Linux HowTo documents have been published, which caused the developers undue grief from being plagued with questions that were already answered in the up to date versions. 8.6. Chiusura Agli albori dell'era Linux (circa dieci anni fa), non esistevano molti driver e nemmeno molti utenti, e io avevo il tempo di seguire lo sviluppo dei singoli driver, leggere dei problemi comuni nelle newsgroup, e rispondere alle domande e alle e-mail. Ma le cose sono molto diverse ora: ci sono moltissimi driver, ed un numero ancora più grande di utenti,e non esiste maniera in cui io possa restare al corrente di tutti i nuovi sviluppi! Qui è dove ho bisogno del vostro aiuto: se avete trovato un nuovo driver che non viene menzionato qui, se avete trovato qualche errore madornale o informazione non aggiornata, inviatemi una e-mail. È un grande documento ed è facile non accorgersi di qualcosa. Se avete inviato una mail per una modifica e questa non è stata inclusa nella versione successiva, non si esiti a scrivere ancora, in quanto potrebbe essersi persa tra la marea di SPAM e spazzatura che ricevo nella posta elettronica. Grazie! Paul Gortmaker, p_gortmaker@yahoo.com