request_irq () kills kernel

request_irq () kills kernel

[Rudolf Ladyzhenskii]

Hi, all

I am writing a driver to support MPC8260 hardware timers.
The very moment I call request_irq(), kernel dies without a warning (I use
2.4.4 kernel).

I was looking through the kernel code and I discovered that other drivers
use request_8xxirq() instead of request_irq(). Now, those things have been
defined to be same in /arch/ppc/kernel/irq.c, but both appear in System.map.
Which one should I use?
Also, anyone have any ideas why kernel would die?
I am trying to hook to interrupt 0x0c (Timer0) and I checked SIMR_L register
to make sure Timer interrupts are masked.

Thanks,
Rudolf


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: request_irq () kills kernel

[Dan Malek]

Rudolf Ladyzhenskii wrote:


> I was looking through the kernel code and I discovered that other drivers
> use request_8xxirq() instead of request_irq().

Hmmm.....I didn't think request_irq() should exist.  The reason for the
name change is to ensure people writing the drivers know a different
integrated interrupt controller is in use and to catch any legacy drivers
that would call request_irq() and mess up the interrupt controller.
We are discussing other options, but I'm holding out for a more generic
solution to all of the interrupt controller variants.

> ..... Now, those things have been
> defined to be same in /arch/ppc/kernel/irq.c, but both appear in System.map.
> Which one should I use?

You should only be using request_8xxirq() for all integrated peripherals.

> Also, anyone have any ideas why kernel would die?
> I am trying to hook to interrupt 0x0c (Timer0) and I checked SIMR_L register
> to make sure Timer interrupts are masked.

Installing an interrupt handler will automatically unmask that interrupt.
If the hardware isn't properly initialized, like the timer is constantly
generating interrupts, you will get stuck in an infinite interrupt loop.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: request_irq () kills kernel

[Rudolf Ladyzhenskii]

Thanks, Dan,

This was mu suspicion too about request_irq().
I could not get to the request_8xxirq() from driver. I found that file
/arch/ppc/kernel/ppc_ksyms.c did not export it for 8260 processor, only for
8xx processor. After I changed that file I am able to use request_8xxirq()
and it does not crash anymore.

Rudolf

> -----Original Message-----
> From: Dan Malek [mailto:dan@embeddededge.com]
> Sent: Thursday, November 22, 2001 2:39 PM
> To: Rudolf Ladyzhenskii
> Cc: Linuxppc-Embedded (E-mail)
> Subject: Re: request_irq () kills kernel
>
>
>
> Rudolf Ladyzhenskii wrote:
>
>
> > I was looking through the kernel code and I discovered that
> other drivers
> > use request_8xxirq() instead of request_irq().
>
> Hmmm.....I didn't think request_irq() should exist.  The
> reason for the
> name change is to ensure people writing the drivers know a different
> integrated interrupt controller is in use and to catch any
> legacy drivers
> that would call request_irq() and mess up the interrupt controller.
> We are discussing other options, but I'm holding out for a
> more generic
> solution to all of the interrupt controller variants.
>
> > ..... Now, those things have been
> > defined to be same in /arch/ppc/kernel/irq.c, but both
> appear in System.map.
> > Which one should I use?
>
> You should only be using request_8xxirq() for all integrated
> peripherals.
>
> > Also, anyone have any ideas why kernel would die?
> > I am trying to hook to interrupt 0x0c (Timer0) and I
> checked SIMR_L register
> > to make sure Timer interrupts are masked.
>
> Installing an interrupt handler will automatically unmask
> that interrupt.
> If the hardware isn't properly initialized, like the timer is
> constantly
> generating interrupts, you will get stuck in an infinite
> interrupt loop.
>
>
> 	-- Dan
>
>

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: request_irq () kills kernel

[Dan Malek]

Rudolf Ladyzhenskii wrote:

> .... After I changed that file I am able to use request_8xxirq()
> and it does not crash anymore.

OK, but does it actually _work_ for you :-).

Thanks.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: request_irq () kills kernel

[Rudolf Ladyzhenskii]

>
> > .... After I changed that file I am able to use request_8xxirq()
> > and it does not crash anymore.
>
> OK, but does it actually _work_ for you :-).
>
It installs the handler (I can see it in the /proc/interrupts) and does not
crash. I have not checked the interrupts themselves yet. Have to fix up some
other problems first.

Rudolf

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: request_irq () kills kernel

[Peter Barada]

>I am writing a driver to support MPC8260 hardware timers.
>The very moment I call request_irq(), kernel dies without a warning (I
>use 2.4.4 kernel).
>
>I was looking through the kernel code and I discovered that other
>drivers use request_8xxirq() instead of request_irq(). Now, those
>things have been defined to be same in /arch/ppc/kernel/irq.c, but
>both appear in System.map. Which one should I use?
>Also, anyone have any ideas why kernel would die?

I'm don't know which call to use, but this reminds me of a slightly
different problem I had bringing up the ppc kernel.  I accidently set
the frequency to 200 instead of 200Mhz, so the system timer was
programmed to interrupt one every 200 clocks instead of once every 200
*million* clocks, and the timer ISR takes longer than 200 clocks to
execute, so by the time the kernel was done servicing the timer, it
expired again!  This caused the processor to appear like it stopped
executing since it spent *all* of its time in the interrupt service
routine.

You may want to look at how you are setting up the timers and making
sure that the interrupt frequency is not so high as to prevent any
other processing.

--
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/