24 Aug
2010
24 Aug
'10
5:58 p.m.
On Tue, 24 Aug 2010 08:30:39 -0700
Mark Knecht <markknecht(a)gmail.com> wrote:
On Tue, Aug 24, 2010 at 8:13 AM, David Santamauro
<david.santamauro(a)gmail.com> wrote:
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.
Mark,
On Tue, 24 Aug 2010 06:54:30 -0700
Mark Knecht <markknecht(a)gmail.com> wrote:
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? On Tue, Aug 24, 2010 at 5:10 AM, David
Santamauro
<david.santamauro(a)gmail.com> wrote:
Manual says PCI at irq 20.
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.
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 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