On Wed, Mar 13, 2019 at 10:29 AM Zane Healy via cctalk < cctalk at classiccmp.org> wrote: Yes, you will need to apply the patches (I believe patch #448 is the one you need, but why not apply them all...), they fix the MSCP drivers & boot code for the Viking and CMD SCSI controllers. - Josh

Can I assume that all the patches have been applied and tested and none of them have been rescinded? Next, can I assume one need only apply them all in order to bring a system up to current level? And then the logical direction this is going. Is there any where I can find a file containing all of the patches already unpacked so I can feed them all into a system just installed? Dealing with them in the only format I have found so far could take weeks to actually run them. :-) bill

On Fri, Mar 15, 2019 at 1:55 PM Bill Gunshannon via cctalk <cctalk at classiccmp.org> wrote: I already replied to Bill off list with some additional information. I'll reply to the list in case anyone else runs into this for the first time. You don't need to apply *all* of the patches starting from the very beginning. If you started with the distribution here (or some mirror of it) it is already at patch level 431: https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/ https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/VERSION Current Patch Level: 431 Date: April 21, 2000 So patches only need to be applied starting with 432. The time frame of patches 432 through 444 is 2000 through 2003, so somewhat close to the 2.11BSD distribution release referenced above. Then patches 445 through 447 are 2006 through 2008. Then patches 448 through 450 are somewhat recent, 2015 through 2016. I haven't bothered installing anything beyond patch 444 when I set up some 2.11BSD systems in the past. I did try patch 445, which is supposed to fix issues running on a system with no FP unit, but that didn't seem to help when I was trying to get 2.11BSD to run on a QED-993 CPU, which lacks FP support. Never did get 2.11BSD (or RSTS/E) to run on the QED-993 CPU. The individual patch files can currently be found here: https://www.retro11.de/data/211bsd/patches/ These mirrors seem to come and go over time so you might want to grab a copy of the patch files while you can so you don't have to go looking for them somewhere else in the future.

On Sat, Mar 16, 2019, 7:19 AM Bill Gunshannon via cctalk < cctalk at classiccmp.org> wrote: A number of them require manual shell commands before applying, which makes the process harder than you'd expect. Warner

On Sat, Mar 16, 2019, 8:09 AM Bill Gunshannon via cctalk < cctalk at classiccmp.org> wrote: The patches were sent out by email with instructions on how to apply them. This went on for years by different people so that process wasn't uniform. I ran into this when I wanted to quickly create a bad 2.11github repo... I thought it would be quick, but quickly turned into a pita. Warner

On Sat, Mar 16, 2019 at 8:42 AM Bill Gunshannon via cctalk <cctalk at classiccmp.org> wrote: I do that on a DOS PC with a Fujitsu M2444AC 1/2-inch tape drive attached to an Computer Logics PCTD16 ISA bus Pertec interface card using a program I hacked up to do that. Works great if you happen to have a Pertec interface tape drive and a PCTD16 card. But that's no help for you. Sticking with a DOS PC there is ST.EXE by John Wilson. I have used that once or twice long ago and don't remember anything about using it now. http://www.dbit.com/pub/ibmpc/util/ http://www.dbit.com/pub/ibmpc/util/README http://www.dbit.com/pub/ibmpc/util/st.txt st SCSI tape utility. Can be used to capture tape images for Ersatz-11, among other things. Use "st -f scsi6: iget foo.tap" to read the entire tape at SCSI ID 6 into the file "foo.tap", suitable for use with E11's MOUNT command. It can also go the other way, use "iput" instead of "iget" to write foo.tap onto the tape. Fixed block sizes with recordless files are also supported, like what you get with the UNIX "dd" program. More often I used an Exabyte EXB-8200 8mm SCSI tape drive attached to CMD CQD SCSI controllers on Q-Bus systems. To write TAP / TPC tape images to the EXB-8200 I used a Linux system with some code that I hacked up to do that. Much easier than trying to figure out how to do that on a Windows system. It's been a while since I last used that, might take a while to find that code.

On 3/16/19 3:12 PM, Al Kossow via cctalk wrote: I just took a quick glance but somehow I doubt that's going to compile or run on a PDP-11. :-) u32? I grabbed a copy. I am willing to try almost anything. :-) bill

