From JTW%MIT-SPEECH at XX.LCS.MIT.EDU Fri Sep 26 00:00:00 1986 From: JTW%MIT-SPEECH at XX.LCS.MIT.EDU (John Wroclawski) Date: Fri 26 Sep 86, 00:00 Subject: dump code fukt In-Reply-To: <860926124710.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <12242133556.4.JTW@MIT-SPEECH> From: David A. Moon Subject: dump code fukt Date: Fri, 26 Sep 86 03:56:39 EDT From: "Pandora B. Berman" .... My first guess is hardware flaking, possibly followed by inadequate resetting action by the software. The code hasn't changed in forever. MT:RETRYING WRITE OPERATION MAG TAPE STATUS TM03 error status decode routine needs to be written ? MTAPE: FORMATTER ERROR, STATUS= 140600,,40000 This is transport unsafe, usually means it went offline while trying to write. MTAPE: FORMATTER ERROR, STATUS=150660,,100320 MAG TAPE STATUS TM03 error status decode routine needs to be written ? This is a mess. To some extent the bits are inconsistant (seems to imply a number of data transfer errors during a positioning command), but could possibly be interpreted as the result of a misformed data transfer command. I assume multi-reel incremental dumps have worked in the past... Is this actually true? ------- From Moon at STONY-BROOK.SCRC.Symbolics.COM Fri Sep 26 18:47:00 1986 From: Moon at STONY-BROOK.SCRC.Symbolics.COM (David A. Moon) Date: Sep 26 86 12:47 EDT Subject: dump code fukt In-Reply-To: <[AI.AI.MIT.EDU].98958.860926.CENT0> Message-ID: <860926124710.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 26 Sep 86 03:56:39 EDT From: "Pandora B. Berman" when i tried to dump AI (incr) this evening, i lost. AI 230 ran off the end of the reel somewhere in the middle of VAFB;, saying MT:RETRYING WRITE OPERATION MAG TAPE STATUS TM03 error status decode routine needs to be written ? MTAPE: FORMATTER ERROR, STATUS= 140600,,40000 and giving me a DUMP prompt. thinking this might just be a case of terminal dirk, i cleaned the drive and started over again with the same tape. same result. so i tried dumping onto AI 231. this time, i got MTAPE: FORMATTER ERROR, STATUS=150660,,100320 MAG TAPE STATUS TM03 error status decode routine needs to be written ? the job at a prompt, and the tape waiting at EOT. so i rewound it and ICHECK'd it. the ICHECK ended without any strange msgs. maybe the first time was just due to incorrectly placed-EOT mark (it did have one, but i'm not sure which side they're -supposed- to be on), but the second tape worked OK. so something is wrong here.. The MT: and MTAPE: messages (why the inconsistency?) show up in :PEEK ", so they came from the ITS system rather than from DUMP (it can be hard to distinguish when you run DUMP on the system-console). The "error status decode routine needs to be written" message came from DUMP. I guess its routine for explaining the details of tape errors was never converted from the version for the KA/KL tape controller. John, do you know what those octal numbers in the formatter error message mean? I assume multi-reel incremental dumps have worked in the past, so has something in the hardware broken? The tape code in ITS hasn't changed recently, has it? From CENT at AI.AI.MIT.EDU Fri Sep 26 09:56:39 1986 From: CENT at AI.AI.MIT.EDU (Pandora B. Berman) Date: Sep 26 86 03:56:39 EDT Subject: dump code fukt Message-ID: <[AI.AI.MIT.EDU].98958.860926.CENT0> when i tried to dump AI (incr) this evening, i lost. AI 230 ran off the end of the reel somewhere in the middle of VAFB;, saying MT:RETRYING WRITE OPERATION MAG TAPE STATUS TM03 error status decode routine needs to be written ? MTAPE: FORMATTER ERROR, STATUS= 140600,,40000 and giving me a DUMP prompt. thinking this might just be a case of terminal dirk, i cleaned the drive and started over again with the same tape. same result. so i tried dumping onto AI 231. this time, i got MTAPE: FORMATTER ERROR, STATUS=150660,,100320 MAG TAPE STATUS TM03 error status decode routine needs to be written ? the job at a prompt, and the tape waiting at EOT. so i rewound it and ICHECK'd it. the ICHECK ended without any strange msgs. maybe the first time was just due to incorrectly placed-EOT mark (it did have one, but i'm not sure which side they're -supposed- to be on), but the second tape worked OK. so something is wrong here. From RDZ at AI.AI.MIT.EDU Fri Sep 19 21:03:13 1986 From: RDZ at AI.AI.MIT.EDU (Ramin Zabih) Date: Sep 19 86 15:03:13 EDT Subject: No subject Message-ID: <[AI.AI.MIT.EDU].96071.860919.RDZ> AI crashed with "TTY: buffer empty at TYIREM". Dump is in CRASH;TYIREM CRASH From ALAN at AI.AI.MIT.EDU Sun Sep 14 03:08:22 1986 From: ALAN at AI.AI.MIT.EDU (Alan Bawden) Date: Sep 13 86 21:08:22 EDT Subject: When you run out of TCP buffers. Message-ID: <[AI.AI.MIT.EDU].93646.860913.ALAN> There must be a path through the ITS TCP code that fails to free a buffer somehow. Twice I have seen MC run itself completely out of buffers. (See the dump MC:CRASH;CRASH TCPFUL, for an example.) In the most recent example, ITS had been running for 35 days before this happened, which might be relevant, although in the previous case it had only been running for 10 days. Bug-COMSAT: COMSAT behaves weirdly when this happens. Take a look at some of the recent stats files on MC. Like for -every- host it tries to contact with TCP it reports: Bad Greeting="+" or somesuch. From DPH at AI.AI.MIT.EDU Mon Sep 8 17:04:04 1986 From: DPH at AI.AI.MIT.EDU (Daniel Huttenlocher) Date: Mon, 8 Sep 86 11:04:04 EDT Subject: No subject Message-ID: <[AI.AI.MIT.EDU].92012.860908.DPH> AI bughalted trying to free a packet still in use. Crash dump in PKT USE. From DPH at AI.AI.MIT.EDU Thu Sep 4 21:29:10 1986 From: DPH at AI.AI.MIT.EDU (Daniel Huttenlocher) Date: Thu, 4 Sep 86 15:29:10 EDT Subject: No subject Message-ID: <[AI.AI.MIT.EDU].90952.860904.DPH> AI got a system revived at 14:38, and seemed to leave all jobs hung or detached (at least ignoring tty input). about 45 mins later it started printing system full messages on the console. dumped to SYS FULL