Date: Tue, 7 Dec 1999 02:36:26 +0100 (MET) From: Gerard Roudier <groudier@club-internet.fr> To: Parag Patel <parag@cgt.com> Cc: Mike Smith <msmith@FreeBSD.ORG>, Ed Hall <edhall@screech.weirdnoise.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) Message-ID: <Pine.LNX.3.95.991207020453.978A-100000@localhost> In-Reply-To: <6268.944520117@pinhead.parag.codegen.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 6 Dec 1999, Parag Patel wrote: =20 [ ... ] > In the proecss, we discovered a very interesting thing about the > NCR/Symbios chips, at least the 810 and 825 series. Turns out that when > they are executing their scripts, and the scripts access an on-board PCI > register, that access actually negotiates for the PCI bus and uses it to > read the register! That's right - it uses the PCI bus to talk to > itself - even when it's not DMA-ing anything! That's true for drivers that uses MEMORY MOVE scripts instructions to access chip IO registers from SCRIPTS, as does the ncr and most existing generic SYM53C8XX PCI device drivers. Such a technic is no longer PCI compliant since PCI specifications 2.2. The sym driver uses LOAD/STORE instead that donnot involve any self mastering from the chip and so preserves PCI 2.2 compliance. But this needed to drop support of 810 and 825. Btw, even using the sym driver has been reported to trigger the problem, so this should not be the cause of the problem.=20 > Freaked us out when we saw it, 'cause the CPU wasn't anywhere near any > code that was accessing the NCR's registers. Of course it slows down > script execution but could slow down the PCI bus depending on the > script. And this is all without the CPU being involved. Certainly > it'll cause more PCI-bus activity that most other chips, and perhaps > this is why NCR controllers tend to trigger the DMA condition. I donnot know about the fxp driver, but looking into the code as a newbie, I didn't get how this driver ensures instruction and memory ordering and PCI transaction ordering when it is needed (could it be never needed?). It also seems to write non atomically to some 32 bit quantities in memory that seem to be accessed by the PCI device. Indeed, I may for sure did miss lots of things, but this seems strange to me. Sorry if my remarks are irrelevant. I just was wondering. > It seems that whoever designed the NCR's script-engine glommed it onto > the original programmed I/O SCSI core using the PCI bus instead of > redesigning the chip. Cheap short-cut. Dunno if any other NCR chips > exhibit this behavior, but I wouldn't be surprised. A well designed PCI device must be capable of having its master part accessing its target part through the PCI BUS lines without contention.=20 This does not imply that using such a feature is recommended since it wastes PCI bandwidth (and btw is not compliant with PCI-2.2). Using internal pathes instead is recommended to access internal ressources. The sym driver does this the right way using LOAD/STORE (at least, it is what I beleive :), but this could not be achieved for ealiest 810/815/825 due to the lack of these SCRIPTS instructions for these chips.=20 G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" 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.991207020453.978A-100000>