首页 > 代码库 > vxWorks socket的buf不释放 ENOBUFS 错误

vxWorks socket的buf不释放 ENOBUFS 错误

网络问题解决  

2010-02-06 21:53:40|  分类: vxWorks|举报|字号 订阅

 
 
1,网络出现问题,如rpccore后端客户RPC超时,未知网络接口,muxDevLoad失败,wdbConfig配置WDB通讯接口出错等,可以用网络调试函数来解决。
2,若目标机开始运行时可以ping通,而运行自己的socket应用(或使用网络的库如ftp服务)后,应用会停顿一会。这时需考虑配置对网络性能的影响。
3,如果再也ping不通了,就需要在目标机tShell用调试函数来解决问题(tShell可以定向到串口)。先用i查看tNetTask是否仍在优先级 50运行,如果被挂起(suspendded),就再用tt tNetTask查看任务栈轨迹。这时可能有代码使用了空指针,或出现未初始化中断。如果应用运行正常,但随着sockets数或包数的增加,应用出现停止。
可以从tShell中调用下列的show函数(当然得添加相应组件)。 
->i 显示运行任务,显示优先级 
->netStackSysPoolShow 显示网络栈系统内存池[pool]状态 
->netStackDataPoolShow 显示网络栈数据内存池状态 
->inetstatShow 显示socket和其接收队列 
->ipstatShow 显示ip协议统计数据 
->tcpstatShow 显示tcp协议统计数据 
->udpstatShow 显示udp协议统计数据 
->icmpstatShow 显示icmp协议统计数据 
->mRouteShow 显示路由表,包括屏蔽码 
->RouteShow 显示路由表,不包括屏蔽码 
->iosFdShow 显示文件描述符 
->arpShow 显示arp表 
->hostShow 显示主机表 
->ifShow 显示IP的接口,END和BSD4.4驱动 
->muxShow 显示成功载入MUX的END驱动
下面对各种症状进行描述: 
A. ENOBUFS (socket应用出错)若网络栈或驱动的内存池太小,应用可能出现停顿,随资源释放,一会又恢复过来。可能发生类似EBOBUFS或 S_netBufLib_NO_POOL_MEMORY样的错误。调用netStackSysPoolShow 和netStackDataPoolShow来检查,若没有可用的空缓冲区,应该增加缺省分配和修改IP配置参数。 
B. 目标机ping不通,RPC后端超时若socket的缓冲没有被读,会耗尽驱动缓冲区。驱动没有可用缓冲区,就不能接受和发送包。Ping就失败,主机也不能连接目标机。muxShow只显示END驱动,若启动设备在muxShow中列出,所使用的驱动就是END。ifShow能显示END和BSD4.4驱动。用inetstatShow可以确定哪个socket的接受队列有数据。该信息可以用来确定哪个任务没有读socket。若ifShow和ipstatShow显示接受队列没有数据,驱动可能有错。可以交换使用END或BSD驱动来试试。若BSP支持多个网卡类型,可以换卡试试。若muxShow没显示任何驱动,表明配置的是BSD驱动。可在config.h或工程中配置BSD,不定义INCLUDE_END,或去掉 network components->network devices->end attach interface、END接口支持组件。如果你没有替换驱动版本可用,可使用loopback驱动。在目标机同时运行客户端和服务器,向 127.0.0.1发送。 
C. 目标机能ping,但不能传送数据可以用inetstatShow,或在主机用netstat。若发送方有数据返回,而接受方没有,client/server应用代码可能出现死锁。将信息长度降到1460以下(TCP),查看是否有死锁发生。 
D. 协议问题查看错误发生前后show函数的统计数据,对照查找错误发生的线索。 
E. 优先级问题保证tNetTask任务比依赖网络的应用任务的优先级要高。 
F. 硬件或驱动配置问题更换网卡,或使用不同的网卡。观察HUB的灯,灯能表明驱动的运行。配置BSD驱动,调用ifShow查看是否冲突(END驱动不报告这类信息)。若驱动报告大量冲突,则检查该网络中的其他节点是否在全双工模式工作。
 
 
 
 
 

vxWorks socket的buf不释放 ENOBUFS 错误