garyj@neptun.pcs.com (Gary Jennejohn) (11/09/90)
Hi, Group! 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. All well and good, but I see strange behavior when I access the disk the first 2 times. At the first access I always see a REQ timeout, at the second access I see "can't initialize the disk" immediately. The third and subsequent accesses work. When the MMU is turned off I don't see any access problems. The disk works first time every time. Accesses to the duarts do not exhibit any strangenesses. So, the question is, what's going on here? Why do I see this behavior only when address translation is enabled? Does it maybe have something to do with the fact that the ICU is already in a special memory region and is also being cache inhibit-ed by the MMU? I haven't tried turning off the CI-bit for the ICU yet. Do any of you more experienced 32532-ers have any ideas? Is anyone else using the MMU? Gary
culberts@hplwbc.hpl.hp.com (Bruce Culbertson) (11/10/90)
> 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? Sometimes when you most need the debugger, you are trying to debug a user program which goes so crazy that it disables the debugger. I tried to minimize the number of ways this could happen so I made the debugger operate in unmapped mode and without interrupts. This may be futile, of course, since the user code can still bomb the debugger by writing over its stack. I am just trying to explain why I did things the way I did -- I am not trying to discourage Gary's experimentation. Is anyone else using the MMU? Yes. Minix runs user code in mapped spaces. It runs its own code unmapped. The debugger is aware of the MMU in some very limited ways. When returning from user code, the monitor disassembles the instruction which the user's pc points to. If the user pc is mapped, as indicated by the psr and mcr, then the address of the disassembled instruction is followed by a V. For example, Minix users who use my bpt program will see something like: 58V bpt (breakpoint exception) Command (type ? for help): This indicates that the user code was exitted due to a breakpoint exception, and that the next user instruction is bpt and is located at 0x58 in the user's virtual space. Where is 58V in physical memory? The monitor's expression syntax includes a function for converting virtual addresses to physical addresses. Here are some examples. v(48123) returns 0x48123 if 1) the psr indicates supervisor mode and mcr indicates that supervisor is unmapped or 2) the psr indicates user mode and mcr indicates that user is unmapped. v(48123) returns 0x34123 if the psr indicates supervisor mode, mcr indicates that supervisor is mapped, and ptb0 points to a page table which maps the virtual page at 0x48000 to a physical page at 0x34000. v(48123) returns 0x34123 if the psr indicates user mode, mcr indicates that user is mapped, and ptb1 points to a page table which maps the virtual page at 0x48000 to a physical page at 0x34000. v(48123, 4000) returns 0x34123 if 4000 points to a page table which maps the virtual page at 0x48000 to a physical page at 0x34000. 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. By the way, I think I used "user" in three different ways -- monitor code versus non-monitor code, 32532 supervisor versus user mode, and Minix OS code versus application code. Hope you can figure out what I meant. Bruce Culbertson
gs@vw25.chips.com (George Scolaro) (11/10/90)
[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