Messages in this thread |  | | | Date | Sat, 24 Jul 1999 21:29:06 +0200 (MET DST) | | From | Gerard Roudier <> | | Subject | Re: Joking PCI bridges: still another one. |
| |
On Sat, 24 Jul 1999, Paul Jakma wrote:
> 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/
|  |