> On Jan 3, 2019, at 10:08 PM, Fritz Mueller via cctalk <cctalk@classiccmp.org> 
> wrote:
> 
> 
>> On Jan 3, 2019, at 5:17 PM, Paul Koning <paulkon...@comcast.net> wrote:
>> 
>> So in this example, 55230 is the error logging entry point for the RK11 
>> driver. ... 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.
> 
> Thanks, Paul!  Tried but no luck:
> 
> ...
> 
> (...system starts looping error behavior; type ^P...)
> 
>    BE125652
>    _55230/004537
>    _55230;B
>    _P
> 
> (...system resumes looping error behavior without hitting breakpoint; sadness)
> 
> Any additional or different recommended breakpoints to try?  Or did I miss 
> setting this up (I’m new to ODT.)
> 
>       thanks much,
>         --FritzM.

The ODT command syntax is correct.  I confirmed by setting a breakpoint at 
DSQ$DK, the "queue a disk request" driver entry point, and that breaks 
correctly -- just to make sure my memory hasn't faded.

Plan B: set a breakpoint at "ERL" (040672 in your map) which is the entry point 
to the error logging code.  That's where the display register is incremented as 
part of logging an error.  On entry, R0 is the EMT code (a LOG$xx code, because 
these are EMTs in kernel mode).  Many of those codes are fixed and defined in 
KERNEL.MAC which is in the kit.  The ones that are configuration-dependent are 
in the RSTS.MAP listing, for example LOG$KB.  The log code would tell us which 
device or component is unhappy.

        paul

Reply via email to