88E6390端口Link问题BUG解决

本文针对Marvell88E6390交换芯片在特定条件下光口状态异常的问题,提供了原厂推荐的配置解决方案。通过在系统初始化时进行特定配置,解决了光口打包时端口状态显示不正确的问题,但同时发现环网测试倒换时间变长,最终通过重新启用中断解决了该问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Marvell 88E6390是一款11端口全千兆以太网二层交换芯片,是一款较新的产品,芯片有原厂级别的BUG。我们的设备以交换芯片1port-8配置为千兆电口,port9-10千兆光口。光口在打包(满速率很快,低速时间较长,跟报文的总数有关系)一段时候之后拔掉网线,端口的状态仍然为Link,led灯闪烁,跟没有拔出网线端口的状态一样。沟通原厂给了解决方案,这里分享出来,希望能够帮助大家。

原厂的建议是在系统初始化的时候做如下配置:

 按照原厂这个建议在初始化qdStart();初始化之做上述的配置时序代码如下;

    /* load marvell chip driver */
    qdStart(gDevCpuPort, 0);

    /*init port patch ,zhoulinhua@2018-09-03*/
    init_each_port();

配置时序代码:

/*init port patch,zhoulinhua@2018-09-03,*/
void init_each_port()
{
	int port;
	int buf;
	
	/*step1:portstate for each port to be configured to disable
	*Port register 4 [1:0] = 0x0
	*/
	for(port=1;port <= MAX_PORT_NUM; port++)
	{
		readPort(port,0x4,&buf);
		buf &= 0xfffc;
		//printf("%s %s %d: buf=0x%04x\r\n",__FILE__,__FUNCTION__,__LINE__,buf);//zhoulinhua@2018-09-26,test
		writePort(port,0x4,buf);
	}

	/*step2:
	*For Port 9:
	*	Swith Port 5 register 0x1A = 0x01C0
	*	Swith Port 4 register 0x1A = 0xFD20
	*/
	writePort(0x5,0x1a,0x01C0);
	writePort(0x4,0x1a,0xFD20);
	
	/*step3:
	For Port 10:
	*	Swith Port 5 register 0x1A = 0x01C0
	*	Swith Port 4 register 0x1A = 0xFD40
	*/
	writePort(0x5,0x1a,0x01C0);
	writePort(0x4,0x1a,0xFD40);
	
	/*step4: Preform a software reset of swtich core:
	*	Global 1 Register 4 .15 = 1
	*/
		readGlobal(0x4,&buf);
		buf |= 0x8000;
		//printf("%s %s %d: buf=0x%04x\r\n",__FILE__,__FUNCTION__,__LINE__,buf);//zhoulinhua@2018-09-26,test
		writeGlobal(0x4,buf);
		
	/*step5: Change the PortState for each port back to the forwarding state
	*	Port register 4 [1:0] = 0x3
	*/
	for(port=1;port <= MAX_PORT_NUM; port++)
	{
		readPort(port,0x4,&buf);
		buf |= 0x3;
		//printf("%s %s %d: buf=0x%04x\r\n",__FILE__,__FUNCTION__,__LINE__,buf);//zhoulinhua@2018-09-26,test
		writePort(port,0x4,buf);
	}
	
	return 0;
}

这样配置之后,光口慢速率打包端口状态正常了,但是环网测试倒换时间本来是ms级别变成了s级别,查看中断没有上来,读取交换芯片的DevIntEn(Global 1 offset 0x4)位被置为0,中断被关闭了。明明qdStart中有如下调用打开了中断:

/* Enable phy interrupt for port link state changed */
    if((status=QDIntEnable(dev)) != GT_OK)
    {
        MSG_PRINT(("QDIntEnable return Failed\n"));
        return status;
    }

猜测可能software rest的时候被清,因此在调用 init_each_port()之后重新调用QDIntEnable(dev))得以解决、

以上是我分享的一点希望能帮到大家。

 

