Preempted interrupt handler

I'm actually working on a driver for a Marvell chip on a MIPS-based board running a 2.4 kernel. I have one problem:
In my module, my interrupt handler is never executed. I have traced the code until action->handler(irq, action->dev_id, regs) in handle_IRQ_event() but when the handler should be executed, it is not and the kernel reenters in the low-level interrupt dispatch routine (because we're using level sensitive interrupts and it is still up). I've checked that the function pointer called is the one of my handler but my routine is never entered.

But when my handler is included in the kernel (ie not compiled as a module), it works! My function gets executed and acks the interrupt. In this case all goes fine.

Moreover, I've noticed that the kernel symbols are mapped at adresses like 0x80258040 (start_kernel) but my module (and so is my handler) is loaded at something like 0xc000275c . I was thinking the module would be loaded in the same memory area as the kernel, so I think this is weird... Perhaps, the module handler can't be executed because of its location but I don't know how to fix this.

Quoted 14 lines · Yoann Allain

I'm actually working on a driver for a Marvell chip on a MIPS-based board running a 2.4 kernel. I have one problem:
In my module, my interrupt handler is never executed. I have traced the code until action->handler(irq, action->dev_id, regs) in handle_IRQ_event() but when the handler should be executed, it is not and the kernel reenters in the low-level interrupt dispatch routine (because we're using level sensitive interrupts and it is still up). I've checked that the function pointer called is the one of my handler but my routine is never entered.

But when my handler is included in the kernel (ie not compiled as a module), it works! My function gets executed and acks the interrupt. In this case all goes fine.

Quoted 6 lines

Moreover, I've noticed that the kernel symbols are mapped at adresses like 0x80258040 (start_kernel) but my module (and so is my handler) is loaded at something like 0xc000275c . I was thinking the module would be loaded in the same memory area as the kernel, so I think this is weird... Perhaps, the module handler can't be executed because of its location but I don't know how to fix this.

Good new then - you don't need to fix anything :-)

The sympthoms you're describing are not specific enough, so only some general advice:

- Make sure you're running a current version of modutils; older versions have a number of bugs that could result in almost any kind of ill behaviour.
- Make sure all object files of the modules have been built with -mlong-calls. That's done automatically by the kernel's makefiles but not necessarily when building out of tree and certain versions would silently tolerate the resulting relocation error.

Ralf

Is it normal for the modules to be loaded at 0xc0000000 (this is highmem, isn't it)? I see the same on my bcm1250 box. I've been wondering why they can't be loaded in kseg0. Or is it because of bad modutils/compiler flags?

Is it normal for the modules to be loaded at 0xc0000000 (this is highmem, isn't it)? I see the same on my bcm1250 box. I've been wondering why they can't be loaded in kseg0. Or is it because of bad modutils/compiler flags?

thanks
srini

Quoted 1 line

Ralf

Quoted 6 lines

Is it normal for the modules to be loaded at 0xc0000000 (this is highmem, isn't it)? I see the same on my bcm1250 box. I've been wondering why they can't be loaded in kseg0. Or is it because of bad modutils/compiler flags?

It is not necessary highmem. 0xc0000000 is a MAPPED(i.e. use TLB) kernel segment,
used by vmalloc to allocate a large virtually continous memory area for modules. Use kseg0 you have to get a large physically continuous area, and that is difficult unless you reserve some memory.