The saga continues!!! I really don;t remember it being this hard back in the good ole' days but then we had lots of real hardware to work with and systems weren't kludges like what I have in my house. :-) I am currently working with E11 V7.3. My prime interest is in getting a 2.11 system running so I can use tcopy(1) to copy tape images to my one real tape drive. It is SCSI so it is going to be TMSCP on the real system. It is also TMSCP on the E11 system. The problem is I don't seem to be able to do anything on E11 to make 2.11 BSD actually have more than one functional tape. I have tried two TMSCP tapes. I have tried two TMSCP controllers. I have tried one TMSCP tape and various configurations of other tape drives. the result is always the same. I hcae tried building a kernel with all the tapes included. I have tried building kernels with two tapes at a time with different combinations of TMSCP and the others. None of them ever come up with more than one drive. March 26 05:11:44 init: configure system hk ? csr 177440 vector 210 skipped: No autoconfig routines. ht ? csr 172440 vector 224 skipped: No autoconfig routines. ra 0 csr 172150 vector 154 vectorset attached rl ? csr 174400 vector 160 skipped: No autoconfig routines. tm ? csr 172520 vector 224 skipped: No autoconfig routines. tms 0 csr 174500 vector 260 skipped: No CSR. tms 1 csr 164334 vector 774 vectorset attached ts ? csr 172520 vector 224 skipped: No autoconfig routines. xp ? csr 176700 vector 254 skipped: No autoconfig routines. I especially don't understand the "No CSR" for tms Unit 0. If I remove the entry for Unit 1 in the E11.ini file then it recognizes Unit 0. But never both and never any other tape drive. Is there something in 2.11 that I am missing? bill

On 3/26/19 3:02 PM, Glen Slick via cctalk wrote: I'm happy either way. But, from the E11 documentation: "DEC generally didn?t have more than one tape drive per TMSCP controller, but as with MSCP disks, E11 has no such artificial limits. However this means it may be possible to configure a system which is incompatible with the PDP-11 operating system?s TMSCP driver, so it is best to define a separate controller for each drive anyway." Mine has two entries: tms 0 174500 260 5 tmsintr # tmscp driver tms 1 164334 0 5 tmsintr # tmscp driver Yes, but it didn't work as I would expect being as the init message says no controller found. I have run it again for the additional devices but they end out being dead. ls -l shows all the tape devices get created but they are none functional. Yeah, got all that. The problem seems to be init not finding them during the configure system stage. And even given the possible confusion over multiple TMSCP controllers, it doesn't explain why the second I add a TMSCP drive all the others seem to just go away in the eyes of 2.11. bill

You set the vector on the second one to zero. Should it be something else? De

