中断问题

Question

LDD3的 scull和short模块调试:

scull的main.c中:
ssize_t scull_read(struct file *filp, char __user *buf, size_t count,
                loff_t *f_pos)
{
        struct scull_dev *dev = filp->private_data;
        struct scull_qset *dptr;        /* the first listitem */
        int quantum = dev->quantum, qset = dev->qset;
        int itemsize = quantum * qset; /* how many bytes in the listitem */
        int item, s_pos, q_pos, rest;
        ssize_t retval = 0;
printk(KERN_ALERT "scull:count= %ld\n",count);
        ...........................................

}

short的short.c中:
atomic li=ATOMIC_INIT(0);-------看发生了多少次中断
ssize_t do_short_read (struct inode *inode, struct file *filp, char __user *buf,
                size_t count, loff_t *f_pos)
{
         int retval = count, minor = iminor (inode);
        unsigned long port = short_base + (minor&0x0f);
        void *address = (void *) short_base + (minor&0x0f);
        int mode = (minor&0x70) >> 4;
        unsigned char *kbuf = kmalloc(count, GFP_KERNEL), *ptr;
printk(KERN_ALERT "short:count=%ld,li=%ld\n",count,atomic_read(&li));
        if (!kbuf)
        .........................................................
}
irqreturn_t short_interrupt(int,void*,struct pt_regs*)
{
atomic_inc(&li);
......
}
request_irq(irq,short_interrupt.....);

初始化时:安装了一个/proc/文件目录(通过create_proc_read_entry),名为short(主要是当cat /proc/short时能显示全局变量li的值
scull.ko对dd if=/dev/scull0 bs=2 count=1的printk反应是count=2,
short.ko对dd if=/dev/short0 bs=2(或bs=1) count=1的printk反应是count=0(2008年12月26日结果),有时count=4(2008年12月27日结果).
另外,我通过echo -ne "\377"> /dev/short0命令形式人为给/dev/short0发0xff(9脚和10脚相连,即引发中断),再dd if=/dev/short0 bs=1 count=1 ,do_short_read返回count=4,li=0,但是我马上cat /proc/short却显示li=2 (这就有两个问题1) 就是前面的问题为什么count=4: (2)do_short_read和/proc/short显示的li为什么不同,且我只发了一个中断li应该等于1
我继续echo -ne "\000" >/dev/short0 然后echo -ne "\377" >/dev/short0再次引发中断,同样do_short_read返回li=0,而/proc/short返回3

有时候不动电脑,过一会,cat /proc/interrupts 或cat /proc/short发现short_interrupt例程也执行了.
另外还发现一个现象:当上次unload模块之前echo -ne "\377" > /dev/short0
(即9和10脚高电平),然后再load模块,立即cat /proc/interrupts发现模块有中断,但cat /proc/short却又发现li=0

情帮忙分析分析,谢了!

Answer 1

源代码也有,问题也说了,怎么就没人回复呢?

Answer 2

我的建议是，这种测试，不要用echo这样的shell指令，直接写程序，通过系统调用接口来操作，这样比较稳妥。

Answer 3

版主:我就按你的要求,自己写程序,通过系统调用来操作,如有问题再来请教.

Answer 4

ok，主要是这个程序我没测过，没有硬件条件

Answer 5

ssize_t do_short_read (struct inode *inode, struct file *filp, char __user *buf,                size_t count, loff_t *f_pos)
{
...
printk(.....count=......);
.....
}
用自己写的程序(采用系统调用)发现: 特别要注意顺序
读2字节 count=7
读3 count=8
读4 count=8
读5 count=8
读2 count=8
读3 count=8
读20  count=9
读21  count=9
读1   count=9
读50  count=9
读100 count=9

真不好理解???

Answer 6

你这个是测试程序？我的意思是你测试的时候，直接通过调用write()，read()这类函数来操作，这样对程序的执行流程比较有把握和控制。
一条echo指令或者 cat指令，你有时候不知道它执行了几次read和write调用。

Answer 7

proc系统在使用前做初始化(全1)。试试看。

Answer 8

size_t do_short_read (struct inode *inode, struct file *filp, char __user *buf,                size_t count, loff_t *f_pos)
{
...
printk(.....count=......);
.....
}
上面是模块中的程序.

用自己写的测试程序(采用系统调用open,write,read)发现: 特别要注意顺序
读2字节 count=7
读3 count=8
读4 count=8
读5 count=8
读2 count=8
读3 count=8
读20  count=9
读21  count=9
读1   count=9
读50  count=9
读100 count=9

Answer 9

呵呵，看来这样的话，还是比较容易分析的吧。
这样你可以再结合以下你内核的驱动程序，好好思考一下程序的执行流程

ps：新年了，这么积极以兄弟，送你5分