Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!mips!daver!bungi.com!news From: gs@vw25.chips.com (George Scolaro) Newsgroups: comp.sys.nsc.32k Subject: Re: MMU and disk Message-ID: Date: 9 Nov 90 19:59:10 GMT Sender: news@daver.bungi.com Lines: 49 Approved: news@daver.bungi.com [In the message entitled "Re: MMU and disk" on Nov 9, 10:11, Bruce Culbertson writes:] > > Not having anything better to do, I decided to change the debugger so > > that memory is mapped thru the MMU. I mapped the I/O regions with the > > CI (cache inhibit) bit turned on. > > ... > > Do any of you more experienced 32532-ers have any ideas? Is anyone else > > using the MMU? > > I do not have any good ideas regarding the disk problems Gary is > having. Most I/O addresses cause a 32532 signal (called /ioh?) > to be asserted. This prevents caching, regardless of the ci bit > in the pte. The data ports for the SCSI controllers, however, > do not assert /ioh. This is to circumvent a '532 bug -- if /ioh > is asserted, the '532 seems to fetch both data and instructions > from memory. This doubles the number of memory cycles to read/ > write a disk block, which noticably affects disk performance. > I know this does not answer Gary's question -- I am just trying > to describe some of the complications. Actually to be totally clear: The 532 uses /IODEC and /IOINH to perform accesses to I/O space. /IODEC is an input and /IOINH is an output. The 532 expects any and all I/O devices to assert /IODEC during a valid access and to ignore the bus access if /IOINH is asserted (by the 532). This mechanism is necessary to ensure correct order of execution of user code. Primarily this mechanism is a solution to having a write buffer inside the 532. The scenario is: software does a write to an I/O control register, software then does an I/O read to the data register - the write to the control register hasn't happened because reads have higher priority than writes - result bang! The solution that NS came up with is that the 532 will assert /IOINH during any read access in which write data is pending in it's write buffer. The target I/O will assert /IODEC and ignore the read access because /IOINH is asserted. The 532 detects /IODEC and flushes the write buffer out and the re-executes the read access. The problem is that the 532 does not appear to cache the instructions that surround this /IODEC - /IOINH cycle - leading to a real performance hit on the SCSI read/write loops. Our solution was to not /IODEC-/IOINH the SCSI data space. Of course this means that the 532 will attempt to cache the data - so the SCSI driver must ensure that it increments the read address for each access - else you would end up reading the cached data rather than the I/O data. Again as Bruce says, this doesn't answer your apparent problem. best regards, -- George Scolaro (gs@vw25.chips.com) Chips & Technologies (408) 434-0600 3050 Zanker Road San Jose, CA 95134