TUHS

tuhs@tuhs.org

6532 discussions

by Richard Tobin

> Basically, until C came along, the standard practice was for indices > to start at 1. Certainly Fortran and Pascal did it that way. Mercury Autocode used 0. http://www.homepages.ed.ac.uk/jwp/history/mercury/manual/autocode/4.jpg -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

8 years

Re: [TUHS] 211bsd: kernel panic after a 'here document' in tcsh

by Walter F.J. Mueller

Hi, a few remarks on the feedback on the kernel panic after a 'here document' in tcsh. To Michael Kjörling question: > I'm curious whether the same thing happens if you try that in some > other shell? (Not sure how widely here documents were supported back > then, but I'm asking anyway.) And Johnny Billquist remark > Not sure if any of the other shells have this. 'here documents' are available and work fine in sh and csh. And are in fact used, examples /usr/adm/daily (a /bin/sh script) su uucp << EOF /etc/uucp/clean.daily EOF /usr/crash/why (a /bin/csh script) adb -k {unix,core}.$1 << 'EOF' version/sn"Backtrace:"n $c 'EOF' To Michael Kjörling remark > The PC value in the panic report ("pc 161324") strikes me as high and Johnny Billquist remark > This is in kernel mode, and that is in the I/O page. 211bsd uses split I/D space and uses all 64 kB I space for code. The top 8 kB are in fact the overlay area, and the crash happened in overlay 4 (as indicated by ov 4). With a simple nm /unix | sort | grep " 4" one gets 161254 t ~psignal 4 162302 t ~issignal 4 so the crash is just 050 bytes after the entry point of psignal. So the PC address is fine and not the problem. For psignal look at http://www.retro11.de/ouxr/211bsd/usr/src/sys/sys/kern_sig.c.html#s:_psignal the crash must be one of the first lines. psignal is an internal kernel function, called from http://www.retro11.de/ouxr/211bsd/usr/src/sys/sys/kern_sig.c.html#xref:s:_p… and has nothing to do with the libc function psignal http://www.retro11.de/ouxr/211bsd/usr/man/cat3/psignal.0.html http://www.retro11.de/ouxr/211bsd/usr/src/lib/libc/gen/psignal.c.html To Johnny Billquist remark > Could you (Walter) try the latest version of 2.11BSD and see if you > still get that crash? very interesting that you see a core dump of tcsh rather a kernel panic. Whatever tcsh does, it should not lead to a kernel panic, and if it does, it is primarily a bug of the kernel. It looks like there are two issues, one in tcsh, and one in the kernel. I've a hunch were this might come from, but that will take a weekend or two to check on. With best regards, Walter

8 years

Re: [TUHS] 211bsd: kernel panic after a 'here document' in tcsh

by Johnny Billquist

