Re: Yet another panic

Doug Ledford (dledford@dialnet.net)
Wed, 17 Jun 1998 03:44:35 -0500

Martin Mares wrote:
> > > You should worry at this point by the way. That function is called
> > > when the 2940 encounters a PCI error condition - such as a parity error.
> > > It could be something innocent like a PCI target abort when no PCI bus
> > > time is free.
> >
> > It shouldn't be calling the BIOS according to my understanding of the pci
> > function changes. Specifically, pcibios_read_config_byte would call the
> > BIOS, but I was under the impression that the pci_read_config_byte didn't
> > call into the BIOS. Am I wrong on this one?
>
> Yes. Both pcibios_* and pci_* functions can call the BIOS as on some
> machines we talk only to the BIOS.
>
> The question is whether we really need to access PCI configuration space in
> interrupt handlers. If we do, I'll change the PCI functions to use IRQ-safe
> spinlocks instead of global cli(). We currently need no locking on the device
> list.

Well, as Alan pointed out, that's an error recovery routine only triggered
by large numbers of spurious interrupts. Since we can't always be sure that
spurios interrupts are an error, we read STATUS1 in order to find out if
there *is* an actual error condition outstanding. If there is, we clear it
and go on. Without this code, it's possible to have a single PCI error
condition throw the machine into an interrupt storm under 2.1.x and lock the
machine under 2.0.x. Now, these conditions are rare, and the PCI parity
checking stuff is turned off at detect time by default (at least in the
latest driver), but if it is enabled, then we need to either be able to get
at that register, or I have to create some sort of timer/bottom_half/other
non-interrupt function to correct the error condition.

-- 


 Doug Ledford  <dledford@dialnet.net>
  Opinions expressed are my own, but
     they should be everybody's.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu