On Tue, 24 Aug 2010 08:30:39 -0700 Mark Knecht <markknecht@xxxxxxxxx> wrote: > On Tue, Aug 24, 2010 at 8:13 AM, David Santamauro > <david.santamauro@xxxxxxxxx> wrote: > > > > Mark, > > > > > > On Tue, 24 Aug 2010 06:54:30 -0700 > > Mark Knecht <markknecht@xxxxxxxxx> wrote: > > > >> On Tue, Aug 24, 2010 at 5:10 AM, David Santamauro > >> <david.santamauro@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
