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.
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).
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.
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:
(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.
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.
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.
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.
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.
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
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.
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.
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, <valori
ignorati> e if_port #1 (il transceiver esterno).
io=0x300 irq=9 xcvr=1
In alternativa, se il driver è compilato nel kernel, è possibile fissare gli stessi valori all'avvio passando i parametri attraverso LILO.
LILO: linux ether=9,0x300,0,1,eth0
Ciò che segue imposta l'IRQ3, la ricerca della locazione base, <valori ignorati> e il transceiver di default if_port #0 (il transceiver interno).
LILO: linux ether=3,0,0,0,eth0
Problema: 3c503: configured interrupt X invalid, will use autoIRQ.
Causa: La sheda 3c503 può usare solo uno degli IRQ{5, 2/9, 3, 4} (solo queste linee sono connesse alla scheda). Se si passa un valore di IRQ che non 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.
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.
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.
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.
/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.
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.
unresolved symbol ei_open e non viene caricatoState 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.
ifconfig mostra un indirizzo di I/O sbagliato per la schedaNo, 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.
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.
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.
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:
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.
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.
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à.
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.
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:
jiffies per HZ/100
per tener conte del diverso valore di HZ che usa l'Alpha.
(timeout=2; diventa timeout=2*HZ/100;)
- int *mem_base = (int *)dev->mem_start; - mem_base[0] = 0xba5eba5e; + unsigned long mem_base = dev->mem_start; + writel(0xba5eba5e, mem_base);
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.
Per le informazioni più aggiornate sull'hardware Sparc, si visiti il seguente sito:
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.
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!)
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.
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.
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.
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.
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.
/dev/ per le schede EthernetHo /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.
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.