PowerQUICC III以太网控制器中断与TOE机制详解与驱动优化-开发者社区

1. 项目概述与核心价值

在嵌入式网络设备开发中，尤其是像工业网关、路由器、交换机或者高性能工控机这类对网络吞吐量和实时性有严苛要求的场景里，我们常常会与飞思卡尔（现恩智浦）PowerQUICC III这类集成了高性能以太网控制器（eTSEC）的处理器打交道。手册里那些关于中断和TCP/IP卸载的章节，初看可能只是寄存器描述的罗列，但背后隐藏的正是决定你系统网络性能上限的关键设计哲学。我处理过不少因为中断风暴导致系统卡顿，或者因为软件校验和计算吃掉大半CPU周期而无法跑满千兆线的案例。究其根源，往往是对控制器底层机制理解不透，配置不当。

这篇文章，我就结合MPC8544E的参考手册，把以太网控制器中断处理与TCP/IP硬件卸载这两块“硬骨头”嚼碎了讲清楚。这不是一篇照本宣科的翻译，而是一个在一线踩过坑的工程师，带你从手册的只言片语中，还原出整套高效、可靠的驱动设计与性能调优思路。我们会深入中断合并（Interrupt Coalescing）如何平衡延迟与CPU占用，剖析TCP/IP卸载（TOE）如何将协议栈的繁重计算任务甩给硬件，并分享在实际部署中如何配置、调试以及避坑。无论你是正在为新产品选型，还是在优化现有设备的网络驱动，相信这里的细节和经验都能给你带来直接的帮助。

2. 中断处理机制深度解析

中断是现代处理器响应外部事件的核心机制。对于网络控制器而言，每收到或发完一个数据包就产生一次中断，在低速网络中或许可行，但在百兆、千兆乃至更高速度下，这种“来一个包打断一次”的模式会瞬间将CPU淹没在中断处理的上下文切换中，导致系统吞吐量急剧下降甚至瘫痪。因此，一个成熟的高性能以太网控制器，其中断子系统设计必定是精细且可配置的。

2.1 中断源识别与分类处理

MPC8544E的eTSEC控制器通过IEVENT（中断事件）寄存器来标识中断来源。驱动开发者的首要任务，就是在中断服务程序（ISR）的入口，准确地读取并处理这个寄存器。

关键寄存器：IEVENT这个寄存器中的每一个比特位都代表一个可能的中断事件。手册将其大致分为三类，这为我们编写高效、清晰的ISR提供了逻辑框架：

错误中断：除了RXB、RXF、TXB、TXF之外的所有IEVENT位。这包括XBUN（发送FIFO欠载）、BSY（忙错误）、BABT/BABR（帧过长）、CRC错误、LC（迟冲突）等。错误处理通常需要最高优先级，因为可能涉及链路状态异常或硬件故障，需要及时记录并可能触发恢复流程。
接收中断：由RXB（接收缓冲区）或RXF（接收帧）位触发。这表明有新的网络数据已经到达并被DMA搬运到了主机内存中。
发送中断：由TXB（发送缓冲区）或TXF（发送帧）位触发。这表明之前提交给控制器发送的数据包已经完成，其对应的缓冲区描述符（BD）可以被回收复用。

注意：在ISR中，对于需要在本轮处理的中断源，读取IEVENT后应立即向相应位写1来清除它。这是一个标准的“读-清除”操作，防止同一中断被重复触发。但务必根据手册说明操作，有些位可能通过其他方式清除。

2.2 缓冲区描述符（BD）环与中断的关系

这是理解eTSEC数据流的核心。无论是发送还是接收，驱动软件和硬件控制器都通过一个在内存中创建的环形队列——BD环来协作。每个BD描述了一块用于存放网络帧数据的内存缓冲区（数据缓冲区）的状态。

发送流程：驱动将待发送的数据包地址和长度等信息填入一个或多个空闲的TxBD（发送BD），并将其R（Ready）位置1，然后通知控制器。控制器依次处理R=1的BD，将对应缓冲区的数据发出。发送完成后，硬件会将R位清零，并可能设置L（Last）等状态位。当TXF中断发生时，意味着一个完整的帧（可能由多个BD组成）已发送完毕。
接收流程：驱动预先准备一批空闲的RxBD（接收BD），并将其E（Empty）位置1，提交给控制器。当网络数据到达时，控制器将其DMA到E=1的BD所指向的缓冲区，填满后硬件将E清零，并更新数据长度等状态。当RXF中断发生时，意味着一个完整的帧已接收完毕。

