Markus Franke wrote: > Dear Xenomai-Users / Developers, > > I have finished my work on a parallelport module for measuring external > interrupt latencies. It is based on another kernel-module working on > plain linux. Interrupt latencies are measured via triggering an > interrupt over a connection between data pin 7 and the ACK-pin. > > The kernel module loads fine without any problems. When starting the > User-space task the system freezes without any output in the kernel log. > I was trying to solve the problem for several days now without any > success. I would appreciate, if somebody would have a short look on it. > Maybe its just a small problem which can be fixed easily. > > The kernel-module as well as the user-space task are attached. > > Thanks in advance and regards, > Markus Franke > > PS.: I am aware of the fact that there is already a testcase in the > testsuite for measuring external interrupt latencies. Nevertheless, I > would like to gain experiences in developing with Xenomai and I want to > know why the attached code doesn't work. I will also work with the > testcases in the testsuite soon. >
...
>
> // ISR
> int parport_isr(xnintr_t* cookie)
> {
> rdtsc(t_end);
>
> outb(0x00,SPPDATAPORT);
>
> #ifdef DEBUG
> printk(KERN_INFO "parport_latency: Interrupt fired!!!\n");
> printk(KERN_INFO "parport_latency: interruptcount before =
> %d!!!\n",atomic_read(&interruptcount));
> #endif
>
> atomic_inc(&interruptcount);
>
> #ifdef DEBUG
> printk(KERN_INFO "parport_latency: interruptcount after=
> %d!!!\n",atomic_read(&interruptcount));
> #endif
>
> wake_up_interruptible(&intlatpar_queue);
This is a hard-RT IRQ handler, thus any scheduling Linux service is
strictly forbidden.
[Reminds me of the I-pipe debugging service that can catch such faults
but still needs some integration work...]
>
> #ifdef DEBUG
> printk(KERN_INFO "parport_latency: exit parport_isr()!!!\n");
> #endif
>
> return 0;
> }
>
> /* the struct of fileoperations */
> static struct file_operations intlat_fops = {
> .read = latdev_read,
> .open = latdev_open,
> .release = latdev_release,
> .ioctl = latdev_ioctl
> };
>
>
> // Initialise module
> int parport_init(void)
> {
> int err = 0;
>
> printk(KERN_INFO "parport_latency: Initialisation started\n");
>
> /* enable parallel port interrupt generation, probably not needed */
> outb(SSPINTERRUPTENABLE,SPPCONTROLPORT);
>
> err = rt_intr_create(&intr, "parport_latency", INTR_NR, &parport_isr,
> NULL, 0);
> if(err != 0)
> {
> printk(KERN_INFO "parport_latency: Error while requesting
> Interrupt %d, error %d\n", INTR_NR, err);
> return -1;
> }
>
> err = rt_intr_enable(&intr);
> if(err != 0)
> {
> printk(KERN_INFO "parport_latency: Error while enabling
> Interrupt %d, error %d\n", INTR_NR, err);
> return -1;
> }
>
> if(register_chrdev(INTLAT_DEV_MAJOR,INTLAT_DEV_NAME,&intlat_fops) < 0)
> {
> printk(KERN_WARNING "intlat: parport_latency():
> register_chrdev() failed.\n");
> rt_intr_disable(&intr);
> return -1;
> }
Hmm, a Linux character device for this purpose... I guess you should
study the existing irqbench test a bit first. And if you don't see why
something is done the way it is - ask here.
Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
