Question on MPC83xx interrupts

Question on MPC83xx interrupts

[Andre Schwarz]

All,

I'm currently running a MPC8343 based board.

Looks like I'm having problems with IRQs of a PCI device.

/proc/interrupts give :

           CPU0
 16:        554   IPIC   Level     i2c-mpc
 17:         11   IPIC   Level     i2c-mpc
 18:        134   IPIC   Level     ath
 19:       1557   IPIC   Level     serial
 21:        341   IPIC   Level     mpc83xx_spi
 38:          0   IPIC   Level     ehci_hcd:usb1
BAD:          2



I wonder if the IRQ number should match the vector of the datasheet ... 
giving :

14  -> I2C1
15  -> I2C2
16  -> SPI
38  -> USB DR

The "ath" is a PCI Ath5k WiFi module connected to IRQ1, i.e. mapped to 
vector 17.


Are the IRQ numbers shifted/mapped/scrambled in any way ?

Can anyone shed some light on this ?


Cheers,
Andre Schwarz
Matrix Vision

MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Re: Question on MPC83xx interrupts

[Scott Wood]

On Tue, Apr 22, 2008 at 06:58:33PM +0200, Andre Schwarz wrote:
> I wonder if the IRQ number should match the vector of the datasheet ... 
> giving :

No.  The numbers in /proc/interrupts are virtual IRQ numbers, which are a
purely Linux-internal construct.

-Scott

Re: Question on MPC83xx interrupts

[Andre Schwarz]

[-- Attachment #1: Type: text/plain, Size: 774 bytes --]

Scott Wood schrieb:
> On Tue, Apr 22, 2008 at 06:58:33PM +0200, Andre Schwarz wrote:
>   
>> I wonder if the IRQ number should match the vector of the datasheet ... 
>> giving :
>>     
>
> No.  The numbers in /proc/interrupts are virtual IRQ numbers, which are a
> purely Linux-internal construct.
>
> -Scott
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>   
Scott,

thanks - any Idea how to figure out where the BAD comes from ?
Is it simply an unhandled/unacked one ?


regards,
Andre


MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

[-- Attachment #2: Type: text/html, Size: 1390 bytes --]

Re: Question on MPC83xx interrupts

[Scott Wood]

On Tue, Apr 22, 2008 at 07:36:48PM +0200, Andre Schwarz wrote:
> thanks - any Idea how to figure out where the BAD comes from ?
> Is it simply an unhandled/unacked one ?

It generally happens when an interrupt is requested, and the core takes
the exception, but then the interrupt source deasserts itself.

-Scott

Re: Question on MPC83xx interrupts

[Andre Schwarz]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

Scott Wood schrieb:
> On Tue, Apr 22, 2008 at 07:36:48PM +0200, Andre Schwarz wrote:
>   
>> thanks - any Idea how to figure out where the BAD comes from ?
>> Is it simply an unhandled/unacked one ?
>>     
>
> It generally happens when an interrupt is requested, and the core takes
> the exception, but then the interrupt source deasserts itself.
>
> -Scott
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>   
So this is not bad at all if you have a device with self-clearing 
interrupts ...

Thanks,
Andre


MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

[-- Attachment #2: Type: text/html, Size: 1391 bytes --]

Re: Question on MPC83xx interrupts

[Scott Wood]

On Tue, Apr 22, 2008 at 08:51:23PM +0200, Andre Schwarz wrote:
> Scott Wood schrieb:
> >On Tue, Apr 22, 2008 at 07:36:48PM +0200, Andre Schwarz wrote:
> >  
> >>thanks - any Idea how to figure out where the BAD comes from ?
> >>Is it simply an unhandled/unacked one ?
> >>    
> >
> >It generally happens when an interrupt is requested, and the core 
> >takes
> >the exception, but then the interrupt source deasserts itself.
> >
> >-Scott
> So this is not bad at all if you have a device with self-clearing 
> interrupts ...

Right, as long as you don't get too many of them I wouldn't worry.

-Scott

Re: Question on MPC83xx interrupts

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

On Tue, 2008-04-22 at 12:23 -0500, Scott Wood wrote:
> On Tue, Apr 22, 2008 at 06:58:33PM +0200, Andre Schwarz wrote:
> > I wonder if the IRQ number should match the vector of the datasheet ... 
> > giving :
> 
> No.  The numbers in /proc/interrupts are virtual IRQ numbers, which are a
> purely Linux-internal construct.

You can see the mapping between virq and hwirq numbers by turning on
CONFIG_VIRQ_DEBUG and looking in /sys/kernel/debug/powerpc/virq_mapping
(after mounting debugfs).

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Question on MPC83xx interrupts

[André Schwarz]

Michael Ellerman schrieb:
> On Tue, 2008-04-22 at 12:23 -0500, Scott Wood wrote:
>> On Tue, Apr 22, 2008 at 06:58:33PM +0200, Andre Schwarz wrote:
>>> I wonder if the IRQ number should match the vector of the datasheet .=
..=20
>>> giving :
>> No.  The numbers in /proc/interrupts are virtual IRQ numbers, which ar=
e a
>> purely Linux-internal construct.
>=20
> You can see the mapping between virq and hwirq numbers by turning on
> CONFIG_VIRQ_DEBUG and looking in /sys/kernel/debug/powerpc/virq_mapping
> (after mounting debugfs).
>=20
> cheers
>=20

Ahhh - thanks Michael !

very useful ...



Cheers,
Andr=E9

MATRIX VISION GmbH, Talstra=DFe 16, DE-71570 Oppenweiler  - Registergeric=
ht: Amtsgericht Stuttgart, HRB 271090
Gesch=E4ftsf=FChrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Re: Question on MPC83xx interrupts

[Segher Boessenkool]

> You can see the mapping between virq and hwirq numbers by turning on
> CONFIG_VIRQ_DEBUG and looking in /sys/kernel/debug/powerpc/virq_mapping
> (after mounting debugfs).

Ooh, nice!  Are there plans to move this into some "real" sysfs
nodes?


Segher