要確定你對你的 init 版本使用正確的文法．這裡所沒有的一些 init 會在 /etc/inittab 檔案裡使用不同的文法．
要確定你對你的 getty 版本使用正確的文法．
這個問題可能發生在 DCD 或 DTR 沒有設定正確的時候．
DCD 應該只在真的有連線時(像是有人撥接進來)才被設定，而不是在 getty 持續監看該埠的時候．
檢查並確定你的數據機正確地配置成只在真正連線時才設定 DCD．
DTR 應該在任何東西使用或監看線路時設定，像是 getty, kermit, 或其它通訊程式．
另一個引起 ``device busy'' 錯誤的普遍原因是你設定你的串列埠使用一個已經被某種其它東西使用的中斷． 在每一個設備初始化的時後，它會要求 Linux 允許它使用它的硬體中斷． Linux 持續追蹤那個中斷被指定給誰，而如果你的中斷已經被佔用，你的設備將不能適當地初始化． 該設備真的並沒有什麼辦法告訴你發生的這件事，除了當你嘗試去使用它的時候，它會回應 ``device-busy'' 錯誤訊息． 檢查你所有的卡(串列，乙太網路，SCSI 界面等等)．找尋硬體中斷衝突的地方．
確定你的數據機有正確的配置．查看暫存器 E 和 Q．
這可能發生在你的數據機跟 getty 溝通的時候．
確定你正確地從 /etc/inittab 呼叫 getty．
使用錯誤的文法或設備名稱將會引起嚴重的問題．
以下法檢查你的 /etc/gettydefs 文法是否正確:
linux# getty -c /etc/gettydefs
這也可能發生在 uugetty 初使化失敗時．參閱
getty 或 uugetty 仍然無法運作 一節．
你的硬體中斷可能有衝突．確定沒有硬體中斷是被分享的．
檢查你所有的卡(串列卡, 乙太網路卡, SCSI 等等)確定你串列設備配的跳接設定以及 setserial 參數是正確的．
同時檢查 /proc/ioports 及 /proc/interrups 以確定是否有衝突發生．
uugetty 並沒有重新執行
這在 DTR 訊號掉下而你的數據機沒有重置時會發生．
這個問題在我身上發生的時候我看到我的 RD 跟 SD LEDs 瘋狂地閃爍．你需要讓你的數據機重置．
大部份的 Hayes 相容數據機使用 &D3 來做這件事，但是在我的 USR Courier 上，我得要設 &D2 以及 S13=1．查閱你的數據機手冊．
getty:
在你的 /etc/gettydefs 項目裡可能沒有設 CLOCAL 給終端機，而且可能你用的並不是完整的 null modem 連接線．
你需要 CLOCAL 來告訴 Linux 忽略數據機控制信號．它看起來像這裡這樣:
# 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
kill 砍掉該 getty 行程這樣新行程會以新的項目產生．
agetty:
加上 -L 旗標到你的 /etc/initab 中的 agetty 那行．
這會使得它忽略數據機控制信號．然後鍵入 init q 以重新執行 init．
這個項目看起來像這樣:
s1:345:respawn:/sbin/agetty -L 9600 ttyS1 vt100
如果你嘗試在大於 38400 bps 的速率下使用你的數據機，而你並沒有 16550A UARTs 的話，你應該要將它們升級． 有關 UARTs 的說明參閱 什麼是 UARTs? 一節．
這是事實．Linux 在系統啟動時並沒有做任何的 IRQ 偵測，它只做串列設備偵測． 所以，不要理會它所顯示有關硬體中斷的部份，因為它只是假定使用標準的硬體中斷． 這是因為硬體中斷偵測不可靠，而且可能被瞞騙而這樣做的．
所以即使我的 ttyS2 設在 IRQ5，我仍然看到
Jan 23 22:25:28 misfits vmunix: tty02 at 0x03e8 (irq = 4) is a 16550A
setserial 來告訴 Linux 你所使用的硬體中斷．
Linux 啟動後，你可以查看 /proc/interrupts 檔以了解真正被配置的 IRQ 是什麼．
rz 以及/或是 sz 不動
如果 Linux 在你嘗試傳送檔案時會尋找 /dev/modem 的話，查看 /etc/profile 以及 /etc/csh.cshrc．
某些發行套件會在這些地方定義一些別名，最著名的是 Slackware．
這些別名擾亂了 zmodem 程式．把它們拿掉或是更正它們．
這在當你把二進位資料送往螢幕的時候會發生在虛擬控制台上，或者有時候會發生在串列連線上．
修復這個問題的方法是輸入 echo ^v^[c．因為控制字元之故，它是:
linux% echo <ctrl>v<esc>c
getty 或 uugetty 仍然無法運作
getty_ps 上有個 DEBUG 選項．編輯你的 /etc/conf.{uu}getty.ttySN 配置檔並加上 DEBUG=NNN．
其中 NNN 是下列的數字組合之一，根據你想要偵測什麼錯誤而定:
D_OPT 001 option settings
D_DEF 002 defaults file processing
D_UTMP 004 utmp/wtmp processing
D_INIT 010 line initialization (INIT)
D_GTAB 020 gettytab file processing
D_RUN 040 other runtime diagnostics
D_RB 100 ringback debugging
D_LOCK 200 uugetty lockfile processing
D_SCH 400 schedule processing
D_ALL 777 everything
DEBUG=010 是個開始的好地方．
如果你正在執行 syslogd 的話，偵錯資訊將會出現在你的記錄檔裡．
如果你沒有執行 syslogd 那麼 getty 的資訊將會出現在 /tmp/getty:ttySN 裡而 uugetty 的資訊則會出現在 /tmp/uugetty:ttySN 裡，而且它們也會被放到 /var/adm/getty.log 裡去．
查看偵錯資訊看看發生了什麼．最可能的是，你將得要調整一些你配置檔裡的參數，並且重新配置你的數據機．
你應該也去試試 mgetty．有些人在使用它時更為幸運．