中断服务程序中的BD处理关键：手册特别强调了一点：由于网络速度可能很快，或者中断响应有延迟，在一次中断触发时，可能已经完成了多个BD的处理。因此，ISR绝不能只处理一个BD就返回。

对于发送中断（TXF）：ISR需要遍历TxBD环，从上次处理完的位置开始，连续检查多个BD，直到找到一个R位仍为1（表示尚未发送完成）的BD为止。这期间所有R=0的BD，其对应的数据缓冲区都可以被驱动安全回收，用于装载新的待发送数据。
对于接收中断（RXF）：同理，ISR需要遍历RxBD环，连续处理数据，直到找到一个E位仍为1（表示缓冲区空，未被新数据填充）的BD为止。这期间所有E=0的BD，其指向的缓冲区里都存放着已接收的网络数据包，需要上交协议栈处理。

实操心得：在驱动中，我们通常维护两个指针：一个Producer索引（硬件更新BD的位置），一个Consumer索引（驱动消费BD的位置）。在ISR中，我们通过比较TXB/TXF或RXB/RXF中断，并结合检查BD状态位（R或E），来安全地更新Consumer索引，从而批量回收或提交BD。这能极大提升中断处理效率。

2.3 中断合并（Interrupt Coalescing）：性能与延迟的权衡艺术

这是eTSEC提供的一项至关重要的性能优化功能。其核心思想是“攒一波再通知”，主动减少中断发生的频率，从而降低CPU的上下文切换开销。

中断合并可以分别针对发送和接收路径独立启用和配置。它通过两个维度来“攒”中断：

帧计数阈值（Frame Count Threshold）：通过TXIC.ICFT（发送中断合并配置寄存器）和RXIC.ICFT字段配置。例如，设置为8，则意味着控制器在发送或接收了8个帧之后，才产生一次TXF或RXF中断。
定时器阈值（Timer Threshold）：通过TXIC.ICTT和RXIC.ICTT字段配置。单位为64个接口时钟或系统时钟周期（由ICCS位选择）。例如，设置为1000，则意味着从第一个帧触发计时开始，如果在计时器倒计数到0之前，帧计数阈值未达到，那么时间到了也会强制产生一次中断。

中断产生的实际条件是“两者孰先”。只要帧数达到ICFT值，或者计时器达到ICTT值，就会立即触发中断。中断发生后，相应的计数器和计时器会重置，开始下一轮计数。

配置策略与考量：

高吞吐、低CPU占用场景：设置较大的ICFT（如64）和适中的ICTT（如几毫秒）。这能最大程度合并中断，适合后台文件传输、视频流等对微小延迟不敏感的应用。
低延迟、交互式场景：设置较小的ICFT（如1或2）和较小的ICTT（如100微秒以内）。这能保证数据包被尽快处理，适合VoIP、工业控制指令等实时应用。
默认与关闭：如果不启用中断合并，则每个帧完成都会产生中断。在调试初期，或者极低负载的系统中，可以先关闭此功能以简化逻辑。

避坑指南：手册中提到了一个细节：在“优雅停止”（Graceful Stop）事件（如收到流控暂停帧��完成时，如果中断合并定时器还未到期，控制器可能会先产生一个GTS/GRS中断，紧接着定时器到期后又产生一个TXF/RXF中断。为了避免第二个中断干扰对第一个事件的服务，建议在服务GTS/GRS的ISR中，临时屏蔽（Mask）掉TXF/RXF中断。这是一个典型的硬件特性导致的“伪中断”问题，需要在驱动中妥善处理。

中断合并阈值计算示例：假设系统时钟为333 MHz，ICCS设置为1（使用系统时钟），ICTT设置为0x0BB8（十进制3000）。计时器单位 = 64 / 系统频率 = 64 / (333 * 10^6) ≈ 0.192 微秒。中断时间阈值 =ICTT* 计时器单位 = 3000 * 0.192 μs ≈ 576 微秒。这意味着，即使收到的数据包很少，最晚每576微秒也会产生一次接收中断，防止数据在控制器缓冲区中滞留过久。

2.4 错误处理与状态恢复

eTSEC定义了详尽的错误类型，并在IEVENT、TSTAT（发送状态）、RSTAT（接收状态）寄存器以及BD中设置相应标志。一个健壮的驱动必须有完善的错误处理逻辑。

