-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathunix-v6-trouble-2.html
522 lines (459 loc) · 27.8 KB
/
unix-v6-trouble-2.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>fritzm.github.io - PDP-11/45: V6 Unix Troubleshooting, Part II</title>
<meta name="description" content="">
<meta name="author" content="Fritz Mueller">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<!-- Le HTML5 shim, for IE6-8 support of HTML elements -->
<!--[if lt IE 9]>
<script src="https://fritzm.github.io/theme/html5.js"></script>
<![endif]-->
<!-- Le styles -->
<link href="https://fritzm.github.io/theme/bootstrap.min.css" rel="stylesheet">
<link href="https://fritzm.github.io/theme/bootstrap.min.responsive.css" rel="stylesheet">
<link href="https://fritzm.github.io/theme/local.css" rel="stylesheet">
<link href="https://fritzm.github.io/theme/pygments.css" rel="stylesheet">
<!-- Photoswipe -->
<link rel="stylesheet" href="https://fritzm.github.io/theme/photoswipe.css">
<link rel="stylesheet" href="https://fritzm.github.io/theme/default-skin/default-skin.css">
<script src="https://fritzm.github.io/theme/photoswipe.min.js"></script>
<script src="https://fritzm.github.io/theme/photoswipe-ui-default.min.js"></script>
<script src="https://fritzm.github.io/galleries.js"></script>
<script type="text/javascript">
var pswipe = function(gname, index) {
var pswpElement = document.querySelectorAll('.pswp')[0];
var items = galleries[gname];
var options = { index: index };
var gallery = new PhotoSwipe(pswpElement, PhotoSwipeUI_Default, items, options);
gallery.init();
};
</script>
<!-- So Firefox can bookmark->"abo this site" -->
<link href="https://fritzm.github.io/feeds/all.rss.xml" rel="alternate" title="fritzm.github.io" type="application/rss+xml">
</head>
<body>
<div class="navbar">
<div class="navbar-inner">
<div class="container">
<a class="btn btn-navbar" data-toggle="collapse" data-target=".nav-collapse">
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</a>
<a class="brand" href="https://fritzm.github.io">fritzm.github.io</a>
<div class="nav-collapse">
<ul class="nav">
</ul>
</div>
</div>
</div>
</div>
<div class="container">
<div class="content">
<div class="row">
<div class="span9">
<div class='article'>
<div class="content-title">
<h1>PDP-11/45: V6 Unix Troubleshooting, Part II</h1>
Sun 25 October 2020
by <a class="url fn" href="https://fritzm.github.io/author/fritz-mueller.html">Fritz Mueller</a>
</div>
<div><p><em>[A catch-up article, documenting discoveries of Feb 2019]</em></p>
<p>In early 2019, I made a V6 Unix pack from the Ken Wellsch tape image, as mentioned in <a href="https://fritzm.github.io/unix-and-ms11.html">this blog
entry</a>. It booted on my machine, but dumped core on the first <code>ls</code> in single-user
mode, or as soon as I did any heavy lifting in multi-user mode.</p>
<p>The following is the conclusion of a chronology of the troubleshooting campaign that took place over the next
month and a half, culminating in a hardware fix and successful operation of V6 Unix on the machine (part I is
<a href="https://fritzm.github.io/unix-v6-trouble-1.html">here</a>.) This was largely a collaborative effort between Noel Chiappa an
myself via direct email correspondence, though some help was received from others via the cctalk mailing list
as well.</p>
<p>By this point, the nature of the <code>ls</code> problem had been fairly well characterized: part of the <code>ls</code> process
address space ended up holding an incorrect portion of its program text; subsequently, when execution jumped
to some of these unexpected bits, an out-of-bounds memory access would occur triggering a memory management
trap. Efforts now focus on understanding how and why the bad bits got there...</p>
<h3>February 7</h3>
<p>[Here and below, block-quoted content is excerpted from email correspondence.]</p>
<p>Fritz:</p>
<blockquote>
<p>Noel, is it possible for you deduce where Unix <em>should</em> be placing these "bad" bits (from file offset octal
4220)? Maybe a comparison of addresses where the bits should be, with addresses where the "bad" copy ends
up, could point us at some particular failure modes to check in the KT11, CPU, or RK11...</p>
</blockquote>
<p>Noel:</p>
<blockquote>
<p>Yes, it's quite simple: just add the virtual address in the code to the physical address of the bottom of
the text segment (given in UISA0). The VA is actually 04200, though: the 04220 includes 020 to hold the
a.out header at the start of the command file.</p>
<p>So, with UISA0 containing 01614, that gives us PA:161400 + 04200 = PA:165600, I think. And it wound up at
PA:171600 - off by 04000 (higher) - which is obviously an interesting number.</p>
</blockquote>
<hr>
<blockquote>
<p>Here's where it gets 'interesting'.</p>
<p>Executing a command with pure text on V6 is a very complicated process. The shells fork()s a copy of itself,
and does an exec() system call to overlay the entire memory in the new process with a copy of the command
(which sounds fairly simple, at a high level) - but the code path to do the exec() with a pure text is
incredibly hairy, in detail. In particular, for a variety of reasons, the memory of the process can get
swapped in and out several times during that. I apparently used to understand how this all worked, see this
message:</p>
<p><a href="https://minnie.tuhs.org/pipermail/tuhs/2018-February/014299.html">https://minnie.tuhs.org/pipermail/tuhs/2018-February/014299.html</a></p>
<p>but it's so complicated it's going to take a while to really comprehend it again. (The little grey cells are
aging too, sigh...)</p>
<p>The interesting point is that when V6 first copies the text in from the file holding the command (using
readi(), Lions 6221 for anyone who's masochistic enough to try and actually follow this :-), it reads it in
starting from the bottom, one disk block at a time (since in V6, files are not stored contiguously).</p>
<p>So, if it starts from the bottom, and copies the wrong thing from low in the file <em>up</em> to VA:010200, when it
later gets to VA:010200 in the file contents, that <em>should</em> over-write the stuff that got put there in the
wrong place <em>earlier</em>. Unless there's <em>another</em> problem which causes that later write to <em>also</em> go somewhere
wrong...</p>
<p>So, I'm not sure when this trashage is happening, but because of the above, my <em>guess</em> is that it's in one
of the two swap operations on the text (out, and then back in). (Although it might be interesting to look at
PA:165600 and see what's actually <em>there</em>.) Unix does swapping of pure texts in a single, multi-block
transfer (although not always as an integral number of blocks, as we found out the hard way with the QSIC
:-).</p>
<p>So my suspicions have now switched back to the RK11... One way to proceed would be to stop the system after
the pure text is first read in (say around Lions 4465), and look to see what the text looks like in main
memory at <em>that</em> point. (This will require looking at KT11 registers to see where it's holding the text
segment, first.)</p>
<p>If that all looks good, we'll have to figure out how to stop the system after the pure text is read back in
(which does not happen in exec(), it's done by the normal system operation to swap in the text and data of a
process which is ready to run).</p>
<p>We could also stop the system after the text is swapped out, and key in a short (~ a dozen words) program to
read the text back in from the swap device, and examine it - although we'd have to grub around in the system
a bit to figure out where it got written to. (It might be just easier to stop it at, say, Lions 5196 and
look at the arguments on the kernel stack.)</p>
</blockquote>
<p>Fritz:</p>
<blockquote>
<blockquote>
<p>...it might be interesting to look at PA:165600 and see what's actually <em>there</em></p>
</blockquote>
<p>A sea of zeros, as it turns out.</p>
</blockquote>
<hr>
<blockquote>
<blockquote>
<p>The most valuable thing ... would be to look at the text segment, after it's read in and before it's
swapped out. I can work out where to put a halt, if you want to try that.</p>
</blockquote>
<p>Yes, this sounds like a good plan to me! Is this as simple as dropping a HALT at VA:0 in the text? </p>
</blockquote>
<p>Noel:</p>
<blockquote>
<p>No; actually, probably easier! :-) Probably easiest is to, just before you type 'ls', put a HALT in the OS
just after 4467 in Lions. Halt the machine momentarily, patch the kernel, and CONT. (Basically the same as
your patch to the trap vector, just a different address.) That'll be at 021320 (should contain 062706),
physical or virtual. :-)</p>
<p>When the system halts, you'll need to look at the text in memory. Two ways to find the location: look on the
kernel stack, the address should be the second thing down:</p>
<div class="highlight"><pre><span></span>mov 16(r3),-(sp)
add $20,(sp)
mov (r4),-(sp)
jsr pc,*$_swap
</pre></div>
<p>(i.e. the thing that 020 got added to). Probably easier, though, is just to look in UISA0 (which at this
point is pointing to the block of memory that's been allocated to read the text into, Lions 4459-60).</p>
<p>That number in UISA0, T, will be the click address of the text. So PA:T00 should be the start of the text
(170011 010600, etc). So then PA:(T00+010200) should be the trashed chunk of text: 110024 010400 000167
000016 010500 etc (right) or 016162 004767 000224 000414 016700 (wrong).</p>
</blockquote>
<h3>February 8</h3>
<p>Noel:</p>
<blockquote>
<p>In addition to the info I already sent about how to [set the breakpoint], if you could note down the top 3
words on the kernel stack, and the contents of the RK registers, those would be really useful; the first
will allow us to work out what <em>should</em> be in the RK registers after the swap I/O operation completes - I
don't think the RK11 will be asked to do anything after that finishes and before the system hits that halt
in xalloc().</p>
<p>To find the kernel stack.... read out KISA6, S. This value will point to the 'user' area of that process,
plus the kernel stack. The kernel SP should be something like 01417xx; subtract 140000 (the segment number),
and add what's left to S00. Alternatively, you can probably use the rotating switch on the front panel to
just look up VA:1417xx (whatever's in R6) directly.</p>
<p>Oh, if you need some bed-time reading to put you to sleep, check out the bottom section ("exec() and
pure-text images") in:</p>
<p><a href="http://gunkies.org/wiki/Unix_V6_internals">http://gunkies.org/wiki/Unix_V6_internals</a></p>
<p>which will explain what's going on here with the swapping in and out, which is sorta complicated.</p>
</blockquote>
<h3>February 9</h3>
<p>Noel:</p>
<blockquote>
<blockquote>
<p>just halt the machine after the text is swapped in</p>
</blockquote>
<p>The code we need is at Lions 2034, where the pure text of a process is swapped in (and this should only be
traversed once; I don't think the system will need to swap in the text of the shell); just put a HALT in (in
the usual manner, just before trying 'ls') at 015406, which should contain a 062706 (again).</p>
<p>At that point, since the text size is 010400, and the location of the text in physical memory is 0161400,
the BAR <em>should</em> contain 0172000. If not, and it's 0232000 (note that the 0200000 bit will be in the CSR,
the lower XM bit) instead, Bazinga!, it's nailed (unless the system somehow snuck another RK operation in
there, but I don't see anything that could do that).</p>
</blockquote>
<p>I finally get some time back in front of the machine, after a few days in bed with a cold:</p>
<blockquote>
<blockquote>
<p>...put a HALT in the OS just after 4467 in Lions. Halt the machine momentarily, patch the kernel, and CONT.
(Basically the same as your patch to the trap vector, just a different address.) That'll be at 021320
(should contain 062706)...</p>
</blockquote>
<p>But alas, it does not. [PA:021320] = 010246. Furthermore, [PA:015406] = 016504.</p>
</blockquote>
<hr>
<blockquote>
<p>I just tried under SIMH, also, and got consistent results:</p>
<div class="highlight"><pre><span></span>[PA:015406] = 016504
[PA:021320] = 010246
</pre></div>
<p>...so, one would think, my rkunix and yours are different?</p>
</blockquote>
<p>Noel:</p>
<blockquote>
<p>That must be it. I thought we were both working from the V6 distribution? Oh, yours prints out that Western
Electric copyright notice, I don't think mine has that...</p>
</blockquote>
<h3>February 10</h3>
<p>The first part of the day is spent sorting out and comparing the "Wellsch" V6 distribution that I have been
using, and the "Ritchie" version that Noel has been using. Noel comes to the conclusion that the only
differences in the kernel sources are in fact the four <code>printfs</code> for the copyright notice, but this is enough
to perturb the locations of various symbols of interest between the two kernels. He also finds the binaries
<code>ls</code>, <code>cc</code>, <code>as</code>, <code>as2</code>, <code>ld</code> <code>c0</code>, <code>c1</code>, and <code>c2</code> all match; as do liba.a, libc.a and crt0.o.</p>
<p>Getting back on the trail of the bug:</p>
<blockquote>
<p>So the first place I'd like to try HALTing is just after the call to swap, Lions 4467; at that point, the
text should be in main memory, and also just written to disk. Should be at 021320 (old contents should be
062706).</p>
<p>Fun things to do here: look at the text in main memory (0161400 and up), see if it's correct at this point.
Also: pull the arguments off the top of the stack, and write a small program to read it back in...</p>
</blockquote>
<p>This turns out to be one last typo ("rkunix" vs. "rrkunix" on Noel's part) resulting in incorrect symbol
addresses for my kernel, but I'm hip to Noel's curveballs now so:</p>
<blockquote>
<p>Okay, using today's newly acquired 'db' skillz :-), in my rkunix, that spot is at PA:21420. Firing up the
machine again and trying that now...</p>
</blockquote>
<p>It works; I end up stopped at the breakpoint and start extracting data:</p>
<blockquote>
<p>Hmmm:</p>
<div class="highlight"><pre><span></span><span class="n">PA</span><span class="o">:</span><span class="mi">161400</span><span class="o">:</span> <span class="mi">141644</span> <span class="mi">141660</span> <span class="mi">000000</span> <span class="mi">000000</span> <span class="mi">000000</span> <span class="mi">000000</span> <span class="mi">000000</span> <span class="mi">000000</span>
<span class="n">PA</span><span class="o">:</span><span class="mi">161420</span><span class="o">:</span> <span class="mi">000000</span> <span class="mi">000000</span> <span class="mi">000000</span> <span class="mi">000000</span> <span class="mi">000000</span> <span class="mi">000000</span> <span class="mi">000000</span> <span class="mi">000000</span>
</pre></div>
</blockquote>
<p>Noel:</p>
<blockquote>
<p>The text is probably at a different location in PA at this point. Read out UISA0 for its base.</p>
</blockquote>
<p>Fritz:</p>
<blockquote>
<div class="highlight"><pre><span></span><span class="n">UISA0</span><span class="o">:</span> <span class="mi">001654</span>
<span class="n">PA</span><span class="o">:</span><span class="mi">165400</span><span class="o">:</span> <span class="mi">170011</span> <span class="mi">010600</span> <span class="mi">011046</span> <span class="mi">005720</span> <span class="mi">010066</span> <span class="mi">000002</span> <span class="mi">004767</span> <span class="mi">000010</span>
<span class="n">KSP</span><span class="o">:</span> <span class="mi">141656</span> <span class="o">-></span> <span class="n">PA</span><span class="o">:</span><span class="mi">165256</span>
<span class="n">PA</span><span class="o">:</span><span class="mi">165256</span><span class="o">:</span> <span class="mi">007656</span> <span class="mi">001654</span> <span class="mi">000104</span> <span class="mi">000000</span> <span class="mi">101602</span> <span class="mi">066312</span> <span class="mi">000000</span> <span class="mi">141726</span>
<span class="n">PA</span><span class="o">:</span><span class="mi">175600</span><span class="o">:</span> <span class="mi">110024</span> <span class="mi">010400</span> <span class="mi">000167</span> <span class="mi">000016</span> <span class="mi">010500</span> <span class="mi">010605</span> <span class="mi">101446</span> <span class="mi">010346</span>
</pre></div>
<p>So far so good -- both beginning and eventually-bogus sections of text check out at this point!</p>
</blockquote>
<p>Noel:</p>
<blockquote>
<p>Woo-Hoo!!!! YEAH!!!!</p>
<p>So that part of the text <em>is</em> right at this point.</p>
<p>Needless to say, this is <em>very</em>, very important data.</p>
<p>So chances are very strong, at this point, that it's the RK11.</p>
<p>What did you want to do next? You could start with the RK11 registers. Also, use PDP11GUI to read the copy
off the swap device, once I decipher the stack?</p>
</blockquote>
<hr>
<blockquote>
<div class="highlight"><pre><span></span><span class="n">PA</span><span class="o">:</span><span class="mi">165256</span><span class="o">:</span> <span class="mi">007656</span> <span class="mi">001654</span> <span class="mi">000104</span> <span class="mi">000000</span> <span class="mi">101602</span> <span class="mi">066312</span> <span class="mi">000000</span> <span class="mi">141726</span>
</pre></div>
<p>OK, so the 01654 is the start address in PA (in clicks) for the area to swap out, and that matches UISA0.
0104 is the text length (also in clicks), and that also matches. The 0 is a flag which says it's a write
(read is 01). And the 07656 is the block number (4014.).</p>
</blockquote>
<p>Fritz:</p>
<blockquote>
<p>I should have a valid swap on the disk from before I shut down... Going to fire up PDP11GUI and grab it now
to have a look. We want blocks 4014-4022, then? (9 x 512-byte blocks = 0110 clicks if I got that right?)</p>
</blockquote>
<p>Noel:</p>
<blockquote>
<p>4014.-4023., I think...</p>
<blockquote>
<p>(9 x 512-byte blocks = 0110 clicks if I got that right?)</p>
</blockquote>
<p>I think 8-1/2 or so; text is 010400 bytes (a little less, actually, but that's what the system is using),
01000 bytes/block, = 010.4 blocks.</p>
</blockquote>
<p>Fritz:</p>
<p>Hmm, the beginning looks good, but it seems to cut off to soon:</p>
<blockquote>
<div class="highlight"><pre><span></span>0000000 000000 000000 000000 000000 000000 000000 000000 000000
*
7656000 170011 010600 011046 005720 010066 000002 004767 000010
7656020 010016 004737 006374 104401 004567 010154 162706 000044
7656040 012716 000001 004737 004652 010067 022314 010516 062716
7656060 177762 004737 006346 016500 177762 062700 177413 010067
|
7660320 000137 002346 016516 000004 012746 020452 004737 003562
7660340 005726 000137 002542 005067 017552 012704 022336 005003
7660360 012716 021050 004737 005042 110024 005203 022703 000020
7660400 000000 000000 000000 000000 000000 000000 000000 000000
*
11410000
</pre></div>
</blockquote>
<p>Noel:</p>
<blockquote>
<blockquote>
<div class="highlight"><pre><span></span>7656000 170011 010600 011046 005720 010066 000002 004767 000010
</pre></div>
</blockquote>
<p>Yup, good start; SETD, etc.</p>
<blockquote>
<div class="highlight"><pre><span></span>7660360 012716 021050 004737 005042 110024 005203 022703 000020
7660400 000000 000000 000000 000000 000000 000000 000000 000000
</pre></div>
</blockquote>
<p>Hunh; not good. (Might be worth looking at that location in main memory, see if it's zeros or not.)</p>
<p>That's so odd that it's all zeros - I wonder where they came from? Maybe they were already on the disk, and
the write stopped way early? (At 01000 bytes per block, it stopped after 2-1/2 blocks; 056000s, 057000s,
stopped half-way through the 060000's.)</p>
<p>Would be useful to have the RK register contents after the swap() call returns...</p>
</blockquote>
<p>Fritz:</p>
<blockquote>
<p>Okay, the write should be from PA:165400 - PA:175777, to sectors 07656 - 07667. Block 7667 encodes to an
RKDA value of 012363.</p>
<p>After the halt, I find:</p>
<div class="highlight"><pre><span></span><span class="n">RKDS</span><span class="o">:</span> <span class="mi">004707</span> <span class="o">(</span><span class="n">OK</span><span class="o">)</span>
<span class="n">RKER</span><span class="o">:</span> <span class="mi">000000</span> <span class="o">(</span><span class="n">OK</span><span class="o">)</span>
<span class="n">RKCS</span><span class="o">:</span> <span class="mi">000322</span> <span class="o">(</span><span class="n">BOGUS</span><span class="o">!</span> <span class="n">EX</span><span class="o">.</span><span class="na">MEM</span> <span class="o">=</span> <span class="mi">01</span><span class="o">)</span>
<span class="n">RKWC</span><span class="o">:</span> <span class="mi">000000</span> <span class="o">(</span><span class="n">OK</span><span class="o">)</span>
<span class="n">RKBA</span><span class="o">:</span> <span class="mi">176000</span> <span class="o">(</span><span class="n">OK</span><span class="o">)</span>
<span class="n">RKDA</span><span class="o">:</span> <span class="mi">012363</span> <span class="o">(</span><span class="n">OK</span><span class="o">)</span>
</pre></div>
<p>So, EX.MEM are the smoking bits here! I will review the associated designs and come up with things the
try/check.</p>
</blockquote>
<hr>
<blockquote>
<p>Okay, taking a look:</p>
<p>RKBA is implemented in the M795 module in slots AB07, as detailed on sheet RK11-C-15. The M795 is a generic
WC/BA Unibus interfacing module. The BA part only covers 16 bits, but generates an overflow out "D15
RKBA=ALL 1 L".</p>
<p>EX MEM 01 and EX MEM 02 are maintained on the M239 module in slot A17, as detailed on sheet RK11-C-03. The
M239 is a 3x 4-bit counter/register module, so this also implements counting up these bits, when triggered
by "D15 RKBA = ALL 1 L".</p>
<p>Based on where we see the data on disk fall off (offset 2400) and the start PA (165400), I'm guessing we get
a false trigger on this "ALL 1" at RKBA 167777. So that looks like a false "1" detect on RKBA bit 12.</p>
<p>So I think the thing to do is to put the M795 out on an extender, load RKBA with 167777, and have a check at
E28 pin 5, and E34 pin 8!</p>
<p>And we leave the cliffhanger there, for now, at least until tomorrow evening. Because due to the way the
RK11-C is mounted, in order to do the above I'm going to have to spin the whole machine around (its a dual
H960), extend the RK05's so there is room to physically climb in the back, rig a work light, and get on in
there...</p>
</blockquote>
<h3>February 11</h3>
<blockquote>
<p>SUCCESS!!</p>
<p>Put the M795 out on an extender, loaded 167777 in RKBAR, and had a look around with a logic probe. Narrowed
it down to E34 (a 7430 8-input NAND). Pulled, socketed, replaced, and off she goes!</p>
<p>I can now successfully boot and run both V6 Unix and RSTS/E V06C from disk.</p>
<p><em>THAT</em> was a really fun and rewarding hunt :-) First message in the thread was back on Dec 30, 2018. Lots
of debugging and DRAM repairs, then the final long assault to this single, failed gate...</p>
<p>Thanks to all here for the help and resources, and particular shout-outs for Noel and Paul who gave
generously of their time and attention working through the densest bits, both on and off the list.</p>
<p>I predict a long happy weekend and a big power bill at the end of the month :-)</p>
</blockquote>
<p><img style="display:block; margin-left:auto; margin-right:auto" src="/images/pdp11/M795.png"
title="M795 WC/BAModule"/>
<p style="text-align: center;"><em>M795 module and the single failed gate</em></p></p></div>
<hr>
</div>
</div>
<div class="span3">
<div class="well" style="padding: 8px 0; background-color: #FBFBFB;">
<ul class="nav nav-list">
<li class="nav-header">
Site
</li>
<li><a href="https://fritzm.github.io/archives.html">Archives</a>
<li><a href="https://fritzm.github.io/tags.html">Tags</a>
<li><a href="https://fritzm.github.io/feeds/all.rss.xml" rel="alternate">RSS feed</a></li>
</ul>
</div>
<div class="well" style="padding: 8px 0; background-color: #FBFBFB;">
<ul class="nav nav-list">
<li class="nav-header">
Categories
</li>
<li><a href="https://fritzm.github.io/category/arcade-games.html">Arcade Games</a></li>
<li><a href="https://fritzm.github.io/category/math.html">Math</a></li>
<li><a href="https://fritzm.github.io/category/micros.html">Micros</a></li>
<li><a href="https://fritzm.github.io/category/pdp-11.html">PDP-11</a></li>
<li><a href="https://fritzm.github.io/category/programming.html">Programming</a></li>
<li><a href="https://fritzm.github.io/category/radios.html">Radios</a></li>
</ul>
</div>
<div class="social">
<div class="well" style="padding: 8px 0; background-color: #FBFBFB;">
<ul class="nav nav-list">
<li class="nav-header">
Social
</li>
<li><a href="http://facebook.com/fritzmueller">facebook</a></li>
<li><a href="http://instagram.com/infrafritz">Instagram</a></li>
<li><a href="http://www.linkedin.com/pub/fritz-mueller/a/679/62/">LinkedIn</a></li>
<li><a href="http://jsfiddle.net/user/fritzm/fiddles/">JSFiddle</a></li>
<li><a href="https://github.com/fritzm">GitHub</a></li>
</ul>
</div>
</div>
</div>
</div> </div>
<footer>
<br />
<p><a href="https://fritzm.github.io">fritzm.github.io</a> © Fritz Mueller 2023</p>
</footer>
</div> <!-- /container -->
<!-- Photoswipe -->
<div class="pswp" tabindex="-1" role="dialog" aria-hidden="true">
<div class="pswp__bg"></div>
<div class="pswp__scroll-wrap">
<div class="pswp__container">
<div class="pswp__item"></div>
<div class="pswp__item"></div>
<div class="pswp__item"></div>
</div>
<div class="pswp__ui pswp__ui--hidden">
<div class="pswp__top-bar">
<div class="pswp__counter"></div>
<button class="pswp__button pswp__button--close" title="Close (Esc)"></button>
<button class="pswp__button pswp__button--share" title="Share"></button>
<button class="pswp__button pswp__button--fs" title="Toggle fullscreen"></button>
<button class="pswp__button pswp__button--zoom" title="Zoom in/out"></button>
<div class="pswp__preloader">
<div class="pswp__preloader__icn">
<div class="pswp__preloader__cut">
<div class="pswp__preloader__donut"></div>
</div>
</div>
</div>
</div>
<div class="pswp__share-modal pswp__share-modal--hidden pswp__single-tap">
<div class="pswp__share-tooltip"></div>
</div>
<button class="pswp__button pswp__button--arrow--left" title="Previous (arrow left)">
</button>
<button class="pswp__button pswp__button--arrow--right" title="Next (arrow right)">
</button>
<div class="pswp__caption">
<div class="pswp__caption__center"></div>
</div>
</div>
</div>
</div>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>
<script src="https://fritzm.github.io/theme/bootstrap-collapse.js"></script>
</body>
</html>