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

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