Re: Scanning problems - machine lockups

[=?ISO-8859-1?Q?G=E9rard_Roudier?=]

On Fri, 19 Jan 2001, Bob Frey wrote:

> On Thu, Jan 18, 2001 at 11:24:54PM +0000, Stephen Kitchener wrote:
> > The only thing that might be odd is that the scanner's scsi card and the 
> > display card are using the same IRQ, but I thought that IRQ sharing was ok in 
> > the new kernels. The display card is an AGP type and the scsi card is pci.
> >
> > As you might have guessed, I am at a loss as to what to do next. Any help 
> > appriciated, even suggestions as to how I can track down what I haven't done 
> > (yet!)
> Sharing interrupts could be the problem. Interrupt sharing is supported
> in the kernel as far as two different drivers being able to register a
> handler for the same interrupt, but not much beyond that. From studying
> the code I don't find any handling of unclaimed or spurious interrupts.
> 
> Some drivers (like video cards) do not register a handler for their card's
> interrupt. So when another driver (like the advansys driver) shares an
> interrupt with this card's "unregistered" interrupt there is no one left
> to handle the interrupt. The system will loop taking an interrupt from
> the card. I've observed this using the frame buffer driver. Note: this
> problem is unnoticed if the (video) card does not share an interrupt with
> another driver, because (at least on x86) Linux does not enable the
> PIC IRQ bit for IRQs that do not have registered interrupted handlers.
> 
> For Linux I think the right way to handle this is to have each (SA_SHIRQ)
> sharing capable interrupt handler return a TRUE or FALSE value indicating
> whether the interrupt belongs to the driver. In kernel/irq.c:handle_IRQ_event()
> check the return value. If after one pass through all of the interrupt
> (action) handlers no one has claimed the inerrupt then log a warning message
> (spurious interrupt) and clear the interrupt. The difficult/painstaking
> problem is that all SA_SHIRQ drivers need to be changed to return a return
> value to make this work.

There is no ordering of interrupts with respect to transactions in PCI.
As a result, getting interrupts that does not match a pending interrupt
condition as seen by driver can happen, without the interrupt being
spurious.

As a result, the 2 following assertions:
- All interrupts in PCI are spurious
- No interrupt is PCI is spurious
Are less wrong than asserting that some interrupts in PCI are relevant and
some are spurious. :-)

And btw, some hardwares, notably Intel ones, seems to ensure coherency
prior to deliver interrupts. This is a useless work when the IRQ is
actually shared and does only make sense for ISA or ISA-like PCI devices
and in situations where the IRQ is not actually shared.

> Anyway the simplest solution for you is probably if you can is to put
> assign the video card its own interrupt. Putting the two advansys cards
> on the same interrupt is fine. I have used interrupt sharing between
> multiple advansys cards and and ethernet cards without a problem.

In theory, the O/S should warn _loudly_ if any PCI device hasn't a
software driver attached, for the reason there is no generic way to
actually quiesce completely a PCI device. As a result, loading drivers
after boot or just loading drivers with interrupt enabled at boot is
unsafe with PCI devices. This shall be considered, even if the risk of a
breakage is generally very low.

  Gérard.