2.6.26 内核下中断处理的奇怪问题

jhon

2.6.26 内核下中断处理的奇怪问题 [复制链接]

使用 2.6.26 内核 在 ks8695x 遇到了下面的问题：


int g_nAlloc=0, g_nFree=0;
int hw_isr0(...)
{
...

    spin_lock(&g_nsLock);
    if( ((g_nAlloc+1)%250) != g_nFree ) {
        g_nAlloc = (g_nAlloc+1)%250 ;
    }

    barrier();

    if( g_nFree != g_nAlloc ) {
        g_nFree = (g_nFree+1)%250;
    }

    spin_unlock(&g_nsLock);

...
}


上述函数通过GPIO 口响应一个外部硬中断，可以确定 g_nAlloc g_nFree 只在上面的代码中涉及到，且我确定中断源只有一个。现在问题是，上述函数经过数次执行后，g_nAlloc g_nFree 的值【有时候】会出现不等的情况！可是在应用层下跑都是正常的。开始听说乱序执行可能导致类似问题，因此用了 barrier()，但好像没什么改善。我是新手，各位前辈有什么建议没有？

luson

不好意思，CPU 型号应该是 ks8695px。

liverpool

帮顶下。

MARK。

gaoli.85

按理说你加入barrier()后，读到的值应该都已经是正确的，不知道你是怎么判断 g_nAlloc g_nFree这两个值的？

nmylx

引用 3 楼 laiguo 的回复:
按理说你加入barrier()后，读到的值应该都已经是正确的，不知道你是怎么判断 g_nAlloc g_nFree这两个值的？

是这样，hw_isr0() 响应的中断由我触发，每次触发后 hw_isr0() 被调用若干次，每一轮系统响应完中断后，我会由应用程序利用驱动的read系统调用在内核打印 g_nAlloc g_nFree 的值，有时候打印的值两者是不相等的，但有时候又相等，但在内核线程或是应用里面测试，每次都是相等的，符合期望。

alfwoo

自己顶一下。