Re: [LAU] irq sharing

On Tue, 24 Aug 2010 08:30:39 -0700
Mark Knecht <markknecht@email-addr-hidden> wrote:

> On Tue, Aug 24, 2010 at 8:13 AM, David Santamauro
> <david.santamauro@email-addr-hidden> wrote:
> >
> > Mark,
> >
> >
> > On Tue, 24 Aug 2010 06:54:30 -0700
> > Mark Knecht <markknecht@email-addr-hidden> wrote:
> >
> >> On Tue, Aug 24, 2010 at 5:10 AM, David Santamauro
> >> <david.santamauro@email-addr-hidden> 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
>
> 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:
>
> http://en.wikipedia.org/wiki/Pci-x

I read that as well, but my MB pci-x slots are (apparently) backwards
(pardon my ignorance)

see page 7
http://www.tyan.com/manuals/m_s5396_120.pdf

... backwards, meaning, I'd have to stick the card in backwards.

David

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Tue Aug 24 20:15:04 2010