Linux-2.6.21 S3c6400中断剖析<六>(原创)-上海嵌入式索漫科技培训教材

xiajiashan

Linux-2.6.21 S3c6400中断剖析<六>(原创)-上海嵌入式索漫科技培训教材 [复制链接]

作者：下家山（请尊重原创，转载请注明）  http://www.xiajiashan.com

五．客户出现的问题

    5．1 现象（软件锁和网络超时）

       客户在用我们发布的驱动测试时出现

       “BUG: soft lockup detected on CPU#0!”并伴随有“NETDEV WATCHDOG: eth0: transmit timed out”现象出现

       我们拿到客户的板子后测试发现，在ping的时候很难出现上述问题，而在用iperf工具测试时，马上就会出现(几秒钟)，而且是在TX时候出现（RX正常）。

       虽然出现两个现象，大部分是先出现“BUG: soft lockup detected on CPU#0!”，再出现“NETDEV WATCHDOG: eth0: transmit timed out”。（有时候是先出现“NETDEV WATCHDOG: eth0: transmit timed out”再出现“BUG: soft lockup detected on CPU#0!”）

      5．2 什么是软件锁和网络超时

       先来说说“BUG: soft lockup detected on CPU#0!”。

       网上有人说这个不算bug，只要你的系统io，或者某个服务10秒内都没反应，就会出

现这个信息。而且这个信息是可忽略的，它只是提醒你某个地方占用CPU时间太长，需要注意。但是，我们这里却不可忽略，因为OS都down掉了。

    在我看来“NETDEV WATCHDOG: eth0: transmit timed out”这个错误还是“BUG: soft lockup detected on CPU#0!”带来的（即使是“NETDEV WATCHDOG: eth0: transmit timed out”这个错误先出现）。因为，当CPU检测到某个线程占用CPU时间超过10秒并报告“BUG: soft lockup detected on CPU#0!”时，那么网络传输肯定会超时即会报告“NETDEV WATCHDOG: eth0: transmit timed out”（因为网络传输超时时间设置的是20ms）。

       疑问：既然网络超时时间比软件锁(soft lockup)要短，为什么大部分时间是先出现软件锁错误信息再出现网络超时信息呢？

      5．3 问题是由什么引起的

       这样两个问题，也许都是因为系统阻塞造成的。

最初，我们一直怀疑我们的驱动有问题，因为我们的kernel是客户提供的，6400的BSP也是客户提供的，我们没有理由去怀疑linux-2.6.21不够稳定，也没有理由去怀疑samsung的BSP有问题，因为6400已经用到了ipone 上面，更让我们肯定的是ping正常。

既然是系统阻塞，我们最先怀疑是我们驱动中，特别是在IO部分的while 语句造成

（因为做实验发现while(1)也会出现“BUG: soft lockup detected on CPU#0!”）。

取消一切while等语句，用if else delay()语句组合来取代。经调试，问题依然。

 

我们针对驱动 一条一条语句的查，反复配置各个SPI寄存器，但并无改善。因问题只在发送部分，所以我们又怀疑我们的发送进程和队列有问题。于是，我们换到

驱动版本，这个不涉及到队列问题，也不行。

             

 

驱动中用到了很多自旋锁spin_lock_init，这也是容易发生阻塞的地方，但屏蔽驱动中所有的自旋锁语句，情况并无改善。

       最后出问题的地方似乎只有发送进程方面了。

       驱动发送进程有两条线：

我们分别在进出两个进程的地方加了定时器，看这两个进程执行的时间。但并没有规律，即很短的时候也会出现问题而很长的时候却没有问题。

上面的调试，我们都是用的polling 方式，但在这种方式下各种可能性都调试并没有找到问题的原因。

于是，我们想到换成 DMA或interrupt方式。

但是，在用DMA调试时总是提示client already has channel，因为客户之前给我们的内核DMA部分没有基于2410，引入了subchannel，但跟到内核里面去，感觉其DMA对subchannel的计算上好像有问题，因此也没有调下去。

再后来，改到interrupt方式。

但是，中断方式调试驱动出现下面的现象：

如不注册外部中断，驱动下载正常，反之，下载出问题。

到了这里，感觉应该是中断之间干扰（因为SPI采用中断方式后，就注册了SPI中断和外部中断两个中断）。

但是，我们的驱动代码已经应用在几个客户上，改动的地方只是跟SPI有关的几个寄存器。况且我们也实在查不到我们驱动的问题。似乎不跳出原来的思维很难找到问题所在。后来跟到内核中断部分去了，发现其代码好像有点问题(主要参考2410部分的中断)，于是对其进行了改动，并在polling上再次调试，发现问题解决了，后来，用interrupt方式调试也没有问题了。

   

wiin

请问如何改动的，有哪些注意点呢？