LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Hardware > Linux - Embedded & Single-board computer
User Name
Password
Linux - Embedded & Single-board computer This forum is for the discussion of Linux on both embedded devices and single-board computers (such as the Raspberry Pi, BeagleBoard and PandaBoard). Discussions involving Arduino, plug computers and other micro-controller like devices are also welcome.

Notices

Reply
 
Search this Thread
Old 06-06-2009, 05:10 PM   #1
nesta
Member
 
Registered: Aug 2006
Posts: 100

Rep: Reputation: 15
what is /proc/interrupts & /proc/irq/*/spurious mean?


Hi All,
i have a board shipped with Linux kernel 2.6.27.

i have some problems in interrupts but while i was gathering some info about the interrupts on my board by
Code:
cat /proc/interrupts
           CPU0
 16:       2525   OpenPIC   Level     enet_tx
 17:       5606   OpenPIC   Level     enet_rx
 18:          0   OpenPIC   Level     enet_error
 21:          3   OpenPIC   Level     fsldma-channel
 22:          3   OpenPIC   Level     fsldma-channel
 23:          3   OpenPIC   Level     fsldma-channel
 25:          3   OpenPIC   Level     fsldma-channel
 26:        461   OpenPIC   Level     serial
 27:          0   OpenPIC   Level     i2c-mpc
 48:          4   OpenPIC   Level     phy_interrupt
 50:          0   OpenPIC   Edge      DSP-A
 52:         11   OpenPIC   Edge      DSP-B
 54:          0   OpenPIC   Level     FPGA
BAD:          0
actually i m interested in IRQ number 52.
from the previous command: it seems to me OpenPIC has received 11 interrupt from the device namely DSP-B& this interrupt is edge triggered. Is it correct?

Also i use:
Code:
cat /proc/irq/52/spurious
count 11
unhandled 0
last_unhandled 0 ms
but actually i dont understan its meaning?
does it mean that i received 11 spurious interrupt? i expect this because the name of the file is spurious.

what does the field unhandled mean?

thanks for ur help.
 
Old 06-16-2009, 09:33 AM   #2
GrapefruiTgirl
Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 543Reputation: 543Reputation: 543Reputation: 543Reputation: 543Reputation: 543
It appears that the files in /proc/irq/*/spurious basically show a breakdown of where any spurious interrupts have occurred.
Your embedded system looks slightly different than my desktop system, but if I do:

`cat /proc/interrupts` I get the following:

Code:
sh-3.1# cat /proc/interrupts
           CPU0       CPU1
  0:        335          0   IO-APIC-edge      timer
  1:      30764          0   IO-APIC-edge      i8042
  6:          4          0   IO-APIC-edge      floppy
  7:          1          0   IO-APIC-edge
  9:          0          0   IO-APIC-fasteoi   acpi
 12:     881584          0   IO-APIC-edge      i8042
 14:     375849          0   IO-APIC-edge      ide0
 15:         85          0   IO-APIC-edge      ide1
 18:    4462873          0   IO-APIC-fasteoi   nvidia, nvidia
 19:          0          0   IO-APIC-fasteoi   serial
 20:    3394343          0   IO-APIC-fasteoi   HDA Intel
 21:        231          0   IO-APIC-fasteoi   ehci_hcd:usb1
 22:      40497          0   IO-APIC-fasteoi   sata_nv, eth0
 23:        135          0   IO-APIC-fasteoi   sata_nv, ohci_hcd:usb2
NMI:          0          0   Non-maskable interrupts
LOC:    6222105    7073890   Local timer interrupts
SPU:          0          0   Spurious interrupts
RES:      44719      87819   Rescheduling interrupts
CAL:       7339      12277   Function call interrupts
TLB:      19512      23211   TLB shootdowns
TRM:          0          0   Thermal event interrupts
ERR:          1
MIS:          0
sh-3.1#
So as you can see, there's a line there for 'spurious' which your embedded system doesn't show (probably for space/memory reasons I suppose, but I really don't know-- maybe that's why the 'BAD' line is there). Now, *IF* for example my above listing showed a number of spurious interrupts, I would need to look into /proc/irq/*/spurious to find out exactly where they occurred.

The file you showed above at /52/spurious tells us that there were 11 interrupts in total, and that there are/were zero unhandled interrupts. An unhandled interrupt is one for which there was no software or kernel code waiting for it or prepared to deal with it, and therefore an unhandled interrupt just kinda flies off into space

I'm guessing now: I think the 'last_unhandled' field would indicate how long the interrupt line was held by the unhandled interrupt, in milliseconds; I did no research on this though, so I could be wrong here.. Just a logical guess.

I have no clue as to whether the interrupt you are looking at for the item labeled '52' is correct, or edge-triggered, or what. I'd have to go with what the kernel says: It's a PIC generated, edge-triggered interrupt; that's what the kernel has determined from the hardware.

Finally, what is a spurious interrupt? While I'm not able to give an engineer's prespective, here's something I read just the other day when looking into some kernel driver parameters (paraphrase):
"Many motherboards/BIOS's generate a spurious interrupt early during boot"... For legacy reasons of some kind...

For the longest time, I ALWAYS got a spurious interrupt early in boot, on my desktop motherboard. It isn't harmful, but just gave an annoying message in dmesg. If I recall, it was on IRQ7 which is associated with the LP/Parallel Printer port.
The latest kernel has some fixes to deal with these legacy spurious interrupts, and if nothing else, I think since my last upgrade that I no longer see those messages -- I'm sure the interrupt is still happening, but probably the kernel has just stopped telling me about it.

Hope this helps!
Remember, this is all based on my own reading of stuff here and there, and not on any engineering background I have (which I don't have!) so if you need more/concrete information, Google is your best friend.

Sasha
 
Old 06-16-2009, 09:33 AM   #3
GrapefruiTgirl
Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 543Reputation: 543Reputation: 543Reputation: 543Reputation: 543Reputation: 543
It appears that the files in /proc/irq/*/spurious basically show a breakdown of where any spurious interrupts have occurred.
Your embedded system looks slightly different than my desktop system, but if I do:

