Avanti Indietro Indice

15. Risoluzione di problemi

15.1 Non posso ottenere 56K dal mio modem a 56K

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 26.6 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).

15.2 L'invio o lo scarico di file è lento o interrotto.

Il controllo di flusso (per il PC e/o per il modem) potrebbe non essere abilitato. Se avete impostato un'altra velocità DTE (tipo 115.2K) allora il flusso dal vostro modem al vostro PC funziona bene ma molto del flusso 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. 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.

15.3 Ricevendo una chiamata continuo a ricevere "line NNN of inittab invalid"

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.

15.4 Quando cerco di chiamare l'esterno, ottengo ``/dev/ttySN: Device or resource busy"

Ovvero: /dev/ttySN: Dispositivo o risorsa occupata

Questo problema può sorgere quando DCD o DTR non sono implementati correttamente. DCD dovrebbere attivarsi solo quando esiste una vera connessione (ad esempio qualcuno ci ha chiamati), non quando getty sta "osservando" la porta. Controllate che il vostro modem sia configurato per attivare una DCD solo quando c'è una connessione. DTR dovrebbe essere attivato ogniqualvolta qualcuno stia usando o "osservando" la linea, come getty o kermit o qualche altro programma di comunicazione

Un'altra comune causa di errori "device busy" (dispositivo occupato) è quando si imposta la porta seriale con un interrupt che è già preso da qualcosa d'altro. Quando ogni dispositivo si inizializza, chiede a Linux il permesso di usare i suoi interrupt hardware. Linux mantiene traccia di quale interrupt ha assegnato ed a chi, e se il vostro interrupt è gia stato occupato, il vostro dispositivo non sarà in grado di inizializzarsi correttamente. Il dispositivo non ha molti modi per informarvi che questo è capitato, ad eccetto di quando si tenta di usarlo, allora restituisce un errore di "device busy". Controllate gli interrupt di tutte le vostre schede (seriali, ethernet, SCSI, ecc.). Cercate i conflitti di IRQ.

15.5 Continuo a ricevere ``Id "S3" respawning too fast: disabled for 5 minutes''

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.

15.6 Il mio modem è bloccato dopo che qualcuno ha agganciato, oppure uugetty non riparte

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).

15.7 uugetty non funziona ancora

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
Impostare 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.

15.8 Il mio modem è fisicamente al suo posto ma non può essere trovato

Se conoscete le porte seriali esistenti prima di avere installato un modem interno, allora il problema è cercare la nuova porta seriale. Di questo ci si occupa nella successiva sezione. Questa sezione riguarda come scoprire quale porta seriale ha un modem su di essa.

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 ?.

Il vostro problema potrebbe essere dovuto ad un winmodem (o simile) che non può essere usato con Linux. Vedere Evitare: winmodem. Il programma "setserial" potrebbe essere usato per identificare le porte seriali ma non rileverà se ci sono modem collegati ad esse. Quindi è meglio usare prima "wvdialconf".

Un altro modo di vedere se c'è un modem su una porta è lanciare "minicom" sulla porta (andate nei menù di setup con ^AO). Poi digitate "AT" e dovreste vedere OK (o 0 se è impostato per restituire codici numerici di risultato ("digit result codes")). Se ci vogliono parecchi secondi per ottenere una risposta (incluso anche solo il cursore che si sposta di una riga) allora vedere Estremamente lento: il testo appare sullo schermo lentamente e dopo lunghi ritardi

15.9 Le seguenti sottosezioni sono sia nel Serial che nel Modem HOWTO:

15.10 La mia porta seriale è fisicamente lì ma non può essere trovata

Controllate i menù ed i messaggi del BIOS. Se c'è una porta seriale PnP od un bus ISA provate "pnpdump --dumpregs" e/o consultate il Plug-and-Play HOWTO. Per il bus PCI guardate in /proc/pci. Potreste provare a rilevarla con setserial. Vedere Probing. Se nulla sembra passare la porta potrebbe esserci ma avere un interrupt sbagliato. Vedere Estremamente lento: il testo appare sullo schermo lentamente e dopo lunghi ritardi

15.11 Estremamente lento: il testo appare sullo schermo lentamente e dopo lunghi ritardi

È 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 (e potrebbe anche essere solo un invisibile carattere di <return> ma notate 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".

Come controllo finale 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 un metodo di polling inefficiente (ma più veloce). Se sembra che questo risolva i problemi di "lentezza", allora si tratta di un problema di interrupt ma dovreste comunque cercare di risolverlo visto che il polling usa eccessive risorse del computer. Cercare di trovare il conflitto di interrupt potrebbe non essere semplice visto che guardare nella directory /proc potrebbe essere fuorviante. Assicuratevi che nessun IRQ sia condiviso illegalmente. Controllate tutte le vostre schede (seriali ethernet, SCSI, ecc...). Assicuratevi di avere impostato correttamente i ponticelli (o il PnP) ed i parametri di setserial per tutti i vostri dispositivi seriali. Controllate anche /proc/ioports e /proc/interrupts e /proc/pci alla ricerca di conflitti. Per ulteriori dettagli vedere il Serial-HOWTO: Interrupt Problem Details. Se riguarda i dispositivi Plug-and-Play, vedere anche il Plug-and-Play-HOWTO

15.12 Abbastanza lento: Mi aspettavo che fosse 2-4 volte più veloce

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.

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.

15.13 La schermata di avvio mostra IRQ sbagliati per le porte seriali.

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
all'inizio quando parte Linux (i vecchi kernel potrebbero mostrare "ttyS02" come "tty02") Dovete usare setserial per dire a Linux che IRQ state usando.

15.14 "Cannot open /dev/ttyS?: Permission denied"

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.

15.15 "Operation not supported by device" (messaggio di errore) per ttySx

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.

15.16 "Cannot create lockfile. Sorry" (messaggio di errore)

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".

15.17 "Device /dev/ttyS? is locked."

Ovvero: Il dispositivo dev/ttyS? è bloccato./

Questo vuol dire che qualcun altro (o qualche altro processo) sta presumibilmente usando la porta seriale. Usate "ps -alx" per scoprirlo. Cercate qualsiasi programma che usi la porta seriale. Potreste anche controllare il file di lock che si trova in /var/lock tipo /var/lock/LCK..ttyS2 (contiene il numero identificativo del processo che sta usando la porta). Potrebbe essere un processo "ribelle" che dovrete eliminare. Se il processo non esiste, potreste rimuovere il file di lock. La maggior parte delle applicazioni fanno questo automaticamente così è raro che dobbiate ancora rimuovere dei file di lock manualmente.

15.18 Software che può essere d'aiuto


Avanti Indietro Indice