From DEVON%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU Tue Jul 29 17:39:53 1986 From: DEVON%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU (Devon S. McCullough) Date: Jul 29 86 11:39:53 EDT Subject: No subject Message-ID: <[MX.LCS.MIT.EDU].936970.860729.DEVON> the door on MX's tape drive seems to be wedged partly open. As far as I know, it is still true that if you use it, the controller will deposit bad parity words into system buffers which will cause MX to bughalt. Anything new on this? From DEVON%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU Tue Jul 29 17:10:47 1986 From: DEVON%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU (Devon S. McCullough) Date: Jul 29 86 11:10:47 EDT Subject: No subject Message-ID: <[MX.LCS.MIT.EDU].936964.860729.DEVON> the network stopped talking across the railroad tracks (as usual on rainy days) so I left my plasma TV and walked over to the VT52 by MX's console. Now :TCTYP DESCRIBE says I have Sail,-%TOSAI which looks like a bug to me. It echoes H when I type backspace at DDT, for instance. From Moon at STONY-BROOK.SCRC.Symbolics.COM Fri Jul 25 00:46:00 1986 From: Moon at STONY-BROOK.SCRC.Symbolics.COM (David A. Moon) Date: Jul 24 86 18:46 EDT Subject: MC In-Reply-To: <[AI.AI.MIT.EDU].75103.860724.ALAN> Message-ID: <860724184615.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 24 Jul 86 15:15:31 EDT From: Alan Bawden Date: Thu, 24 Jul 1986 13:53 EDT From: Rob Austein MC seems to have stopped talking to its IMP.... MC's IMP cable was half unplugged at the IMP end. PEEK on MC claims that there are no free packet buffers, all sockets in use, but shows nobody using the net. Who claimed all sockets were in use? I guess some program told you this because both conditions return the same error code. I don't actually understand why unplugging the IMP cable should cause all the buffers to get used up. There is a crash dump in MC:CRASH;CRASH TCPFUL if a TCP wizard wants to tell us. (This happened on MC once before, see MC:CRASH;CRASH TCP.) Maybe all the packet buffers were full of packets waiting to be sent to the IMP. Maybe a cable fell off ... Very good! I gunned COMSAT on MC so that it wouldn't time out all the messages in its queue trying to send through a broken interface. But of course Puff launched another one within an hour. By the way, I believe the NET command in LOCK still resets the network, cycling HOST MASTER READY on the IMP cable. That wouldn't have plugged the cable back in in this case of course, but might still have been a useful thing to try. I hope this command works on KS's. From ALAN at AI.AI.MIT.EDU Thu Jul 24 21:15:31 1986 From: ALAN at AI.AI.MIT.EDU (Alan Bawden) Date: Jul 24 86 15:15:31 EDT Subject: MC In-Reply-To: Msg of Thu 24 Jul 1986 13:53 EDT from Rob Austein Message-ID: <[AI.AI.MIT.EDU].75103.860724.ALAN> Date: Thu, 24 Jul 1986 13:53 EDT From: Rob Austein MC seems to have stopped talking to its IMP.... MC's IMP cable was half unplugged at the IMP end. PEEK on MC claims that there are no free packet buffers, all sockets in use, but shows nobody using the net. Who claimed all sockets were in use? I guess some program told you this because both conditions return the same error code. I don't actually understand why unplugging the IMP cable should cause all the buffers to get used up. There is a crash dump in MC:CRASH;CRASH TCPFUL if a TCP wizard wants to tell us. (This happened on MC once before, see MC:CRASH;CRASH TCP.) Maybe a cable fell off ... Very good! I gunned COMSAT on MC so that it wouldn't time out all the messages in its queue trying to send through a broken interface. But of course Puff launched another one within an hour. From SRA at XX.LCS.MIT.EDU Thu Jul 24 19:53:00 1986 From: SRA at XX.LCS.MIT.EDU (Rob Austein) Date: Jul 24 1986 13:53 EDT Subject: MC Message-ID: MC seems to have stopped talking to its IMP. XX isn't having any trouble with this, so it's (probably) not BBN doing something random. Attempting to connect to 10.3.0.44 causes the IMP to claim that MC is down. PEEK on MC claims that there are no free packet buffers, all sockets in use, but shows nobody using the net. Maybe a cable fell off the LH/DH or maybe something else. I gunned COMSAT on MC so that it wouldn't time out all the messages in its queue trying to send through a broken interface. From ALAN at AI.AI.MIT.EDU Tue Jul 15 23:16:43 1986 From: ALAN at AI.AI.MIT.EDU (Alan Bawden) Date: Jul 15 86 17:16:43 EDT Subject: TCP Checksum Routine Message-ID: <[AI.AI.MIT.EDU].70523.860715.ALAN> This afternoon AI crashed because the TCP segment checksuming routine referenced location 400000, which is normally non-existant in the system's page table, thus taking a page fault. The offending instruction was the ILDB at THCKS5. There is a crash dump in CRASH;CRASH TCPSUM, although I may have trashed the accumulators and the BUGxxx locations before taking the dump. I guess we have to suspect that this routine checksums randomness a lot, and we were only lucky to catch it this time because it happened to hit the 2% of system memory that would cause it to halt. From ALAN at AI.AI.MIT.EDU Sun Jul 13 23:58:41 1986 From: ALAN at AI.AI.MIT.EDU (Alan Bawden) Date: Jul 13 86 17:58:41 EDT Subject: Disappear here. In-Reply-To: Msg of Sun 13 Jul 86 10:29:11 EDT from Daniel Weise Message-ID: <[AI.AI.MIT.EDU].69293.860713.ALAN> Date: Sun, 13 Jul 86 10:29:11 EDT From: Daniel Weise AI went catatonic this morning. I took a dump to CATA TONIC and reloaded. Thanks. Its just unit #1 being broken again. From DANIEL at AI.AI.MIT.EDU Sun Jul 13 16:29:11 1986 From: DANIEL at AI.AI.MIT.EDU (Daniel Weise) Date: Jul 13 86 10:29:11 EDT Subject: Disappear here. Message-ID: <[AI.AI.MIT.EDU].69227.860713.DANIEL> AI went catatonic this morning. I took a dump to CATA TONIC and reloaded. Daniel From ALAN at AI.AI.MIT.EDU Sat Jul 12 09:56:36 1986 From: ALAN at AI.AI.MIT.EDU (Alan Bawden) Date: Jul 12 86 03:56:36 EDT Subject: DRAGON;SYSMSG LOG Message-ID: <[AI.AI.MIT.EDU].68883.860712.ALAN> The latest PFTHMG DRAGON (installed on the four KS10s, but not the KL) permanently logs memory errors in addition to disk errors. The file DRAGON;DISK LOG is now called DRAGON;SYSMSG LOG.