On Tue, Mar 26, 2019 at 5:10 PM Bill Gunshannon via cctalk <cctalk at classiccmp.org> wrote: When in doubt, Use the Source. src\sys\autoconfig\do_config.c expect_intr(dp) DTAB *dp; { HAND *hp; register int addr = dp->dt_vector; /* * A vector of 0 has special meaning for devices which support programmable * (settable) vectors. If a xxVec() entry point is present in the driver and * /etc/dtab has a value of 0 for the vector then 'autoconfig' will allocate * one by calling the kernel routine 'nextiv'.

On Sun, Mar 31, 2019 at 12:50 PM Bill Gunshannon via cctalk < cctalk at classiccmp.org> wrote: I believe the console plus the seven additional serial lines show up as individual DL11 units; these are configured via the NKL parameter in your kernel configuration. Set it to 8 and see what happens... Can you elaborate as to what you're doing here (what hardware, how you're bringing it up, etc) and what errors you're getting or what behavior you're seeing? It can't hurt anything, but my guess is that it's unlikely to solve your networking issues. - Josh

On Mon, Apr 1, 2019 at 5:55 PM Bill Gunshannon via cctalk < cctalk at classiccmp.org> wrote: Based on: "/netnix bad magic 407 netinit failed" it looks like the networking portion of the kernel (built into /netnix) was either not built correctly, or not installed properly. Any errors when building netnix? Do you have a netnix in the build directory for the kernel? Does it match the one in root? As for the serial lines, the line "autoconfig: warning: more than three handlers for device tty1 on line 36." sounds suspicious. I'm not entirely sure that the output from autoconfig indicates failure here -- did you create the device files in /dev corresponding to the serial lines? - Josh

On Mon, Apr 1, 2019 at 5:55 PM Bill Gunshannon via cctalk <cctalk at classiccmp.org> wrote: Did you change the "cn" at the beginning of each line you added to the dtab entries below to "tty1" through "tty7"? If so, don't do that. If it is not "cn" the routine src/sys/autoconfig/read_nlist.c: read_nlist() won't be able to correctly link the attach routine pointer for the device entries to src/sys/pdp/cons.c: cnattach() # If you have DL11s, you must give each line an explicit unit number instead # of using a '?' as above. If you use a '?', autoconfig(8) will start # assigning unit numbers starting at 0 which will effectively move your # console to that first line. Start your unit numbers with '1'. # # cn 1 176500 300 5 cnrint cnxint # kl/dl-11 (on mvx11-aa)

On Tue, Apr 2, 2019 at 9:39 AM Bill Gunshannon via cctalk <cctalk at classiccmp.org> wrote: What exactly do you have for the "cn" device entries in /etc/dtab ? #Name Unit# Addr Vector Br Handler(s) # Comments # If you have DL11s, you must give each line an explicit unit number instead # of using a '?' as above. If you use a '?', autoconfig(8) will start # assigning unit numbers starting at 0 which will effectively move your # console to that first line. Start your unit numbers with '1'. # # cn 1 176500 300 5 cnrint cnxint # kl/dl-11 (on mvx11-aa) "handlers" here refers to the receive interrupt handler "cnrint" and the transmit interrupt handler "cnxint". Did you alter anything on the device entries other than the unit number, csr address, and vector address? Try deleting everything on the device entry lines after "cnxint" (For reference, "cnrint" and "cnxint" are the names of the interrupt handler routines in src/sys/pdp/cons.c Those names have to match to be able to link up the pointers to the interrupt handlers).

On Tue, Apr 2, 2019 at 5:09 PM Bill Gunshannon via cctalk <cctalk at classiccmp.org> wrote: Hmm, I spent some time experimenting with this on a SIMH PDP-11 and it appears that the device entry lines in /etc/dtab cannot end exactly at the last character of an interrupt handler name. At least one isspace() character is required before the newline character at the end of the line. I would consider that a bug in the read_dtab() routine in src/sys/autoconfig/read_dtab.c These are the device entry lines I ended up adding to /etc/dtab to ensure that there is at least one isspace() character before the newline character at the end of the line. The '#' comment character isn't necessary, just makes it obvious that there is at least one isspace() character after the last interrupt handler name. cn 1 176500 300 5 cnrint cnxint # cn 2 176510 310 5 cnrint cnxint # cn 3 176520 320 5 cnrint cnxint # cn 4 176530 330 5 cnrint cnxint # cn 5 176540 340 5 cnrint cnxint # cn 6 176550 350 5 cnrint cnxint # cn 7 176560 360 5 cnrint cnxint # After changing the NKL definition in the kernel configuration file and rebuilding and installing a new kernel with that change I now get this when booting the system: November 1 10:44:01 init: configure system ra 0 csr 172150 vector 154 vectorset attached rl 0 csr 174400 vector 160 attached rx 0 csr 177170 vector 264 attached tms 0 csr 174500 vector 260 vectorset attached cn 1 csr 176500 vector 300 attached cn 2 csr 176510 vector 310 attached cn 3 csr 176520 vector 320 attached cn 4 csr 176530 vector 330 attached cn 5 csr 176540 vector 340 attached cn 6 csr 176550 vector 350 attached cn 7 csr 176560 vector 360 attached erase, kill ^U, intr ^C To create the device nodes for the additional DL lines in /dev I then did the following: # cd /dev # rm ttyl* # ./MAKEDEV dl1 dl2 dl3 dl4 dl5 dl6 dl7 # ls -l ttyl* crw------- 1 root 0, 1 Nov 1 10:59 ttyl1 crw------- 1 root 0, 2 Nov 1 10:59 ttyl2 crw------- 1 root 0, 3 Nov 1 10:59 ttyl3 crw------- 1 root 0, 4 Nov 1 10:59 ttyl4 crw------- 1 root 0, 5 Nov 1 10:59 ttyl5 crw------- 1 root 0, 6 Nov 1 10:59 ttyl6 crw------- 1 root 0, 7 Nov 1 10:59 ttyl7 Then to enable getty to run on those addition DL lines I added entries for those device in /etc/ttys. There was already an entry for ttyl1 in /etc/ttys, but I had to change the 'off' to 'on' for that entry: /etc/ttys new entries: ttyl1 "/usr/libexec/getty std.9600" vt100 on secure ttyl2 "/usr/libexec/getty std.9600" vt100 on secure ttyl3 "/usr/libexec/getty std.9600" vt100 on secure ttyl4 "/usr/libexec/getty std.9600" vt100 on secure ttyl5 "/usr/libexec/getty std.9600" vt100 on secure ttyl6 "/usr/libexec/getty std.9600" vt100 on secure ttyl7 "/usr/libexec/getty std.9600" vt100 on secure After making all of those changes and restarting the system I got login prompts on the additional DL lines after exiting single user mode. In summary the only changes I had to make from the generic 2.11BSD installation were: (1) Change the NKL definition in the kernel configuration file and rebuild and install a new kernel with that change (2) Add new 'cn' device entries for the additional DL lines in /etc/dtab (3) ./MAKEDEV dl1 ... dl7 in /dev for the additional DL lines (3) Add additional ttyl1 ... ttyl7 entries for the additional DL lines in /etc/ttys

Bill Gunshannon via cctalk wrote: I have an 11/83 running rt11,rsx11,xxdp and 2.11 bsd (patched) under my desk for years, but it gets seldom powered on...last boot was in January.. I think I put an CMD220 or CDM240 in it, and I have SCSI disks and an additional 8GB quarter Inch Tape Drive from Tandberg (SLR5) mounted, works fine.. I think I have an DHV11 in it, had to boot first to kow it exactly. Network is also working. Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 info at tsht.de Fax +49 3731 74200 Tel +49 3731 74222 Mobil: 0172 8790 741

On Sat, Mar 16, 2019 at 6:19 AM Bill Gunshannon via cctalk <cctalk at classiccmp.org> wrote: That looks like a match for the patch 442 for file /usr/src/usr.bin/f77/expr.c I'm not sure what the "Overdue" message means. I never got that while applying patches 432 through 444. Log below of applying patch 442 through the end of patching file /usr/src/usr.bin/f77/expr.c # cd /usr/src/patches # sh 442 # sh 442.shar # patch -p0 < 442.patch Hmm... Looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** /usr/src/bin/od.c.old Sun Feb 8 14:24:54 1987 |--- /usr/src/bin/od.c Mon Nov 19 20:07:49 2001 -------------------------- Patching file /usr/src/bin/od.c using Plan A... Hunk #1 succeeded at 1. Hunk #2 succeeded at 697. Hunk #3 succeeded at 720. Hunk #4 succeeded at 776. Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** /usr/src/ucb/ex/ex_io.c.old Sun Sep 8 11:59:44 1991 |--- /usr/src/ucb/ex/ex_io.c Mon Nov 19 20:08:08 2001 -------------------------- Patching file /usr/src/ucb/ex/ex_io.c using Plan A... Hunk #1 succeeded at 5. Hunk #2 succeeded at 856. Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** /usr/src/ucb/pascal/pi/pas.y.old Thu Mar 17 14:17:22 1983 |--- /usr/src/ucb/pascal/pi/pas.y Mon Nov 19 20:06:16 2001 -------------------------- Patching file /usr/src/ucb/pascal/pi/pas.y using Plan A... Hunk #1 succeeded at 210. Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** /usr/src/ucb/pascal/pi/const.c.old Fri Jul 10 13:58:28 1981 |--- /usr/src/ucb/pascal/pi/const.c Mon Nov 19 20:08:29 2001 -------------------------- Patching file /usr/src/ucb/pascal/pi/const.c using Plan A... Hunk #1 succeeded at 1. Hunk #2 succeeded at 29. Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** /usr/src/ucb/pascal/pxp/const.c.old Sat May 31 03:50:44 1986 |--- /usr/src/ucb/pascal/pxp/const.c Mon Nov 19 20:06:17 2001 -------------------------- Patching file /usr/src/ucb/pascal/pxp/const.c using Plan A... Hunk #1 succeeded at 31. Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** /usr/src/ucb/pascal/pxp/pas.y.old Fri Jul 10 13:59:37 1981 |--- /usr/src/ucb/pascal/pxp/pas.y Mon Nov 19 20:06:20 2001 -------------------------- Patching file /usr/src/ucb/pascal/pxp/pas.y using Plan A... Hunk #1 succeeded at 203. Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** /usr/src/usr.bin/f77/data.c.old Mon Feb 16 16:57:36 1987 |--- /usr/src/usr.bin/f77/data.c Mon Nov 19 20:06:22 2001 -------------------------- Patching file /usr/src/usr.bin/f77/data.c using Plan A... Hunk #1 succeeded at 16. Hunk #2 succeeded at 74. Hunk #3 succeeded at 87. Hunk #4 succeeded at 96. Hunk #5 succeeded at 108. Hunk #6 succeeded at 134. Hunk #7 succeeded at 153. Hunk #8 succeeded at 166. Hunk #9 succeeded at 214. Hunk #10 succeeded at 232. Hunk #11 succeeded at 267. Hunk #12 succeeded at 274. Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** /usr/src/usr.bin/f77/defines.old Mon Feb 16 16:57:36 1987 |--- /usr/src/usr.bin/f77/defines Mon Nov 19 20:06:23 2001 -------------------------- Patching file /usr/src/usr.bin/f77/defines using Plan A... Hunk #1 succeeded at 233. Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** /usr/src/usr.bin/f77/defs.old Mon Feb 16 16:57:41 1987 |--- /usr/src/usr.bin/f77/defs Mon Nov 19 20:06:24 2001 -------------------------- Patching file /usr/src/usr.bin/f77/defs using Plan A... Hunk #1 succeeded at 268. Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** /usr/src/usr.bin/f77/equiv.c.old Tue Jun 27 19:54:24 1989 |--- /usr/src/usr.bin/f77/equiv.c Mon Nov 19 20:06:25 2001 -------------------------- Patching file /usr/src/usr.bin/f77/equiv.c using Plan A... Hunk #1 succeeded at 47. Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** /usr/src/usr.bin/f77/exec.c.old Mon Feb 16 16:57:37 1987 |--- /usr/src/usr.bin/f77/exec.c Mon Nov 19 20:06:27 2001 -------------------------- Patching file /usr/src/usr.bin/f77/exec.c using Plan A... Hunk #1 succeeded at 227. Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** /usr/src/usr.bin/f77/expr.c.old Mon Feb 16 16:57:37 1987 |--- /usr/src/usr.bin/f77/expr.c Mon Nov 19 20:06:43 2001 -------------------------- Patching file /usr/src/usr.bin/f77/expr.c using Plan B... Hunk #1 succeeded at 21. Hunk #2 succeeded at 33. Hunk #3 succeeded at 49. Hunk #4 succeeded at 62. Hunk #5 succeeded at 75. Hunk #6 succeeded at 95. Hunk #7 succeeded at 115. Hunk #8 succeeded at 163. Hunk #9 succeeded at 237. Hunk #10 succeeded at 289. Hunk #11 succeeded at 1075. Hunk #12 succeeded at 1250. Hunk #13 succeeded at 1303. Hunk #14 succeeded at 1340. Hunk #15 succeeded at 1361. Hunk #16 succeeded at 1375. Hunk #17 succeeded at 1407. Hunk #18 succeeded at 1458. Hunk #19 succeeded at 1675. Hunk #20 succeeded at 1709. Hunk #21 succeeded at 1761. Hunk #22 succeeded at 1768. Hunk #23 succeeded at 1848. Hunk #24 succeeded at 1901. Hunk #25 succeeded at 2079. Hunk #26 succeeded at 2115. Hunk #27 succeeded at 2123. Hunk #28 succeeded at 2131.