IRQ storm

[abishai]

I've noticed that logs are complaining about IRQ storm

Oct  5 18:43:41 darkstar kernel: interrupt storm detected on "irq19:"; throttling interrupt source
Oct  5 18:44:14 darkstar last message repeated 3 times
Oct  5 18:46:01 darkstar last message repeated 6 times

vmstat -i

interrupt                          total       rate
irq19: pcm0                       763525        813
irq23: ehci0 ehci1                 64223         68

dmesg

pcm0: <Envy24HT audio (ESI Juli@)> port 0xd080-0xd09f,0xd000-0xd07f irq 19 at device 1.0 on pci8

I'm using snd_envy24ht added to kernel configuration file. IRQ storm starts on the first usage of associated /dev/dsp1 and slightly rising even when the usage of sound card discontinued.
Now it''s generating 917 interrupts (on the end of post editing). It it normal? It's flooding the logs, but on the other side, sound card works as intended.

 

[SirDice]

What version of FreeBSD? It may have been fixed already. It's usually caused by a badly behaving driver but it's also possible the hardware itself isn't 100%.

 

[abishai]

I'm using releng/10.0 with latest binary fixes. Custom kernel includes snd_envy24ht() and disables NVIDIA HDMI pcm devices. Should I try audio/oss instead of FreeBSD's OSS implementation? Or this port is outdated compared with FreeBSD OSS? I'm not sure what version we have now.

 

[Terri_Kennedy]

I've noticed that logs are complaining about IRQ storm

It it normal? It's flooding the logs, but on the other side, sound card works as intended.

I posted about this before, but I can't find the search function to see where on these forums it was. Anyway...

This can also be caused by an unconfigured device sharing the IRQ. If the unconfigured device generates an interrupt, it gets handed to the driver(s) for any other devices on that IRQ. The driver then looks at the interrupt, goes "not my device", and returns. Since this doesn't actually clear the cause of the interrupt, it will happen again if whatever condition triggered it in the first place recurs.

Sometimes you can convince the BIOS to rearrange the interrupt-to-device mapping to move either the problem device or the wanted device to another IRQ. Sometimes the interrupts can be individually assigned, sometimes there a single option named "Interrupt swizzling" (useful link) which will shuffle them. That may help (if your system offers these options).