常见错误及处理：

发送错误（TXE）：可能包含XFUN（发送欠载）、CRL（重试超限）、LC（迟冲突）等。处理方式通常是：记录错误统计，清除TSTAT[THLT]（如果被置位）以恢复发送队列，并可能重新提交发送失败的数据包（取决于协议栈策略）。
接收错误：如BSY（无可用BD，忙错误）、FIQ（帧被分配到无效队列）、CRC错误等。对于BSY和FIQ，需要检查并确保有足够的RxBD并正确配置了接收队列。对于CRC错误，通常直接丢弃该错误帧。
DMA/总线错误（EBERR,DPE）：这类错误比较严重，可能指示内存访问异常或数据损坏。需要记录日志，并可能触发更高层次的错误恢复机制。

错误处理流程：

读取并记录：在ISR中，读取IEVENT、TSTAT、RSTAT以及出错BD的状态位，将错误类型和计数记录到驱动统计信息中。
清除状态：向TSTAT和RSTAT中的相关HLT（停止）位写1以清除它们。对于DMACTRL[GTS]和[GRS]（优雅停止控制）也需要类似操作。
恢复操作：如果错误导致队列停止（THLT或QHLT被置位），在清除状态位后，控制器会自动恢复该队列的传输或接收。驱动需要确保有足够的资源（如BD）可供控制器继续使用。

3. TCP/IP硬件卸载（TOE）机制剖析与应用

TCP/IP卸载引擎（TOE）是eTSEC的另一大亮点功能。它的目标是将原本由CPU软件执行的、计算密集型的协议校验和计算，转移到以太网控制器硬件中完成，从而释放CPU资源，提升系统整体性能。

3.1 TOE功能概览与启用

eTSEC的TOE功能在发送和接收路径上可以独立启用，并且支持不同深度的协议解析。

接收路径TOE：通过RCTRL[PRSDEP]（接收控制寄存器，解析深度）字段控制。
- 00：禁用TOE，按普通以太网帧处理。
- 01：解析到第2层（L2），识别以太网、VLAN等头部。
- 10：解析到第3层（L2-L3），识别IPv4/IPv6头部，并可验证IPv4头部校验和。
- 11：解析到第4层（L2-L4），识别TCP/UDP头部，并可验证TCP/UDP载荷校验和（包含伪头部）。
发送路径TOE：通过TCTRL[TUCSEN]（发送控制寄存器，TCP/UDP校验和使能）位全局启用，并通过每个帧的发送帧控制块（Tx FCB）进行精细的每帧控制。

核心价值：对于一个大帧（如1500字节的MTU），计算其TCP校验和需要遍历整个载荷进行累加，这对CPU是一个不小的负担。TOE硬件在DMA数据的同时并行完成校验和计算或验证，几乎零开销。这对于网络服务器、防火墙、网关等需要处理大量数据的设备，性能提升尤为显著。

3.2 帧控制块（FCB）：软硬件通信的桥梁

当启用TOE时，每个网络帧（在发送或接收时）都会关联一个8字节的FCB。FCB位于帧数据之前，由第一个BD指向。它是驱动软件告知硬件期望的卸载操作（发送时），以及硬件向软件反馈解析和校验结果（接收时）的协议。

发送帧控制块（Tx FCB）详解：驱动在组包时，需要在数据缓冲区前预留8字节填写Tx FCB。其结构定义了几个关键控制位：

字段名	位	描述与配置要点
`VLN`	0	VLAN控制字有效位。如果使能了VLAN插入，且此位置1，则使用`VLCTL`字段作为VLAN标签。
`IP`	1	关键位。置1表示L3头部是IP头（IPv4或IPv6），此时`L3OS`字段有效。
`IP6`	2	IP版本。仅在`IP=1`时有效。0表示IPv4，1表示IPv6。
`TUP`	3	关键位。置1表示L4头部是TCP或UDP，硬件将基于此进行L4校验和卸载。
`UDP`	4	L4协议。仅在`TUP=1`时有效。0为TCP，1为UDP。
`CIP`	5	IPv4头部校验和生成使能。仅在`IP=1`且`IP6=0`时有效。置1则由硬件计算并填充IPv4头的校验和字段。
`CTU`	6	TCP/UDP校验和生成使能。仅在`IP=1`且`TUP=1`时有效。置1则由硬件计算并填充TCP/UDP头的校验和字段。
`NPH`	7	重要位。禁用伪头部校验和计算。如果IP包有选项（Options）或IPv6有扩展头，硬件无法正确计算伪头部校验和，此时需置1，并由软件预先计算好伪头部校验和填入`PHCS`字段。
`L3OS`	8-15	L3头部偏移量。从帧起始处（含FCB）到IP头开始的字节数。用于定位IP头。
`L4OS`	0-7	L4头部偏移量。从L3头部起始处到TCP/UDP头开始的字节数。用于定位传输层头。
`PHCS`	0-15	伪头部校验和。当`NPH=1`时，由软件填写。
`VLCTL`	0-15	VLAN控制字。当`VLN=1`时有效。

