Kernel panic on interrupts

Hi all, I have been working on this following problem for a while and I'm getting nowhere.

I am using single-board computer (SBC) running White Dwarf Linux v2.0 with the following details:

Kernel: v2.4.20 White Dwarf Linux: v2.0 gnu: v3.3

I have written a kernel module to react on an external hardware interrupt that will occur at e.g. IRQ 7 line. The idea is then my application code could wait for an interrupt (perform an ioctl(WAIT_ON_INTERRUPT)) and react to it.

The basic structure of this module is given below:

MyModule.o

------------------

wait_queue_head_t int_queue;

__init initModule() { ?.. proper initialization, etc ?.

//register the interrupt handler request_irq(IRQ7,myHndlr, PORTNAME,NULL) //initialize the queue head init_waitqueue_head(&int_queue); }

myHndlr() { //re-wake the interrupt if asleep wake_up_interruptible(&int_queue); }

myIoclt() { //re-init the queue head init_waitqueue_head(&int_queue); //now wait for the interrupt interruptible_sleep_on(&int_queue); }

And I compiled this module using proper flags such as _MODULE _KERNEL etc....

I know the above module coupled with my application worked very well with kernel 2.2.20.

PROBLEM

------- When I recently moved to kernel 2.4.20, I get a kernel panic (Oops screen dump) every time I get the interrupt occurring. Hence, when interrupt occurs the trace jumps to myHndlr() and kernel panic occurs at the point of wake_up_interruptible(&int_queue);

What could this be?

Why did the identical module worked for 2.2.20 and not for 2.4.20?? (I made sure I used the proper lib for 2.4.20 when compiling the MyModule.o)

I have noticed slight variation of the code in /kermel/sched.c between

2.2.20 & 2.4.20, where these functions wake_up_interruptible() etc) are defined.

Could it also be as a result of implementation of softirq functions. Should I enable Softirq?

I tried using cpu_raise_softirq() within MyModule.o. The module compiled correct but when I load into the kernel, I get a lot of unresolved symbols. What about ksoftirqd_CPU0, is this interfering with the system?

Any help in this matter is appreciated.

Regards, Nejhdeh Ghevondian

Reply to
Nejhdeh Ghevondian
Loading thread data ...

Take a look at rtc.c how this is done.

-Michael

Reply to
Michael Schnell

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.