On 2017-06-06 04:00, Michael Kjörling <michael(a)kjorling.se> wrote: > > On 5 Jun 2017 16:12 +0200, from w.f.j.mueller(a)retro11.de (Walter F.J. Mueller): >> I'm using 211bsd (Version 447) and found that a 'here document' in tcsh >> leads to a kernel panic. It's absolutely reproducible on my system, both >> when run it on my FPGA PDP-11 or in simh. Just doing >> >> tcsh >> cat << EOF > I'm curious whether the same thing happens if you try that in some > other shell? (Not sure how widely here documents were supported back > then, but I'm asking anyway.) Not sure if any of the other shells have this. We're basically talking csh, sh and ksh unless I remember wrong. But it's a good question. If noone else have tried it by tomorrow, I could check. >> is enough, and I get >> >> ka6 31333 aps 147472 >> pc 161324 ps 30004 >> ov 4 >> cpuerr 20 >> trap type 0 >> panic: trap >> syncing disks... done >> >> looking at the crash dump gives >> >> cd /etc/crash >> ./why 4 >> Backtrace: >> 0147372: _boot(05000,0100) from ~panic+072 >> 0147414: _etext(011350) from ~trap+0350 >> 0147450: ~trap() from call+040 >> 0147516: _psignal(0101520,0160750) from ~trap+0364 >> 0147554: ~trap() from call+040 >> >> so the crash is in psignal, which is afaik the kernel internal >> mechanism to dispatch signals. > The PC value in the panic report ("pc 161324") strikes me as high, but > 161324 octal is 58068 decimal, so it's not excessively so, and perhaps > in line with what one might expect to see with a kernel pinned near > top of memory. Are the offsets in the backtrace constant, i.e. does it > always crash on the same code? 161324 is way high. This is in kernel mode, and that is in the I/O page. Basically no code lives in the I/O page (some boot roms and hardware diagnostics excepted). This smells like corrupted memory (pointer or stack), or something else very funny. > Not knowing what cpuerr 20 is specifically doesn't help, and at least > http://www.retro11.de/ouxr/29bsd/usr/src/sys/sys/trap.c.html#n:112 > (which doesn't seem to be too far from what you are running) isn't > terribly enlightening; CPUERR is simply a pointer into a memory-mapped > register of some kind, as seen at > http://www.retro11.de/ouxr/29bsd/usr/include/sys/iopage.h.html#m:CPUERR, > and at least pdp11_cpumod.c from the simh source code at > http://simh.trailing-edge.com/interim/pdp11_cpumod.c wasn't terribly > enlightening, though of course I could be looking in entirely the > wrong place. Like others said - the cpu error register is documented in the processor handbook. 020 means Unibus Timeout, which is consistent with trying to access something in the I/O page, where there is no device configured to respond to that address. I just tried the same thing on a simh system here, and I do not get a crash. This on 2.11BSD at patch level 449, running on an emulated 11/94. I do however get tcsh to crash. simh:/home/bqt> su - Password: erase, kill ^U, intr ^C # tcsh simh:/# cat << EOF Illegal instruction - core dumped # Suspended (tty input) simh:/home/bqt> simh:/home/bqt> cat /VERSION Current Patch Level: 448 Date: January 5, 2010 Yes, it says patch level 448, but it really is 449. This was the system where I worked together with Steven when doing the 449 patch set, but I never got around to actually updating the VERSION file itself. Also, this was while running on the console. Could you (Walter) try the latest version of 2.11BSD and see if you still get that crash? Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

8 years

211bsd: kernel panic after a 'here document' in tcsh

by Walter F.J. Mueller

Hi, I'm using 211bsd (Version 447) and found that a 'here document' in tcsh leads to a kernel panic. It's absolutely reproducible on my system, both when run it on my FPGA PDP-11 or in simh. Just doing tcsh cat << EOF is enough, and I get ka6 31333 aps 147472 pc 161324 ps 30004 ov 4 cpuerr 20 trap type 0 panic: trap syncing disks... done looking at the crash dump gives cd /etc/crash ./why 4 Backtrace: 0147372: _boot(05000,0100) from ~panic+072 0147414: _etext(011350) from ~trap+0350 0147450: ~trap() from call+040 0147516: _psignal(0101520,0160750) from ~trap+0364 0147554: ~trap() from call+040 so the crash is in psignal, which is afaik the kernel internal mechanism to dispatch signals. Questions: 1. has anybody seen this before ? 2. any idea what the reason could be ? With best regards, Walter

8 years

Re: [TUHS] 211bsd: kernel panic after a 'here document' in tcsh

by jnc＠mercury.lcs.mit.edu

> From: Jacob Ritorto > Where might one find the list of trap_types Look in: http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/sys/pdp/scb.s which maps from trap vector locations (built into the hardware; consult a PDP-11 CPU manual for details) to trap type numbers, which are defined here: http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/sys/pdp/trap.h and handled here: http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/sys/pdp/trap.c > and cpuerrs? That just prints the contents of the CPU Error Register; see an appropriate PDP-11 CPU manual - 11/70, /44, /73, /83 or /84 for what all the bits mean. Also the "KDJ11-A CPU Module User's Guide", which also documents it. In theory, there's also a KDJ11-B UG, but it's not online. If anyone has one, can we please get it scanned? Thanks! Noel

8 years

Early Unix Spider network

by Paul Ruizendaal

