这个bug不好查…

计划没有变化快,周一计划的任务几乎没怎么做,时间完全交给了一个BUG;

最近大家在做新主板的功能,同事说DeviceNet不通,尽管我对DeviceNet一点不懂,不过好歹之前测过CAN模块在新主板上的功能,于是负责起了这个bug;

电脑连上CAN分析仪,包都看不到,上哪通去?搞硬件的同时出差了,没人懂连线的方法,算了,自己试吧;反复接线,终于接通了,在我这的环境,改了改代码,能够看到数据包了;

同事拿过去一看,依然不行,然后问我怎么改的代码,我跟她一起看的时候,注意到我们的代码里的波特率居然跟标准的不一样??什么?这。。。改成一样的,拿到同事环境,果然那边也通了;问了下上面,说是跟具体硬件有关,以前是故意这样写的;

连上DeviceNet模块吧,一试,不通啊!!同事说把发送周期调大一点吧,改之,果然,通了;

好吧!这是为什么??难道是别的线程的优先级太高了,抢占了当前发送线程??于是我把相关的3个线程绑定到一个CPU上,而且只有他们3个线程;他们的优先级也规划好;启动,依然不通;

打日志吧;看到错误是发送缓冲区已满;还是怀疑优先级影响了调度,于是将填充队列线程的优先级降低,不受其他线程影响;启动,依然不通;但是这个填充线程还是调用了,证明,两个更高优先级的线程主动放弃了CPU;

于是在库写函数的前后加日志,以确定是否写入卡住了;果然,经过一些拍之后,就会出现一次卡主的情况,这时候写线程进入睡眠,于是填充数据线程又开始向队列放数据,放着放着就满了;

确认是底层问题,还是考虑,是否应用层线程优先级比系统中断高,抢了系统中断的情况,于是将应用成的中断优先级都改低,最高不超过系统中断;启动之,依然不通;

好了,这回可以安心查驱动代码了;

从库函数一路过去,是通过ioctl陷入内核的,于是打了各种日志;

在dmesg中发现驱动的发送队列果然被填满了,于是进入了睡眠,证实了之前猜测的情况;

看驱动代码,思路是当第一个包过来之后,就会开启一个标记,有这个标记则靠中断来驱动发送,即每次中断过来都会发送数据;于是考虑是否是中断问题?

在中断的入口处打印时间,果然,发现中断的触发时间很长,甚至接近1ms才有一次中断触发,两次写数据之间甚至隔了几十ms,这不扯呢么?

周六又过来查了一天,觉得作为软件人员,我已经尽力了,周一跟上面汇报一下,联合其他人一起确认下;可能我需要一个懂中断的硬件人员,帮我测测中断频率什么的;

未完待续…


续…

isa就是这么慢…

本文链接:这个bug不好查...

转载声明:转载请注明来源:Linux TCP/IP Stack,谢谢!


发表评论

电子邮件地址不会被公开。 必填项已用*标注