Upewnij się, że stosujesz odpowiednia składnie w pliku
/etc/inittab zgodną z twoją wersja programu
init. Różne wersje tego programu obecne w świecie Linux-a
mają różną składnię. Również upewnij się, że używasz poprawnej
składni dla twojej wersji getty.
Ten problem może się pojawiać, gdy DCD i DTR nie są ustawione
poprawnie. DCD powinno być włączone tylko wtedy, gdy jest
rzeczywiste połączenie (gdy ktoś do ciebie zadzwonił i w
danej chwili wykorzystuje modem i port szeregowy), a nie kiedy
getty nasłuchuje na porcie. Sprawdź czy twój modem jest
skonfigurowany, aby włączać DCD tylko podczas trwania
połączenia. DTR powinno być włączone zawsze, gdy coś sprawdza
lub nasłuchuję linię, jak getty, kermit lub inny
program komunikacyjny.
Inną powszechną przyczyną omunikatu ``device busy'' (urządenie zajęte) jest skonfigurownie portu szeregowego w taki sposob, że używa przerwania IRQ przydzielonego do innego urządzenia. Podczas inicjowania portu sterownik, pyta się Linux-a o pozwolenie na wykorzystanie przerwania sprzętowego. Linux pamięta, które przerwanie zostało mu przydzielone i jeśli twoje przerwanie zostało już przydzielone, urządzenie (np. port szeregowy) nie bedzie mogło zostać prawidłowo zainicjowane. Urządzenie nie ma za bardzo jak powiedzieć Ci o tym, poza przypadkiem kiedy próbujesz go użyc. Przekazuje wtedy błąd ``device busy''. Sprawdź przerwania wszystkich swoich kart (szeregowych, sieciowych, SCSI, itd.). Szukaj konfliktów przerwań IRQ.
Upewnij się, że Twój modem jest skonfigurowany
poprawnie. Przyjżyj się rejestrom E i Q. Przyczyną
może być pogawędka modemu z programem getty.
Upenij się ,że poprawnie wywołujesz getty w pliku
/etc/inittab/. Używanie błędnej składni lub
nieporawnych nazw urządzeń jest przyczyną licznych kłopotów.
Upewnij się, że /etc/gettydefs ma poprawną składnie.
W tym celu wydaj polecenie:
linux# getty -c /etc/gettydefs
Przyczyna może leżeć w niepoprawnej inicjalizacji programu
uugetty. Patrz pytanie ``getty lub uugetty
nadal nie pracuje poprawnie''.
Prawdopodobnie konflikt IRQ. Upewnij się, żę IRQ nie są
wspólne. Sprawdź wszystkie karty (szeregowe, sieciowe, SCSI,
itd.). Upewnij się, że ustawienia mikroprzełączników i
parametry ustawiane przez setserial są poprawne dla
wszystkich urządzeń szeregowych. Sprawdź
/proc/interrupts i /proc/ioports w
poszukiwaniu konfliktów.
uugetty nie uruchimi się ponownie. Przyczyna może leżeć w tym, że kiedy spada sygnał DTR twój
modem się nie zeruje. Widziałem jak diody RD i SD na moim
modemie szalały, kiedy cos takiego mi się zdarzyło. Twój modem
musi się zerować. Wiekszość modemów zgodnych z Hayes wymaga
ustawienia &D3, lecz w moim USR Courier musiałem
ustawić &D2 i S13=1. Sprawdź w dokumnetacji
modemu.
Prawdopodobnie pozycja dotycząca tego terminala w pliku
/etc/gettydefs nie zawiera opcji CLOCAL. I
prawdopodobnie nie używasz pełnego kabla bezmodemowego (full
null modem cable). Musisz ustawić opcję CLOCAL, dzieki
której Linux ignoruje sygnały strujące modemem. To powinno
wyglądać mniej więcej tak:
# 38400 bps Dumb Terminal entry
DT38400# B38400 CS8 CLOCAL # B38400 SANE -ISTRIP CLOCAL #@S @L login: #DT38400
# 19200 bps Dumb Terminal entry
DT19200# B19200 CS8 CLOCAL # B19200 SANE -ISTRIP CLOCAL #@S @L login: #DT19200
# 9600 bps Dumb Terminal entry
DT9600# B9600 CS8 CLOCAL # B9600 SANE -ISTRIP CLOCAL #@S @L login: #DT9600
zabij (kill) proces getty, tak aby
uruchomil się następny, który odczyta nowe ustawienia.
agetty:
dodaj do wiersza agetty w pliku /etc/inittab
parametr -L. W ten sposób zmusisz agetty do
ignorowania sygnałów sterowania modemem. Następnie zrestartuj
program init wydając polecenie init q. Odpowiedni
wpis w pliku /etc/inittab powinien wyglądać mniej
więcej tak:
s1:345:respawn:/sbin/agetty -L 9600 ttyS1 vt100
Jeśli próbujesz uruchomić swój modem z prędkością co najmniej 19200 bps i nie posiadasz układów UART 16550A, powinieneś je wymienić. Patrz rozdział Co to jest UART.
To prawda. Linux nie wykonuje podczas startu rozpoznania IRQ, jedynie strawdza istnienie urządzeń szeregowych. Dlatego nie przejmuj się tym co wypisuje podczas startu na temat IRQ, ponieważ po prostu zakłada standardową konfiguracje. Dzieje się tak ponieważ wykrywanie przerwań IRQ nie jest pewne i mogą być odczytane niepoprawnie.
Dlatego pomimo, że moj ttyS2 jest skonfigurowany na IRQ
5 nadal widzę:
Jan 23 22:25:28 misfits vmunix: tty02 at 0x03e8 (irq = 4) is a 16550A
Musisz powiedzieć Linux-owi o przerwaniach IRQ, korzystając z
programu setserial. Po uruchomieniu systemu możesz zajżeć
do pliku /proc/interrupts i zobaczyć, jak zostały
przydzielone.
rz i/lub sz nie działają kiedy pracuje na moim Linux-ie przez modem.
Jeśli przy próbie transferu plików Linux szuka urządzenia
/dev/modem sprawdź zawartość plików
/etc/profile i /etc/csh.cshrc. W niektórych
dystrybucjach (szczególnie w Slackware) może tam być
zdefiniowana garść aliasów, które wywołują całe
zamieszanie. Poraw je lub po prostu usuń.
Tak się dzieje, gdy wyślesz na konsolę wirtualną dane binarne,
lub czasami przy połączeniach przez porty szeregowe. Jednym ze
sposobów na przywrócenie normalengo wyglądu ekranu jest
napisanie echo ^v^[c lub:
linux% echo
<ctrl>v<esc>c
getty lub uugetty nadal nie dziala.
getty_ps posiada opcję DEBUG. Zmień plik
konfiguracyjny /etc/conf.{uu}getty.ttySN i dodaj
opcję DEBUG=NNN. NNN może przyjmować kombinacje
podanych poniżej wartości ( w zależności o tego jakie
informacje chcesz otrzymywać):
D_OPT 001 ustawianie opcji
D_DEF 002 przetwarzanie domyśłnych plików konfiguracyjnych
D_UTMP 004 obsługa utmp/wtmp
D_INIT 010 inicjowanie liniii (INIT)
D_GTAB 020 przetwarzanie pliku gettytab
D_RUN 040 inna diagnostyka czasu wykonania
D_RB 100 odpluskwianie obcji ringback
D_LOCK 200 obsługa pliku blokady
D_SCH 400 obsługa zaplanowanych zdarzeń
D_ALL 777 wszystko
Na początek mozna ustawić DEBUG=010.
Jeśli korzystasz z syslogd, informacje odpluskwiające
będą pojawiać się w plikach dzienników. Jeśli syslogd nie
jest uruchomiony komunikaty dotyczące odpluskwiania getty
będa zachowywane w /tmp/getty:ttySN, a dotyczące
uugetty w pliku /tmp/uugetty:ttySN oraz w
pliku /var/adm/getty.log. Przypatrz się tej informacji
i postaraj się zrozumieć co się dzieje. Prawdobodobnie
będziesz musiał dostroić kilka parametrów w plikach
konfiguracyjnych i ponwnie skonfigurwać modem.
Możesz spróbować mgetty. Część ludzi miała z nim więcej szczęścia.