错误消息也可能是类似“Modem not responding”（调制解调器未响应）的内容。至少有 4 个可能的原因
对于没有驱动程序的 Winmodem（或有缺陷的调制解调器），通常可以找到调制解调器所在的串行端口。但是，当 wvdial 程序（或任何其他程序）查询该端口时，由于 Winmodem 需要驱动程序才能执行任何操作，因此它不会得到响应。因此，您会看到一条消息，指出未找到调制解调器。但是，很可能在启动时检测到调制解调器卡，并且它会显示一条消息，暗示已找到调制解调器。因此，您被告知调制解调器已找到，但又未找到！这一切都意味着没有找到可用的调制解调器，因为找到了一个无法工作的调制解调器。当然，它可能由于其他原因而无法工作，而不是因为它是没有驱动程序的 Winmodem（或 Linmodem）。请参阅 基于软件的调制解调器（Winmodem、Linmodem）。
情况 2 和 3 意味着调制解调器不存在串行端口设备（例如 /dev/ttyS2）。如果您怀疑是这种情况，请参阅 找不到串行端口。
如果您幸运的话，问题是情况 4。那么您只需要找到您的调制解调器在哪一个 ttyS 上。
有一个程序可以查找常用串行端口上的调制解调器，称为“wvdialconf”。只需键入“wvdialconf <a-new-file-name>”。它将创建新文件作为配置文件，但除非您要使用“wvdial”进行拨号，否则您不需要此文件。请参阅 什么是 wvdialconf？ 不幸的是，如果您的调制解调器处于“在线数据”模式，wvdialconf 将报告“No modem detected”（未检测到调制解调器）。请参阅 minicom（测试调制解调器）
另一种尝试找出某个端口上是否有调制解调器的方法是在该端口上启动“minicom”（首先为该串行端口设置 minicom 之后。您需要保存设置，然后退出 minicom 并重新启动它）。然后键入“AT”，您应该看到“OK”。如果您没有看到，请尝试键入 ATQ0 V1 EI。如果您仍然没有得到 OK（并且可能甚至没有看到您键入的 AT），那么该端口上可能没有调制解调器。这可能是由于上述情况 1、2 或 3 造成的。
如果您键入的内容确实通过调制解调器，那么缺乏响应可能是由于调制解调器处于“在线数据”模式，此时它无法接受任何 AT 命令。您可能一直在使用调制解调器，然后突然断开连接（例如使用信号 9 终止进程）。在这种情况下，您的调制解调器没有重置为可以与 AT 命令交互的“命令模式”。“Minicom”可能会显示“You are already online. Hangup first.”（您已在线。请先挂断。）（有关此 minicom 消息的另一种含义，请参阅 您已在线！请先挂断。）好吧，您有点在线，但您可能没有通过电话线连接到任何东西。Wvdial 会报告“modem not responding”（调制解调器未响应）的相同情况。
要解决此问题，作为最后的手段，您可以重新启动计算机。另一种尝试解决此问题的方法是向调制解调器发送 +++，以告知它从“在线数据模式”退回到“命令模式”。在 +++ 序列的两侧必须有大约 1 秒的延迟（在“保护时间”内未发送任何内容）。如果另一个进程正在使用调制解调器，则这可能不起作用，因为 +++ 序列可能会与其他字符插入它们之间或 +++ 之后（在保护时间内）结束。具有讽刺意味的是，即使调制解调器线路空闲，键入意外的 +++ 也可能会引发控制数据包的交换（您永远看不到），这将违反所需的保护时间，从而使 +++ 无法达到您的预期效果。+++ 通常在名为“挂断字符串”的字符串中，因此如果您命令 minicom（或类似程序）挂断，则可能会起作用。另一种方法是退出 minicom，然后再次运行 minicom。
除了对 AT 没有响应之外，您在 minicom 中可能观察到的其他问题是
这意味着什么取决于发送它的程序。调制解调器实际上可能正在使用中（忙）。SuSE 发行版报告的另一个原因是可能存在两个串行驱动程序而不是一个。一个驱动程序内置于内核中，第二个是模块。
在 kppp 中，当尝试获取/设置串行端口“stty”参数失败时，会发送此消息。（它类似于尝试使用“stty -F /dev/ttySx”时可能得到的“Input/output error”（输入/输出错误））。要获取其中一些 stty 参数，驱动程序必须知道端口的真实地址。因此，驱动程序可能具有错误的地址。“setserial”命令将显示驱动程序的想法，但在这种情况下，它很可能是错误的。因此，“modem busy”（调制解调器忙）通常意味着找不到串行端口（以及调制解调器）。
如果您有 pci 调制解调器，请使用以下命令之一：lspci -v 或 cat /proc/pci 或 dmesg 来查找调制解调器串行端口的正确地址和 irq。然后检查“setserial”是否显示相同的内容。如果不是，您需要在启动时运行一个脚本，其中包含一个 setserial 命令，该命令将告诉驱动程序正确的地址和 irq。
调制解调器的 CD 信号已开启。要么您实际上已在线（远程调制解调器正在向您发送载波），要么您的调制解调器已设置为始终发送 CD 信号。在 minicom 中，键入 at&v 以查看是否设置了 &C 或 &C0。如果是，即使您处于离线状态，CD 也会开启，并且您会错误地收到此错误消息。解决方法是在初始化字符串中设置 &C1 或将其保存在调制解调器中。
线路上的噪声必须非常低，才能以接近 56k 的速度工作。某些电话线路非常糟糕，以至于可获得的速度远低于 56k（例如 28.8k 甚至更慢）。有时，连接到同一线路的分机电话可能会导致问题。要测试这一点，您可以将调制解调器直接连接到电话线进入建筑物的位置，并断开该线路上其他所有设备的馈线（如果其他人可以容忍此类测试）。
流控制（在您的 PC 和/或调制解调器到调制解调器之间）可能未启用。对于上传情况：如果您设置了较高的 DTE 速度（例如 115.2k），那么从您的调制解调器到您的 PC 的流量可能工作正常，但是由于电话线路瓶颈，另一个方向的上传流量将无法完全通过。这将导致许多错误和数据包的重新发送。因此，发送文件可能需要太长时间。在某些情况下，文件根本无法通过。
对于下载情况：如果您正在下载长的未压缩文件或网页（并且您的调制解调器使用数据压缩），或者如果您设置了较低的 DTE 速度，那么由于没有流量控制，下载也可能损坏。
确保您为您的 init 版本使用了正确的语法。不同的 init 版本在 /etc/inittab 文件中使用不同的语法。确保您为您的 getty 版本使用了正确的语法。
Id "S4" 只是一个例子。在这种情况下，请查看 /etc/inittab 中以“S4”开头的行，并调用 getty。此行导致了问题。确保此行的语法正确，并且设备 (ttyS4) 存在且可以找到。如果调制解调器已否定 CD 并且 getty 打开了端口，您将收到此错误消息，因为否定 CD 将终止 getty。然后 getty 将重新生成，但会再次被终止，等等。因此，它会一遍又一遍地重新生成（速度过快）。似乎如果连接到调制解调器的电缆已断开连接，或者您使用了错误的串行端口，则就像 CD 被否定了一样。当您的调制解调器与 getty 聊天时，所有这些都可能发生。确保您的调制解调器配置正确。查看 AT 命令 E 和 Q。
如果您使用 uugetty，请通过执行以下操作来验证您的 /etc/gettydefs 语法是否正确
linux# getty -c /etc/gettydefs
当 uugetty 初始化失败时，也会发生这种情况。请参阅 uugetty 仍然无法工作 部分。
一种可能的原因是，当有人挂断后 DTR 掉线时，您的调制解调器无法正确重置。大多数 Hayes 兼容调制解调器使用 &D3 可以正常执行此操作。但是对于 USR Courier、SupraFax 和其他一些调制解调器，您必须设置 &D2（在某些情况下为 S13=1）。查看您的调制解调器手册（如果您有的话）。请参阅 结束拨入呼叫
它的意思与字面意思完全相同。其他人可能正在同一条线路上使用另一部电话。如果未将电话线插入调制解调器，或者电话线以某种方式断开，您也会收到此错误。尝试将真正的电话插入调制解调器使用的电话线。检查是否有拨号音。
如果由于某种原因您的调制解调器未检测到拨号音，那么您可以通过在初始化字符串中放入 X3 来强制它仍然拨号。
这意味着来自另一台调制解调器的模拟正弦波（载波）不存在，就像它应该存在一样。如果您已经连接，则表示连接已丢失。线路中可能存在噪声或连接不良。另一台调制解调器可能因某种原因挂断了您的电话：也许自动登录过程没有正常进行。也许 PPP 没有正常启动。也许超过了时间限制。
如果您在连接之前收到此错误，则表示您的调制解调器未检测到另一台调制解调器的载波。如果另一端没有正常工作的调制解调器，则可能会发生这种情况。例如，答录机可能接听了您的电话，而不是调制解调器。如果调制解调器未能协商要使用的协议，也会发生 NO CARRIER。如果您有一个早期的 V.90 调制解调器，它首先尝试协商高速 X2 或 K56flex 协议，则可能会发生这种情况。这两种协议已过时，并且当发生这种情况时，某些 ISP 服务器将断开连接（挂断），因为它们不了解此类协议，并且不会等待足够长的时间让呼叫调制解调器回退到 V.90。
如果您通过断开 DTR 信号或向调制解调器发送挂断信号 (ATH) 来强制调制解调器断开连接，您可能会收到此错误消息。但在这种情况下，您（或您的软件）想要断开连接，因此应该没有问题。在这种情况下，只有在数据丢失时，您才应该收到 NO CARRIER。因此，对于大多数通过挂断（或通过断开 DTR）断开连接的情况，您只会收到 OK 消息。您的调制解调器拨号程序甚至可能不会向您显示该消息。
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，信息将出现在 /tmp/getty:ttySN 中以进行 getty 调试，以及 /tmp/uugetty:ttySN 中以进行 uugetty 调试，以及 /var/adm/getty.log 中。查看调试信息，看看发生了什么。最有可能的是，您需要调整配置文件中的某些参数，并重新配置您的调制解调器。
您也可以尝试 mgetty。有些人使用它时运气更好。
有 3 种可能性
首先检查启动时的 BIOS 消息（以及串行端口的 BIOS 菜单）。然后对于 PCI 总线类型，运行 lspci -v。如果这显示类似“LPC Bridge”的内容，那么您的端口很可能在 LPC 总线上，Linux 对 LPC 总线的支持还不好（但 BIOS 可能会找到它）?? 如果它是 ISA 总线 PnP 串行端口，请尝试“pnpdump --dumpregs”和/或参阅 Plug-and-Play-HOWTO。如果端口恰好已启用，则以下两段可能有助于找到 IO 端口
这主要用于旧式非 PCI 端口和非即插即用的 ISA 端口。
使用“scanport”（仅限 Debian??）将扫描所有已启用的总线端口，并且可能会发现一个未知的端口，该端口可能是串行端口（但它不会探测该端口）。它可能会使您的 PC 挂起。如果您怀疑您的端口可能位于某个地址，您可以尝试使用 setserial 手动探测，但如果您有多个地址要探测，这是一个缓慢而乏味的任务。请参阅 探测。
如果您的 PC 的 BIOS 可以处理 ISA（也可能可以处理 PCI），那么如果您发现 IRQ 冲突，可能是由于可用 IRQ 短缺造成的。BIOS 通常维护一个保留 IRQ 列表，这些 IRQ 保留给旧式 ISA 卡。如果保留的 IRQ 过多，BIOS 可能无法找到空闲 IRQ，并且会错误地为串行端口分配一个 IRQ，从而导致冲突。因此，请检查所有保留的 IRQ 是否真的需要，如果不需要，请取消保留串行端口可以使用的 IRQ。有关更多详细信息，请参阅 Plug-and-Play-HOWTO。
很可能是错误设置/冲突的中断。以下是一些症状，这些症状将在您第一次尝试使用调制解调器、终端或串行打印机时发生。在某些情况下，您键入了一些内容，但直到几秒钟后屏幕上才显示任何内容。可能只显示最后键入的字符。它可能只是一个不可见的 <return> 字符，因此您只会注意到光标向下跳了一行。在其他情况下，应该在屏幕上显示大量数据，但只出现大约 16 个字符的批次。然后，需要等待很长时间（几秒钟）才能显示下一批字符。您可能还会收到“input overrun”（输入溢出）错误消息（或在日志中找到它们）。
有关症状以及发生这种情况的原因的更多详细信息，请参阅 Serial-HOWTO 部分：“中断问题详细信息”。
如果它涉及即插即用设备，另请参阅 Plug-and-Play-HOWTO。
作为快速检查以查看它是否真的是中断问题的方法，请使用“setserial”将 IRQ 设置为 0。这将告诉驱动程序使用轮询而不是中断。如果这似乎解决了“慢”问题，那么您遇到了中断问题。您仍然应该尝试解决该问题，因为轮询会过度使用计算机资源。
检查以查找中断冲突可能不容易，因为 Linux 据说不允许任何中断冲突，并且如果它认为您正在尝试创建冲突，则会向您发送 /dev/ttyS?: Device or resource busy 错误消息。但是，如果“setserial”告诉内核不正确的信息，则可能会创建真正的冲突。内核已被欺骗，因此不认为存在任何冲突。因此，使用“setserial”不会揭示冲突（查看 /proc/interrupts 也不会，/proc/interrupts 的信息基于“setserial”）。您仍然需要知道“setserial”的想法，以便您可以查明它的错误之处，并在确定硬件中实际设置的内容时进行更改。
您需要做的是通过检查跳线或使用 PnP 软件来检查硬件的设置方式，以检查硬件的实际设置方式。对于 PnP，运行“pnpdump --dumpregs”（如果是 ISA 总线）或运行“lspci”（如果是 PCI 总线）。将此与 Linux（例如“setserial”）认为硬件的设置方式进行比较。
一个明显的原因是波特率设置得太慢。据称，这曾经发生在尝试将波特率设置为高于硬件可以支持的速度（例如 230400）时。
另一个原因可能是串行端口上的任何东西（例如调制解调器、终端、打印机）都没有您想象的那么快地工作。56k 调制解调器很少以 56k 的速度工作，并且互联网经常存在拥塞和瓶颈，这会减慢速度。如果另一端的调制解调器没有与电话线的数字连接（并且使用大多数计算机商店不出售的特殊“数字调制解调器”），则不可能达到 33.6k 以上的速度。
另一个可能的原因是您有一个过时的串行端口：UART 8250、16450 或早期的 16550（或者串行驱动程序认为您有）。请参阅 Serial-HOWTO 中的“什么是 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 上产生电压。因此出现“cannot open”（无法打开）消息。要么设置 clocal，要么将串行端口连接器连接到某些东西并为其通电。
即使设备已通电并连接到端口，有时也可能会阻止打开端口。一个例子是设备已否定 CD，而您 PC 上的 CD 引脚也被否定（负电压）。
这意味着 setserial、stty 等请求的操作无法完成，因为内核不支持这样做。以前，这通常是由于未加载“serial”模块造成的。但是，随着 PnP 的出现，它可能很可能意味着在驱动程序（和 setserial）认为的地址处没有调制解调器（或其他串行设备）。如果那里没有调制解调器，那么发送到该地址的命令（用于操作）显然不会完成。请参阅 我的串行端口硬件中设置了什么？
如果“serial”模块未加载，但“lsmod”显示您现在已加载它，则可能是现在已加载，但在您收到错误消息时未加载的情况。在许多情况下，模块会在需要时自动加载（如果可以找到）。要强制加载“serial”模块，可以将其列在文件：/etc/modules.conf 或 /etc/modules 中。实际模块应位于：/lib/modules/.../misc/serial.o。
有时，当无法创建锁定文件时，您会收到错误的错误消息：“... Device or resource busy”（设备或资源忙）而不是上面的消息。当程序“打开”端口时，会在 /var/lock/ 中创建一个锁定文件。锁定目录的错误权限将不允许在该处创建锁定文件。使用“ls -ld /var/lock”查看权限是否正常。为 root 所有者和组提供 rwx 权限应该可以工作，前提是需要拨号输出的用户属于该组。其他人应该具有 r-x 权限。即使使用此方案，也可能存在安全风险。使用“chmod”更改权限，使用“chgrp”更改组。当然，如果没有“lock”目录，则无法在该处创建锁定文件。有关锁定文件的更多信息，请参阅 Serial-HOWTO 小节：“什么是锁定文件”。
这意味着其他人（或其他进程）据说正在使用串行端口。有多种方法可以尝试找出哪个进程正在“使用”它。一种方法是查看锁定文件 (/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，并且您仅启动其中一台设备，则一切正常，因为尚未发生冲突。但是，当您接下来尝试启动第二台设备（而不退出第一台设备）时，您会收到“... busy”（... 忙）错误消息。这是因为内核仅跟踪实际使用的 IRQ，并且实际冲突仅在设备正在使用（打开）时才会发生。I/O 地址（例如 0x3f8）冲突的情况类似。
此错误有时是由于有两个串行驱动程序引起的：一个是模块，另一个编译到内核中。两个驱动程序都试图抢占相同的资源，并且一个驱动程序发现它们“忙”。
当您看到此消息时，有两种可能的情况
ttyS2 无法使用的唯一原因是 setserial 错误地预测了冲突。您需要做的是找到 setserial 认为 ttyS2 正在使用的中断。查看 /proc/tty/driver/serial。您还应该能够使用 ttyS2 的“setserial”命令找到它。
旧版本中的错误：在 2001 年之前的版本中存在一个错误，该错误会导致您无法使用 “setserial” 查看串口信息。尝试查看时会给出相同的 “... busy” 错误消息。
要尝试解决此问题，请重启或：退出或正常终止所有可能冲突的进程。 如果您重启：1. 观察启动时串口的相关信息。 2. 期望在启动时运行 “setserial” 的文件本身不会再次造成相同的冲突。
如果您认为您知道 ttyS2 正在使用的 IRQ，您可以查看 /proc/interrupts 以查找当前还有什么（除了另一个串口）正在使用此 IRQ。您可能还需要仔细检查此处（以及通过 “setserial” 显示的）任何可疑的 IRQ 是否正确（与硬件中设置的相同）。测试是否存在潜在中断冲突的一种方法是使用 “setserial” 将 IRQ 设置为 0（轮询）。然后，如果 busy 消息消失，则很可能存在潜在的中断冲突。 不建议将其永久设置为 0，因为它会增加 CPU 的负载。
这意味着与串口的通信无法正常工作。 这可能意味着在 setserial 认为您的端口所在的 IO 地址处，实际上没有串口。 也可能是中断冲突（或 IO 地址冲突）。 这也可能意味着串口正在使用中（忙碌或已打开），因此 setserial 或 stty 获取/设置参数的尝试失败。 如果您在串口名称中输入了错误，例如输入 “ttys” 而不是 “ttyS”，也会发生这种情况。
LSR 是一个硬件寄存器的名称。 它通常意味着在驱动程序认为您的串口所在的地址处，没有串口。 您需要找到您的串口，并可能需要配置它。 请参阅 定位串口：IO 地址 IRQ 和/或 什么是 Setserial
这是硬件 FIFO 缓冲区溢出，您无法增加其大小。 错误提示（在 2002 年报告）：由于某些 2.4 版本内核中的错误，端口号可能会丢失，您只会看到 “ttyS”（没有端口号）。 但是，如果正在使用诸如 “tts/2” 之类的 devfs 表示法，则没有此错误。 请参阅 Serial-HOWTO 中的 “Higher Serial Thruput”。
此段落适用于调制解调器既用于拨入又用于拨出的情况。 如果调制解调器生成 DCD (=CD) 信号，某些程序（但不是 mgetty）会认为调制解调器正忙。 当您尝试使用调制解调器拨出，而调制解调器的 DCD 或 DTR 未正确实现时，这将导致问题。 调制解调器应仅在存在实际连接时（即有人拨入时）才断言 DCD，而不是在 getty 监视端口时。 检查以确保您的调制解调器配置为仅在存在连接时才断言 DCD (&C1)。 当 getty、kermit 或其他通信程序正在使用或监视线路时，通信程序应始终开启（断言）DTR。
端口上可能正在运行其他程序。 使用 “top”（前提是您已将其设置为显示端口号）或键入 “ps -alxw”。 查看结果，看看端口是否正在被另一个程序使用。 注意 gpm 鼠标程序，它通常在串口上运行。
以下是您可能想要在故障排除中使用的一些程序