Re: dmesg: PCI interrupts are no longer routed automatically.........

[linux-os]

On Mon, 10 Jan 2005, Bjorn Helgaas wrote:

> On Wed, 2005-01-05 at 13:15 -0500, linux-os wrote:
> > The problem is that the PLX-9656BA INTCSR is not in configuration
> > space, but runtime registers off a BAR. The interrupt source
> > can be from a PLD that hasn't even had its microcode loaded
> > yet!
> >
> > FYI, the PLX or similar clone is the bus interface chip for many
> > busmastering PCI boards.
> >
> > > You wouldn't want your ISR mucking around with a half-initialized
> > > device, so does it have to check a "device_configured" flag
> > > or something?
> >
> > Yes. If the device isn't configured, the ISR reads all the INTCSR
> > bits, then writes 0 to the register to prevent anything else.
>
> The PLX might be a common device, but it sounds like this
> particular issue depends on the design of the rest of the
> board.  And presumably, nobody who cared about performance
> would design a board with this property, right?  I mean, to
> add a test in the ISR for a condition that exists only for
> a few milliseconds at driver startup-time seems sub-optimal.

I'm not so sure about that. There are many hardware registers
to be read in the ISR before the ISR can "decide" what it is
supposed to do. I'm not sure that the few hundred nanoseconds
required to read/test a variable is all the consequential.

What I do know is that the board must recover from all known
errors because you can't irradiate a patient with X-Rays and
then decide to throw away the data.

Also, like most bus-mastering devices, you only get an interrupt
to report something, basically one interrupt per transmitted
packet and one per received. There are a few diagnostic thing
that make more, but they are not common events. The 'packets'
are 10 megabytes in length so the interrupts are really hidden
in the noise. Even Ethernet drivers with their 1500 max byte
packets that use this interface chip should really check for
a "real" interrupt now that hot-swap is commonplace.

> > If the PLX had been reset, then the INTCSR bits would all
> > be masked off. However, reset is really only guaranteed from
> > power OFF on some motherboards, in particuar the ones with
> > so-called "hot-swap" capabilites fail. There is a software
> > reset that, in fact, even reloads its serial EEPROM. However,
> > the BAR needs to be accessible for this to be used.
> >
> > So it would be wonderful if the correct IRQ could be made
> > available before the chip could generate an interrupt.
>
> If we exposed a new pcibios_route_irq() (to hide the arch-
> specific nature of IRQ routing via ACPI or other information),
> could you do what you need in a pci_fixup_early quirk?

That would be wonderful. If you have a patch I will install
it immediately and change the content of my macro (the source-code
even compiles on 2.4.x so there are lots of macros).

Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
                 98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/