<think>我们正在处理一个网络设备问题88e1111芯片的发送指示灯亮起,但使用pcap捕获工具未捕获到数据。需要分析可能的原因并提供解决方案。注意:这是一个硬件与软件结合的问题,可能涉及物理层、数据链路层、驱动、配置等多个方面。可能原因分析:1.**物理连接问题**:虽然发送灯亮,但可能由于网线、端口问题导致数据未到达捕获设备。2.**捕获位置问题**:捕获工具(如Wireshark)可能没有在正确的网络接口上捕获,或者捕获点不在数据路径上。3.**过滤设置问题**:捕获工具可能设置了过滤器,导致目标数据被过滤掉。4.**驱动或硬件问题**:网卡驱动可能存在bug,或者硬件本身存在问题(如88e1111芯片配置或状态异常)。5.**数据包内容问题**:发送的数据包可能不符合标准(如错误的MAC地址、CRC错误等),导致被捕获工具丢弃。6.**交换机或中间设备问题**:如果网络中有交换机等设备,可能由于VLAN、端口镜像等问题导致数据未到达捕获点。7.**操作系统或内核问题**:操作系统网络栈可能存在问题,数据包在到达捕获点之前被丢弃。8.**数据包未进入协议栈**:如果数据包是由网卡直接发送(如通过原始套接字或DPDK),可能绕过操作系统的协议栈,导致捕获工具无法捕获。解决方案:1.**检查物理连接**:-确认网线连接正确,尝试更换网线或端口。-使用其他设备验证发送端是否确实发送了数据(例如用另一台设备捕获)。2.**确认捕获位置**:-确保在正确的网络接口上进行捕获。如果是通过交换机连接,可能需要配置端口镜像(SPAN)将发送端口的流量镜像到捕获端口。-如果是在发送数据的主机上捕获,尝试在发送数据之前将网卡设置为混杂模式(但通常发送的数据即使不是混杂模式也能捕获到本机发出的包)。3.**检查捕获过滤设置**:-检查是否设置了捕获过滤器(如Wireshark的capturefilter)或显示过滤器(displayfilter),移除所有过滤器再试。-尝试捕获所有接口(如果有多个接口)的数据。4.**检查驱动和硬件**:-更新网卡驱动到最新版本。-检查88e1111的配置(通过寄存器访问,通常需要专业工具或驱动支持),确认其工作模式(如半双工/全双工)和速度设置是否正确。-使用硬件诊断工具检查网卡状态。5.**检查数据包内容**:-如果可能,使用其他方式(如硬件抓包设备)捕获数据,分析数据包是否有效。-在发送端使用回环测试(loopback)检查网卡是否正常工作。6.**检查中间设备**:-如果网络中有交换机,配置端口镜像以确保捕获到目标端口的数据。-检查交换机的VLAN配置,确保捕获端口和发送端口在同一个VLAN中。7.**操作系统和内核检查**:-检查系统日志(如`dmesg`或`/var/log/messages`)是否有网卡相关的错误信息。-使用`ethtool`(Linux)或类似工具检查网卡统计信息(如错误计数、丢弃计数等)。-使用`tcpdump`命令行工具尝试捕获,避免GUI工具可能的问题。8.**绕过协议栈的情况**:-如果应用程序使用原始套接字或DPDK等直接发送数据,则数据包不会经过操作系统的协议栈,因此无法被常规的捕获工具捕获。此时需要专门的工具(如DPDK的pdump)来捕获。具体针对88e1111芯片:-88e1111是一款常见的千兆以太网PHY芯片,通常与MAC控制器(如集成在CPU或FPGA中)配合使用。因此,还需要检查MAC控制器的配置和状态。-使用`ethtool`查看和设置88e1111(在Linux中,首先使用`ethtool-i<interface>`查看驱动信息,然后使用`ethtool<interface>`查看状态)。-例如,检查连接状态:`ethtooleth0`,关注“Linkdetected”是否为yes,速度、双工模式是否正确。逐步排查步骤建议:1.在发送数据的主机上运行`tcpdump-i<interface>-wcapture.pcap`,同时发送数据。然后检查capture.pcap文件是否有数据。2.如果主机上捕获不到,尝试在接收端(如果存在)捕获,或者使用集线器(hub)连接发送端和接收端,并在集线器上连接捕获设备(注意:交换机不行,因为需要广播介质)。3.使用硬件工具(如网络分路器或带端口镜像的交换机)捕获。如果以上步骤仍无法解决,可能需要深入检查硬件设计(如PCB布线、信号完整性)和驱动源码。引用说明:本文参考了网络调试的一般经验[^1]和88e1111数据手册[^2]中的常见问题排查部分。§§相关问题§§1.如何配置交换机的端口镜像来捕获网络流量?2.Linux下如何使用ethtool诊断网卡问题?3.使用DPDK发送的数据包如何捕获?4.网络数据包发送过程中,哪些环节可能导致数据包丢失?</think>### 88e1111芯片发送灯亮但pcap未捕获数据的排查指南 #### 可能原因及解决方案: 1. **捕获位置错误** - **原因**:数据包未流经捕获点(如未配置端口镜像,或抓包工具绑定到错误接口) - **解决方案**: - 在发送设备上执行本地抓包:`tcpdump -i eth0 -w capture.pcap` - 若需捕获交换机流量,配置**端口镜像(SPAN)**,将发送端口流量复制到监控端口 - 使用网络分路器(Tap)物理接入链路 2. **驱动/硬件问题** - **原因**: - PHY芯片(88e1111)与MAC层通信异常 - DMA传输错误导致数据未送达操作系统协议栈 - **解决方案**: - 检查驱动状态:`ethtool -i eth0`(确认驱动版本及加载状态) - 查看硬件错误计数:`ethtool -S eth0 | grep error` - 更新网卡固件或回滚驱动版本(已知Marvell芯片存在DMA缓存问题[^1]) 3. **过滤规则干扰** - **原因**:抓包工具设置了过滤规则(如BPF过滤器),或操作系统防火墙丢弃数据包 - **解决方案**: - 使用无过滤捕获:`tcpdump -i any -s0 -w dump.pcap` - 临时禁用防火墙:`iptables -F`(测试后恢复) - 检查NIC配置:`ethtool -k eth0` 确认 `rx-all` 开启 4. **VLAN/封装问题** - **原因**:802.1Q VLAN标签导致数据包被错误处理 - **解决方案**: - 抓包时指定VLAN:`tcpdump -i eth0 vlan 100` - 检查交换机端口VLAN配置是否匹配 5. **协议栈旁路** - **原因**:应用直接通过DPDK/XDP等框架发送数据,绕过内核协议栈 - **解决方案**: - 使用专用抓包工具:`dpdk-pdump`(针对DPDK应用) - 在物理链路中点捕获(交换机镜像或分路器) 6. **物理层故障** - **原因**:发送灯亮但信号质量差(如阻抗不匹配、电缆损坏) - **解决方案**: - 使用`ethtool eth0`检查链路状态:确认`Link detected: yes` - 执行环回测试:`ethtool -t eth0` - 更换网线/端口,检查PCB布线阻抗(88e1111要求差分阻抗100Ω±10%) #### 诊断流程图: ```mermaid graph TD A[发送灯亮但pcap无数据] --> B{本地抓包是否有数据?} B -->|是| C[问题在外部路径] B -->|否| D{检查驱动/硬件错误} D -->|有错误| E[更新驱动/固件] D -->|无错误| F{是否使用内核旁路?} F -->|是| G[用dpdk-pdump捕获] F -->|否| H[检查防火墙/过滤规则] C --> I[配置端口镜像] I --> J[验证镜像端口状态] ``` > **关键命令示例**: > 查看88e1111状态:`ethtool -d eth0`(需驱动支持寄存器读取) > 实时监控丢包:`watch -n 1 'ethtool -S eth0 | grep drop'`
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值