From ALAN at MC.LCS.MIT.EDU Sat Jan 31 23:01:01 1987 From: ALAN at MC.LCS.MIT.EDU (Alan Bawden) Date: Jan 31 87 17:01:01 EST Subject: TCP buffers Message-ID: <165683.870131.ALAN@MC.LCS.MIT.EDU> I wish we could figure out why ITS consistently dribbles away its TCP buffers until there are none left. I also wish that when this happens, COMSAT didn't exhibit this bizare behavior: 162430 Unqueueing to host THEORY.LCS.MIT.EDU 162431 ICP->THEORY.LCS.MIT.EDU (TCP-SMTP=Bad Greeting="221 BCNU") 162432 Unqueueing to host RED.RUTGERS.EDU 162433 ICP->RED.RUTGERS.EDU (TCP-SMTP=Bad Greeting="221 BCNU") 162434 Unqueueing to host BRL-SEM.ARPA 162435 ICP->BRL-SEM.ARPA (TCP-SMTP=Bad Greeting="221 BCNU") 162435 Unqueueing to host LBL.ARPA 162436 ICP->LBL.ARPA (TCP-SMTP=Bad Greeting="221 BCNU") 162437 Unqueueing to host SDCSVAX.UCSD.EDU 162438 ICP->SDCSVAX.UCSD.EDU (TCP-SMTP=Bad Greeting="221 BCNU") 162439 Unqueueing to host R20.UTEXAS.EDU 162440 ICP->R20.UTEXAS.EDU (TCP-SMTP=Bad Greeting="221 BCNU") 162441 Unqueueing to host SAIL.STANFORD.EDU 162442 ICP->SAIL.STANFORD.EDU (TCP-SMTP=Bad Greeting="221 BCNU") 162444 Unqueueing to host ATHENA.MIT.EDU 162444 ICP->ATHENA.MIT.EDU (TCP-SMTP=Bad Greeting="221 BCNU") 162445 Unqueueing to host CHARON.MIT.EDU 162446 ICP->CHARON.MIT.EDU (TCP-SMTP=Bad Greeting="221 BCNU") From Alan at AI.AI.MIT.EDU Mon Jan 26 21:03:00 1987 From: Alan at AI.AI.MIT.EDU (Alan Bawden) Date: Jan 26 87 15:03 EST Subject: IAP In-Reply-To: <870115152304.7.ALAN@PIGPEN.AI.MIT.EDU> Message-ID: <870126150304.6.ALAN@KAREN.AI.MIT.EDU> Despite the fact that in the IAP guide I promised four sessions of the ITS course, there will -not- be a fourth session this week. See you all again next year! From JTW%MIT-SPEECH at XX.LCS.MIT.EDU Thu Jan 22 00:00:00 1987 From: JTW%MIT-SPEECH at XX.LCS.MIT.EDU (John Wroclawski) Date: Thu 22 Jan 87, 00:00 Subject: RP06 undocumented behavior Message-ID: <12273069628.19.JTW@MIT-SPEECH> The twenex world recently discovered that an RP0x which gets a header compare error (HCE) without getting a header CRC error (HCRC) at the same time may need to have a recalibrate operation done rather than just a recenter and retry type thing. Otherwise the head ends up mispositioned till it eventually slams into the stops (which either fixes it or breaks it but good). Apparently this is contrary to what the "manual" says. I don't know what ITS does in this case. Just writing it down for the record. ------- From ALAN at AI.AI.MIT.EDU Thu Jan 22 10:16:36 1987 From: ALAN at AI.AI.MIT.EDU (Alan Bawden) Date: Jan 22 87 04:16:36 EST Subject: PEEK shouldn't ever PCLSR anyone In-Reply-To: Msg of Wed 21 Jan 1987 00:25 EST from Rob Austein Message-ID: <143202.870122.ALAN@AI.AI.MIT.EDU> After fixing PEEK to not needlessly PCLSR device servers a few days ago, I have been periodically watching COMSAT and DQDEV on MC waiting to catch them in the act of getting hung up. This afternoon I found them in the wedged state and was able to figure out what causes the problem. The problem has nothing to do with the BOJ/JOB code, and is not a bug in DQDEV. Actually it is an apparently long-standing timing error in the implementation of .HANG. Specifically, when you did (as DQDEV does) TRNN AC,%FLAG .HANG the code for .HANG knew that the TRNN instruction could never skip unless the C(AC) changed, and since nothing can change a job's accumulators without PCLSRing the job, .HANG could simply hang forever. This is all well and good, except .HANG neglected to run the instruction once itself to be certain that AC hadn't been changed by an interrupt routine that ran -between- the TRNN and the .HANG. I have assembled an ITS with the fix and I will test it the next time I get a chance. From CENT at AI.AI.MIT.EDU Wed Jan 21 08:12:12 1987 From: CENT at AI.AI.MIT.EDU (Pandora B. Berman) Date: Jan 21 87 02:12:12 EST Subject: ai crashed Message-ID: <142633.870121.CENT@AI.AI.MIT.EDU> again, or halted, or whatever it was. see CRASH;UNIT0 FUKT. Unit 0 had spun down. i spun it up and reloaded. From ALAN at AI.AI.MIT.EDU Fri Jan 16 23:13:23 1987 From: ALAN at AI.AI.MIT.EDU (Alan Bawden) Date: Jan 16 87 17:13:23 EST Subject: [MOON: Mysterious MC won't shut down crash explained] Message-ID: <141115.870116.ALAN@AI.AI.MIT.EDU> After reading the following bug report, you will realize that this reveals a bug in the way jobs are sometimes killed when they have locks locked. If you -first- clobbering their PC's to point to a .LOGOUT in location 0, and only the .LOGOUT then checks to see if the PC is in the critical routine table, then the critical routine table is worthless... Date: Jan 16 87 01:39:40 EST From: David A. Moon To: ALAN at AI.AI.MIT.EDU cc: BUG-COMSAT at AI.AI.MIT.EDU Re: Mysterious MC won't shut down crash explained You aren't going to like this one damn bit. TMPLOC 44, -LCCBLK,,CCBLK ;aobjn ptr to critical code table for lock hacking looks like it would put an aobjn pointer into location 44, doesn't it? It doesn't. It puts -LCCBLK into location 44 and CCBLK into the next location inline (where it happens to get ignored). This is because ; TMPLOC , - puts argument at given LOC ; without changing location counter outside macro call. DEFINE TMPLOC VAL,?ARG [definition deleted] Why the heck doesn't TMPLOC use a rest-of-line arg? Now -LCCBLK is -1,,777772, an aobjn pointer to a page that is mapped into absolute page 120, which contains whatever it happens to contain. If the PC happens to lie within the bounds of the first word there, the system executes the second word there as an instruction, with the extra added feature (see IODCD1 in ITS) that if the LH is zero, SETOM is substituted. Thus when Comsat executes the .LOGOUT that ALOGO4 puts into its AC 0 when the system job guns it, the unlocking of Comsat's locked switches, if that absolute page contains zeros, will do a SETOM 0. If Comsat doesn't pclsr, that -1 is never seen, but if it does PCLSR out of the .LOGOUT (we still don't know where it pclsred from), it executes that -1 as an instruction, causing the lossage we saw. Yow! It looks like it's been this way for eons. Maybe this also explains why the Comsat locks don't always seem to work right. From Peter_Lothberg_STUPI%QZCOM.MAILNET at MIT-MULTICS.ARPA Fri Jan 16 01:07:00 1987 From: Peter_Lothberg_STUPI%QZCOM.MAILNET at MIT-MULTICS.ARPA (Peter_Lothberg_STUPI%QZCOM.MAILNET at MIT-MULTICS.ARPA) Date: 16 Jan 87 01:07 +0100 Subject: IAP In-Reply-To: <870115152304.7.ALAN@PIGPEN.AI.MIT.EDU> Message-ID: <227734@QZCOM> If someone has a home-video-tape-recorder-and-camera-set at MIT availible, it wold be nice to have a vide tape of the lecture, for us that can't show up. From Alan at AI.AI.MIT.EDU Thu Jan 15 21:23:00 1987 From: Alan at AI.AI.MIT.EDU (Alan Bawden) Date: Jan 15 87 15:23 EST Subject: IAP In-Reply-To: <870107165040.1.ALAN@PIGPEN.AI.MIT.EDU> Message-ID: <870115152304.7.ALAN@PIGPEN.AI.MIT.EDU> Those of you who missed the second session of the ITS course last night should be aware that next week we will once again meet on -Wednesday-. It seems I screwed up when I thought we couldn't have the playroom this Tuesday, and it is actually -next- Tuesday than has the conflict. Next Wednesday we'll do something about Job Devices. How to write one, or how they are implemented, or something like that... From Alan at AI.AI.MIT.EDU Wed Jan 7 22:50:00 1987 From: Alan at AI.AI.MIT.EDU (Alan Bawden) Date: Jan 7 87 16:50 EST Subject: IAP Message-ID: <870107165040.1.ALAN@PIGPEN.AI.MIT.EDU> Those of you who missed the first session of the ITS course last night should be aware that next week we will meet on -Wednesday- instead of Tuesday. The following week we will go back to meeting on Tuesdays. (All meetings are in the 7th floor playroom at 7:30). Next Wednesday we will hear a bit about the ITS filesystem (not all that much to tell) and then Ed Schwalenberg will tell us about "CAMEXEC: An ITS-style Operating System for PDP11's". From ALAN at AI.AI.MIT.EDU Sun Jan 4 11:03:53 1987 From: ALAN at AI.AI.MIT.EDU (Alan Bawden) Date: Sun, 4 Jan 87 05:03:53 EST Subject: IAP Message-ID: <136289.870104.ALAN@AI.AI.MIT.EDU> Yes, there will be an IAP course this January about ITS. The first meeting will take place in the 7th floor playroom this Tuesday (the 6th) at 7:30 PM. On Tuesday we will talk about a number of things, including what topics people might want to hear about in future sessions. As a main event, I am preparing an explanation of everyone's favorite ITS feature: PCLSRing: What it is, how it's implemented, and why Lisp Machines should have it. I'll try and satisfy both the people who want to hear about low-level, bits-between-the-toes issues, and those who want to learn universal, cosmic principles. I'll even relate PCLSRing to quantum mechanics. From ALAN at AI.AI.MIT.EDU Thu Jan 1 21:43:25 1987 From: ALAN at AI.AI.MIT.EDU (Alan Bawden) Date: Thu, 1 Jan 87 15:43:25 EST Subject: MX unit #5 In-Reply-To: Msg of Wed 31 Dec 86 22:12:10 EST from Leigh L. Klotz Message-ID: <135733.870101.ALAN@AI.AI.MIT.EDU> Date: Wed, 31 Dec 86 22:12:10 EST From: Leigh L. Klotz I just got a non-recoverable disk data error on klotz;emacs :ej, which is on 14. When you log in, SYS:SYSTEM MAIL warned you that unit #5 was sinking fast. Yeah, many files on that pack/drive have suffered. Perhaps I'll try swapping that pack with the one on unit #4 and see what happens. If we are really lucky, that will destroy both of them! Date: Wed, 31 Dec 86 22:28:06 EST From: Leigh L. Klotz I renamed the bad file to klotz;.bad. :EJ, but the error went away. It had been repeatable. Is anyone interested in this? Should I be sending mail to POOR-MC? POOR-MC is probably the right place, although perhaps there is a POOR-MX list that I don't know about. (POOR-KL?) From KLOTZ%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU Thu Jan 1 04:28:06 1987 From: KLOTZ%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU (Leigh L. Klotz) Date: Dec 31 86 22:28:06 EST Subject: No subject Message-ID: <963808.861231.KLOTZ@MX.LCS.MIT.EDU> I renamed the bad file to klotz;.bad. :EJ, but the error went away. It had been repeatable. Is anyone interested in this? Should I be sending mail to POOR-MC? From KLOTZ%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU Thu Jan 1 04:12:10 1987 From: KLOTZ%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU (Leigh L. Klotz) Date: Dec 31 86 22:12:10 EST Subject: No subject Message-ID: <963796.861231.KLOTZ@MX.LCS.MIT.EDU> I just got a non-recoverable disk data error on klotz;emacs :ej, which is on 14.