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.
Ho sentito che è disponibile un driver aggiornato oppure un driver preliminare o alpha (sperimentale) per la mia scheda. Dove posso procurarmelo?
Il ``più nuovo dei nuovi'' driver può essere trovato sul sito FTP di
Donald: cesdis.gsfc.nasa.gov nell'area /pub/linux/. Qui
le cose cambiano abbastanza frequentemente perciò si cerchi bene. In
alternativa, per localizzare il driver che si sta cercando, può essere
più facile usare un browser WWW all'indirizzo:
(ci si guardi dai browser WWW che fanno il ``munge'' (NdT munge: trasformare in modo imperfetto le informazioni [dal Jargon Lexicon]) del sorgente sostituendo i TAB con spazi e così via -- se si è incerti usare ftp o almeno un URL FTP per scaricare).
Ora, se il driver è realmente un alpha o pre-alpha, lo si tratti come tale. In altre parole, non si reclami perché non si capisce cosa farne. Se non si riesce a capire come installarlo allora probabilmente non lo si dovrebbe provare. Anche se mette fuori uso la propria macchina, non si reclami. Si mandi invece un rapporto ben documentato del bug o, ancora meglio, una patch!
Si noti che alcuni dei driver sperimentali/alpha ``utilizzabili'' sono
stati inclusi nell'albero dei sorgenti del kernel standard. Una delle
prime cose che verranno chieste quando si esegue make config è
``Prompt for development and/or incomplete code/drivers'' (proposta
per il codice o driver in fase di sviluppo o incompleti). Si dovrà
rispondere ``Y'' (sì) per richiedere l'inclusione di un qualche driver
alpha/sperimentale.
Cosa è necessario fare affinché Linux possa utilizzare due schede Ethernet?
La risposta a questo quesito dipende se si sta/stanno usando il/i
driver come modulo caricabile o direttamente compilato nel kernel.
Adesso moltissime distribuzioni di Linux usano driver modulari. Ciò
evita di dover distribuire un mucchio di kernel ciascuno contenente
un insieme diverso di driver. Si usa invece un singolo kernel di base
e i driver necessari per un particolare sistema utente vengono
caricati una volta che l'avvio del sistema è arrivato al punto tale da
poter accedere ai file dei moduli dei driver (memorizzati di solito in
/lib/modules/).
Con il driver come modulo:
Nel caso di driver PCI, in genere il
modulo rileva automaticamente tutte le schede installate di quello
specifico modello. Comunque il rilevamento di una scheda non è una
operazione sicura per schede ISA, perciò di solito è necessario
fornire l'indirizzo base di I/O della scheda affinché il modulo sappia
dove guardare. Questa informazione è memorizzata nel file
/etc/conf.modules.
Come esempio si consideri un utente che ha due schede ISA
NE2000, una a 0x300 ed una a 0x240 e le righe da mettere nel
file /etc/conf.modules:
alias eth0 ne
alias eth1 ne
options ne io=0x240,0x300
Come agisce: se l'amministratore (o il kernel) fa un modprobe
eth0 oppure un modprobe eth1 allora dovrebbe essere caricato il
driver ne.o sia per eth0 che per eth1. Inoltre quando è
caricato il modulo ne.o, dovrebbe esserlo con le opzioni
io=0x240,0x300 cosicché il driver sa dove cercare le schede. Si
noti che 0x è importante, cose del tipo 300h, comunemente
usate nel mondo DOS, non funzionano. Cambiando l'ordine di 0x240
e 0x300 si cambierà quale scheda fisica finirà in eth0 e
quale in eth1.
Per gestire più schede, molti driver modulari ISA possono accettare
diversi valori di I/O separati da virgole, come in questo esempio.
Comunque, alcuni driver (più vecchi?), come il modulo 3c501.o,
attualmente sono in grado di gestire solo una scheda per modulo
caricato. In questo caso si può caricare il modulo due volte per far
sì che entrambe le schede siano rilevate. Il file
/etc/conf.modules dovrebbe presentarsi così:
alias eth0 3c501
alias eth1 3c501
options eth0 -o 3c501-0 io=0x280 irq=5
options eth1 -o 3c501-1 io=0x300 irq=7
In questo esempio l'opzione -o è stata usata per dare a ogni
istanza del modulo un nome univoco, poiché non è possibile caricare
due moduli con lo stesso nome. È anche usata l'opzione irq= per
specificare la configurazione IRQ hardware della scheda (questo metodo
può essere usato anche con moduli che accettano valori di I/O separati
da virgole, ma è meno efficiente poiché il modulo finisce per essere
caricato due volte anche se non sarebbe realmente necessario).
Come esempio finale, si consideri un utente con una scheda 3c503 a
0x350 e una SMC Elite16 (wd8013) a 0x280. Avranno:
alias eth0 wd
alias eth1 3c503
options wd io=0x280
options 3c503 io=0x350
Per le schede PCI, tipicamente sono necessarie solamente le righe
alias per correlare le interfacce ethN con l'appropriato
nome del driver, poiché l'I/O base di una scheda PCI può essere
rilevato in modo sicuro.
I moduli disponibili sono tipicamente memorizzati in
/lib/modules/`uname -r`/net dove il comando uname -r
fornisce la versione del kernel (es. 2.0.34). Si può guardare là per
vedere quale corrisponde alla propria scheda. Una volta che si hanno
le impostazioni corrette nel proprio file conf.modules, si può
collaudare il tutto con:
modprobe ethN
dmesg | tail
dove `N' è il numero dell'interfaccia Ethernet che si sta collaudando.
Con il driver compilato nel kernel: Se si ha il driver compilato nel kernel, allora tutto quel che serve per usare più schede Ethernet lo si ha già. Comunque si noti che al momento, per default, solo una scheda Ethernet è rilevata automaticamente. Ciò aiuta a evitare possibili blocchi all'avvio causati dal rilievo di schede ``ombrose''.
(Nota: dagli ultimi kernel 2.1.x, i rilievi al boot sono stati separati in sicuri ed insicuri, in modo che tutti quelli sicuri (es. PCI e EISA) trovino automaticamente tutte le loro schede. Nei sistemi con più di una scheda Ethernet e almeno una scheda ISA, sarà ancora necessario fare una delle cose che seguono.)
Ci sono due modi per abilitare l'auto-rilevamento della seconda (e la
terza, e...) scheda. Il metodo più semplice è di passare al momento
dell'avvio, degli argomenti al kernel, solitamente usando LILO. Il
rilevamento della seconda scheda può essere ottenuto con un semplice
argomento di boot come ether=0,0,eth1. In questo caso eth0
e eth1 saranno assegnate nell'ordine in cui sono rilevate le
schede al boot. Diciamo che si vuole che la scheda a 0x300 sia
eth0 e quella a 0x280 sia eth1, allora si potrebbe
usare
LILO: linux ether=5,0x300,eth0 ether=15,0x280,eth1
Il comando ether= accetta più della terna IRQ, I/O e nome
mostrata sopra. Si veda la sezione
Passare argomenti Ethernet... per la sintassi completa, i parametri specifici
delle schede e dritte su LILO.
Questi argomenti di boot possono essere resi permanenti cosicché non
si debba reinserirli ogni volta. Si veda l'opzione di configurazione
di LILO append nel manuale di LILO.
Il secondo metodo (non raccomandato) è di modificare il file
Space.c e sostituire la voce 0xffe0 per l'indirizzo I/O con
uno zero. La voce 0xffe0 dice di non cercare quel dispositivo --
rimpiazzandola con uno zero si abiliterà l'autorilevamento di quel
dispositivo.
Si noti che, se si intende usare Linux come gateway tra due reti, si dovrà ricompilare un kernel abilitando l'IP forwarding (inoltro degli IP). Solitamente usare un vecchio AT/286 con un software del tipo ``kbridge'' è una soluzione migliore.
Se si sta leggendo questa cosa mentre si naviga in rete, si potrebbe guardare il mini-howto che Donald ha nel suo sito WWW. Si veda Multiple Ethercards.
ether= non è servito a niente. Perché?
Come descritto sopra, il comando ether= funziona solo per
driver compilati nel kernel. Adesso molte distribuzioni usano i
driver in forma modulare, perciò il comando ether= è usato ancora
raramente (certa documentazione più vecchia non è ancora stata
aggiornata per riportare questo cambiamento). Se si vogliono adoperare
le opzioni per un driver Ethernet modulare si devono fare
modifiche al file /etc/conf.modules.
Se si sta usando un driver compilato nel kernel e si è aggiunto un
comando ether= al proprio file di configurazione LILO, si noti
che esso non avrà effetto fino a che non si riesegue lilo per
eseguire il file di configurazione aggiornato.
Problema: Una scheda clone PCI NE2000 non è rilevata all'avvio usando una versione del kernel v2.0.x.
Causa:
Il driver ne.c, fino alla versione del kernel v2.0.30, conosce
solo il numero identificativo PCI delle schede clone basate su RealTek
8029. Da allora, molti altri hanno distribuito cloni PCI NE2000 con
diversi numeri identificativi PCI, perciò il driver non li rileva.
Soluzione: La soluzione più facile consiste nell'aggiornare il kernel di Linux alla versione v2.0.31 (o più recente). Essa è a conoscenza dei numeri identificativi di circa cinque diversi chip PCI NE2000 e li rileva automaticamente all'avvio o nella fase di caricamento del modulo. Se si aggiorna alla versione 2.0.34 (o più recente) esiste un driver specifico NE2000 solo PCI che è leggermente più piccolo e più efficiente del driver originario ISA/PCI.
Problema: Una scheda clone PCI NE2000 si presenta come una ne1000 (scheda a 8 bit!) all'avvio o quando si carica il modulo ne.o per la versione v2.0.x, perciò non funziona.
Causa: Alcuni cloni PCI non implementano l'accesso byte wide (perciò non sono realmente compatibili NE2000 al 100%). Ciò fa pensare al sistema che siano schede NE1000.
Soluzione: È necessario aggiornare il kernel alla versione v2.0.31 (o più recente) come descritto sopra. Adesso il driver controlla che non si verifichi questo problema hardware.
Problema: Una scheda PCI NE2000 ha prestazioni orribili, anche se si riduce la dimensione della finestra come descritto nella sezione Suggerimenti per le prestazioni.
Causa: Le specifiche per il chip 8390 originale, progettato e commercializzato più di dieci anni fa, osservavano che per ottenere la massima affidabilità, era necessaria una lettura fittizia dal chip prima di ogni operazione di scrittura. Il driver ha i mezzi per farlo ma è stato disabilitato per default sin dai tempi dei kernel v1.2. Un utente ha riferito che riabilitare questa 'mis-feature' ha migliorato le prestazioni ottenute con un clone economico PCI NE2000.
Soluzione:
Visto che questa soluzione è stata riportata da una sola persona, non
ci si illuda troppo. La riabilitazione della
lettura prima della scrittura si ottiene semplicemente modificando il
file del driver in linux/drivers/net/, togliendo il commento
alla riga contenente NE_RW_BUGFIX e poi ricompilando il kernel o
il modulo come al solito. Se funziona si invii una e-mail che descrive la
differenza di prestazioni e il tipo di scheda/chip che si possiede
(la stessa cosa può essere fatta anche per il driver ne2k-pci.c).
Problema:
Il driver ne2k-pci.c, con una scheda PCI NE2000, riporta messaggi
di errore del tipo timeout waiting for Tx RDC e non funziona
bene.
Causa: La propria scheda e/o il collegamento tra la scheda e il bus PCI non può gestire l'ottimizzazione I/O a long word usata in questo driver.
Soluzione:
Prima di tutto, si controllino le impostazioni disponibili nel
BIOS/CMOS setup per vedere se alcune di quelle correlate alla
temporizzazione del bus PCI, sono troppo stringenti per ottenere
operazioni affidabili. Altrimenti, l'uso del driver ISA/PCI ne.c
(o la rimozione di #define USE_LONGIO dal driver ne2k-pci.c)
dovrebbe permettere di usare la scheda.
Problema: Una scheda ISA Plug and Play NE2000 (per esempio RealTek 8019) non è rilevata.
Causa: Le specifiche originarie NE2000 (e perciò il driver per Linux NE2000) non hanno il supporto per il Plug and Play.
Soluzione: Si usi il disco di configurazione DOS fornito con la
scheda per disabilitare PnP e per assegnare la scheda ad uno specifico
indirizzo di I/O e IRQ. Si aggiunga una riga a
/etc/conf.modules del tipo options ne io=0xNNN dove
0xNNN è l'indirizzo di I/O in formato esadecimale a cui la scheda
è stata assegnata (ciò assume che si stia usando un driver modulare;
se non è così si usi all'avvio un argomento ether=0,0xNNN,eth0).
Può accadere anche che si debba entrare nel BIOS/CMOS setup e
contrassegnare l'IRQ come Legacy-ISA al posto di PnP. In alternativa,
se è necessario lasciare PnP abilitato per la compatibilità con
qualche altro sistema operativo, si consideri il pacchetto
isapnptools. Si provi man isapnp per capire se è già
installato nel proprio sistema. Se non lo è, si dia un'occhiata al
seguente URL:
Problema: Un driver NE*000 riporta `not found (no reset ack)' durante il rilevamento all'avvio.
Causa: Ciò è collegato alla modifica vista in precedenza. Dopo la verifica iniziale che un 8390 è all'indirizzo di I/O rilevato, si effettua la riinizializzazione (reset). Quando la scheda ha completato tale operazione, si suppone dichiari (acknowlodge) che è completata. La propria scheda non lo fa e così il driver assume che nessuna scheda NE sia presente.
Soluzione: Si può dire al driver che si possiede una scheda
scadente specificando al momento dell'avvio il valore esadecimale
0xbad, solitamente non usato, per mem_end (NdT: si noti che
``bad'' significa letteralmente ``cattivo, brutto, scarso, ecc.'').
Quando si usa 0xbad, si deve anche fornire un I/O base
diverso da zero per la scheda. Per esempio, una scheda a 0x340
che non dichiara il completamento del reset dovrebbe usare qualcosa
del tipo:
LILO: linux ether=0,0x340,0,0xbad,eth0
bad=0xbad
proprio come si fornisce l'indirizzo di I/O.
Problema: Una scheda NE*000 blocca la macchina al primo accesso alla rete.
Causa: Questo problema è stato riportato per kernel a partire dalla versione 1.1.57 fino alla corrente. Sembra confinato a poche schede clone configurabili via software. Apparentemente sie aspettano di essere inizializzate in qualche modo speciale.
Soluzione: Diverse persone hanno riferito che l'esecuzione del programma DOS di configurazione software e/o l'uso del driver per DOS forniti con la scheda prima di fare il boot ``a caldo'' di Linux (cioé usando loadlin o con il ``saluto a tre dita'' (CTRL-ALT-CANC)) consente alla scheda di funzionare. Ciò indicherebbe che queste schede necessitano di essere inizializzate in un modo particolare, leggermente diverso da ciò che fa l'attuale driver per Linux.
Problema:
Una scheda Ethernet NE*000 a 0x360 non viene rilevata.
Causa: La propria scheda ha uno spazio degli indirizzi di I/O
ampio 0x20, il che la fa entrare in collisione con la porta
parallela a 0x378. Altri dispositivi che possono essere lì sono
il secondo controller del floppy (se in dotazione) a 0x370 e il
controller secondario IDE a 0x376--0x377. Se la/le porta/e sono
già assegnate ad un altro driver, il kernel non permette che avvenga
il rilevamento.
Soluzione: Si sposti la propria scheda ad un indirizzo del tipo
0x280, 0x340, 0x320 o si compili senza il supporto per la
stampante su porta parallela.
Problema: La rete ``scompare'' ogniqualvolta si stampa qualcosa (NE2000).
Causa: Il problema è lo stesso visto sopra, ma si ha un kernel più vecchio che non verifica la sovrapposizione delle regioni di I/O. Si usi la stessa soluzione vista prima e ancora meglio ci si procuri un nuovo kernel.
Problema: NE*000 ethercard probe at 0xNNN: 00 00 C5 ... not found. (invalid signature yy zz)
Causa: Prima di tutto, si ha una scheda NE1000 o NE2000
all'indirizzo 0xNNN? Se sì, l'indirizzo hardware riportato ha l'aria
di essere uno valido? Se sì, allora si possiede un clone NE*000
disgraziato. Si suppone che tutti i cloni NE*000 abbiano il valore
ox57 nei byte 14 e 15 della PROM SA sulla scheda. La propria
scheda non ce l'ha -- essa ha invece 'yy zz'.
Soluzione:
Ci sono due modi di aggirare l'ostacolo. Il più facile consiste
nell'usare un valore di mem_end 0xbad come descritto sopra per il
problema `no reset ack'. Ciò consentirà di bypassare il controllo
della firma, sempre che si fornisca anche un valore I/O base diverso
da zero. Questa soluzione non richiede di ricompilare il kernel.
Il secondo metodo (per hacker) comporta la modifica delle stesso
driver e la ricompilazione del proprio kernel (o modulo). Il driver
(usr/src/linux/drivers/net/ne.c) contiene un elenco ``Hall of Shame''
(Ndt: gioco di parole con ``Hall of Fame''; ``fame''= famoso,
``shame''=vergogna, disonore) pressappoco alla riga 42. Questo elenco è
usato per rilevare cloni disgraziati. Per esempio, le schede DFI usano
``DFI'' nei primi 3 byte della PROM al posto di usare 0x57 nei byte
14 e 15 (come dovrebbero fare).
Problema: La macchina si blocca durante l'avvio giusto dopo il messaggio `8390...' oppure `WD....'. La rimozione della NE2000 risolve il problema.
Soluzione:
Si cambi l'indirizzo base della propria NE2000 con qualcosa del tipo
0x340. In alternativa si può usare l'argomento di boot
``reserve='' in combinazione con l'argomento ``ether='' per tutelare
la scheda da rilievi di altri driver di dispositivi.
Causa: Il proprio clone NE2000 non è un clone abbastanza buono. Una NE2000 effettiva è un abisso senza fondo che intrappola ogni driver che stia facendo l'autorilevamento nel suo spazio. Spostare la NE2000 ad un indirizzo meno popolare la porta fuori dalla portata di altri rilievi automatici, consentendo alla macchina di avviarsi.
Problema: La macchina si blocca all'avvio durante il rilevamento SCSI.
Causa: È lo stesso problema visto precedentemente, si cambi l'indirizzo della scheda Ethernet o si usino gli argomenti di boot reserve/ether.
Problema: La macchina si blocca all'avvio durante il rilevamento della scheda sonora.
Causa: No, in realtà ciò avviene durante il rilevamento SCSI ``silenzioso'' ed è lo stesso problema visto precedentemente.
Problema: NE2000 non rilevata all'avvio -- nessun tipo di messaggio.
Soluzione: Non esiste una ``soluzione magica'' visto che possono essere parecchie le cause per cui non è stata rilevata. Il seguente elenco dovrebbe aiutare a risolvere i possibili problemi.
1) Si compili un nuovo kernel che includa solo i driver dei
dispositivi di cui si ha bisogno. Si verifichi che si stia davvero
avviando il kernel nuovo. Dimenticare di eseguire lilo, eccetera può
portare ad avviare quello vecchio (si guardi attentamente l'ora e la
data di compilazione riportati all'avvio). Suona ovvio, ma l'abbiamo
fatto tutti in passato. Ci si assicuri che il driver sia
effettivamente incluso nel nuovo kernel cercando nel file
System.map cose tipo ne_probe.
2) Si guardino attentamente i messaggi all'avvio. Davvero non accenna
mai al fatto che sta facendo un rilevamento ne2k, per esempio
`NE*000 probe at 0xNNN: not found (blah blah)' o fallisce proprio
silenziosamente? C'è una grossa differenza.
Si usi dmesg|more per rivedere i messaggi di avvio dopo aver fatto
il login o si digiti Shift-PgUp per scorrere il contenuto dello
schermo dopo che l'avvio si è completato e appare il prompt del login.
3) Dopo l'avvio si esegua un cat /proc/ioports e si verifichi
che l'intero spazio di I/O richiesto dalla scheda sia libero. Se si
parte da 0x300, il driver n2ek richiederà 0x300-0x31f. Se
un qualsiasi altro driver di dispositivo ha occupato anche solo una
porta da qualche parte in quell'intervallo, il rilevamento non avrà
luogo a quell'indirizzo e continuerà silenziosamente al prossimo degli
indirizzi rilevati. Un caso frequente è avere il driver lp che riserva
0x378 o il secondo canale IDE che riserva 0x376, il che
impedisce al driver ne il rilevamento in 0x360-0x380.
4) Allo stesso modo come sopra per cat /proc/interrupts. Ci
si assicuri che nessun altro dispositivo abbia occupato l'interrupt
per il quale è stata impostata la scheda. In questo caso, il
rilevamento avviene e il driver Ethernet protesta rumorosamente
all'avvio perché non riesce a ottenere la linea IRQ desiderata.
5) Se si è ancora perplessi del fallimento silenzioso del driver,
allora lo si modifichi aggiungendo alcuni printk() al rilevamento.
Per esempio con il ne2k si potrebbero aggiungere/rimuovere righe
(contrassegnate rispettivamente con un '+' o '-') in
linux/drivers/net/ne.c tipo:
int reg0 = inb_p(ioaddr);
+ printk("NE2k probe - now checking %x\n",ioaddr);
- if (reg0 == 0xFF)
+ if (reg0 == 0xFF) {
+ printk("NE2k probe - got 0xFF (vacant I/O port)\n");
return ENODEV;
+ }
Perciò esso produrrà messaggi di output per ogni indirizzo di porta che esamina e si potrà capire se l'indirizzo della propria scheda è stato o no rilevato.
6) Ci si può anche procurare il diagnostico ne2k nel sito ftp di Don
(pure citato nell'howto) e vedere se è in grado di rilevare la propria
scheda dopo che si è avviato Linux. Si usi l'opzione `-p 0xNNN'
per dirgli dove cercare la scheda (l'indirizzo di default è 0x300
e non va a guardare da nessun'altra parte a differenza del rilevamento
all'avvio). L'output risultante quando trova una scheda sarà qualcosa
del tipo:
Checking the ethercard at 0x300. Register 0x0d (0x30d) is 00 Passed initial NE2000 probe, value 00. 8390 registers: 0a 00 00 00 63 00 00 00 01 00 30 01 00 00 00 00 SA PROM 0: 00 00 00 00 c0 c0 b0 b0 05 05 65 65 05 05 20 20 SA PROM 0x10: 00 00 07 07 0d 0d 01 01 14 14 02 02 57 57 57 57 NE2000 found at 0x300, using start page 0x40 and end page 0x80.
I propri valori register e PROM saranno probabilmente diversi. Si noti
che tutti i valori PROM sono duplicati per una scheda a 16 bit,
l'indirizzo Ethernet (00:00:c0:b0:05:65) appare nella prima riga e la
firma ripetuta 0x57 appare alla fine della PROM.
L'output risultante quando non c'è nessuna scheda installata a
0x300 sarà qualcosa del tipo:
Checking the ethercard at 0x300. Register 0x0d (0x30d) is ff Failed initial NE2000 probe, value ff. 8390 registers: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff SA PROM 0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff SA PROM 0x10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Invalid signature found, wordlength 2.
I valori 0xff si presentano poiché quello è il valore restituito
quando si legge una porta di I/O libera. Si possono vedere
dei valori diversi da 0xff anche se si ha qualche altro tipo di
hardware nella regione rilevata.
7) Si provi a fare un warm boot di Linux da un dischetto di avvio per DOS (attraverso loadlin) dopo aver eseguito il driver per DOS o il programma di configurazione forniti. Può essere che faccia una qualche `magia' extra (cioé non standard) per inizializzare la scheda.
8) Si provi il packet driver di Russ Nelson ne2000.com per vedere se almeno questo riesce a rilevare la propria scheda -- se no, allora le cose non vanno bene. Esempio:
A:> ne2000 0x60 10 0x300
Gli argomenti sono: il vettore degli interrupt software, l'IRQ hardware e l'I/O base. Lo si può trovare in un qualsiasi archivio msdos nel file pktdrv11.zip. La versione attuale può essere più recente della 11.
Problema: Si ottengono messaggi tipo il seguente:
eth0: bogus packet size: 65531, status=0xff, nxpg=0xff
Causa: C'è un problema di memoria condivisa.
Soluzione: La causa più comune è dovuta a macchine PCI che non
sono configurate per mappare dispositivi nella memoria ISA. Perciò si
finisce per leggere la RAM del PC (tutti valori 0xff) invece
della RAM della scheda che contiene i dati provenienti dal pacchetto
ricevuto.
Altri tipici problemi facili da risolvere sono: i conflitti di scheda, avere la cache o la ``shadow ROM'' abilitata per quella regione o avere il proprio bus ISA che va ad una velocità superiore agli 8 MHz. Si trovano anche un numero sorprendente di guasti di memoria sulle schede Ethernet, perciò si esegua un programma di diagnostica nel caso in cui se ne possieda uno per la propria scheda.
Problema: La scheda SMC EtherEZ non funziona nella modalità a memoria non condivisa (PIO).
Causa: Le versioni più vecchie del driver Ultra supportavano la scheda solo nella modalità a memoria condivisa.
Soluzione: Il driver a partire dalla versione del kernel 2.0 supporta anche la modalità ad I/O programmato. Si aggiorni alla versione v2.0 o più recente.
Problema: Le vecchie wd8003 e/o le wd8013 configurabili con i ponticelli ottengono sempre l'IRQ sbagliato.
Causa: Le vecchie schede wd8003 e i cloni wd8013 configurabili con i ponticelli non possiedono la EEPROM dalla quale il driver può leggere l'impostazione dell'IRQ. Se il driver non è in grado di leggere l'IRQ allora esso prova a scoprirlo automaticamente con auto-IRQ. Se l'auto-IRQ restituisce il valore zero, il driver non fa altro che assegnare IRQ 5 a una scheda a 8 bit o IRQ 10 a una scheda a 16 bit.
Soluzione: Si eviti il codice di auto-IRQ e si comunichi al kernel qual è l'IRQ per il quale la scheda è stata configurata nel proprio file di configurazione dei moduli (o mediante una argomento di boot per i driver compilati nel kernel).
Problema: La scheda SMC Ultra è rilevata come wd8013, ma l'IRQ e l'indirizzo base della memoria condivisa sono sbagliati.
Causa: La scheda Ultra assomiglia molto a una wd8013 e se il driver Ultra non è presente nel kernel, il driver wd può scambiare la Ultra per una wd8013. Il rilevamento della Ultra avviene prima del rilevamento della wd perciò questo di solito non accade. La Ultra memorizza l'IRQ e l'indirizzo base della memoria in un modo diverso nella EPROM, da cui i valori contraffatti riportati.
Soluzione: Si ricompili il kernel con solo i driver di cui si ha bisogno. Se si ha una commistione di schede ultra e wd nella stessa macchina e si stanno usando i moduli allora si carichi per primo il modulo ultra.
Problema: La 3c503 si prende l'IRQ N, ma questo serve per una qualche altro dispositivo che ha bisogno dell'IRQ N (per esempio il driver del CDROM, il modem, ecc.). Si può risolvere la cosa senza ricompilare il kernel?
Soluzione:
Il driver della 3c503 cerca una linea di IRQ libera nell'ordine {5,
9/2, 3, 4} e dovrebbe scegliere una linea che nessuno sta usando. Il
driver decide quando la scheda è attivata con ifconfig.
Se si sta usando un driver modulare, si possono usare dei parametri del modulo per impostare molte cose, incluso il valore dell'IRQ.
Ciò che segue imposta l'IRQ9, la locazione base 0x300, <valori
ignorati> e if_port #1 (il transceiver esterno).
io=0x300 irq=9 xcvr=1
In alternativa, se il driver è compilato nel kernel, è possibile fissare gli stessi valori all'avvio passando i parametri attraverso LILO.
LILO: linux ether=9,0x300,0,1,eth0
Ciò che segue imposta l'IRQ3, la ricerca della locazione base, <valori ignorati> e il transceiver di default if_port #0 (il transceiver interno).
LILO: linux ether=3,0,0,0,eth0
Problema: 3c503: configured interrupt X invalid, will use autoIRQ.
Causa: La sheda 3c503 può usare solo uno degli IRQ{5, 2/9, 3, 4} (solo queste linee sono connesse alla scheda). Se si passa un valore di IRQ che non appartiene al precedente insieme, si otterrà il messaggio sopra indicato. Di solito non è necessario specificare un valore di interrupt per la 3c503. La 3c503 effettuerà l'autoIRQ quando viene usato ifconfig e sceglie uno degli IRQ{5, 2/9, 3, 4}.
Soluzione: Si usi uno degli IRQ validi elencati sopra oppure si abiliti l'autoIRQ ma senza specificare la linea IRQ in alcun modo.
Problema: I driver per la 3c503 forniti non utilizzano la porta AUI (thicknet). Come si può optare per essa al posto della porta thinnet di default?
Soluzione: La porta 3c503 AUI può essere selezionata al momento dell'avvio per i driver compilati nel kernel e all'inserzione del modulo per i driver modulari. La selezione avviene impostando ad 1 il bit meno significativo della variabile attualemente non usata dev->rmem_start, cosicché un parametro all'avvio tipo:
LILO: linux ether=0,0,0,1,eth0
dovrebbe funzionare per i driver compilati nel kernel.
Per specificare la porta AUI quando si carica il driver come modulo è
sufficiente aggiungere xcvr=1 alla riga delle opzioni del modulo
insieme con i propri valori di I/O e IRQ.
Per ottenere i migliori risultati (e il minimo rompimento) si
raccomanda di usare il programma (di solito DOS) fornito con la
propria scheda per disabilitare il meccanismo PnP e impostarla
definitivamente a un indirizzo di I/O e un IRQ. Ci si assicuri che
l'indirizzo di I/O che si utilizza sia rilevato all'avvio o, se si
usano i moduli, si fornisca l'indirizzo sotto forma di opzione
io= in /etc/conf.modules. Può darsi che si debba anche
entrare nel BIOS/CMOS setup e contrassegnare l'IRQ come Legacy-ISA al
posto di PnP (se il proprio computer ha questa opzione).
Si noti che non è necessario avere DOS installato per eseguire un programma di configurazione basato su DOS. Di solito è sufficiente avviare da un dischetto DOS ed eseguire i programmi dal dischetto fornito. Si può anche scaricare gratuitamente OpenDOS e FreeDOS.
Se si necessita, per la compatibilità con qualche altro sistema
operativo, che sia abilitato il PnP, allora con Linux si dovrà usare
il pacchetto isapnptools per configurare ogni volta la(e) scheda(e)
all'avvio. Ci si dovrà ancora assicurare che l'indirizzo di I/O
scelto per la scheda sia rilevato dal driver o fornito sotto forma di
opzione io=.
Di solito la causa di ciò e che si sta usando un kernel che non include il supporto per la propria particolare scheda. Per un kernel modulare ciò significa che non si è richiesto di caricare il modulo di cui si ha bisogno o che è necessario specificare al modulo un indirizzo come opzione.
Se si sta usando un kernel basato sui moduli per esempio quelli
installati dalla maggior parte delle distribuzioni Linux, allora si
provi a usare l'utilità di configurazione della distribuzione, per
selezionare il modulo adatto alla propria scheda. Per le schede ISA è
una buona idea determinare l'indirizzo di I/O della scheda e
aggiungerlo come opzione (per esempio io=0x340) se l'utilità di
configurazione ne richiede qualcuna. Se non c'è alcuna utilità di
configurazione allora si dovrà aggiungere il nome corretto del modulo
(e le opzioni) al file /etc/conf.modules -- si veda man
modprobe per maggiori dettagli.
Se si sta usando un kernel precompilato che è parte della distribuzione, allora si controlli la documentazione per vedere che kernel si è installato e se è stato compilato con il supporto per la propria scheda. Se non lo è stato, allora o si prova a procurarsene uno con il supporto per la propria scheda, oppure se ne compili uno su misura.
Solitamente è una buona cosa compilare il proprio kernel con solo i driver di cui si ha bisogno, poiché questa cosa non solo riduce la dimensione del kernel (risparmiando memoria RAM preziosa per le applicazioni!) ma riduce anche il numero di rilevamenti che possono incasinare hardware ``sensibile''. Compilare un kernel non è così complicato come sembra. Si deve solo rispondere sì o no a una serie di domande su quali driver si vogliono, e lui fa tutto il resto.
Un'altra causa importante è l'avere un altro dispositivo che usa una
parte dello spazio di I/O di cui ha bisogno la propria scheda. Molte
schede usano uno spazio di I/O di 16 o 32 byte. Se la propria scheda
è impostata a 0x300 ed usa 32 byte. allora il driver chiederà la
regione 0x300-0x31f. Se un qualsiasi altro dispositivo ha
registrato anche solo una porta da qualche parte in quell'intervallo,
il rilevamento non avrà luogo a quell'indirizzo e il driver continuerà
silenziosamente con il prossimo indirizzo fra quelli che prova.
Quindi, dopo il boot, si faccia cat /proc/ioports per
verificare che l'intero spazio d'I/O che la scheda richiede è libero.
Un altro problema è l'avere la propria scheda impostata con i
ponticelli a un indirizzo di I/O che non viene controllato di
default. L'elenco di tali indirizzi per ogni driver si trova
facilmente proprio dopo i commenti iniziali nel sorgente del
driver. Anche se l'impostazione I/O della propria scheda non è
nell'elenco degli indirizzi controllati, la si può fornire al boot
(per i driver compilati nel kernel) con il comando ether=
come descritto in
Passare argomenti Ethernet.... I driver modulari possono fare uso dell'opzione
io= in /etc/conf.modules per specificare un
indirizzo che non è controllato di default.
ifconfig mostra un indirizzo di I/O sbagliato per la scheda
No, non lo fa. Lo si sta solamente interpretando in modo scorretto.
Questo non è un bug e i numeri riportati sono corretti.
Capita solo che in alcune schede basate su 8390 (wd80x3,
smc-ultra, ecc.) il chip 8390 in realtà risiede a un offset
rispetto alla prima porta di I/O assegnata. Questo è il valore
salvato in dev->base_addr ed è ciò che ifconfig riporta.
Se si vuole vedere l'intero intervallo di porte che la propria
scheda usa, allora si provi cat /proc/ioports che darà i
numeri che ci si aspetta.
Alcuni BIOS PCI potrebbero non abilitare tutte le schede PCI all'accensione, specialmente se è attivata l'opzione ``PNP OS'' del BIOS. Questa mis-feature è per supportare la versione corrente di Window che ancora usa alcuni driver in real mode. Si disabiliti questa opzione oppure si provi ad aggiornare a un driver più recente che abbia il codice per abilitare una scheda disabilitata.
0xffff)
Questa cosa solitamente si presenta come una serie di letture di
valori 0xffff. Nessun tipo di scheda a memoria condivisa
potrà funzionare in una macchina PCI finché non si configuri
correttamente il BIOS PCI. Lo si deve impostare per permettere
l'accesso in memoria condivisa dal bus ISA alla regione di memoria che
la propria scheda cerca di usare. Se non si capisce quali impostazioni
sono appropriate allora si chieda al proprio fornitore o all'esperto
di computer locale. Per i BIOS AMI, solitamente c'è una sezione ``Plug
and Play'' dove ci dovrebbero essere delle impostazioni tipo ``ISA
Shared Memory Size'' e ``ISA Shared Memory Base''. Per le schede come
la wd8013 e la SMC Ultra, si modifichi la dimensione predefinita da
``Disabled'' a 16kB e si metta l'indirizzo della memoria condivisa
della propria scheda nell'altra impostazione.
Si faccia un cat /proc/interrupts. Il totale corrente del
numero di eventi di interrupt generati dalla propria scheda sarà
nell'elenco dato dal comando precedente. Se è a zero e/o non
aumenta quando si prova a usare la scheda allora probabilmente
c'è un conflitto di interrupt con un altro dispositivo installato
nel computer (indifferentemente dal fatto che l'altro dispositivo
abbia o meno un driver installato/disponibile). Si cambi l'IRQ di
uno dei due dispositivi a un IRQ libero.
Werner Almesberger sta lavorando al supporto ATM per Linux. Sta lavorando con la scheda ENI155p della Efficient Networks ENI155p ( Efficient Networks) e la scheda ZN1221 della Zeitnet ( Zeitnet).
Werner sostiene che il driver per la ENI155p è abbastanza stabile, mentre quello per la ZN1221 non è ancora finito.
Si veda lo stato attuale dei driver al seguente URL:
C'è un qualche supporto per gigabyte Ethernet sotto Linux?
Sì, attualmente ce ne sono almeno due. Un driver per l'adattatore Gigabit Ethernet PCI G-NIC della Packet Engines è disponibile nei kernel v2.0 e v2.2. Per maggiori dettagli, supporto e driver aggiornati, si veda:
http://cesdis.gsfc.nasa.gov/linux/drivers/yellowfin.html
Il driver acenic.c disponibile nei kernel v2.2 può essere usato
con la scheda Gigabit Ethernet AceNIC della Alteon e con altre
schede basate su Tigon come la 3c985 della 3Com. Il driver
dovrebbe funzionare anche con la GA620 della NetGear, ma la cosa
non è ancora stata verificata.
C'è il supporto FDDI per Linux?
Sì. Larry Stefani ha scritto un driver per v2.0 usando le schede DEFEA (FDDI EISA) e DEFPA (FDDI PCI) della Digital. Era stato incluso nel kernel v2.0.24. Attualmente non sono supportate altre schede.
Il Full Duplex mi darà i 20MBps? Linux lo supporta?
Cameron Spitzer ha scritto quanto segue sulle schede 10Base-T full duplex: «Se se ne connette una a uno switched hub full duplex e il proprio sistema è abbastanza veloce e non sta facendo molto altro, può mantenere la connessione occupata in entrambe le direzioni. Non ci sono cose tipo 10BASE-2 o 10BASE-5 full duplex. Il full duplex funziona disabilitando il rilevamento delle collisione nell'adattatore. Questo è il motivo per cui non lo si può fare con un cavo coassiale; la LAN in questo modo non funzionerebbe. Il 10BASE-T (interfaccia RJ45) usa fili separati per la trasmissione e la ricezione così è possibile utlizzare entrambe le direzioni nello stesso momento. Lo switching hub si fa carico del problema delle collisioni. La frequenza dei segnali è 10Mbps.»
Quindi come si può vedere si sarà in grado di ricevere e trasmettere solo a 10Mbps e così non ci si aspetti un incremento delle prestazioni di un fattore 2. Che sia o meno supportato, la cosa dipende dalla scheda e forse anche dal driver. Alcune schede possono fare l'auto negoziazione, altre hanno bisogno del supporto da parte del driver e per altre ancora è necessario che l'utente selezioni un'opzione nella configurazione EEPROM della scheda. Comunque solamente utilizzatori seri/pesanti noteranno la differenza tra le due modalità.
Se si spendono soldi in più su un computer multi processore (MP)
allora si comperi anche una buona scheda Ethernet. Per i kernel v2.0
non è veramente necessario, ma lo è sicuramente per quelli v2.2. La
maggior parte delle schede più vecchie non intelligenti
(per esempio progetti per bus ISA PIO e memoria condivisa) non furono mai
pensate considerando in alcun modo l'uso con macchina MP. La tendenza
attuale è di comperare una scheda intelligente di progettazione
moderna e assicurarsi che il driver sia stato scritto (o aggiornato)
per gestire le operazioni MP (le parole chiave sono ``progettazione
moderna'': le NE2000 PCI sono semplicemente un progetto di 10 anni fa
adattato a un bus moderno). La presenza del testo spin_lock nei
sorgenti del driver è un buona indicazione che il driver è stato
scritto per gestire le operazioni MP. Si veda sotto per i dettagli
completi su perché di dovrebbe acquistare una buona scheda per l'uso
MP (e cosa accade se non lo si fa).
Nei kernel v2.0, solo un processore alla volta era permesso ``in modalità kernel'' (ovvero poteva cambiare i dati del kernel e/o eseguire device driver). Quindi dal punto di vista della scheda (e del driver associato) non c'era niente di diverso rispetto ad operazioni uni-processore (UP) e le cose funzionavano come prima (questo era il modo più semplice di ottenere una versione MP di Linux funzionante: un unico grosso lock (blocco, semaforo) attorno a tutto il kernel permette l'accesso ad un solo processore alla volta. In questo modo si sa che non si avranno due processori che provano a cambiare la stessa cosa allo stesso tempo!).
Lo svantaggio nel permettere un solo processore alla volta in modalità kernel è che si ottengono prestazioni di tipo MP solamente se si eseguono programmi indipendenti e che fanno calcoli pesanti. Se i programmi fanno un sacco di input/output (I/O) come la lettura e la scrittura di dati su disco o attraverso la rete, allora tutti i processori tranne uno saranno in stallo in attesa che le loro richieste di I/O siano completate mentre l'unico processore in esecuzione in modalità kernel freneticamente prova a eseguire tutti i device driver per soddisfare le richieste di I/O. Il kernel diventa il collo di bottiglia e poiché c'è solo un processore in modalità kernel, le prestazioni di una macchina MP in presenza di I/O pesante, in questo caso detoriorano velocemente verso quelle di una macchina a singolo processore.
Poiché questa cosa è chiaramente inferiore al caso ideale (specialmente per server di file/WWW, router, ecc.) i kernel v2.2 hanno un lock più fine. Ciò significa che più di un processore alla volta può essere in modalità kernel. Invece di un unico grosso lock attorno all'intero kernel, ci sono un sacco di piccoli lock che proteggono i dati critici dall'essere manipolati da più di un processore alla volta, per esempio un processore può eseguire il driver della scheda di rete, mentre nello stesso momento un altro esegue il driver il disco.
Okay, con tutto questo bene in mente, ecco qui le insidie: il lock più
fine significa che si può avere un processore che prova a inviare
dati attraverso un driver Ethernet mentre un altro prova ad
accedere allo stesso driver/scheda per fare qualcos'altro (per
esempio ottenere le statiche della scheda per il comando cat
/proc/net/dev). Oops, le statistiche della propria scheda
sono state appena inviate attraverso il cavo, mentre invece si
volevano i dati per le proprie statistiche. Sì, si è un po'
confusa la scheda chiedendole di fare due (o più!) cose alla
volta ed è probabile che mandi in crash la propria macchina mentre
ci prova.
Quindi il driver che funzionava per UP non è più abbastanza buono: necessita di essere aggiornato con i lock che controllano l'accesso alla scheda cosicché i tre processi di ricezione, trasmissione e manipolazione dei dati di configurazione siano serializzati al grado necessario alla scheda per funzionare stabilmente. La parte strana qui è che un driver non ancora aggiornato con lock per operazioni MP stabili, sembrerà probabilmente funzionare su macchine MP in presenza di un leggero carico di rete, ma provocherà il crash della macchine o almeno esibirà uno strano comportamento quando due (o più!) processori proveranno a fare più di uno di questi tre processi nello stesso momento.
Un driver Ethernet aggiornato per MP richiederà (al minimo) un lock
attorno al driver che limiti l'accesso ai punti d'ingresso del
kernel nel driver in maniera ``uno alla volta, prego''. Con
questa cosa, le cose saranno serializzate cosicché l'hardware
sottostante dovrebbe essere trattato come se fosse usato in una
macchina UP, e quindi dovrebbe essere stabilee. Lo svantaggio è
che un unico lock attorno all'intero driver Ethernet ha le stesse
implicazioni negative sulle prestazioni dell'avere un unico grosso
lock attorno a tutto il kernel (ma su scala più piccola), ovvero
si può avere un solo processore alla volta che usa la scheda.
[Nota tecnica: L'impatto sulle prestazioni può anche
includere un incremento nelle latenze degli interrupt se i lock
che è necessario aggiungere sono del tipo irqsave e sono
tenuti per un lungo periodo di tempo.]
Possibili miglioramenti a questa situazione possono essere fatti in due modi. Si può provare a minimizzare il tempo tra quando si fa il lock e quando lo si rilascia, e/o si può implementare un lock più fine all'interno del driver (per esempio un lock attorno all'intero driver sarebbe eccessivo se invece fosse necessario solamente un lock o due per proteggere contro l'accesso simultaneo a una coppia di registri/impostazioni delicati della scheda).
Comunque, per le più vecchie schede non intelligenti che non sono mai state progettate pensando all'uso MP, nessuno di questi miglioramenti può essere realizzato. Peggio ancora le schede non intelligenti tipicamente richiedono che il processore sposti dati tra la scheda e la memoria del computer, cosicché nel caso peggiore il lock sarà mantenuto per tutto il tempo necessario per spostari ogni pacchetto da 1.5kB sul bus ISA.
Le più moderne schede intelligenti tipicamente spostano i dati direttamente da e nella memoria del computer senza nessun aiuto da parte di un processore. Questa è una grande vittoria, poiché il lock è mantenuto allora solo per il breve tempo che il processore impiega per dire alla scheda dove prendere/mettere nella memoria il prossimo pacchetto di dati. Inoltre le schede più moderne tendono meno a richiedere un grosso unico lock attorno all'intero driver.
Dalla versione v2.0, solo i driver 3c509, depca, de4x5, pcnet32 e tutti quelli 8390 (wd, smc-ultra, ne, 3c503, ecc.) sono stati resi ``indipendenti dall'architettura'' così da poter funzionare su sistemi basati su CPU DEC Alpha. Possono funzionare anche altri driver PCI aggiornati presenti nella pagina WWW di Donald poiché sono stati scritti appositamente indipendenti dall'architettura.
Si noti che le modifiche richieste per rendere un driver indipendente dall'architettura non sono così complicate. Si deve solo fare quanto segue:
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);
-sostituire tutte le chiamate memcpy() che hanno la memoria I/O
come sorgente o destinazione con le appropriate
memcpy_fromio() o memcpy_toio().
I dettagli sulla gestione degli accessi alla memoria in maniera
indipendente dall'architettura sono documentati nel file
linux/Documentation/IO-mapping.txt fornito con i kernel
recenti.
Per le informazioni più aggiornate sulla roba Sparc, si provi il seguente URL:
Si noti che qualche hardware Ethernet Sparc riceve il suo indirizzo
MAC dal computer ospite, e quindi ci si può ritrovare con più
interfacce allo stesso indirizzo MAC. Se si ha bisogno di mettere
più di una interfacia nella stessa rete, allora si usi l'opzione
hw di ifconfig per assegnare un indirizzo MAC univoco.
Le questioni riguardati il porting dei driver PCI su piattaforma Sparc sono simili a quelle citate sopra per la piattaforma AXP. Inoltre ci possono essere un po' di questione relative all'endian, poiché la Sparc è big endian mentre AXP e ix86 sono little endian.
Ci sono parecchie altre piattaforme hardware sulle quali può girare Linux, come Atari/Amiga (m68k). Come nel caso Sparc è meglio controllare nel sito ufficiale del port di Linux per quella piattaforma per vedere cosa attualmente è supportato (sono benvenuti link ai suddetti siti -- inviatemeli!)
Possono connettere assieme sistemi basati su 10/100BaseT (RJ45) senza un hub?
Senza altri dispositivi/marchingegni si possono collegare facilmente 2 macchine, ma non di più. Si veda Doppino intrecciato, che spiega come farlo. E no, non si può far su un hub semplicemente incrociando un po' di fili assieme e qualcos'altro. È praticamente impossibile gestire bene il segnale di collisione senza duplicare l'hub.
Ricevo un sacco di messaggi `SIOCSIFxxx: No such device' al boot, seguiti da un `SIOCADDRT: Network is unreachable'. Cosa c'è che non va?
Il proprio dispositivo Ethernet non è stato rilevato al boot o
all'inserzione del modulo e quando sono eseguiti ifconfig e
route non hanno nessun dispositivo con cui lavorare. Si usi
dmesg | more per rivedere i messaggi di boot e vedere se
c'è un qualche messaggio sul rilevamento della scheda Ethernet.
Ricevo `SIOCSFFLAGS: Try again' quando eseguo `ifconfig'. Eh?
Qualche altro dispositivo si è preso l'IRQ che la propria scheda Ethernet
prova ad usare e quindi questa non può usarlo. Non si deve
necessariamente riavviare per risolvere ciò, poiché alcuni
dispositivi si prendono l'IRQ solo quando ne hanno bisogno e poi
lo rilasciano quando hanno fatto. Esempi sono alcuni schede
sonore, porte seriali, driver per floppy disk, ecc. Si può
digiare cat /proc/interrupts per vedere quali interrupt
sono attualmente in uso. La maggior parte dei driver per
schede Ethernet per Linux si prendono l'IRQ solo quando sono
attivate per l'uso con `ifconfig'. Se si riesce a far sì che
l'altro dispositivo rilasci la linea IRQ richiesta allora si
dovrebbe essere in grado di `Try again' (riprovare) con ifconfig.
Quando eseguo ifconfig senza alcun argomento, mi dice che LINK è UNSPEC (invece di 10Mbs Ethernet) e dice anche che il mio indirizzo hardware è di tutti zeri.
Questo è perché si sta usando una versione del programma `ifconfig' più recente della versione del kernel. Questa nuova versione di ifconfig non è in grado di riportare queste proprietà quando usata con un kernel più vecchio. Si può o aggiornare il proprio kernel, tornare a una versione più vecchia di `ifconfig' oppure semplicemente ignorare la cosa. Il kernel conosce l'indirizzo hardware e non gli interessa se ifconfig non può leggerlo.
Si possono ricevere strane informazioni se il programma ifconfig
che si sta usando è molto più vecchio del proprio kernel.
Quando eseguo ifconfig senza alcun argomento, mi dice che ho un enorme numero di errori sia nei pacchetti ricevuti che trasmessi. Tutto sembra funzionare bene. Cosa c'è che non va?
Si guardi bene. Dice RX packets grande numero PAUSE
errors 0 PAUSE dropped 0 PAUSE overrun 0.
E la stessa cosa per la colonna TX. Quindi i grandi numeri
che si vedono sono il numero totale di pacchetti che la propria
macchina ha ricevuto e trasmesso. Se ancora si trova la cosa
confusa, si provi invece ad usare cat /proc/net/dev.
/dev/ per le schede EthernetHo /dev/eth0 come link (collegamento) a /dev/xxx. È giusto?
Contrariamente a ciò che si è sentito, i file in /dev/* non sono
utilizzati. Si può cancellare qualsiasi /dev/wd0,
/dev/ne0 e voce simile.
Dovrei disabilitare i trailer quando uso `ifconfig' con la mia scheda?
Non si possono disabilitare i trailer e nemmeno si dovrebbe volerlo fare. I `trailer' sono degli stratagemmi (hack) per evitare la copia dei dati negli strati di rete. L'idea era di usare un banale header di dimensione fissata `H', mettere le informazioni dell'header di dimensione variabile alla fine del pacchetto e allocare tutti gli `H' byte del pacchetto prima dell'inizio della pagina. Sebbene fosse una buona idea, in pratica ha mostrato di non funzionare bene. Se qualcuno suggerisce l'uso di `-trailers', si noti che è l'equivalente del sangue delle capre sacrificali. Non sarà niente per risolvere il problema, ma se il problema si risolve da solo allora qualcuno può affermare una profonda conoscenza delle arti magiche.
Come posso accedere a basso livello al dispositivo Ethernet in Linux, senza passare attraverso TCP/IP e company?
int s=socket(AF_INET,SOCK_PACKET,htons(ETH_P_ALL));
Questo consente di avere un socket che riceve qualsiasi tipo di
protocollo. Si facciano chiamate recvfrom() a questo socket e
lui riempirà sockaddr con il tipo di dispositivo nel campo
sa_family e il nome del dispositivo nell'array sa_data. Non so chi
abbia originariamente inventato SOCK_PACKET per Linux (c'è da
anni) ma è una cosa superba. Si può usare anche per inviare roba
grezza attraverso chiamate sendto(). Naturalmente per fare
entrambe le cose si deve avere l'accesso come root.