> The people working on TCP/IP did know of the Spider work (like they knew of > the Cambridge ring work), but it didn't really have any impact; it was a > totally different direction than the one we were going in. I'm aware of that, and I think it was the same the other way around. My interest is tracing how the networking API of Unix developed in the very early days, and that's were there is a link. When I asked a few months back why Bell Labs did not jump onto the work done at UoI, Doug observed that the lab's focus was on Datakit and that triggered my interest. >>>> it turns out that the TIU driver was in Warren's repo all along: > > V4?! Wow. I'd have never guessed it went that far back. My current understanding is that Spider development began in 1969 and that it was first operational in 1972. By '73/'74 it connected a dozen computers at Murray Hill and Unix had gained basic network programs. From Sandy Fraser's "Origins of ATM" video lecture I understand that the Spider learnings included that using a mini to simulate a switch/router was too slow and too costly, and that doing flow control inside the network induced avoidable complexity (I guess Fraser/Cerf/Pouzin all learned that lesson around the same time). The follow-on, custom designed Datakit switch was to correct these issues. Work started in 1974 and I guess that prototypes may have been available around 1978 (when Spider was apparently switched off at Murray Hill). By 1981 a multi-site Datakit network connected various Bell labs and by 1983 Datakit was introduced as a commercial service. As to the Spider network API, it currently seems that it was relatively simple: it exposed the switch as a group of character mode devices, with the user program responsible for doing all protocol work. Interestingly, Spider used a high speed DMA based I/O board (DR11-B), whereas the Datakit switch was apparently connected to a low speed polled I/O board (DR11-C). I did not find the Datakit device driver(s) in the V7 source tree (only a few references in tty.h), so it is hard to be sure of anything. However, it seems that in V7 the Datakit switch was used as "a fancy modem" so to speak, supporting the uucp software stack. There is source for a Datakit driver in the V8 tree, but I currently have no time to study that (and perhaps it is beyond my scope anyway). All input and corrections much appreciated.

8 years, 1 month