`cat /proc/interrupts` I get the following:

Code:
sh-3.1# cat /proc/interrupts
           CPU0       CPU1
  0:        335          0   IO-APIC-edge      timer
  1:      30764          0   IO-APIC-edge      i8042
  6:          4          0   IO-APIC-edge      floppy
  7:          1          0   IO-APIC-edge
  9:          0          0   IO-APIC-fasteoi   acpi
 12:     881584          0   IO-APIC-edge      i8042
 14:     375849          0   IO-APIC-edge      ide0
 15:         85          0   IO-APIC-edge      ide1
 18:    4462873          0   IO-APIC-fasteoi   nvidia, nvidia
 19:          0          0   IO-APIC-fasteoi   serial
 20:    3394343          0   IO-APIC-fasteoi   HDA Intel
 21:        231          0   IO-APIC-fasteoi   ehci_hcd:usb1
 22:      40497          0   IO-APIC-fasteoi   sata_nv, eth0
 23:        135          0   IO-APIC-fasteoi   sata_nv, ohci_hcd:usb2
NMI:          0          0   Non-maskable interrupts
LOC:    6222105    7073890   Local timer interrupts
SPU:          0          0   Spurious interrupts
RES:      44719      87819   Rescheduling interrupts
CAL:       7339      12277   Function call interrupts
TLB:      19512      23211   TLB shootdowns
TRM:          0          0   Thermal event interrupts
ERR:          1
MIS:          0
sh-3.1#
So as you can see, there's a line there for 'spurious' which your embedded system doesn't show (probably for space/memory reasons I suppose, but I really don't know-- maybe that's why the 'BAD' line is there). Now, *IF* for example my above listing showed a number of spurious interrupts, I would need to look into /proc/irq/*/spurious to find out exactly where they occurred.

The file you showed above at /52/spurious tells us that there were 11 interrupts in total, and that there are/were zero unhandled interrupts. An unhandled interrupt is one for which there was no software or kernel code waiting for it or prepared to deal with it, and therefore an unhandled interrupt just kinda flies off into space

I'm guessing now: I think the 'last_unhandled' field would indicate how long the interrupt line was held by the unhandled interrupt, in milliseconds; I did no research on this though, so I could be wrong here.. Just a logical guess.

I have no clue as to whether the interrupt you are looking at for the item labeled '52' is correct, or edge-triggered, or what. I'd have to go with what the kernel says: It's a PIC generated, edge-triggered interrupt; that's what the kernel has determined from the hardware.

Finally, what is a spurious interrupt? While I'm not able to give an engineer's prespective, here's something I read just the other day when looking into some kernel driver parameters (paraphrase):
"Many motherboards/BIOS's generate a spurious interrupt early during boot"... For legacy reasons of some kind...

For the longest time, I ALWAYS got a spurious interrupt early in boot, on my desktop motherboard. It isn't harmful, but just gave an annoying message in dmesg. If I recall, it was on IRQ7 which is associated with the LP/Parallel Printer port.
The latest kernel has some fixes to deal with these legacy spurious interrupts, and if nothing else, I think since my last upgrade that I no longer see those messages -- I'm sure the interrupt is still happening, but probably the kernel has just stopped telling me about it.

Hope this helps!
Remember, this is all based on my own reading of stuff here and there, and not on any engineering background I have (which I don't have!) so if you need more/concrete information, Google is your best friend.

Sasha
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Boot hang after 'proc on /proc type proc (rw)' Hagoromo Slackware 13 10-05-2007 05:03 PM
Correlation between /proc/devices and /proc/modules ColinLadyka Linux - General 1 02-13-2006 05:25 PM
protential IRQ conflict ??? results of /proc/interrupts feetyouwell Red Hat 1 01-02-2004 09:32 PM
see this output of /proc/interrupts bmahesh Linux - Hardware 5 09-19-2003 02:16 PM
Mouse detected in bios but not assigned IRQ in /proc/interrupts Onyx^ Linux - Hardware 4 08-26-2003 09:43 AM


All times are GMT -5. The time now is 03:48 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration