Mailinglist Archive: opensuse (5130 mails)

< Previous Next >
Re: [SLE] Changing hardware IRQ's
  • From: S Glasoe <srglasoe@xxxxxxxxxxx>
  • Date: Tue, 2 May 2006 08:24:59 -0500
  • Message-id: <200605020824.59840.srglasoe@xxxxxxxxxxx>
On Tuesday 02 May 2006 6:11 am, Damon Register wrote:
> S Glasoe wrote:
> > Don't bother. Unless you can actually prove a problem with IRQ sharing,
> > it doesn't matter. That is why you see the longer PCI hardware ID in
> > which
> That might be hard to do but in my experience (I admit it is limited)
> it was and still is something worth investigating

Depends on the age and version of the hardware and software being used.
Systems made since about 2000 or so typically won't have IRQ sharing

> > Pre-1999/2000, the older systems at that time needed correct IRQ
> > settings and usually would not share IRQs. That is really old-school
> > these days. You may run into this on pre-400-500 MHz systems but it is
> > less of an issue,
> That may be true but I believe it hasn't gone away entirely and must
> still be considered. I just ran into an IRQ sharing problem with a
> SBS ARINC 429 card that would not work when sharing an interrupt and
> even the vendor admitted their card didn't like sharing.

Ah, the exception to my generalizations. Yes _if_ a specific add-in card is
designed that _it_ shouldn't or can't share IRQs then that will be
difficult to reconcile in today's systems. I'm guessing here but that card
is probably fairly low in sales volume and its for specialized
communications that may need almost real-time processing or has to get
through no matter what.

> > especially in Linux, because the PCI routines are much better about
> > uniquely identifying each piece of hardware.
> The SBS product is for Windows and it is a shame they don't have a Linux
> version so I could see how that IRQ problem does with Linux. If there
> was a Linux version, do you believe that it might actually behave
> differently and perhaps even tolerate IRQ sharing?

I doubt it, based on the what this card is designed to do. They are probably
building to the most common denominator their customers have for these
cards: a Windows PC. They probably have the talent to do a non-OS specific
version but most likely they don't have the budget to do it. Testing for
bullet-proof operations in one OS (and several versions of that OS)
probably uses up tons of resources and gets their bean counters mighty

If this is the same ARINC I worked with in the early '90s then I can
understand why they want a dedicated IRQ for this type of communication
board. It has to work and can't be interrupted. The communication has to go

> Damon Register


< Previous Next >