PDP11: RP11: Interrupt on IE+RESET+GO #389
Conversation
Recent analysis of the 2.9BSD kernel revealed that RP11 was expected to interrupt on control RESET function if IE bit was also set. Documentation was not very clear of the fact, saying in one place that RESET+GO does not interrupt (which is not contradictory with the above because it does not mention IE). In other place, however, it says that IE always causes interrupt when DONE is asserted. Thus, since RESET does assert DONE, an interrupt should be posted if IE is set. The autoconfig binary from 2.9BSD uses this feature of RP11 to check the presence of the controller. Formerly RESET was always clearing RPCS with DONE unconditionally, and that reset IE as well. This patch makes sure that the IE bit is preserved, and if set, it posts an interrupt when RESET asserts DONE.
|
Before the patch: After the patch: Note the change in the Surprisingly It's interesting to note that since |
|
A lot of devices clear IE as part of the reset function. I take it that's not the case for the RP11? It would be nice to confirm this using the controller schematics. |
TBH, I am not very good at reading those, and especially when the CSR drawings exactly are (ironically) the worst quality scans of all other pages in there: http://www.bitsavers.org/pdf/dec/unibus/RP11_schem_Sep74.pdf But I can read source code quite well, and what I saw 2.9BSD was doing, confirms my finding that if software was writing IE+RESET+GO into the CSR, the controller was expected to interrupt. Usually (all normal) software writes RESET+GO, which resets IE (because IE is 0 in such a command), and as a result, clears the interrupt, if any was pending. Besides, this is the exact quote from the RP11-C documentation (that's on top of page 4-22, I had to manually retype it because it's scanned document with text not copy/paste-able.) Anyways, the operative word in the above is "whenever", and that IE is set by the program. IE+RESET+GO are set by the program, and should cause an interrupt. Conversely (and way more wide-spread used) RESET+GO clears the interrupt (and the IE bit, obviously). IE and RESET(+GO) share the same byte, so you can't set a function to run without updating IE at the same time (minimally with a byte instruction). But OTOH you can update IE without causing any function, e.g. IE+RESET [no GO] -- with RP11-C one has to be careful, though, as not to change the MX bit (memory extension A<16:17>, also tucked in there) while an I/O is in progress, because that would mess up memory locations accessed by that operation. BTW, I re-ran all XXDP, X11, DOS-11, RSX-11 tests that I had at my disposal (in addition to running 2.9BSD now, and doing all sorts of wild things like setting up file systems etc without a single hitch), and I can confirm that nothing appears to be broken. |
|
Are there still any concerns? Can this please be pushed, if not? |
|
Thanks, @pkoning2 !
Looking at 2.9BSD Massbus RP04/5/6/7 and RM02/03/05 disks; So it wasn't unique for the RP11 controller, actually. P.S. Bus reset clears IE, though, like you mentioned. |
Recent analysis of the 2.9BSD kernel revealed that RP11 was expected to interrupt on control RESET function if IE bit was also set. Documentation was not very clear of the fact, saying in one place that RESET+GO does not interrupt (which is not contradictory with the above because it does not mention IE).
In other place, however, it says that IE always causes interrupt when DONE is asserted. Thus, since RESET does assert DONE, an interrupt should be posted if IE is set. The autoconfig binary from 2.9BSD uses this feature of RP11 to check the presence of the controller.
Formerly RESET was always clearing RPCS with DONE unconditionally, and that reset IE as well. This patch makes sure that the IE bit is preserved, and if set, it posts an interrupt when RESET asserts DONE.