关于调制解调器或 getty 调制解调器的故障排除，请参阅 Modem-HOWTO。对于文本终端，这里的大部分信息以及 Text-Terminal-HOWTO 中的故障排除信息也很有价值。
虽然对于少量串行端口，您可能只需要一个万用表（用作电压表），但已经制造出简单的专用测试设备来测试串行端口线路。有些被称为“分线...” ，其中分线意味着从电缆中分出导体。这些小工具有一对连接器，可以连接到串行端口连接器（在串行电缆的末端或 PC 的背面）。有些有用于连接电压表的测试点。另一些则有 LED 灯，当某些调制解调器控制线被置为有效（开启）时会亮起。灯的颜色可能表示信号的极性（正电压或负电压）。还有一些带有跳线，因此您可以将任何导线连接到任何导线。有些带有开关。
Radio Shack（在 2002 年）销售一种“RS-232 故障排除器”（以前称为“RS-232 线路测试仪”）Cat. #276-1401。它检查 TD、RD、CD、RTS、CTS、DTR 和 DSR。绿灯表示开启（+12 v），红灯表示关闭（-12 v）。他们还销售一种“RS-232 串行跳线盒”Cat. #276-1403。这允许您以您选择的任何方式连接引脚。这两件商品都属于“外围设备连接助手”的范畴。不幸的是，它们没有列在印刷目录的索引中。它们与 D 型连接器在同一页上，所以在索引中查找“Connectors, Computer, D-Sub”。名为“Active Components”的连锁店可能有售。
任何电压表或万用表，即使是最便宜的售价约为 10 美元的，也应该可以正常工作。尝试使用其他方法检查电压是很棘手的。不要使用 LED，除非它有一个串联电阻来降低 LED 上的电压。470 欧姆电阻用于 20 ma LED（但并非所有 LED 都是 20 ma）。LED 只会在特定极性下亮起，因此您可以测试正电压或负电压。是否有人制造用于汽车电路测试的这种小工具？如果您尝试使用逻辑探头，可能会损坏它们，因为它们设计的 TTL 电压只有 5 伏。尝试使用 12 V 白炽灯泡不是一个好主意。它不会显示极性，并且由于 UART 的输出电流有限，它甚至可能不会亮起。
要测量母连接器上的电压，您可以将弯曲的回形针插入所需的开口中。回形针的直径应不大于引脚，以免损坏触点。将鳄鱼夹（或类似物）夹在回形针上进行连接。注意不要用任何金属物体同时接触两个引脚。
作为最后的手段，如果您没有测试设备并且愿意承担触电（甚至触电身亡）的风险，您可以随时品尝电压。在用舌头接触其中一个测试引线之前，先测试它们以确保它们上没有高压。同时用双手接触两个引线，看看它们是否会电击您。如果没有电击，则用舔舐的方式润湿皮肤接触点并重复。如果此测试给您带来电击，您当然不想用舌头。
对于 12 V 的测试，舔一下手指并握住一个测试引线。将另一个测试引线放在舌头上。如果舌头上的引线是正极，则会有一种明显的味道。您可以先用手电筒电池尝试一下，这样您就会知道期望的味道是什么。
一些 Linux 程序将监控调制解调器控制线，并指示它们是正极 (1) 还是负极 (0)。请参阅 串行监控/诊断 部分
有 3 种可能性
首先检查启动时的 BIOS 消息（以及可能的 BIOS 菜单中的串行端口）。然后对于 PCI 总线类型，使用 lspci -v。如果这显示类似“LPC Bridge”的内容，则您的端口可能在 LPC 总线上，Linux 尚不支持该总线（但 BIOS 可能会找到它）？如果它是 ISA 总线 PnP 串行端口，请尝试“pnpdump --dumpregs”和/或参阅 Plug-and-Play-HOWTO。如果端口恰好已启用，则以下两段可能有助于找到 IO 端口
这主要用于旧式非 PCI 端口和非即插即用的 ISA 端口。
使用“scanport”（仅限 Debian？）将扫描所有已启用的总线端口，并且可能会发现一个未知的端口，该端口可能是串行端口（但它不会探测该端口）。它可能会使您的 PC 挂起。如果您怀疑您的端口可能在某个地址，您可以尝试使用 setserial 手动探测，但如果您有多个地址要探测，这将是一项缓慢而乏味的任务。请参阅 探测。
如果您的 PC 具有处理 ISA（以及可能的 PCI）的 BIOS，那么如果您发现 IRQ 冲突，可能是由于可用 IRQ 短缺。BIOS 通常维护一个保留 IRQ 列表，为旧式 ISA 卡保留。如果保留了太多，BIOS 可能无法找到空闲的 IRQ，并且会错误地为串行端口分配一个 IRQ，从而造成冲突。因此，检查以查看是否真的需要所有保留的 IRQ，如果不需要，则取消保留串行端口可以使用的 IRQ。有关更多详细信息，请参阅 Plug-and-Play-HOWTO。
这很可能是错误设置/冲突的中断。以下是一些症状，当您第一次尝试使用调制解调器、终端或串行打印机时会发生这些症状。在某些情况下，您键入了一些内容，但屏幕上没有任何显示，直到几秒钟后。可能只显示最后键入的字符。它可能只是一个不可见的 <return> 字符，因此您注意到的只是光标向下跳了一行。在其他情况下，当应该在屏幕上显示大量数据时，只会出现大约 16 个字符的批次。然后会有很长时间的等待，等待几秒钟才能显示下一批字符。您可能还会收到“input overrun”错误消息（或在日志中找到它们）。
有关症状以及发生原因的更多详细信息，请参阅 中断问题详细信息 和/或 中断冲突 和/或 错误设置的中断。如果它涉及即插即用设备，另请参阅 Plug-and-Play-HOWTO。
作为快速检查以查看它是否真的是中断问题的方法，请使用“setserial”将 IRQ 设置为 0。这将告诉驱动程序使用轮询而不是中断。如果这似乎解决了“缓慢”问题，那么您遇到了中断问题。您仍然应该尝试解决问题，因为轮询会过度使用计算机资源。
检查以查找中断冲突可能不容易，因为 Linux 据说不允许任何中断冲突，如果它认为您正在尝试创建冲突，它会向您发送 /dev/ttyS?: 设备或资源忙 错误消息。但是，如果“setserial”告诉内核不正确的信息，则可能会创建真正的冲突。内核被欺骗了，因此不认为存在任何冲突。因此，使用“setserial”不会揭示冲突（查看 /proc/interrupts 也不会，它基于“setserial”的信息）。您仍然需要知道“setserial”的想法，以便您可以查明它的错误之处，并在确定硬件中实际设置的内容时进行更改。
您需要做的是通过检查跳线或使用 PnP 软件来检查硬件的设置方式，以检查硬件的实际设置方式。对于 PnP，运行“pnpdump --dumpregs”（如果是 ISA 总线）或运行“lspci”（如果是 PCI 总线）。将此与 Linux（例如“setserial”）认为硬件的设置方式进行比较。
一个明显的原因是波特率设置得太慢。据称，这种情况曾经发生在尝试将波特率设置为高于硬件支持的速度（例如 230400）时。
另一个原因可能是串行端口上的任何东西（例如调制解调器、终端、打印机）的工作速度没有您想象的那么快。
另一个可能的原因是您有一个过时的串行端口：UART 8250、16450 或早期 16550（或者串行驱动程序认为您有）。请参阅
什么是 UART？ 使用“setserial -g /dev/ttyS*”。如果它显示任何低于 16550A 的值，这可能是您的问题。如果您认为“setserial”弄错了，请检查一下。请参阅 什么是 Setserial 了解更多信息。如果您真的有一个过时的串行端口，对 setserial 说谎只会让事情变得更糟。
对于非 PnP 端口，Linux 在启动时不执行任何 IRQ 检测。当串行模块加载时，它只执行串行设备检测。因此，请忽略它关于 IRQ 的说法，因为它只是假设标准 IRQ。这样做是因为 IRQ 检测不可靠，并且可能会被欺骗。但是，当 setserial 从启动脚本运行时，它会更改 IRQ，并在启动屏幕上显示新的（希望是正确的）状态。如果错误的 IRQ 没有在屏幕上的后续显示中得到纠正，那么您就遇到了问题。
所以，即使我将我的 ttyS2 设置为 IRQ 5，我仍然看到
ttyS02 at 0x03e8 (irq = 4) is a 16550A
setserial 来告诉 Linux 您正在使用的 IRQ。
请参阅 /dev/tty? 设备或资源忙
使用“ls -l /dev/ttyS?”检查此端口的文件权限。如果您拥有 ttyS?，那么您需要读取和写入权限：crw，其中 c（字符设备）在第 1 列中。如果您不拥有它，那么如果它在第 8 列和第 9 列中显示 rw-，则它将对您有效，这意味着每个人都对其具有读取和写入权限。使用“chmod”更改权限。还有更复杂（和安全）的方法来获取访问权限，例如属于具有组权限的“组”。某些程序在运行时会更改权限，但在程序正常退出时会恢复权限。但是，如果有人拔掉 PC 的插头，则会异常退出，并且可能无法恢复正确的权限。
除非为 clocal 设置了 stty，否则可能需要断言 CD 引脚才能打开串行端口。如果物理端口未连接到任何东西，或者如果它连接到未通电的东西（例如外部调制解调器），则来自该设备的 CD 上将没有电压。因此出现“无法打开”消息。设置 clocal 或将串行端口连接器连接到某物并为其供电。
即使设备已通电并连接到端口，有时也可能阻止打开端口。这方面的一个例子是设备已否定 CD，并且 PC 上的 CD 引脚被否定（负电压）。
这意味着 setserial、stty 等请求的操作无法完成，因为内核不支持这样做。以前，这通常是由于未加载“serial”模块。但是随着 PnP 的出现，它很可能意味着在驱动程序（和 setserial）认为它所在的地址处没有调制解调器（或其他串行设备）。如果没有调制解调器在那里，发送到该地址的命令（用于操作）显然不会完成。请参阅 我的串行端口硬件中设置了什么？
如果未加载“serial”模块，但“lsmod”显示它现在已加载，则可能是它现在已加载，但在您收到错误消息时未加载。在许多情况下，模块将在需要时自动加载（如果可以找到）。要强制加载“serial”模块，它可以列在文件中：/etc/modules.conf 或 /etc/modules。实际模块应位于：/lib/modules/.../misc/serial.o。
有时，当无法创建锁文件时，您会收到错误的错误消息：“... 设备或资源忙”，而不是上面的错误消息。当程序“打开”端口时，会在 /var/lock/ 中创建一个锁文件。锁目录的错误权限将不允许在那里创建锁文件。使用“ls -ld /var/lock”查看权限是否正常。为 root 所有者和组提供 rwx 权限应该有效，前提是需要拨号的用户属于该组。其他人应该具有 r-x 权限。即使使用此方案，也可能存在安全风险。使用“chmod”更改权限，使用“chgrp”更改组。当然，如果没有“lock”目录，则无法在那里创建锁文件。有关锁文件的更多信息，请参阅 什么是锁文件
这意味着其他人（或其他进程）据称正在使用串行端口。有多种方法可以尝试找出哪个进程正在“使用”它。一种方法是查看锁文件 (/var/lock/LCK...) 的内容。它应该是进程 ID。如果进程 ID 例如是 100，则键入“ps 100”以查明它是什么。然后，如果不再需要该进程，可以通过“kill 100”优雅地终止它。如果它拒绝被终止，请使用“kill -9 100”强制终止它，但这样锁文件将不会被删除，您需要手动删除它。当然，如果没有 100 这样的进程，那么您可以只删除锁文件，但在大多数情况下，如果锁文件包含过时的进程 ID（例如 100），则应自动删除锁文件。
这意味着您尝试访问（或使用）的设备据称正忙（正在使用中），或者它需要的资源（例如 IRQ）据称正被另一个设备使用，并且无法共享。如果它仅表示设备正忙（正在使用中），则此消息很容易理解。但有时这意味着所需的资源已在使用中（忙）。更令人困惑的是，在某些情况下，设备及其需要的资源实际上都不是“忙碌”的。
在过去，如果 PC 通过直接关闭电源来关机，则可能会留下伪造的锁文件，然后在以后会收到此伪造的消息，并且无法使用串行端口。今天的软件应该会自动删除此类伪造的锁文件，但截至 2006 年，“wvdial”拨号程序仍然存在与锁文件相关的问题。如果 wvdial 无法创建锁文件，因为它在 /var/lock/ 目录中没有写入权限，您将看到此错误消息。请参阅 无法创建锁文件。抱歉
以下示例是无法共享中断的情况（至少其中一个中断在 ISA 总线上）。“资源忙”部分通常意味着（例如 ttyS2）“您无法使用 ttyS2，因为另一个设备正在使用 ttyS2 的中断。”潜在的中断冲突是从“setserial”的想法中推断出来的。更准确的错误消息将是“无法使用 ttyS2，因为 setserial 数据（和内核数据）表明另一个设备正在使用 ttyS2 的中断”。如果两个设备使用相同的 IRQ，并且您只启动其中一个设备，则一切正常，因为尚无冲突。但是，当您下次尝试启动第二个设备（而不退出第一个设备）时，您会收到“... 忙”错误消息。这是因为内核只跟踪实际使用的 IRQ，并且除非设备正在使用（打开），否则不会发生实际冲突。I/O 地址（例如 0x3f8）冲突的情况类似。
此错误有时是由于有两个串行驱动程序造成的：一个模块，另一个编译到内核中。这两个驱动程序都尝试抢占相同的资源，并且一个驱动程序发现它们“忙”。
当您看到此消息时，有两种可能的情况
ttyS2 的唯一原因是 setserial 错误地预测了冲突。您需要做的是找到 setserial 认为 ttyS2 正在使用的中断。查看 /proc/tty/driver/serial。您还应该能够使用 ttyS2 的“setserial”命令找到它。
旧版本中的错误：在 2001 年之前，存在一个错误，该错误不允许您使用“setserial”查看它。尝试查看它会给出相同的“... 忙”错误消息。
要尝试解决此问题，请重新启动或：退出或优雅地终止所有可能的冲突进程。如果您重新启动：1. 观察启动时串行端口的消息。2. 希望在启动时运行“setserial”的文件不会（本身）再次创建相同的冲突。
如果您认为您知道 IRQ，例如 ttyS2 正在使用，那么您可以查看 /proc/interrupts 以查找当前还有哪些（除了另一个串行端口）正在使用此 IRQ。您可能还想仔细检查此处（以及通过“setserial”）显示的任何可疑 IRQ 是否正确（与硬件中设置的相同）。测试它是否是潜在中断冲突的一种方法是使用“setserial”将 IRQ 设置为 0（轮询）。然后，如果忙消息消失，则很可能是潜在的中断冲突。永久将其设置为 0 不是一个好主意，因为它会增加 CPU 的负载。
这意味着与串行端口的通信无法正常工作。这可能意味着在 setserial 认为您的端口所在的 IO 地址处没有任何串行端口。它也可能是中断冲突（或 IO 地址冲突）。这也可能意味着串行端口正在使用中（忙或已打开），因此 setserial 或 stty 获取/设置参数的尝试失败。如果您在串行端口名称中犯了错误，例如键入“ttys”而不是“ttyS”，也会发生这种情况。
LSR 是硬件寄存器的名称。它通常意味着在驱动程序认为您的串行端口所在的位置没有串行端口。您需要找到您的串行端口并可能对其进行配置。请参阅 定位串行端口：IO 地址 IRQ 和/或 什么是 Setserial
这是硬件 FIFO 缓冲区的溢出，您无法增加其大小。错误注释（2002 年报告）：由于某些内核 2.4 版本中的错误，端口号可能会丢失，您只会看到“ttyS”（没有端口号）。但是，如果使用了 devfs 表示法（例如“tts/2”），则没有错误。请参阅 更高的串行吞吐量。
可能还有一些其他程序在端口上运行。使用“top”（前提是您已将其设置为显示端口号）或键入“ps -alxw”。查看结果以查看端口是否正在被另一个程序使用。注意 gpm 鼠标程序，它通常在串行端口上运行。
以下是一些您可能想在故障排除中使用的程序
可能是波特率不匹配。如果一个端口以另一个端口设置为接收速度的两倍速度发送，那么每发送两个字符将被接收为一个字符。此接收字符的每个位将是对发送内容的两个位的采样，并且将是错误的。此外，似乎只收到发送字符的一半。对于反方向的流量，情况正好相反。接收到的字符是发送字符的两倍。更糟糕的不匹配会产生更糟糕的结果。
速度不匹配不太可能发生在调制解调器上，因为调制解调器会自动检测速度。速度不匹配的一个原因可能是由于串行端口硬件已设置为以非常快的速度运行。它实际上可能以比您（或应用程序）通过软件设置的速度快 8 倍的速度运行。请参阅 非常高的速度