发送TOE工作流程：

驱动准备发送数据。在组包时，除了填充以太网头、IP头、TCP/UDP头和数据外，还需在数据缓冲区前填充8字节的Tx FCB。
根据帧的协议类型，正确设置Tx FCB中的各个控制位。例如，发送一个普通的IPv4/TCP包，需要设置：IP=1,IP6=0,TUP=1,UDP=0,CIP=1,CTU=1,NPH=0。并正确计算L3OS和L4OS（通常是14和20）。
在对应的TxBD中，除了设置数据长度和缓冲区指针，还必须设置TOE/UN位（在TxBD中可能是一个复用位，需查具体手册），以告知硬件此帧带有FCB，需要TOE处理。
控制器发送数据时，会根据FCB的指示，在DMA过程中自动计算并填充IP校验和、TCP伪头部及校验和。

注意事项：L3OS的计算容易出错。它指的是从整个帧的起始地址（即FCB的第一个字节）到IP头第一个字节的偏移。假设帧结构是[8字节FCB][14字节以太网头][20字节IP头]...，那么L3OS就是8 + 14 = 22。L4OS则是从IP头开始算起到TCP头，即IP头长度（通常是20字节）。

接收帧控制块（Rx FCB）详解：当接收TOE启用（RCTRL[PRSDEP]非零）时，硬件会在每个接收帧的数据前插入一个8字节的Rx FCB。驱动通过解析Rx FCB来获取硬件处理的结果。

字段名	位	描述与含义
`VLN`	0	识别到VLAN标签。仅在`RCTRL[VLEX]`使能时有效。
`IP`	1	识别到IP头。
`IP6`	2	识别到IPv6头（仅在`IP=1`时有效）。
`TUP`	3	��别到TCP或UDP头。
`CIP`	4	IPv4头部校验和已验证。仅当`IP=1`且`IP6=0`时，此位有效表示校验和已检查。
`CTU`	5	TCP/UDP载荷校验和已验证。
`EIP`	6	IPv4头部校验和错误（仅在`CIP=1`时有效）。
`ETU`	7	TCP/UDP校验和错误（仅在`CTU=1`时有效）。
`PERR`	12-13	解析错误。`10`表示L3层头部序列不一致或不支持。
`RQ`	2-7	接收队列索引。由接收过滤器（Filer）根据匹配规则分配。用于多队列负载均衡或流量分类。
`PRO`	8-15	协议标识。如果`IP=1`，此字段为IP头的“协议”字段值（如0x06为TCP，0x11为UDP）。0xFF表示分片包或背靠背IPv6路由扩展头。

接收TOE工作流程：

硬件接收数据，根据RCTRL[PRSDEP]的深度进行协议解析和校验和验证。
硬件将帧数据和其前面的Rx FCB一同DMA到驱动提供的缓冲区中。
驱动在收到RXF中断后，处理接收到的帧。首先读取Rx FCB。
根据IP、TUP等位判断协议类型。根据CIP、CTU、EIP、ETU判断校验和是否已验证以及是否正确。
如果EIP或ETU为1，表示校验和错误，驱动应丢弃此帧（或交给协议栈处理，但标记为无效）。如果校验和正确，驱动可以信任硬件结果，无需软件再计算一遍校验和，直接将数据上交协议栈。
根据RQ字段，可以将数据包分发到不同的处理线程或协议栈实例，实现多队列接收。

3.3 TOE使用中的陷阱与最佳实践

