[LAU] irq sharing

Mark Knecht markknecht at gmail.com
Tue Aug 24 15:30:39 UTC 2010

On Tue, Aug 24, 2010 at 8:13 AM, David Santamauro
<david.santamauro at gmail.com> wrote:
> Mark,
> On Tue, 24 Aug 2010 06:54:30 -0700
> Mark Knecht <markknecht at gmail.com> wrote:
>> On Tue, Aug 24, 2010 at 5:10 AM, David Santamauro
>> <david.santamauro at gmail.com> wrote:
>> >
>> > Hi,
>> >
>> >
>> > Is there a way to forcibly assign ICE1712 to another IRQ? I just
>> > want to test the theory.
>> >
>> IRQ's and their numbering are physical things. Their assignment is
>> made, fundamentally, when the motherboard is designed and is hardwired
>> based on the PC board traces. You cannot change those.
>> For desktop machines the control you do have is to move PCI devices to
>> different PCI slots. Asus motherboards are usually pretty good about
>> calling out what slots share interrupts with other devices. Check your
>> MB manual.
>> If you don't have a manual use your eyes and think about the whole IRQ
>> list. (Not just the part you showed.) Look for another PCI card that
>> seems to be on an interrupt by itself and then switch that card with
>> your sound card.
> Manual says PCI at irq 20.
>> For USB devices, if you have multiple USB controllers and _if_ they
>> use different IRQs, then you may be able to choose a different
>> controller by choosing a different USB connector to plug into. Move
>> your USB devices if this appears to be true about your motherboard.
>> (It is on many of mine...)
>> Note that sharing IRQs with a USB controller isn't necessarily bad. It
>> depends on what sort of USB device is attached, how its driver is
>> written, and how many interrupts it generates. However, all things
>> being equal, it's better if everything is completely separated as that
>> allows very little interaction.
> thanks for the time. I only have one PCI slot, but 3 empty PCI-x slots.
> I basically unplugged all USB devices as well as shut off both network
> interfaces and on board audio interface in the bios and the noise
> persists ...
> Not sure what to try next, this was a shot-in-the-dark.
> David

   Well, at first blush that implies to me this has nothing to do with
interrupts. Is the any card good? Have you tried it in another system?

   This was a long time ago in my chip design architect history but I
helped write one of the early versions of the PCI-x spec for bridging
devices. IIRC PCI-x host controllers were supposed to correctly handle
both 32-bit and 64-bit PCI cards when plugged into those slots so
(according to the original spec written maybe 12 years ago) if your
card physically plugs into whatever connectors your MB provides it
should work. (I.e. - PCI-x slows down to become PCI.) However if you
had any PCI-x cards they would slow down also. Not a problem in your
case it seems.

   Obviously we don't want to damage anything so I'd check your MB
manual on this, as well as looking at any BIOS for any settings or
clues about allowing PCI cards in PCI-x slots. You'll find a
supporting position here:


   As long as your card is a modern PCI card it's likely it will work
but be careful and read your docs first.


More information about the Linux-audio-user mailing list