SC1041_SAIL_PDP-6_hardware_log_1967-09

0300 30-SEP-67

Put Librascope dish in the self test, slow mode (for a change). No errors in first five minutes.

John Sauter

0340 30-SEP-67

Why does SPLIT SYNC light on CPU come on when both CPU and DISK are running even with disk off line?

J. Sauter

0350 30-SEP-67

Running disk diagnostic. Test 1 (all one bits) showed bit 21 dropping. Re-ran it. No errors. Much trouble with core parity errors at location 6777. This is the third location of the write buffer.

Disk addressing failure. Data written starting at band 64+32+16+1, TRACK 1, segment 10+8+7 can sometimes be read on the same band and track on segment 9+8+7.

Much experiment has shown that writing on SEG=9+8+7, BAND = 64+32+16+ 4+2+1 TRACK=1 causes the data on band 64+32+16+1 TRACK 1 segment 10+8+7 to be coped onto segment 9+8+7, same band and track.

An attempt to make the same thing happen with a simpler program resulted in writing a couple of words of data from BAND = 64+32+16 +2 TRK=0, SA = 11+8+2 onto the same place as above. The data that was written was not in core at the time of the writing but it was recognizably data written earlier by this phase of the disk tester. Frankly, I am confused at this point.

The problem appeares not to be timeing dependent ; doing the last write from DDT still manefests the original bug. After getting the bug to happen I did the last two writers from DDT and managed to wipe out all of the above record. There are enough records involved that I had better number them. (a record, by the way, is 128,₀ words, or four sectors, long). The record that is getting wiped out in 207000₈. It is getting wiped by us writing on record 216000. The data being put in it when the program is allowed to run without interruption, or with a read following every write, is the data that was written on record 207100. When the last write before the write on 216100 is done with DDT, even if it is to the same record as is usual for the diagnostic (216073)

The record will be wiped out in a different way.

I tried disturbing the timeing with breakpoints and the same wipe happened. This suggests that the bug may be insensitive to timeing but sensitive to a lot of history of writes. Putting a read after every write, as I did to find the write that was getting us, didn't effect it.

I tried completely the pattern of writes, hitting every sixth record instead of every fifth. No change. The data from record 207100 is still being put in record 207000 when writing on record 216100, as stated in the middle of page 11.

I took the disk off-line and zeroed it, then ran the test again. Same trouble. But record 207100 hadn't yet been written! The data on record 207000 is being marked rather than over-written by another record.

This is beginning to sound saner.

The following instances of transofmration were noted before I had to give up the machine.

207000 --> 207100 000000 --> 000100 777777 --> 777137

Good luck finding this one! I put the disk in selftest when I left at 9:00.

John Sauter

30-SEP-67 1212

TTY 1 double trip

LPT has old START - STOP MANUAL PRINT hang up seems to be lower case [chis?], esp. r (162)

W.S.W.?]

TTY1 adjust and complete preventive maintenance on all 33 TTYs.

Jess Gonzales