4

Here is the output from cat /proc/irq/79/spurious:

count 28
unhandled 0
last_unhandled 0 ms

What are these parameters indicating here — count, last_unhandled? Is this count indicating the number of times this interrupt did not get noticed?

4

count gives the total number of times the IRQ fired, modulo 100,000; spurious gives the number of unhandled events in recent memory; and last_unhandled stores the jiffies at which the last unhandled event occurred (displayed in milliseconds since the kernel booted).

The purpose of these is to track spurious interrupts and allow them to be taken into account if they occur too frequently. When a spurious interrupt occurs, the current time (in jiffies) is compared with the last unhandled time, and the spurious counter is only incremented if the previous spurious interrupt was recent enough. So occasional spurious interrupts won’t affect the system, whereas frequent spurious interrupts will eventually result in the IRQ being disabled (along with a message in the kernel logs):

If 99,900 of the previous 100,000 interrupts have not been handled then assume that the IRQ is stuck in some manner. Drop a diagnostic and try to turn the IRQ off.

  • If there are > 99900 unhandled interrupts, then IRQ is disabled, am I right? This num(99900) is quite high and it is unlikely that IRQ disable happens then? – Ravi Dec 7 '17 at 11:19
  • 1
    Right, IRQs are disabled once 99,900 of the last 100,000 IRQs went unhandled, which is unlikely, unless an IRQ is misconfigured; and then it becomes quite likely in practice. So the implementation meets the requirement: we only want invalid IRQs to be disabled, so the implementation makes it quite hard, but not impossible. (I’ve seen it work as intended on some systems with buggy firmware.) – Stephen Kitt Dec 7 '17 at 12:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.