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 La mia porta seriale è fisicamente presente ma non può essere trovata. Questa sezione riguarda come scoprire quale porta seriale ha un modem ad essa connesso.
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 Cos'è wvdialconf ?. Sfortunatamente, se il vostro modem è in modalità "online data", wvdialconf visualizzerà "No modem detected". Vedere Nessuna risposta ad AT.
Il vostro problema potrebbe essere dovuto ad un winmodem (o simile) che non può essere usato con Linux. Vedere Evitare la maggior parte dei software modem. 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".
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:
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).
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.
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.
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.
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).
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.
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.
Ovvero: riga NNN di inittab non valida
Assicuratevi di usare la sintassi corretta per la vostra versione di
init. I diversi init esistenti usano sintassi differenti nel file
/etc/inittab. Assicuratevi di usare la sintassi corretta
per la vostra versione di getty.
Id "S3" è solo un esempio. In questo caso cercate la riga che inizia con "S3" in
/etc/inittab. Questa è la causa del problema. Assicuratevi che la sintassi
per questa riga sia corretta, che il dispositivo (ttyS3) esista e che possa essere trovato.
Assicuratevi che il vostro modem sia configurato correttamente. Guardate i
registri E e Q.
Questo può capitare quando il vostro modem sta "chiaccherando" con getty.
Per uugetty, verificate che la sintassi del vostro /etc/gettydefs sia corretta
eseguendo il seguente comando:
linux# getty -c /etc/gettydefs
Questo può anche capitare quando l'inizializzazione di uugetty fallisce.
Vedere la sezione
uugetty non funziona ancora.
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 &D3, ma sul suo USR Courier, ha dovuto impostare
&D2 e S13=1. Controllate il manuale del modem (se ne avete uno).
Esiste un'opzione DEBUG all'interno di getty_ps. Modificate il
vostro file di configurazione /etc/conf.{uu}getty.ttySN e
aggiungete DEBUG=NNN. Dove NNN è una delle seguenti combinazioni
di numeri a seconda di quello che state cercando di debuggare:
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
DEBUG=010 è un buon punto da cui partire.
Se avete in esecuzione syslogd, le informazioni di debugging appariranno nei
vostri file di log. Se non avete in esecuzione syslogd le informazioni appariranno
in /tmp/getty:ttySN per il debugging getty
e /tmp/uugetty:ttySN per uugetty ed in
/var/adm/getty.log. 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.
Potete anche provare mgetty. Alcune persone hanno avuto miglior fortuna con
quest'ultimo.
Change log: Apr. 00: 2 porte allo stesso indirizzo
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.
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 Probing. Se nulla sembra passare attraverso la porta, essa potrebbe esserci ma avere un interrupt sbagliato. Vedere Estremamente lento: il testo appare sullo schermo lentamente e dopo lunghi ritardi
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 Rilevamento.
È 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)
Per ulteriori dettaglio sui sintomi e perché questo accade vedere il Serial-HOWTO sezione "Interrupt Problems Details".
Se la cosa coinvolge anche dispositivi Plug-and-Play, vedere anche il Plug-and-Play HOWTO.
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.
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 /dev/ttys?: Device or resource busy (Dispositivo o risorsa impegnata) 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.
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.
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.
Un'altra possibile ragione è che il driver seriale pensa che abbiate una porta seriale obsoleta (UART 8250, 16450, o le prime 16550). Vedere Cosa sono le UART?. 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 Cos'è Serial? per maggiori informazioni. Naturalmente se avete veramente una porta obsoleta, mentire a setserial su questo non farà altro che peggiorare le cose.
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.
Quindi, anche se ho la mia ttyS2 impostata ad IRQ 5, continuo a vedere
ttyS02 at 0x03e8 (irq = 4) is a 16550A
setserial per dire a Linux che IRQ state usando.
Ovvero: Impossibile aprire /dev/ttyS?: Permesso negato
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.
Ovvero: Operazione non supportata dal dispositivo
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 Cos'è impostato nell'hardware della mia porta seriale?.
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.
Ovvero: Spiacente, impossibile creare il file di lock.
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".
Ovvero: Il dispositivo dev/ttyS? è bloccato./
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).
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.
"resource busy" (risorsa impegnata) spesso vuol dire (ad esempio per ttyS2) "Non puoi usare
ttyS2 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 ttyS2 visto che i dati di setserial (e quelli del kernel) indicano che un
altro dispositivo sta usando l'interrupt di ttyS2". 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)
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é ttyS2 non possa essere
usata, eccetto che setserial ha erroneamente previsto un conflitto. Quello che occorre fare è scoprire
quale interrupt setserial pensa che stia usando ttyS2. Più facile a dirsi che a farsi visto
che non potete usare il comando "setserial" per ttyS2 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.
Se pensate di sapere quale IRQ stia usando ttyS2 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.
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 getty 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 getty,
kermit, o qualche altro programma di comunicazione.
Questi sono alcuni dei programmi che potreste aver bisogno di usare per la risoluzione dei problemi: