Preempted interrupt handler

Preempted interrupt handler

[Yoann Allain]

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

Re: Preempted interrupt handler

[Ralf Baechle]

On Mon, Dec 19, 2005 at 06:43:49PM +0100, Yoann Allain wrote:

> 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.

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

Re: Preempted interrupt handler

[Srinivas Kommu]

On Tue, Dec 20, 2005 at 02:18:29PM +0100, Ralf Baechle wrote:
> On Mon, Dec 19, 2005 at 06:43:49PM +0100, Yoann Allain wrote:
> 
> > 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.
> 
> 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.

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

> 
>   Ralf

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

Re: Preempted interrupt handler

[Steven J. Hill]

Srinivas Kommu wrote:
> 
> 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?
>
Yes, it is normal to load them at 0xc0000000. No it is not because of bad
modutils/compiler flags.

-Steve

Re: Preempted interrupt handler

[Fuxin Zhang]

> 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.
> 
> thanks
> srini
> 
>>   Ralf
> 

Re: Preempted interrupt handler

[Yoann Allain]

Fuxin Zhang a écrit :

>>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.
>  
>
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!