Date: Thu, 17 Feb 2000 00:28:08 +0100 (MET) From: Gerard Roudier <groudier@club-internet.fr> To: Juergen Lock <nox@jelal.kn-bremen.de> Cc: Marc van Woerkom <van.woerkom@netcologne.de>, ngr@symbionics.co.uk, freebsd-scsi@FreeBSD.ORG Subject: Re: SC200/ncr53c810 problems Message-ID: <Pine.LNX.3.95.1000216232306.994A-100000@localhost> In-Reply-To: <200002160004.BAA97277@saturn.kn-bremen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 16 Feb 2000, Juergen Lock wrote: > In article <Pine.LNX.3.95.1000213175703.1123A-100000@localhost> you write= : > > > > > >On Fri, 11 Feb 2000, Marc van Woerkom wrote: > > > >> > The ncr53c810 is not PCI2.1 compliant, which I have found to matter. > > > >Early 53C810 are PCI-2.0 compliant. Differences between PCI-2.1 and > >PCI-2.0 should not explain 53C810 failures, on paper. However hardware h= as > >issues as software and may-be some issue can be triggerred when > >associating recent hardwares with old ones. And given the zero interest > >in things that donnot give income in our world, such kind of problem wil= l > >for sure be ignored. >=20 > Didn't the 53C810 have the problem that some of its controller > instruction caused io cycles to appear on the bus that were > in fact internal, violating the latest PCI standards? > and only the later symbios' have replacements for these > instructions that no longer do that... Hmmm... According PCI-2.2 / 3.10.9, a PCI device that accesses it target core as a master through the PCI BUS is not PCI-2.2 compliant. Reason is that PCI-2.2 requirement about Tprop considers the worst case of= =20 signal propagation to be when a device drives a signal and this signal =20 settles at the input of all _other_ devices. Due to the design of PCI (signals are driven at half their nominal level and reflection will do the rest of the work), it is longer for a signal=20 to settle at the driving device than at all other devices. In other words, Tprop for the driving device can be longer than the worst= =20 case considered by PCI-2.2. In result, a PCI-2.2 compliant PCI BUS system that does have no timing budget margin at all can lead to a Tprop for the driving device to be outside PCI-2.2 specifications. In real life, it seems that common 33 MHz PCI BUS systems overclocked to something like 37 MHz (even 40 MHz) still work reasonnably well. Such=20 PCI BUSses have enough margin for PCI devices that master them-selves to=20 meet PCI-2.2 Tprop requirement for 33 MHz clock, in my opinion. This let me think that a _real_ 33 MHz PCI device failing Tprop requirement due to mastering itself can only happen on PCI BUSses that have so few margin that a simple fly that would f*rt too loudly inside the box can break any PCI signaling requirement.:-)=20 However, I think that standard compliance is a serious concern and I have addressed the PCI-2.2 / 3.10.9 requirement in the Linux sym53c8xx driver a short time after I heard about this requirement (I hadn't the PCI-2.2 specs at that time but I read the PCI-sig list). Obviously, the FreeBSD `sym' driver is also ok regarding this requirement. However, for this to be achieved, the SCSI SCRIPTS shall not access chip IO registers using MEMORY MOVE SCRIPTS instructions, but should use LOAD/STORE instead or IO register to IO register operations.=20 Old ncr chips donnot support LOAD/STORE. On the other hand, a driver for these old chips that will not use MEMORY MOVE to access IO registers from SCRIPTS would be painful to write and would probably have bad performances (I donnot want to think a single second to such a stuff).=20 My conclusion is the following: 1) If you want your SYM53C8XX PCI-SCSI chip to not perform self-mastering,= =20 you should purchase a controller supported by the `sym' driver. 2) If you encounter problems with a SYM53C8XX PCI-SCSI chip using the `ncr' driver (self-mastering occuring for IO register reads and may-be self-modifying SCRIPTS in on-chip SRAM), these problems are very unlikely to be due to Tprop not meeting PCI-2.2 requirements (because=20 of self-mastering occuring). Regards, G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.1000216232306.994A-100000>