Re: [TUHS] Early Unix Spider network

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal >>> The report I have is: "SPIDER-a data communication experiment" >>> ... >>> I think it can be public now, but doing some checks. OK, that would be great to have online. I _think_ the hardcopy I have (somewhere! :-) is that report, but my memory should not be trusted. The people working on TCP/IP did know of the Spider work (like they knew of the Cambridge ring work), but it didn't really have any impact; it was a totally different direction than the one we were going in. >>> it turns out that the TIU driver was in Warren's repo all along: V4?! Wow. I'd have never guessed it went that far back. >>> The code calls snstat() >> The object code for snstat() is in libc.a in the dmr's V5 image. >> Reconstructed, the source code is here: >> ... >> In short, snstat() is a modified stty call Yes, I looked and found the original source, appended below. >>> Could that be the tiu sys call (#45) in the sysent.c table for V4-V6? I wonder if we'll ever be able to find a copy of the kernel code for that tiu() system call. And I wonder what it did? > [1] Oldest alarm() code I can find is in PWB1 > ... > Either alarm existed in V5 and V6 .. or is was added after V6 was > released, perhaps soon after. In the latter case the 'nfs' code that we > have must be later than 1974 Remember, that source came from the MIT system, which is a modified PWB1. So it's not surprising it's using PWB1 system calls. Noel -------- / C interface to spider status call .globl _snstat .globl cerror _snstat: mov r5,-(sp) mov sp,r5 mov 4(r5),r0 mov 6(r5),0f mov 8(r5),0f+2 sys stty; 0f bec 1f jmp cerror 1: clr r0 mov (sp)+,r5 rts pc .data 0: .=.+6

8 years, 1 month

Early Unix Spider network / alarm()

by Paul Ruizendaal

Below what I've been able to find about alarm(): [1] Oldest alarm() code I can find is in PWB1, dated July 1977: http://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/sys/os/sys4.c http://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/sys/os/clock.c Either alarm existed in V5 and V6, and was removed from distributions (which seems unlikely to me), or is was added after V6 was released, perhaps soon after. In the latter case the 'nfs' code that we have must be later than 1974 (even though the man page is dated that way). It could be from the 2nd half of 1975. [2] Interestingly, the idea to implement sleep() in terms of alarm() seems to originate in UoI network unix: http://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/ken/sys2.c -- sslep() This occurs in Oct 1977. In V7 this idea is taken to user space and sleep() is no longer a system call. [3] The UoI code has an instance of alarm() being used to break out of a potentially stalled network call, so that usage seems to have established itself early on.

8 years, 1 month

Early Unix Spider network

by Paul Ruizendaal

Progressed a little further: [1] The 'ufs' command was a variation on the 'nfs' command. The man page that Noel provided for nfs includes the paragraph: "There is a command /usr/usg/tom/ufs which transfers files to the USG Unix systems. The option letter 7 for the 11/70 or 4 for the 11/45 should be used. Otherwise 'ufs' is similar to 'nfs'." This means there must have been a Unix based File Store (server). Does anybody have a suggestion who 'tom' at USG might have been? [2] The V5 man pages in the archive have a man page for 'npr', in section VI. It says: NAME npr - print file on Spider line-printer SYNOPSIS npr file … DESCRIPTION Npr prints files on the line, printer in the Spider room, sending them over the Spider loop. If there are no arguments, the standard input is read and submitted. Thus npr may be used as a filter. FILES /dev/tiu/d2 tiu to loop It suggests that the printer was hooked up to the Spider switch and that channel 2 was hardcoded to it. [3] Upon closer inspection, the tiu.c driver is a character mode device, the use of disk buffers and a strategy() routine had me confused. It is just a reflection of the fact that it uses DMA hardware. The code for tiu.c in NSYS/V4 is rather different from the code in the SRI-NOSC tree: thinking on how to select channels seems to have changed in between these two versions. [4] Also I found the below post that mentions the snstat() call: http://minnie.tuhs.org/pipermail/tuhs/2015-December/006286.html The object code for snstat() is in libc.a in the dmr's V5 image. Reconstructed, the source code is here: http://chiselapp.com/user/pnr/repository/Spider/artifact/a93175746bd9f94f In short, snstat() is a modified stty call, an evolution in the direction of the later ioctl() system call. No progress as yet on the early history of 'alarm()'. Paul

8 years, 1 month

Early Unix Spider network

by Paul Ruizendaal

>> It is a paper copy, but I can make a scan for you. > > That makes it sounds like it might not be possible to put it online? > What's the exact title, so I can look and see if it's already online? > I'm pretty sure I've got a hardcopy of some Spider thing, but it would > probably take me a while to find it... ;-) The report I have is: "SPIDER-a data communication experiment", Tech Report 23 , Bell Lab, 1974. I did not find it online, but it may be out there somewhere. I think it can be public now, but doing some checks. > OK, the only one I have is 'nfs'. Here's the source, and man page: > > http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/nfs.a > http://ana-3.lcs.mit.edu/~jnc/tech/unix/man6/nfs.6 Many thanks! There is some puzzling stuff in there that I'd like to figure out, but that is easier to discuss once the report is online. Also, it turns out that the TIU driver was in Warren's repo all along: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/dmr/tdir/tiu.c http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/man/man4/tiu.4 It's fun to read that the V4 man page says "The precise nature of the UNIX interface has not been defined yet." and Noel's version says: "The precise nature of the UNIX interface is defined elsewhere." (yet the dates are the same!). Some things are surprising (to me, at least): First of all, opening a connection to the File Store is a single open on data channel 1: http://chiselapp.com/user/pnr/repository/Spider/artifact/854a591c0e7a3a54?l… I would expected the code to first have sent a connection request to the switch on control channel 1. Perhaps the File Store was an integral part of the switch/router (a Tempo minicomputer ftp://bitsavers.informatik.uni-stuttgart.de/pdf/tempoComputers/TEMPO-1_ad_Nov69.pdf) with channel 1 functionality hardwired. Next, the code has a hackish form of non-blocking I/O: http://chiselapp.com/user/pnr/repository/Spider/artifact/55ee75831bd98d6c?l… I'm puzzled about the alarm() sys call. That did not exist in 1973 -- or did it only exist in Bell Labs private builds? The code calls snstat(), for instance here: http://chiselapp.com/user/pnr/repository/Spider/artifact/55ee75831bd98d6c?l… That seems to be a sys call to here: http://chiselapp.com/user/pnr/repository/Spider/artifact/2c7d65073a7cb0a5?l… Could that be the tiu sys call (#45) in the sysent.c table for V4-V6?

8 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS