[LAU] irq sharing
david.santamauro at gmail.com
Tue Aug 24 15:55:22 UTC 2010
On Tue, 24 Aug 2010 08:30:39 -0700
Mark Knecht <markknecht at gmail.com> wrote:
> 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?
the card works fine on the same hardware under 64-bit windows7. I'm
trying to get it working 100% in fedora 12 64-bit with an rt-kernel
(multi-os machine). I agree, interrupts are probably not the issue.
Last time I was fiddling with this problem I had suspected 64-bit
linux drivers as it works in the 32-bit machine I have.
> 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:
I read that as well, but my MB pci-x slots are (apparently) backwards
(pardon my ignorance)
see page 7
... backwards, meaning, I'd have to stick the card in backwards.
More information about the Linux-audio-user