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).
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.
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.
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.
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.
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
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
È 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
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.
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. 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.
modemstat e statserial mostrano lo stato corrente delle varia linee
di segnale (tipo DTR, CTS, ecc)irqtune darà agli interrupt della porta seriale una priorità maggiore
per migliorare le prestazioni.hdparm per la messa a punto dell'hard-disk potrebbe fornire un ulteriore aiuto