From ALAN at MIT-MC.ARPA Sat Jun 29 11:41:16 1985 From: ALAN at MIT-MC.ARPA (Alan Bawden) Date: Jun 29 85 05:41:16 EDT Subject: crashdump In-Reply-To: Msg of Sat 29 Jun 85 02:39:48 EDT from Glenn S. Burke Message-ID: <[MIT-MC.ARPA].559587.850629.ALAN> Date: Sat, 29 Jun 85 02:39:48 EDT From: Glenn S. Burke crash;unit-0 lost The DF10 got a NXM. I suspect this is an artifact of the way DEC reconfigured the memory last Wednesday. Would we rather have the parity errors back? Damn machine. From GSB at MIT-MC.ARPA Sat Jun 29 08:39:48 1985 From: GSB at MIT-MC.ARPA (Glenn S. Burke) Date: Jun 29 85 02:39:48 EDT Subject: crashdump Message-ID: <[MIT-MC.ARPA].559506.850629.GSB5> crash;unit-0 lost From ALAN at MIT-MC.ARPA Thu Jun 27 04:01:16 1985 From: ALAN at MIT-MC.ARPA (Alan Bawden) Date: Jun 26 85 22:01:16 EDT Subject: MC up again with all 6 disks. Message-ID: <[MIT-MC.ARPA].557107.850626.ALAN> JNC and I swapped the packs in unit 3 and 4 on MC (the rightmost two T-300's) and the disk problems we were experiencing vanished. Perhaps there is some marginal interaction between drives and packs formatted with different alignments? If so, I guess there is some hope that things will clear up after duplicating those packs tomorrow. BUG-ITS: For the record: Earlier today JNC and TY brought MC up with -none- of the T-300's because they believed them all to be broken. They were given this impression when UCOP got an error copying some user directories. In fact, it has been true for a long time that there are bad blocks amoung the directories on those packs, but since we don't really need those extra copies of the directories this is OK. UCOP copies the MFD -first-, and if it gets that far, that is good enough! From MOON at MIT-MC.ARPA Tue Jun 25 07:50:24 1985 From: MOON at MIT-MC.ARPA (David A. Moon) Date: Jun 25 85 01:50:24 EDT Subject: Addition to mailing list Message-ID: <[MIT-MC.ARPA].554803.850625.CENT> Date: 23 Jun 85 20:11 +0100 From: Peter_Lothberg_STUPI%QZCOM.MAILNET at MIT-MULTICS.ARPA Everybody here is waiting for the system to run, all of the hackers in Stockholm that have heard of ITS is lyric. I have started the work on planing howto actualy change the KA hardware, i want to have the posibility to run as much of the DEC diagnostics as possible. So some type of switch-selectable aproach is prefered, but it is no simple. In a month or so we shall try to have the two KI-10 Cpu:s running SMP with T10 7.02. We plan to use this system to assemble the ITS code. ( Are you sure you can deal with that volume of mail? I don't think anyone will mind your being on them if you don't mind. ) Pls try to add: ITS_bugs%QZCOM.MAILNET at MIT-MULTICS.ARPA in both ITS bugs and ITS on ks20. I have done so. Will report as soon there is any sucsess. We eagerly await your report. The box of tapes, processor prints, and documentation is sitting right next to me, thanks to a lot of work by Penny Berman. From JNC at MIT-XX.ARPA Mon Jun 24 00:00:00 1985 From: JNC at MIT-XX.ARPA (J. Noel Chiappa) Date: Mon 24 Jun 85, 00:00 Subject: IMP down detection In-Reply-To: Message from "Christopher C. Stacy " of Mon 24 Jun 85 16:10:43-EDT Message-ID: I think that it's a known bug with the IMP code that if the IMP cycles after ITS is up ITS doesn't deal with that correctly. ------- From CSTACY at MIT-MC.ARPA Mon Jun 24 22:10:35 1985 From: CSTACY at MIT-MC.ARPA (Christopher C. Stacy) Date: Jun 24 85 16:10:35 EDT Subject: IMP down detection Message-ID: <[MIT-MC.ARPA].554168.850624.CSTACY> At some point today, ITS decided the IMP was down. It never noticed it coming back up, and thought it was waiting for the ready line to flap. I ran LOCK and it reset everything. From JNC at MIT-XX.ARPA Fri Jun 21 00:00:00 1985 From: JNC at MIT-XX.ARPA (J. Noel Chiappa) Date: Fri 21 Jun 85, 00:00 Subject: MC disk flakoes Message-ID: John Holden came and looked at the Tridents and pronounced them all OK. Two needed touch ups to the alignment, but nothing major. He says that it was probably the cables, which are known to be flaky. Since he had to remove the cables to run the exerciser, he thinks that he may have frobbed them in the right way to make the problems go away. Things do seem to be working a bit better. We'll see. ------- From GUMBY at MIT-MC.ARPA Fri Jun 21 03:11:48 1985 From: GUMBY at MIT-MC.ARPA (David Vinayak Wallace) Date: Jun 20 85 21:11:48 EDT Subject: more re: mc was wedged this afternoon. In-Reply-To: Msg of Thu 20 Jun 85 12:12:00 EDT from Daniel Weise Message-ID: <[MIT-MC.ARPA].550546.850620.GUMBY> Date: Thu, 20 Jun 85 12:12:00 EDT From: Daniel Weise Claimed no net ports when only 4 people were logged in. Console only echoed my typein but did nothin wit it. Tried warm booting. THat failed. Took crash dump to CRASH SAME and cold booted. More bits: trying to open a STY gave DEVICE FULL, which is weird. I've seen the same thing when MC couldn't get to its tridents. From DANIEL at MIT-MC.ARPA Thu Jun 20 18:12:00 1985 From: DANIEL at MIT-MC.ARPA (Daniel Weise) Date: Jun 20 85 12:12:00 EDT Subject: mc was wedged this afternoon. Message-ID: <[MIT-MC.ARPA].550424.850620.DANIEL> Claimed no net ports when only 4 people were logged in. Console only echoed my typein but did nothin wit it. Tried warm booting. THat failed. Took crash dump to CRASH SAME and cold booted. Daniel From ALAN at MIT-MC Mon Jun 17 02:29:08 1985 From: ALAN at MIT-MC (Alan Bawden) Date: Jun 16 85 20:29:08 EDT Subject: mc needed cold booting this afternoon. Message-ID: <[MIT-MC].544997.850616.ALAN> Date: Sat, 15 Jun 85 14:05:26 EDT From: Daniel Weise MC was really wedged this afternoon. Every minute it kept typing system full, 0 pages, 0 qsk channels, etc. No user jobs able to run. Warm booting didn't help so I took a dump to CRASH FULL and cold-booted, which seems to have fixed things. Well, the crash dump shows an ITS that has been up for 5 minutes and is having trouble initializing the first T-300. So I guess this is the canonical T-300 controller lossage. Date: Sat, 15 Jun 1985 12:04 EDT From: JGA at OZ A little bit more on the recent lossage I mentioned earlier... I was logged in when RHB got wedged. Running Peek, I could see that his job and several others were sitting there with a state of "*logout", whatever that means. Peek could not gun his tree, nor could Lock. A state of "LOGOUT" (the "*" is irrelevant really) means that the job was already on its way towords going away. (Thats why gunning it didn't do anything, it was already as gunned as it could get.) Without a crash dump, or an actual wedged system, I can only guess that this is another symptom of the T-300 lossage. From ALAN at MIT-MC Mon Jun 17 02:26:35 1985 From: ALAN at MIT-MC (Alan Bawden) Date: Jun 16 85 20:26:35 EDT Subject: CHTN lossage In-Reply-To: Msg of Fri 14 Jun 85 18:52:47 EDT from J. Noel Chiappa Message-ID: <[MIT-MC].544988.850616.ALAN> Date: Fri, 14 Jun 85 18:52:47 EDT From: J. Noel Chiappa Recently I have been noticing that when XX goes down, my CHTN hangs and nothing the world seems to get me out, until it decides to timeout the connection. ANyone know why? Yeah, I've noticed this too. It's not new, its been happening for years. Just looking at the code I can't figure out how it can happen. (Note that this is probably just a bug in CHTN; you take the risk of having bugs like this when you go into super image input mode...) From JGA%MIT-OZ at MIT-MC.ARPA Sat Jun 15 18:10:00 1985 From: JGA%MIT-OZ at MIT-MC.ARPA (JGA%MIT-OZ at MIT-MC.ARPA) Date: Jun 15 1985 12:10 EDT Subject: weird wedgitude - part IIa Message-ID: One more note - a finger of MC from OZ shows the dead HACTRNs sitting there with " STY not in use" where the ttyloc usually goes in the finger display. From JGA%MIT-OZ at MIT-MC.ARPA Sat Jun 15 18:04:00 1985 From: JGA%MIT-OZ at MIT-MC.ARPA (JGA%MIT-OZ at MIT-MC.ARPA) Date: Jun 15 1985 12:04 EDT Subject: weird wegitude, part II Message-ID: A little bit more on the recent lossage I mentioned earlier... I was logged in when RHB got wedged. Running Peek, I could see that his job and several others were sitting there with a state of "*logout", whatever that means. Peek could not gun his tree, nor could Lock. There were several different HACTRNs sitting around in this state, which explains the lack of net ports I guess, as well as whole bunch of lispm file jobs. I don't know enough about lispm file jobs to tell whether these were normal or not. About two minutes later my tty got wedged, and I can't log back in because of no net ports, so that's why I'm sending this from OZ. From DANIEL at MIT-MC.ARPA Sat Jun 15 20:05:26 1985 From: DANIEL at MIT-MC.ARPA (Daniel Weise) Date: Jun 15 85 14:05:26 EDT Subject: mc needed cold booting this afternoon. Message-ID: <[MIT-MC.ARPA].543663.850615.DANIEL> MC was really wedged this afternoon. Every minute it kept typing system full, 0 pages, 0 qsk channels, etc. No user jobs able to run. Warm booting didn't help so I took a dump to CRASH FULL and cold-booted, which seems to have fixed things. Daniel From JNC at MIT-MC.ARPA Sat Jun 15 00:52:47 1985 From: JNC at MIT-MC.ARPA (J. Noel Chiappa) Date: Jun 14 85 18:52:47 EDT Subject: CHTN lossage Message-ID: <[MIT-MC.ARPA].543165.850614.JNC> Recently I have been noticing that when XX goes down, my CHTN hangs and nothing the world seems to get me out, until it decides to timeout the connection. ANyone know why? From RHB at MIT-MC.ARPA Thu Jun 13 23:25:50 1985 From: RHB at MIT-MC.ARPA (Robert H. Berman) Date: Jun 13 85 17:25:50 EDT Subject: intermittent login probelm Message-ID: <[MIT-MC.ARPA].541730.850613.RHB> Same thing happened to me today too. (around 4:30-5:30 PM) I got about half-way in my login file and the tterminal hung. tried loggin in several times in a row with no success. Finally logged in and everything has been ok since. From JGA at MIT-MC.ARPA Thu Jun 13 17:23:45 1985 From: JGA at MIT-MC.ARPA (John G. Aspinall) Date: Jun 13 85 11:23:45 EDT Subject: wierd wegitude Message-ID: <[MIT-MC.ARPA].541202.850613.JGA> I'm having an intermittent problem of the terminal getting wedged when I log in. The symptoms are as follows. Pword runs ok, and my login file starts executing. At some point, either as the login file ends, or at a point most of the way through it where I have a :more query about whether to run babyl or not, almost all response to typed characters stops. The only characters that cause a response are ctrl-G and rubout which provoke their usual behaviour. My login file has not been changed in months. Other people logging in from the same concentrator (NPLASMA) have not seen the problem. I get the problem four or five times in a row, then everything is fine again. John. From gls at THINK.ARPA Tue Jun 11 00:00:00 1985 From: gls at THINK.ARPA (Guy Steele) Date: Tuesday, 11 June 1985, 00:00 Subject: STINK In-Reply-To: <[MIT-MC.ARPA].538066.850611.KLH> Message-ID: <850611165410.6.GLS@ROCK.ARPA> Hurray! I simply don't know what to think Of this late resurrection of STINK, Once thought lost, at the last, In the mists of the past Like its sibling, the famed missing link. --Guy From KLH at MIT-MC.ARPA Tue Jun 11 11:36:46 1985 From: KLH at MIT-MC.ARPA (Ken Harrenstien) Date: Jun 11 85 05:36:46 EDT Subject: STINK Message-ID: <[MIT-MC.ARPA].538066.850611.KLH> You may find this news hard to believe. As you may recall, the source for STINK didn't assemble properly, and had a higher version number than the (presumably working) binary. The true source, if it ever existed, has been lost in the distant fires of ITS dump tapes being burned at the stake. I was thinking about a possible hack which at some point might require the services of STINK. Never mind what it is. The problem as I saw it was not the fact that STINK is unique and unsupported, but the fact that STINK could not be supported without a real source. So I made a half-hearted attempt to investigate by comparing the (faulty) result of an assembly with the existing binary, using SRCCOM's /$ switch. Boy, am I glad I put that hack into SRCCOM. The comparison much to my surprise showed the binaries were virtually identical, except for one changed label and a couple of missing symbols. It only took a few minutes to fix those and come up with a source that assembles into exactly the same thing (modulo .FNAM2) as the old TS STINK! Anyway, I wrote out this new source as STINK 200, and installed a new TS STINK. STINK lives again! (phew) From CPH at MIT-MC.ARPA Fri Jun 7 01:11:40 1985 From: CPH at MIT-MC.ARPA (Chris Hanson) Date: Thu, 6 Jun 85 18:11:40 EST Subject: No subject Message-ID: <[MIT-MC.ARPA].533331.850606.CPH> Why do I have to give a password when I supdup over from OZ? What kind of bullshit is this?