要确定你对你的 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 有些人在使用它时更为幸运