More time is getting consumed by the things around it like to enable debugging then the debugging proper.
A Tops10-703 base system with Decnet networking has been generated. The standard basic network partner for my network tests is a Vax8600 with various DMC lines; I only use the more broader equipped Pdp11 with Dmc/Dup lines if I use Dup testing to contrast inline Ddcmp (DCM/DMR) with host based Ddcmp (Dup) behaviour as the latter can be seen as the "proper" standard. The base image was verified configured with the Kdp/Dup communicating with the Vax Dmc; Decnet functioned on the Ddcmp/Routing level and NFT worked. Therefor the base image can be assumed to be sound (enough). Configured with the Dmr and the D8RINT V016 driver set it still establishes the same crash in DEFCIR. This driver - already in its unpatched form - excels in an extraordinary amount of resetting the Dmr device completely, even the unconfigured non existing lines. Debugging D8RINT in 703 is somewhat different from 704 as the code seems to run in a different section from startup; initially the symbols are invisible, but that can be easily managed. Repairing the cause of the DEFCIR crash this still leads to another crash further down the line, but now at least we reach a stage where some Ddcmp activity can be seen. It looks like the Dmr at that point is properly setup to start communicating with the Vax Dmc (set in Dmr mode). However while the Vax is transmitting and receiving start dialog packets, the Tops10 side remains stuck in only transmitting start packets and retrying that after time out of receiving an acknowledge. Before continuing with the investigation of the further behavior of the D8RINT, it is now necessary to first investigate the Dmr emulation path why the Vax transmitted packets are not received. As the Ddcmp process is entirely within the Dmr, the Tops10 side has actually very little to do with it. Either the Dmr hasn't been properly setup or there is something within the emulation. What exactly is wrong cannot easily be explained as the Dmc/Dmr code base in the Pddp10 and Vax emulators is in fact (almost) the same. There is no difference in effective behaviour between the Tcp/IP connections of the Dmc/Dmr pair with and without udp; only when using the normal connections sometimes the lines are seen to be unavailable or busy. While on the Vax normal transmit/receive is shown, on the Pdp10 side this shows: DDCMP Link State: IStart R: 0 N: 0 A: 0 T: 1 X: 0 SACK: false SNAK: false SREP: false rcv_pkt: 00000000 rcv_pkt_size: 0 xmt_buffer: 00000000 nak_reason: 0 TimerRunning: true TimeRemaining: 4 Swbw07> show dmr0 stat DMR0 input (on) queued/total = 8/8 output (on) queued/total = 0/2104 packet data queued/packets sent = 0/263 output buffer size = 16384 bytes in buffer = 0 Buffers received from the network=0 Buffers sent to the network=1012 Output transfers completed for receive buffers=0 Output transfers completed for transmit buffers=0 Input transfers completed for receive buffers=15 Input transfers completed for transmit buffers=0 Control Out operations processed=0 DDCMP control packets received=0 DDCMP control packets sent=1012 To be continued ...
_______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh