2.3. 选择串行速度和参数

串行链路的速度，单位为每秒位数。

现代 PC 上的 Linux 内核支持 1200、2400、4800、9600、19200、38400、57600 和 115200 每秒位数的串行控制台速度。

当串行接口不被用作串行控制台时，内核支持更广泛的串行比特率。[1]

最新的 Linux 内核还可以通过 USB 串行适配器提供串行控制台，速度为 1200、2400、4800、9600、19200、38400、57600 和 115200 每秒位数。

大多数引导加载程序仅支持与内核支持的速度范围不同的速度。LILO 21.7.5 支持 110、150、300、600、1200、2400、4800、9600、19200、38400、56000、57600 和 115200 每秒位数。SYSLINUX 1.67 支持 75 到 56000 每秒位数。GRUB 0.90 支持 2400、4800、9600、19200、38400、57600 和 115200 每秒位数。

您必须为引导加载程序和 Linux 内核选择相同的速度。一个操作系统可能使用多个引导加载程序。例如，Red Hat Linux 使用 SYSLINUX 来安装或升级操作系统；LILO 作为 Red Hat Linux 7.1 及更早版本的引导加载程序；以及 GRUB 作为 Red Hat Linux 7.2 及更高版本的引导加载程序。

如果您正在使用串行终端，或者您正在使用哑调制解调器，那么终端或哑调制解调器的比特率也必须与引导加载程序和内核中选择的比特率相匹配。

如果串行控制台连接到速度低于 9600bps 的 Hayes 兼容调制解调器，则将串行控制台配置为与调制解调器相同的速度。速度高于 9600bps 的调制解调器通常会自动同步到串行端口的速度。

所选比特率还必须受串行端口的 UART 半导体芯片支持。早期没有片上接收缓冲区的 UART 只能可靠地接收高达 14400bps 的速度，这包括型号 8250A、82510、16450 和 16550（没有 A）。最近带有接收缓冲区的 UART 将在所有串行控制台比特率下工作，这包括型号 16550A、16552、16650、16654、16750、16850 和 16950。

除非您有充分的理由，否则请使用流行的每秒 9600 位比特率。这是许多设备的默认比特率。

内核、三个通用引导加载程序以及所有能够运行 Linux 的 IBM PC 支持的速度是：每秒 2400、4800、9600 和 19200 位。这是一个令人沮丧的小选择：速度不够慢，无法支持国际电话线路上的呼叫，速度也不够快，无法上传大型文件。您可能需要选择一个速度，这将导致软件配置的鲁棒性降低。

奇偶校验位的数量以及存在奇偶校验位时的解释。

允许的值是n表示没有奇偶校验位，e表示一个偶校验位，以及o表示一个奇校验位。

建议使用无奇偶校验位和八个数据位。

如果使用奇偶校验，则偶校验是常见的选择。

奇偶校验是一种简单的错误检测形式。现代调制解调器具有更好的错误检测和纠正功能。因此，奇偶校验位仅保护调制解调器和串行端口之间电缆上的数据。如果这条电缆的误码率很低（应该如此），则不需要奇偶校验位。

每个字符的数据位数。

允许的值是7位，或8位，因为 Linux 使用 ASCII 字符集，该字符集至少需要七位。

建议使用八个数据位。这使得该链路可以轻松地用于文件传输，并允许呈现非英语文本。

停止位时长的数量。[2]

允许的值是1或2.

建议使用一个停止位时长。

如果 RS-232 电缆非常长，则可能需要两个停止位时长。

您偶尔可能会看到 1.5 个停止位时长。目的是当链路对于一个停止位时长来说太长，但对于两个停止位时长来说又太短时，获得 4% 以上的数据吞吐量。1.5 个停止位时长现在已经足够罕见，以至于使用它会很危险。

要使用的流控制类型。

Linux 内核允许无流控制和 CTS/RTS 流控制。

默认情况下不进行流控制，这通过省略 <flow_control> 来表示。

建议使用 CTS/RTS 流控制，特别是如果还为串行端口提供登录访问权限。这由 <flow_control> 的r.

CTS/RTS 流控制调节字符的流动。计算机在调制解调器声明“清除发送”之前不会发送字符。如果计算机有足够的缓冲来接收来自调制解调器的字符，则计算机声明“准备发送”。因此，计算机和调制解调器的缓冲区都不会被填满而溢出。

内核的 CTS/RTS 流控制目前存在错误。如果启用了流控制，但永远不会声明 CTS（当调制解调器上没有呼叫或空调制解调器电缆或到终端服务器的电缆上没有会话时会发生这种情况），则机器可能需要很长时间才能写入控制台消息。由于内核启动时的大量内核消息，配置了内核 CTS/RTS 流控制的机器可能需要几分钟才能重新启动。 目前不建议使用内核的 CTS/RTS 流控制。HOWTO 的作者有一个内核补丁可用，他正在寻求将其包含在主流内核源代码中。 用户空间应用程序中的 CTS/RTS 流控制没有内核的错误，并且仍然建议 getty 使用 CTS/RTS 流控制。