linux: the tag that wouldn't die?

[Doug Ledford]

Justin T. Gibbs wrote:

> Are you sure this isn't caused by using I/O instructions instead memory
> mapped I/O. 

I'm positive that isn't the cause because it doesn't happen :)  There is
only one place in the current 5.0.x driver where we don't use the aic_inb
and aic_outb instructions, and that's the aic7xxx_probe() function that
looks for the 284x and 274x cards.  Obviously, I don't probe on the PCI
cards.  For the PCI cards, we use the pci_read_config_* functions to get the
IO and MMAP addresses and to configure those before we ever even go so far
as to do the initial pause of the chip.  If we configure the MMAP IO
address, then we never once touch that chip in PIO mode.  However, that
isn't to say I don't have an idea what else could be causing it, but if I'm
right, that problem is beyond the scope of this driver...

> This was a common problem on a few steppings of the P6 and
> was one of the main reasons I initially added memory mapped I/O support.
> 
> I've never had anyone report PCI parity errors like this with the FreeBSD
> driver when using memory mapped I/O.

There are a few situations that I know of that are "bad" under linux with
regards to this option.  One, some motherboards are shipping with a BIOS
option to change the cacheline size on the motherboard.  If this cache line
size is not set to 8, then it can cause all kinds of problems, including PCI
interrupts for PCI errors.  Two, there are certain motherboards that will
generate a continuous stream of interrupts when this is enabled.  One of
these that has been tested for me is the Intel Alder Quad PPro motherboard
based on the GX chipset.  On my own development motherboard, I can't force a
PCI error interrupt even when the error bits are active, it simply never
occurs.  Mine is an Intel DK440LX based on the LX chipset.  So, the general
issue is that under linux it's unreliable whether or not the PCI parity
error checking is actually checking anything worth checking.  Therefore,
it's disabled by default.

Now, I mentioned that I thought I might know what's causing this.  It could
be one of the FreeBSD/Linux difference things, I'm not sure.  But, certain
motherboards that generate these continuous streams of errors also seem to
have SERR and PARITY enabled in the command register for the primary bus
chipset, and that tends to be active at the time.  Motherboards that don't
ever generate anything tend to have the SERR and PARITY bits of PCI_COMMAND
disabled on the primary chipset.  So, I'm theorizing that possibly there are
differences in the PCI setup code on linux and FreeBSD that result in this. 
Possibly that the primary PCI chipset (the 440LX or 440GX or whatever) are
not having their PCI_COMMAND register set to sane values at boot up and as a
result we either get no checking, or bogus interrupts when we enable the
checking.  To my knowledge, the linux PCI code doesn't touch those bits in
the PCI chipset, and so we rely on the BIOS to set things up in a sane and
useable manner.  If we instead forced it to whatever it needed to be and
cleaned out any stale error information, then that might get things working,
but that's really in the PCI chipset code, not in the driver.

-- 

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

To Unsubscribe: send mail to majordomo at FreeBSD.org
with "unsubscribe aic7xxx" in the body of the message