分片包处理：手册明确指出，eTSEC的解析器在遇到IP分片包时，会停止进一步解析（因为传输层头可能在第一个分片之后）。此时，RxFCB[PRO]会被设置为0xFF，同时RQFPR[IPF]位会被置起。驱动必须检查这些标志。对于分片包，TOE无法提供L4校验和卸载，需要软件处理或由协议栈在重组后计算。
IPv6与扩展头：eTSEC的发送TOE不检查IPv6扩展头。如果发送的IPv6包包含路由头等扩展头，硬件将无法正确计算TCP/UDP的伪头部校验和。此时，必须设置Tx FCB的NPH=1，并由软件预先计算好伪头部校验和填入PHCS字段。这是一个极易忽略的坑。
FCB对齐与BD设置：FCB必须位于BD所指向的第一个数据缓冲区的最开始8字节。并且，只有第一个BD（即帧的起始BD）的TOE/UN位需要置位。后续的BD（如果帧被分散在多个缓冲区）则忽略此位。
性能权衡：TOE虽好，但并非所有场景都需要。对于小包频繁的交互式应用（如DNS、NTP），TOE带来的收益可能不如中断合并和NAPI（Linux中的New API，一种混合中断和轮询的机制）明显。通常，在高速、大帧传输（如文件服务、视频流）中，TOE的收益最大。

4. 驱动实现与性能调优实战

理解了原理，最终要落地到代码和配置上。这里分享一些在PowerQUICC III平台上实现稳健高效网络驱动的关键步骤和调优点。

4.1 驱动初始化与BD环配置

内存分配：为每个发送和接收队列分配连续的、缓存行对齐的DMA内存，用于存放BD环和数据缓冲区。确保内存不可被缓存（或正确进行缓存维护），以防止缓存一致性问题导致硬件看到过时数据。
BD环初始化：
- 发送BD环：将所有TxBD的R位清零，L（Last）和TC（Transmit CRC）等位根据需求设置。将Data Buffer Pointer指向预先分配的数据缓冲区（或留空，在发送时填充）。
- 接收BD环：将所有RxBD的E位置1，表示缓冲区为空，可供硬件使用。将Data Buffer Pointer指向预先分配的空数据缓冲区。通常，接收环的大小（BD数量）是发送环的2倍或更多，以防止BSY错误。
寄存器配置：
- 基本MAC配置：配置MACCFG1、MACCFG2等寄存器，设置双工模式、速度、是否使能流控等。
- BD环基地址：将分配好的BD环的物理地址（DMA地址）写入TBASE（发送基址）和RBASE（接收基址）寄存器。
- BD环大小：配置TMR（发送环大小）和RMR（接收环大小）寄存器。
- 中断使能：在IMASK寄存器中，有选择地使能需要处理的中断源，例如TXF、RXF以及关键的错误中断。初期调试可先使能所有中断以便观察。
- TOE使能：根据需求，设置RCTRL[PRSDEP]和TCTRL[TUCSEN]。如果使用TOE，还需正确配置RCTRL和TCTRL中的相关位。

4.2 中断服务程序（ISR）实现框架

一个典型的eTSEC ISR伪代码逻辑如下：

void etsec_isr(void) { uint32_t ievent = READ_REG(IEVENT); uint32_t imask = READ_REG(IMASK); uint32_t active_irqs = ievent & imask; if (!active_irqs) return; // 可能为共享中断，非本设备触发 // 1. 处理错误中断 if (active_irqs & ERROR_IRQ_MASK) { handle_errors(ievent); // 读取TSTAT, RSTAT，记录错误计数，清除错误状态 // 注意：某些错误（如THLT）清除后硬件会自动恢复 } // 2. 处理接收中断 (RXF, RXB) if (active_irqs & (IEVENT_RXF | IEVENT_RXB)) { // 遍历接收BD环，从consumer索引开始 while (!(rx_bd_ring[consumer_index].flags & BD_EMPTY)) { // 检查Rx FCB（如果TOE使能） if (toe_enabled) { struct rx_fcb *fcb = (struct rx_fcb *)rx_buffers[consumer_index]; // 根据fcb->ip, fcb->tup, fcb->etu等处理数据包 // 如果校验和错误(fcb->etu==1)，可选择丢弃 } // 将数据包长度等信息传递给上层网络协议栈 deliver_packet_to_netstack(rx_buffers[consumer_index] + FCB_SIZE, rx_bd_ring[consumer_index].length); // 回收此BD：重置状态，将E位置1，更新consumer索引 rx_bd_ring[consumer_index].flags = BD_EMPTY; consumer_index = (consumer_index + 1) % RING_SIZE; } // 可能还需要检查RSTAT寄存器，处理特定队列的中断 } // 3. 处理发送中断 (TXF, TXB) if (active_irqs & (IEVENT_TXF | IEVENT_TXB)) { // 遍历发送BD环，从last_processed_tx索引开始 while (!(tx_bd_ring[last_processed_tx].flags & BD_READY)) { // 此BD已发送完成，释放其关联的数据缓冲区 free_tx_buffer(tx_buffers[last_processed_tx]); last_processed_tx = (last_processed_tx + 1) % RING_SIZE; } // 如果有等待发送的包，现在可以唤醒发送任务或队列 wakeup_tx_task(); } // 4. 清除已处理的中断位（写1清除） WRITE_REG(IEVENT, active_irqs); }

4.3 性能调优参数与实践

中断合并参数：这是调优的重点。可以通过/proc/interrupts（Linux）或类似工具观察中断频率。目标是让中断频率与系统处理能力匹配。一个实用的方法是：先设置一个较大的ICTT（如5ms）和一个较小的ICFT（如1），观察在大流量下中断是否过于频繁。然后逐步增大ICFT，直到中断频率降到可接受水平，同时用ping或iperf测试延迟是否在允许范围内。
- 发送路径：TXIC.ICFT和TXIC.ICTT。
- 接收路径：RXIC.ICFT和RXIC.ICTT。
BD环大小：环越大，能缓冲的帧越多，抗突发流量能力越强，但消耗的连续DMA内存也越多。对于千兆网，接收环建议至少256个BD，发送环128个。每个BD对应的数据缓冲区大小通常设置为MTU（1500字节）加上协议头和一些对齐空间（如2K）。
多队列与接收侧扩展（RSS）：eTSEC支持通过接收过滤器（Filer）将不同流量的帧分配到不同的接收队列（由RQ字段指示）。在Linux等现代操作系统中，可以配合多核CPU��将不同的队列绑定到不同的CPU核心上处理，实现真正的并行收包，极大提升多核系统的吞吐量。这需要精心配置接收过滤器规则表（RQFAR, RQFCR, RQFPR）。
TOE启用策略：在驱动中，可以通过一个模块参数或ethtool命令动态开关TOE。对于已知的、大量传输大帧的应用（如Samba文件共享），可以开启。对于混合流量或不确定的环境，可以在驱动中做动态判断：例如，对于长度大于某个阈值（如512字节）的TCP/UDP帧，才在组包时设置Tx FCB启用硬件校验和。

4.4 常见问题排查实录

系统卡顿，网络吞吐量低：
- 检查：首先查看/proc/interrupts，确认eTSEC中断频率是否异常高（如每秒数万次以上）。
- 解决：启用并调整中断合并参数。增加ICFT，适当增加ICTT。确保ISR处理效率高，没有长时间关中断或耗时的操作。
大量接收错误，如BSY（丢弃帧）：
- 检查：RSTAT寄存器，IEVENT[BSY]计数。检查驱动提交给硬件的空闲RxBD数量是否充足。
- 解决：增大接收BD环的大小。优化驱动，确保ISR或下半部任务能及时处理完接收到的数据包并回收BD。检查是否有内存泄漏导致BD无法回收。
启用TOE后，发送的数据包校验和错误：
- 检查：使用抓包工具（如Wireshark）检查发出的包，确认校验和字段是否正确。
- 解决：
  - 确认Tx FCB的L3OS和L4OS计算是否正确。这是最常见的原因。
  - 确认是否发送了IPv6带扩展头的包，如果是，必须设置NPH=1并填写正确的PHCS。
  - 确认数据缓冲区在交给硬件前，IP和TCP/UDP头的校验和字段是否已清零（硬件负责填充）。
接收TOE不生效，RxFCB中标志位不正确：
- 检查：确认RCTRL[PRSDEP]已设置为非零值（10或11）。
- 检查：确认接收缓冲区指针确实指向了包含8字节FCB的空间。检查驱动在提交RxBD时，缓冲区地址是否正确（应该是FCB的地址，而不是数据部分的地址）。
- 检查：对于分片包，PRO=0xFF是正常现象，不应依赖其进行协议分发。
发送或接收队列意外停止（Halt）：
- 检查：TSTAT[THLT]或RSTAT[QHLTn]位是否被置位。通常由严重错误（如DMA错误、BD链异常）引起。
- 解决：在错误处理函数中，除了记录错误，必须向对应的HLT位写1以清除它，硬件才会恢复队列操作。同时检查BD环的连续性，确保没有错误的BD指针。