> On Jan 3, 2019, at 11:51 AM, Fritz Mueller via cctalk <cctalk@classiccmp.org>
> wrote:
>
> Hi Paul,
>
>> On Jan 3, 2019, at 7:01 AM, Paul Koning <paulkon...@comcast.net> wrote:
>>
>> I have a Monitor ODT manual from RSTS V4, I should find a way to make that
>> available. It's pretty nearly standard ODT, there are a few extensions for
>> mapping addresses
>
> Bitsavers has some docs for ODT from contemporaneous versions of RSX-11,
> which have seemed close enough to get me going with some experimentation.
>
>> To find LOG$DK, you can either look in the link map (RSTS.MAP) from the
>> SYSGEN, or ask the init PATCH option to tell you
>
> So, I don’t see a LOG$DK in my V06C RSTS.MAP (though I do have LOG$KB and
> LOG$TM). PA returns “address above module bounds” when looking for it, which
> I assume means it searched without finding it.
What we have here is a confusion on my part. The LOG$xx symbols are for the
most part defined in the kernel definitions file KERNEL.MAC. They are EMT
instructions with a device code in the low byte; in the kernel an EMT is
handled as a request to invoke the error logging machinery.
Dispatching for that goes through a table indexed by the EMT code, so what you
actually need is to look in the correct entry of that table to find the RK11
driver logging entry point. A breakpoint set there should trigger when a disk
error is reported by the driver. Here's how:
RSTS V06C-03 FRITZTS (DK0)
Option: PA
File to patch? ERRTBL
Illegal file name
File to patch?
Module name? ^C
Option: PA
File to patch?
Module name?
Base address? ERRTBL
Offset address? LOG$DK-104000
Base Offset Old New?
030162 000030 055230 ? ^Z
Offset address? ^Z
Base address? 55230
Offset address? 0
Base Offset Old New?
055230 000000 004537 ? ^C
Option:
So in this example, 55230 is the error logging entry point for the RK11 driver.
In V10.1, that code looks like this; I suspect the V6C code is the same or
nearly so:
.SBTTL ERROR LOGGING
ERRENT LOG$DK
CALLX ERLDSK,R5 ;;;USE COMMON ROUTINE
.BYTE ERC$DK ;;;ERROR CODE
.BYTE -1 ;;;OVERLAPPED SEEK
.BYTE RKDS,6 ;;;OFFSET, 6 REGISTERS
.BYTE 0,0 ;;;THAT'S ALL
RETURN ;;; AND BACK
In any case, that doesn't really matter. If you have a breakpoint at this
location, you'll be able to capture the controller CSR contents which -- I hope
-- will explain why the system is not happy.
The way to set the breakpoint is simply to enter control/P for ODT, then
55230;B to set the breakpoint, then P to proceed.
paul
