> At 01:35 AM 7/24/99 +0200, you wrote:
> >
> >
> >On Fri, 23 Jul 1999, Barrett G. Lyon wrote:
> >
> >> >I used ncr... first to drive my symbios logic USCSI board, then sym,
> >> >both w/o any problems.
> >>
> >> Cool, but it caused my Intraserver cards to crash the box :(
> >
> >You may want to report the kernel configuration about ncr/sym drivers and
> >possible ncr/sym driver boot options you are using. Detailing a bit what
> >sort of crash you got is also interesting. Thanks.
>
> After a short uptime the system will lock. Before it locks I got thousands
> of log messages like:
>
> kernel: PYXIS machine check NOT expected
What makes you think that it is the driver that makes problem ?
How behaves the other one (NCR53C8XX/ncr53c8xx) ?
I am in fact very ennoyed about some PCI-HOST bridges that come from
non-PC world. This have been discussed recently about a SUN bridge. I have
read some documentation on existing PCI bridges (docs available on the
Net). For now, I only have found a bridge from IBM that seems to be
compliant enough with PCI specs so that it will not make problems with PCI
device drivers that do not know of those particular bridges (that just
miss the ordering rules that address consistency issues in PCI).
Yours, for example, seems to only be featured of the following 'flushing'
rules an of no 'ordering' rules at all: (excerpt from the 21172 doc)
- Before a read transaction to an I/O location is processed, all preceding
write transactions to devices are flushed out of the buffers.
- Before a read transaction from a PCI device to main memory is
processed, all preceding write transactions by the PCI device to main
memory are flushed out the buffer.
The consistency issue is addressed by PCI by ordering rules that applies
to posted transactions in _both_ directions when a read transaction
crosses the bridge.
My understanding of the behaviour of the 21172 may be just wrong, but the
bridge behaviour I quoted above can be easily worked around by drivers by:
1 - Performing a read (dummy) from the device to memory before raising
interrupt.
2 - performing a read (dummy) from the C code to an IO register from the
C code before scanning the flags that indicate completion.
Note that I may have missed something important in the 21172 bridge
documentation. If I did, then I expect to be fixed very quickly. :-)
I am currently studying how to safely support some bridges that do not
follow the PCI ordering rules and will provide some conditionnal code for
that before the end of August for the ncr/sym drivers. Obviously I can do
nothing for bridges I haven't any documentation about, or that are too
much broken.
Note that it is not proven that your problem is caused by some
inconsistency due to bridge a misfeature that victimized the driver.
> Then the machine would just lockup, this is using the SYM driver on 2.2.10.
> I tested 2.2.11-pre2 kernel out on the same dirver and the PYXIS messages
> came back again.
Regards,
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/