<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<TITLE>The Linux Modem-HOWTO: Risoluzione di problemi </TITLE>
<LINK HREF="Modem-HOWTO-17.html" REL=next>
<LINK HREF="Modem-HOWTO-15.html" REL=previous>
<LINK HREF="Modem-HOWTO.html#toc16" REL=contents>
</HEAD>
<BODY>
<A HREF="Modem-HOWTO-17.html">Avanti</A>
<A HREF="Modem-HOWTO-15.html">Indietro</A>
<A HREF="Modem-HOWTO.html#toc16">Indice</A>
<HR>
<H2><A NAME="trouble_shoot"></A> <A NAME="s16">16. Risoluzione di problemi </A> </H2>
<H2><A NAME="cant_find_modem"></A> <A NAME="ss16.1">16.1 Il mio modem è fisicamente al suo posto ma non può essere trovato </A>
</H2>
<P>I messaggi di errore potrebbero essere qualcosa del tipo "No modem detected" (nessun modem rilevato)
, "Modem non responding" (il modem non risponde), o (strano) "You are already online" (Sei già
collegato) (da minicom). Se avete installato un modem interno (con la porta seriale inclusa nel modem)
o ne state usando uno esterno e non sapete a che porta
seriale sia connesso il problema è cercare la porta seriale.
Vedere
<A HREF="#cant_find_port">La mia porta seriale è fisicamente presente ma non può essere trovata</A>.
Questa sezione riguarda come scoprire quale porta seriale ha un modem ad essa connesso.
<P>C'è un programma che cerca i modem sulle porte seriali comunemente usate chiamato
"wvdialconf". Digitate semplicemente "wvdialconf <un-nuovo-nome-file>".
Verrà creato il nuovo file come file di configurazione ma non avrete bisogno di
esso a meno che non andiate ad usare "wvdial" per telefonare.
Vedere
<A HREF="Modem-HOWTO-9.html#wvdial_">Cos'è wvdialconf ?</A>. Sfortunatamente, se il vostro modem è in
modalità "online data", wvdialconf visualizzerà "No modem detected". Vedere
<A HREF="#no_AT">Nessuna risposta ad AT</A>.
<P>
<P>Il vostro problema potrebbe
essere dovuto ad un winmodem (o simile) che non può essere usato con Linux.
Vedere
<A HREF="Modem-HOWTO-2.html#soft_modem">Evitare la maggior parte dei software modem</A>. Il programma "setserial"
potrebbe essere usato per identificare le porte seriali ma non rileverà se ci sono
modem collegati ad esse. Quindi è meglio provare ad usare prima "wvdialconf".
<P>Un altro modo di vedere se c'è un modem su una porta è lanciare "minicom" sulla porta
(dopo avere precedentemente impostato minicom sulla corretta porta seriale -- dovrete
salvare le impostazioni, quindi uscire da minicom e farlo ripartire).
Poi digitate "AT" e dovreste vedere OK (o 0 se
è impostato per restituire codici numerici di risultato ("digit result codes")).
I risultati potrebbero essere:
<UL>
<LI> Nessuna risposta. Vedere
<A HREF="#no_AT">Nessuna risposta ad AT</A></LI>
<LI> Se ci vogliono parecchi secondi per ottenere una risposta (incluso anche solo il cursore che
si sposta di una riga) allora vedere
<A HREF="#slow_">Estremamente lento: il testo appare sullo schermo lentamente e dopo lunghi ritardi</A></LI>
<LI> Alcuni strani caratteri appaiono, ma non in risposta ad AT. Questo con ogni probabilità significa
che il vostro modem è ancora connesso a qualcosa dall'altra parte della line telefonica che sta
inviando alcuni criptici pacchetti o simile.</LI>
</UL>
<P>
<H3><A NAME="no_AT"></A> Nessuna risposta ad AT </H3>
<P> Il modem dovrebbe inviarvi un "OK" in risposta al vostro "AT", che digitate al modem (usando
minicom o simile). Se non vedete "OK" (e in parecchi casi non vedete neppure "AT" che avete digitato)
il modem non sta rispondendo (dando per scontato che ci sia davvero un modem
verso la porta sulla quale state digitando).
<P>Una ragione per la quale un vero modem non risponde è che si trova in modo "online data" dove non
può accettare alcun comando AT. Potrebbe essere in uso con un altro processo. Se detto processo
è in esecuzione sulla porta, potreste vederlo digitando "ps -t ttyS2" o simile. Comunque il
processo che sta usando la porta seriale (dove si trova il modem) potrebbe essere in esecuzione
su di un terminale tipo /dev/ttyS1 e non sarà individuato usando il comando sopracitato.
<P>Potreste stare usando il modem ed improvvisamente siete stati bruscamente disconnessi (come ad
esempio "uccidendo" il processo con segnale 9). In quel caso il vostro modem non viene
reimpostato a modalità comandi dove può interagire con i comandi AT.
Ecco quindi il messaggio di minicom "You are already online, hangup first" (siete già in linea,
interrompete la comunicazione prima).
Bene, sembra che siate in linea ma potreste non essere collegati con nessuno attraverso la
linea telefonica, wvdial visualizzerà "modem not responding" (il modem non risponde) nella
medesima situazione.
<P>Per risolvere questo problema come soluzione estrema spegnete e riavviate il computer. Un altro
modo è inviare +++ al modem per dirgli di ritornare a modalità comandi dalla modalità in linea.
Da entrambe le parti della sequenza +++ deve esserci circa 1 secondo di ritardo (nulla inviato
durante il "guard time"). Questo potrebbe non funzionare se un altro processo sta usando il
modem visto che la sequenza +++ potrebbe essere attaccata ad altri caratteri inseriti prima o
dopo il +++ (durante il "guard time"). Ironicamente, anche se la linea del modem fosse inattiva,
inviandogli un inaspettato +++ probabilmente si darà il via ad uno scambio di pacchetti (o simile)
che violeranno il richiesto "guard time" così che +++ non fa quello che voi avreste voluto. +++ in
genere si trova nella stringa che viene chiamata "hangup string" (stringa di interruzione) così
se dite a minicom (o simile di interrompere la comunicazione) potrebbe funzionare. Un altro modo
di fare questo è semplicemente quello di uscire da minicom e poi rilanciarlo.
<P>
<H2><A NAME="ss16.2">16.2 Non posso avvicinarmi ai 56K dal mio modem a 56K</A>
</H2>
<P> Deve esserci un livello di disturbo molto basso sulla linea perché il modem possa
solo avvicinarsi ai 56K. Alcune linee telefoniche sono così cattive che le velocità
ottenibili sono molto più lente di 56K (tipo 28.8 od anche meno). Alcune volte telefoni
supplementari connessi alla stessa linea possono causare problemi. Per controllare
questo potreste cercare di connettere il vostro modem direttamente nel punto dove la
linea telefonica si immette nell'edificio, disconnettendo qualsiasi altra cosa che
quella linea alimenti (se nessuno ha qualcosa in contrario).
<P>
<H2><A NAME="ss16.3">16.3 L'invio o lo scarico di file è lento o interrotto.</A>
</H2>
<P> Il controllo di flusso (per il PC e/o da modem a modem) potrebbe non essere
abilitato. Per il caso dell'invio di file:
Se avete impostato un'altra velocità DTE (tipo 115.2K) allora il flusso dal
vostro modem al vostro PC potrebbe funzionare bene ma molto del flusso di invio nell'altra direzione
non passerà completamente a causa del collo di bottiglia della linea telefonica.
Questo risulterà in molti errori e nel reinvio dei pacchetti. Potrebbe anche volerci
un tempo oltremodo lungo per spedire un file. In alcuni casi, i file non arrivano neppure.
<P>Per il caso dello scarico di file:
Se state scaricando dei grandi file non compressi o delle pagine web,
(ed il vostro modem usa la compressione dei dati) oppure se avete impostata una
bassa velocità DTE, allore lo scarico potrebbe essere interrotto a causa della
mancanza del controllo di flusso.
<P>
<H2><A NAME="ss16.4">16.4 Ricevendo una chiamata continuo a ricevere "line NNN of inittab invalid"</A>
</H2>
<P>Ovvero: <CODE>riga NNN di inittab non valida</CODE>
<P>Assicuratevi di usare la sintassi corretta per la vostra versione di
<CODE>init</CODE>. I diversi <CODE>init</CODE> esistenti usano sintassi differenti nel file
<CODE>/etc/inittab</CODE>. Assicuratevi di usare la sintassi corretta
per la vostra versione di <CODE>getty</CODE>.
<P>
<P>
<H2><A NAME="ss16.5">16.5 Continuo a ricevere ``Id "S3" respawning too fast: disabled for 5 minutes''</A>
</H2>
<P> Id "S3" è solo un esempio. In questo caso cercate la riga che inizia con "S3" in
<CODE>/etc/inittab</CODE>. Questa è la causa del problema. Assicuratevi che la sintassi
per questa riga sia corretta, che il dispositivo (ttyS3) esista e che possa essere trovato.
<P>Assicuratevi che il vostro modem sia configurato correttamente. Guardate i
registri <CODE>E</CODE> e <CODE>Q</CODE>.
Questo può capitare quando il vostro modem sta "chiaccherando" con <CODE>getty</CODE>.
<P>
Per uugetty, verificate che la sintassi del vostro <CODE>/etc/gettydefs</CODE> sia corretta
eseguendo il seguente comando:
<BLOCKQUOTE><CODE>
<PRE>
linux# getty -c /etc/gettydefs
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>Questo può anche capitare quando l'inizializzazione di <CODE>uugetty</CODE> fallisce.
Vedere la sezione
<A HREF="#nowork">uugetty non funziona ancora</A>.
<P>
<H2><A NAME="ss16.6">16.6 Il mio modem è bloccato dopo che qualcuno ha agganciato, oppure uugetty non riparte</A>
</H2>
<P> Questo può capitare quando il vostro modem non effettua il reset dopo che è
caduto il DTR.
Greg Hankins ha visto i suoi led RD e SD impazzire quando questo è successo.
Dovete fare resettare il vostro modem. Molti modem Hayes compatibili fanno
questo con <CODE>&D3</CODE>, ma sul suo USR Courier, ha dovuto impostare
<CODE>&D2</CODE> e <CODE>S13=1</CODE>. Controllate il manuale del modem (se ne avete uno).
<P>
<H2><A NAME="nowork"></A> <A NAME="ss16.7">16.7 uugetty non funziona ancora </A>
</H2>
<P>Esiste un'opzione <CODE>DEBUG</CODE> all'interno di <CODE>getty_ps</CODE>. Modificate il
vostro file di configurazione <CODE>/etc/conf.{uu}getty.ttyS</CODE><EM>N</EM> e
aggiungete <CODE>DEBUG=</CODE><EM>NNN</EM>. Dove <EM>NNN</EM> è una delle seguenti combinazioni
di numeri a seconda di quello che state cercando di debuggare:
<P>
<BLOCKQUOTE><CODE>
<PRE>
D_OPT 001 impostazione opzioni
D_DEF 002 elaborazione file di default
D_UTMP 004 elaborazione di utmp/wtmp
D_INIT 010 inizializzazione della linea (INIT)
D_GTAB 020 elaborazione del file gettytab
D_RUN 040 altre diagnostiche di runtime
D_RB 100 ringback debugging
D_LOCK 200 elaborazione del lockfile di uugetty
D_SCH 400 elaborazione schedule
D_ALL 777 tutto
</PRE>
</CODE></BLOCKQUOTE>
Impostare <CODE>DEBUG=010</CODE> è un buon punto da cui partire.
<P>Se avete in esecuzione <CODE>syslogd</CODE>, le informazioni di debugging appariranno nei
vostri file di log. Se non avete in esecuzione <CODE>syslogd</CODE> le informazioni appariranno
in <CODE>/tmp/getty:ttyS</CODE><EM>N</EM> per il debugging <CODE>getty</CODE>
e <CODE>/tmp/uugetty:ttyS</CODE><EM>N</EM> per <CODE>uugetty</CODE> ed in
<CODE>/var/adm/getty.log</CODE>. Controllate la informazioni di debugging e vedete
cosa sta succedendo. Molto probabilmente, dovrete regolare alcuni parametri nel
vostro file di configurazione e riconfigurare il modem.
<P>Potete anche provare <CODE>mgetty</CODE>. Alcune persone hanno avuto miglior fortuna con
quest'ultimo.
<P>Change log:
Apr. 00: 2 porte allo stesso indirizzo
<H2><A NAME="ss16.8">16.8 Le seguenti sottosezioni sono sia nel Serial che nel Modem HOWTO:</A>
</H2>
<H2><A NAME="cant_find_port"></A> <A NAME="ss16.9">16.9 La mia porta seriale è fisicamente lì ma non può essere trovata</A>
</H2>
<P> Se un dispositivo (tipo un modem) pare funzionare allora la porta seriale è stata trovaata.
Se non funziona per niente, allora occorre assicurarsi che la vostra porta seriale
possa essere trovata.
<P>Controllate i menù ed i messaggi del BIOS. Per i bus PCI usate lspci
Se è una porta seriale PnP su bus ISA
provate "pnpdump --dumpregs" e/o consultate il Plug-and-Play HOWTO. Usando "scanport" otterrete
una esplorazione di tutte le porte sul bus ISA e potreste scopire una porta sconosciuta che
potrebbe essere una porta seriale (ma la porta non viene verificata). Il PC potrebbe bloccarsi.
Potreste provare a rilevarla con setserial. Vedere
<A HREF="Modem-HOWTO-9.html#probing_ss">Probing</A>. Se nulla sembra passare attraverso la porta, essa potrebbe esserci ma avere un
interrupt sbagliato.
Vedere
<A HREF="#slow_">Estremamente lento: il testo appare sullo schermo lentamente e dopo lunghi ritardi</A><P>Se due porta hanno lo stesso indirizzo IO allora la verifica indicherà in modo errato solo una porta.
La rilevazione Plug-and-play troverà entrambe le porte così questo potrebbe essere un problema solo
se almeno una delle porte non è Plug-and-play. Errori di tutti i tipi potrebbero verificarsi
per i dispositivi che stanno "condividendo una porta" ma il fatto che ci siano due dispositivi sulla
stessa porta non sembra essere stato rilevato (eccetto, si spera, da voi). Se gli IRQ sono diversi
la rilevazione dell'IRQ con setserial potrebbe "scopire" questa situazione non riuscendo a rilevare
un IRQ. Vedere
<A HREF="Modem-HOWTO-9.html#probing_ss">Rilevamento</A>.
<P>
<P>
<H2><A NAME="slow_"></A> <A NAME="ss16.10">16.10 Estremamente lento: il testo appare sullo schermo lentamente e dopo lunghi ritardi</A>
</H2>
<P> È probabilmente un conflitto od una errata impostazione di interrupt. Ecco alcuni
sintomi di quello che potrebbe succedere la prima volta che cercate di usare un modem,
terminale o stampante. In alcuni casi digitate qualcosa ma sullo schermo
non appare nulla se non dopo parecchi secondi. Solo l'ultimo carattere digitato potrebbe apparire.
Potrebbe anche essere solo un
invisibile carattere di <return> così tutto quel che noterete sarà che il cursore
scende di una riga)
In altri casi dove dovrebbero comparire molti dati sullo schemo, sono un gruppo di circa
16 caratteri compare. Poi c'è un'attesa di parecchi secondi per il prossimo gruppo di
caratteri. Potreste anche ricevere messaggi di errore di "input overrun" (o trovarli
nei file di log)
<P>Per ulteriori dettaglio sui sintomi e perché questo accade vedere il Serial-HOWTO
sezione "Interrupt Problems Details".
<P>Se la cosa coinvolge anche dispositivi Plug-and-Play, vedere anche il Plug-and-Play HOWTO.
<P>Come veloce controllo per vedere se veramente si tratta di un problema di interrupt,
impostate l'IRQ a zero con "setserial". Questo dice al driver di non usare gli
interrupt ma il polling. Se sembra che questo
risolva i problemi di "lentezza", allora si tratta di un problema di interrupt.
Dovreste comunque cercare di risolverlo visto che il polling usa
esagerate risorse del computer.
<P>Cercare di trovare il conflitto di interrupt potrebbe non essere semplice visto che
si suppone che Linux non consenta alcun conflitto di interrupt e di conseguenza vi invii
un errore di
<A HREF="#busy_err">/dev/ttys?: Device or resource busy (Dispositivo o risorsa impegnata)</A>
se pensa che stiate tentando di creare un conflitto. Ma un vero conflitto può essere
creato se "setserial" dispone di informazioni errate. Quindi usare "setserial" non farà rilevare
alcun conflitto (e neppure guardando in /proc/interrupts che basa le suo informazioni
su "setserial"). Dovete quindi sapere quello che "setserial" pensa così che possiate
evidenziare quello che è sbagliato e cambiarlo quando avrete determinato quello che è veramente
impostato nell'hardware.
<P>Quello che dovete fare è verificare come è impostato l'hardware controllando i "jumper" od
usando software PnP per controllare le vere impostazioni dell'hardware. Per il PnP potete lanciare
"pnpdump --dumpregs" (se è un bus ISA) o "lspci" (bus PCI). Confrontate i risultati
con quello che Linux pensa sia impostato nell'hardware.
<P>
<P>
<H2><A NAME="ss16.11">16.11 Abbastanza lento: Mi aspettavo che fosse un poco più veloce</A>
</H2>
<P> Una ragione potrebbe essere che qualunque cosa sia sulla porta seriale (tipo un modem,
un terminale, una stampante) non funziona così veloce come pensate che dovrebbe.
Un modem a 56k raramente funziona a 56k ed Internet spesso è congestionata ed ha colli di
bottiglia che rallentano le cose. Se il modem dall'altra parte non ha una connessione digitale alla
linea telefonica (ed usa uno speciale "modem digitale" non in vendita nella maggior parte
dei negozi di computer), allora le velocità oltre i 33,6k non sono possibili.
<P>Un'altra possibile ragione è che il driver seriale pensa che abbiate una porta seriale
obsoleta (UART 8250, 16450, o le prime 16550). Vedere
<A HREF="Modem-HOWTO-15.html#uart_">Cosa sono le UART?</A>.
Usate "setserial -g /dev/ttyS*".
Se mostra qualsiasi cosa meno di 16550A, allora è probabilmente proprio questo il problema.
Se invece "setserial" lo identifica così sbagliando, modificatela. Vedere
<A HREF="Modem-HOWTO-9.html#set_serial">Cos'è Serial?</A> per maggiori informazioni. Naturalmente se avete veramente una porta
obsoleta, mentire a setserial su questo non farà altro che peggiorare le cose.
<P>
<P>
<H2><A NAME="irqs_shown_wrong"></A> <A NAME="ss16.12">16.12 La schermata di avvio mostra IRQ sbagliati per le porte seriali.</A>
</H2>
<P> Linux non esegue nessuna identificazione di IRQ in avvio. Quando il modulo di
setserial si carica esegue semplicemente una rilevazione del dispositivo seriale.
Quindi non fate caso a quello che dice circa l'IRQ, perché sta semplicemente assumendo
gli IRQ standard. Così è fatto, perché l'identificazione degli IRQ è inaffidabile e
potrebbe essere ingannevole. Ma se e quando setserial viene lanciata da uno script di
avvio, cambia gli IRQ e visualizza il nuovo (ed auspicabilmente corretto) stato nella
schermata di partenza. Se l'IRQ sbagliato non viene corretto da una seguente visualizzazione
sullo schermo, allora avete un problema.
<P>Quindi, anche se ho la mia <CODE>ttyS2</CODE> impostata ad IRQ 5, continuo a vedere
<BLOCKQUOTE><CODE>
<PRE>
ttyS02 at 0x03e8 (irq = 4) is a 16550A
</PRE>
</CODE></BLOCKQUOTE>
all'inizio quando parte Linux (i vecchi kernel potrebbero mostrare "ttyS02" come "tty02")
Dovete usare <CODE>setserial</CODE> per dire a Linux che IRQ state usando.
<P>
<H2><A NAME="ss16.13">16.13 "Cannot open /dev/ttyS?: Permission denied"</A>
</H2>
<P>Ovvero: <CODE>Impossibile aprire /dev/ttyS?: Permesso negato</CODE>
<P> Controllare i permessi su questa porta con "ls -l /dev/ttyS?".
Se siete i proprietari di questa ttyS? allora dovete avere i permessi di lettura e
scrittura: crw con il c (Character device) in colonna 1. Se non siete i proprietari
dovreste invece vedere rw- nelle colonne 8 e 9 che significa che tutti hanno diritti
di lettura e scrittura su di esso. Usate "chmod" per cambiare i permessi. Ci sono
modi più complicati per ottenere accessi tipo appartenere ad un "gruppo" che ha
permessi di gruppo.
<P>
<H2><A NAME="ss16.14">16.14 "Operation not supported by device" per ttySx</A>
</H2>
<P>Ovvero: <CODE>Operazione non supportata dal dispositivo</CODE>
<P> Questo vuol dire che un operazione richiesta da setserial, stty, ecc. non
può essere effettuata perché il kernel non la supporta.
In precedenza questo era spesso causato dal fatto che il modulo seriale non era stato
caricato. Ma con l'avvento del PnP, potrebbe più probabilmente dire che non
c'è un modem (od altro dispositivo seriale) all'indirizzo dove il driver (e setserial)
pensa che sia. Se non c'è un modem lì, i comandi inviati a quell'indirizzo
ovviamente non vengono eseguiti.
Vedere
<A HREF="Modem-HOWTO-6.html#io-irq_in_hdw">Cos'è impostato nell'hardware della mia porta seriale?</A>.
<P>Se il modulo seriale non era caricato ma "lsmod" mostra che ora è caricato potrebbe
essere il caso che sia stato caricato adesso ma non lo era quando si è ricevuto il
mesasggio di errore. In molti casi il modulo verrà automaticamente caricato quando
necessario (se si riesce a trovare). Per forzare il caricamento del modulo seriale si
potrebbe elencarlo nel file /etc/modules.conf o /etc/modules. Il vero modulo dovrebbe
risiedere in /lib/modules/.../misc/serial.o.
<P>
<H2><A NAME="ss16.15">16.15 "Cannot create lockfile. Sorry" (Spiacente, non posso creare il file di lock)</A>
</H2>
<P>Ovvero: <CODE>Spiacente, impossibile creare il file di lock.</CODE>
<P> Quando viene "aperta" una porta da un programma viene creato un file di lock in
/var/lock. Errati permessi per la directory lock non consentiranno la
creazione di un file di lock.
Usare "ls -ld /var/lock" per vedere se i permessi sono a posto: in genere
rwx per tutti (ripetuto 3 volte). Se è sbagliato, usate "chmod" per mettere a posto lo cose.
Naturalmente, se non esiste una directory di lock nessun file di lock potrà esservi creato.
Vedere la sottosezione del Serial-HOWTO: "What Are Lock Files".
<P>
<H2><A NAME="ss16.16">16.16 "Device /dev/ttyS? is locked." (Il dispositivo /dev/ttyS? è bloccato)</A>
</H2>
<P>Ovvero: <CODE>Il dispositivo </CODE>dev/ttyS? è bloccato./
<P> Questo vuol dire che qualcun altro (o qualche altro processo) sta presumibilmente usando
la porta seriale. Ci sono diversi modi per cercare di scoprire quale processo la sta usando.
Un modo è dare un occhiata al contenuto del file di lock (/var/lock/LCK...). Dovrebbe essere
l'identificativo del processo. Se l'identificativo è diciamo 261 digitate "ps 261" per scoprire
cosa sia. Poi, se il processo non è più necessario, potrebbe essere gentilmente eliminato da
"kill 261". Se si rifiuta di essere eliminato usate "kill -9 261" per forzare l'eliminazione,
ma in questo caso il file di lock non sarà rimosso, e dovrete provvedere manualmente. Naturalmente
se non c'è un processo 261 allora basta che rimuoviate il file di lock, ma nella maggior parte
dei casi il file di lock dovrebbe esser stato automaticamente rimosso se contiene un
identificativo di processo chiuso (come 261).
<P>
<H2><A NAME="busy_err"></A> <A NAME="ss16.17">16.17 "/dev/ttyS?: Device or resource busy" (Dispositivo o risorsa occupati) </A>
</H2>
<P>Significa che il dispositivo al quale state tentando di accedere (o usare) è presumibilmente
occupato (in uso) o che una risorsa di cui necessita (tipo un IRQ) è presumibilmente in uso da
parte di un altro dispositivo. Talvolta è davvero occupato ma in altri casi sembra erroneamente
in uso.
<P>"resource busy" (risorsa impegnata) spesso vuol dire (ad esempio per <CODE>ttyS2</CODE>) "Non puoi usare
<CODE>ttyS2</CODE> visto
che un altro dispositivo sta usando l'interrupt di ttyS2". Il potenziale conflitto di interrupt è
determinato da quello che pensa "setserial". Un messaggio di errore più accurato dovrebbe essere "Non
posso usare <CODE>ttyS2</CODE> visto che i dati di setserial (e quelli del kernel) indicano che un
altro dispositivo sta usando l'interrupt di <CODE>ttyS2</CODE>". Se due dispositivi usano lo stesso IRQ e voi
fate partire uno solo dei due dispositivi, tutto è a posto perché non c'è ancora conflitto. Ma
quando in seguito cercate di lanciare il secondo dispositivo (senza chiudere il primo) otterrete il
messaggio di errore "... resource busy". Questo perché il kernel tiene traccia solamente di quale
IRQ è realmente in suo e i conflitti non capitano a meno che i dispositivi siano in uso (aperti)
<P>Ci sono due casi: Potrebbe esserci un vero conflitto di interrupt che si sta evitando.
Ma se setserial ha sbagliato, allora non dovrebbe esserci alcuna ragione perché <CODE>ttyS2</CODE> non possa essere
usata, eccetto che setserial ha erroneamente previsto un conflitto. Quello che occorre fare è scoprire
quale interrupt setserial pensa che stia usando <CODE>ttyS2</CODE>. Più facile a dirsi che a farsi visto
che non potete usare il comando "setserial" per <CODE>ttyS2</CODE> visto che l'IRQ per ttyS2 è presumibilmente
occupato ed otterreste lo stesso messaggio di errore "... busy". Per risolvere o eseguite un riavvio
oppure: uscite od eliminate tutti i processi che potrebbero cauasre il conflitto. Se riavviate: 1.
osservate i messaggi in fase di avvio relativi alle porte seriali. 2. Sperate che il file che lancia
"setserial" all'avvia non sia esso stesso a creare ancora lo stesso conflitto.
<P>Se pensate di sapere quale IRQ stia usando <CODE>ttyS2</CODE> allora potreste dare uno sguardo a
/proc/interrupts per scoprire chi altro sta attualmente usando questo IRQ.
Potreste anche voler fare un doppio controllo perché qualsiasi IRQ mostrato qui (e da "setserial")
sia corretto (lo stesso di quello impostato nell'hardware). Un modo per provare se c'è o meno un
conflitto di interrupt è impostare l'IR1 a 0 (polling) usando "setserial". Se il messaggio di
risorsa occupata (busy) scompare, probabilmente c'è un potenziale conflitto di interrupt. Non
è una buona idea lasciarlo permanentemente impostato a 0 visto verranno usate più risorse della CPU.
<P>Questo paragrafo è principalmente per il caso in cui un modem è usato sia per chiamare che per
ricevere chiamate. Se il segnale DSD è inviato alla porta, quello porta penserà che sia occupata.
Questo problema può sorgere quando state cercando di chiamare con un modem quando DTC o DTR non
sono implememntati correttamente. DCD dovrebbe essere attivo quando c'è una effettiva connessione
(ad esempio qualcuno ci ha chiamati), non quando <CODE>getty</CODE> sta guardando la porta.
Assicuratevi che il vostro modem sia configurato per attivare DCD solo quando c'è una connessione.
DTR dovrebbe essere attivo ogniqualvolta qualcuno sta usando o guardando la linea, tipo <CODE>getty</CODE>,
<CODE>kermit</CODE>, o qualche altro programma di comunicazione.
<P>
<P>
<H2><A NAME="ss16.18">16.18 Strumenti per la risoluzione dei problemi</A>
</H2>
<P>Questi sono alcuni dei programmi che potreste aver bisogno di usare per la risoluzione dei
problemi:
<UL>
<LI> "lsof /dev/ttySx" farà un elenco delle porte seriali che sono aperte.</LI>
<LI> "setserial" mostra ed imposta la configurazione hardware a basso livello di una porta
(quella che il driver pensa che sia). Vedere
<A HREF="Modem-HOWTO-9.html#set_serial">Cos'è setserial</A>.</LI>
<LI> "stty" mostra ed imposta la configurazione di una porta (ad eccezione di quanto gestito
da "setserial").
Vedere la sezione del Serial-HOWTO: "Stty", </LI>
<LI> "modemstat" o "statserial"
che mostrano lo stato corrente dei vari segnali di linea (tipo DTR, CTS, ecc.)
di segnale (tipo DTR, CTS, ecc)</LI>
<LI> "irqtune" darà agli interrupt della porta seriale una priorità maggiore
per migliorare le prestazioni.</LI>
<LI> "hdparm" per la messa a punto dell'hard-disk potrebbe fornire un ulteriore aiuto</LI>
<LI> "lspci" mostra gli effettivi IRQ, ecc, dell'hardware del bus PCI.</LI>
<LI> "pnpdump --dumpregs" mostra gli effettivi IRQ, ecc., dell'hardware per i
dispositivi PnP sul bus ISA.</LI>
<LI> Alcuni "file" nella directory /proc (tipo ioports e interupts).</LI>
</UL>
<P>
<P>
<HR>
<A HREF="Modem-HOWTO-17.html">Avanti</A>
<A HREF="Modem-HOWTO-15.html">Indietro</A>
<A HREF="Modem-HOWTO.html#toc16">Indice</A>
</BODY>
</HTML>
