> On Sat, 24 Jul 1999, Gerard Roudier wrote:
>
> If we assume that all PCI-HOST bridges that are used with X86 hardware are
> all fine (I mean that we just don't care about those that are not so ;) ),
> then the number of remaining bridges (used on non-X86 systems) we can get
> documentation about should not be that large.
> No documentation means not supported or just finger-crossed support and no
> more.
>
> Hi Gerard,
>
> These incompatibilities you speak of, could they be the reason that
> 2.3, 2.2.?-ac? and 2.2-pre2 don't boot on Samsung Alpha UX
> motherboards?
Very probably _no_.
The issue I spoke about involves the flushing of posted write
transactions. Some bridges donnot flush posted transactions when the PCI
spec say they shall do so. PCI devices driver that aren't aware of
specific bridge bahaviour about flushing of posted transactions may
encounter consistency problems due to this difference.
However, most of the time, posted writes are very quickly flushed by
bridges and this should unlikely prevent a system from booting, unless
very bad luck happens. In real life, it also seem that systems with not
quite compliant bridges running drivers that expect bridges to be PCI
compliants are able to stay alive for a long time, but Murphy law may
apply at any time.
> This is the message I get:
>
> sym53c8xx: at PCI bus 1, device 13, function 0
> sym53c8xx: setting PCI_COMMAND_PARITY
> sym53c875-0: rev=0x03, base=0xb100000, io_port=0x9000, irq=20
> sym53c875-0: ID 7, Fast-20, Parity Checking
> sym53c875-0: on-chip RAM at 0xb101000
> CACHE TEST FAILED: script execution failed
> sym53c875-0: start=802b5cf8, pc=802b5cf8, end=802b5d18
> sym53c875-0: CACHE INCORRECTLY CONFIGURED...: giving up...
>
> 2.2.10 works fine. So I copied the 2.2.10 sym53x8xx files over to
> 2.3.10 and 2.2.11pre2, but same thing happens, also with the
> ncr53c8xx driver. So something has changed in 2.2.11pre2 and 2.3 to
> break your driver.
The latest -ac patches incorporates a wrong change in the alpha specific
code that breaks the ncr53c8xx driver and most of the sym53c8xx driver
versions for ALPHA. This change may be reverted and, anyway, a fix will be
supplied in further diffs (not by me).
The offending change had the effect to prevent PCI transactions targetted
from a PCI device to the PCI bus address space to work as expected.
The drivers affected are, for example, those that let the PCI
device self-master itself from the PCI BUS.
Latest sym53c8xx driver version didn't use anymore PCI self-mastering, but
the ncr53c8xx driver cannot work without this feature since the support of
old NCR chips precludes use of LOAD/STORE instructions that hadn't yet
been invented for this chip family at the time of earliest NCR53C8XX
chips.
> The other compiled in drives seem to detect their controllers fine,
> eg IDE.
The linux ncr53c8xx driver and other drivers that deal with this chip
family are perhaps the only drivers that are affected (ALPHA only).
And by the way, the sym53c8xx driver (recent versions) is probably the
only driver for SYM53C8XX chips that does not require PCI self-mastering.
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/