Linux Serial HOWTO 中譯版: 故障排除

Next Previous Contents

## 13. 故障排除

## 13.1 我不斷地收到 ``line NNN of inittab invalid''

要確定你對你的 `init` 版本使用正確的文法．這裡所沒有的一些 `init` 會在 `/etc/inittab` 檔案裡使用不同的文法． 要確定你對你的 `getty` 版本使用正確的文法．

## 13.2 當我試著撥號時，它說 ``/dev/cuaN: Device or resource busy''

這個問題可能發生在 DCD 或 DTR 沒有設定正確的時候． DCD 應該只在真的有連線時(像是有人撥接進來)才被設定，而不是在 `getty` 持續監看該埠的時候． 檢查並確定你的數據機正確地配置成只在真正連線時才設定 DCD． DTR 應該在任何東西使用或監看線路時設定，像是 `getty`, `kermit`, 或其它通訊程式．

另一個引起 ``device busy'' 錯誤的普遍原因是你設定你的串列埠使用一個已經被某種其它東西使用的中斷． 在每一個設備初始化的時後，它會要求 Linux 允許它使用它的硬體中斷． Linux 持續追蹤那個中斷被指定給誰，而如果你的中斷已經被佔用，你的設備將不能適當地初始化． 該設備真的並沒有什麼辦法告訴你發生的這件事，除了當你嘗試去使用它的時候，它會回應 ``device-busy'' 錯誤訊息． 檢查你所有的卡(串列，乙太網路，SCSI 界面等等)．找尋硬體中斷衝突的地方．

## 13.3 我持續接到 ``Id SN respawning too fast: disabled for 5 minutes''

確定你的數據機有正確的配置．查看暫存器 `E` 和 `Q`． 這可能發生在你的數據機跟 `getty` 溝通的時候．

確定你正確地從 `/etc/inittab` 呼叫 `getty`． 使用錯誤的文法或設備名稱將會引起嚴重的問題．

以下法檢查你的 `/etc/gettydefs` 文法是否正確:

> `

>     linux# getty -c /etc/gettydefs

> `

這也可能發生在 `uugetty` 初使化失敗時．參閱 getty 或 uugetty 仍然無法運作 一節．

## 13.4 串列設備很慢或是串列設備只能單向傳送

你的硬體中斷可能有衝突．確定沒有硬體中斷是被分享的． 檢查你所有的卡(串列卡, 乙太網路卡, SCSI 等等)確定你串列設備配的跳接設定以及 `setserial` 參數是正確的． 同時檢查 `/proc/ioports` 及 `/proc/interrups` 以確定是否有衝突發生．

## 13.5 我的數據機在某人斷線後癱瘓或是 `uugetty` 並沒有重新執行

這在 DTR 訊號掉下而你的數據機沒有重置時會發生． 這個問題在我身上發生的時候我看到我的 RD 跟 SD LEDs 瘋狂地閃爍．你需要讓你的數據機重置． 大部份的 Hayes 相容數據機使用 `&D3` 來做這件事，但是在我的 USR Courier 上，我得要設 `&D2` 以及 `S13=1`．查閱你的數據機手冊．

## 13.6 我將我的終端機連到我的 PC 上，但是在我輸入簽入名稱之後，它就鎖住不動

- 如果你使用 `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

  > `

## 13.7 在高速下，我的數據機漏失資料

如果你嘗試在大於 38400 bps 的速率下使用你的數據機，而你並沒有 16550A UARTs 的話，你應該要將它們升級． 有關 UARTs 的說明參閱 什麼是 UARTs? 一節．

## 13.8 在系統啟動時，Linux 沒有依照我的配置回報串列設備．

這是事實．Linux 在系統啟動時並沒有做任何的 IRQ 偵測，它只做串列設備偵測． 所以，不要理會它所顯示有關硬體中斷的部份，因為它只是假定使用標準的硬體中斷． 這是因為硬體中斷偵測不可靠，而且可能被瞞騙而這樣做的．

所以即使我的 `ttyS2` 設在 IRQ5，我仍然看到

> `

>     Jan 23 22:25:28 misfits vmunix: tty02 at 0x03e8 (irq = 4) is a 16550A

> `

在 Linux 啟動時，你必須使用 `setserial` 來告訴 Linux 你所使用的硬體中斷． Linux 啟動後，你可以查看 `/proc/interrupts` 檔以了解真正被配置的 IRQ 是什麼．

## 13.9 當我使用我的數據機叫用 Linux 機器時 `rz` 以及/或是 `sz` 不動

如果 Linux 在你嘗試傳送檔案時會尋找 `/dev/modem` 的話，查看 `/etc/profile` 以及 `/etc/csh.cshrc`． 某些發行套件會在這些地方定義一些別名，最著名的是 Slackware． 這些別名擾亂了 zmodem 程式．把它們拿掉或是更正它們．

## 13.10 我的螢幕印出看起來很好玩的字元

這在當你把二進位資料送往螢幕的時候會發生在虛擬控制台上，或者有時候會發生在串列連線上． 修復這個問題的方法是輸入 `echo ^v^[c`．因為控制字元之故，它是:

> `

>     linux% echo <ctrl>v<esc>c

> `

## 13.11 `getty` 或 `uugetty` 仍然無法運作

`getty_ps` 上有個 `DEBUG` 選項．編輯你的 `/etc/conf.{uu}getty.ttyS`N 配置檔並加上 `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:ttyS`N 裡而 `uugetty` 的資訊則會出現在 `/tmp/uugetty:ttyS`N 裡，而且它們也會被放到 `/var/adm/getty.log` 裡去． 查看偵錯資訊看看發生了什麼．最可能的是，你將得要調整一些你配置檔裡的參數，並且重新配置你的數據機．

你應該也去試試 `mgetty`．有些人在使用它時更為幸運．

Next Previous Contents