Hi all,
shows
how can i manage it, to have snd_hdsp exlusively using one interrupt? All i found was distributing interrupts on processors (irqthreads, irqbalance, affinity), but nothing about how to have an irq reserved for only one device.

Thanks in advance

From what I've read, the interrupt vectors that the IO-APIC interrupt controller uses are set at startup via data stored in ACPI tables. Not something that is easily adjustable, or something that I have any experience tinkering with.

The way I would normally handle this is to boot the kernel with the 'threadirqs' option set. Then you can set the realtime priority of the snd_hdsp irq thread higher so that interrupt requests from the sound card are prioritized over the SMBus interrupt.

Here is a resource I have bookmarked about irq priorities. It is focused around a FireWire card, but the concepts can be applied to PCI and USB audio irq priorities as well: http://subversion.ffado.org/wiki/IrqPriorities

Note that this is geared towards setting IRQs higher to achieve lower latency audio recording, which I assume is what you are trying to do? The rtirq program mentioned in that writeup is helpful and I use it for setting irq priorities. A slackbuild for it is also on slackbuilds.org: https://slackbuilds.org/repository/15.0/system/rtirq/


On a side note: If the i801_smbus driver is causing problems like interrupt storms then it can be disabled at boot with the command line option:
I've read about a bug that did this in pre 5.16 kernels when loading the jc42 kernel module, as mentioned here: https://bugzilla.kernel.org/show_bug.cgi?id=177311

Personally I have never seen the problem or have needed to disable the SMBus interrupt. If its not causing problems then just leave it. Adjusting the realtime priority should allow you to prioritize the sound card over the SMBus on the shared interrupt either way.

HTH.

Thank you for the answer, especially for link to ffado. That was the information about realtime scheduling and irqs i was looking for.
I wasn't aware, that this driver belongs to the i2c world, so i simply built a new kernel without it and now everything works fine again. The ffado page will be a guide for further optimization (which is now not really neccesary).
You were right, it's about audio.