Subject: Preempted interrupt handler

From: Yoann Allain <[email-masked]>
Date: Mon, 19 Dec 2005 18:43:49 +0100

Hi,

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.

Some suggestions?

Thanks in advance.

Yoann

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 20 Dec 2005 14:18:29 +0100

> 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

---

From: Srinivas Kommu <[email-masked]>
Date: Wed, 21 Dec 2005 11:39:06 -0800

>    would silently tolerate the resulting relocation error.

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

-- 
Srinivas Kommu
Cisco Systems, Inc.
Ph. (408) 527-8610

---

From: "Steven J. Hill" <[email-masked]>
Date: Wed, 21 Dec 2005 14:15:18 -0600

> why they can't be loaded in kseg0. Or is it because of bad
Yes, it is normal to load them at 0xc0000000. No it is not because of bad
modutils/compiler flags.

-Steve

---

From: Fuxin Zhang <[email-masked]>
Date: Thu, 22 Dec 2005 08:46:34 +0800

> why they can't be loaded in kseg0. Or is it because of bad
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.

---

From: Yoann Allain <[email-masked]>
Date: Thu, 22 Dec 2005 09:35:07 +0100

>and that is difficult unless you reserve some memory.
I've just found in LDD 2nd version book (page 218), that on MIPS, 
addresses returned by vmalloc belong to a completely different address 
range from kmalloc addresses, whereas on x86 platforms they belong to 
the same.

Concerning the clues given by Ralf, I've tried insmoding the module by a 
recent version of modutils instead of using the insmod brought with 
Busybox : the kernel behaved the same, it doesn't want to use the 
handler of my kernel.
I've also checked that I was compiling with the mlong-calls flag...

Therefore, I think I will compile my module into the kernel, until I 
found a solution to this problem...

Thanks everyone!