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