Updated 2.11BSD disk image for testing

[Chase Covello]

I've prepared an updated 2.11BSD image for testing:
http://chasecovello.com/2.11BSD_rq.dsk.xz

It has the following changes from the one currently included in systems.tar.gz:

• Applied 2.11BSD patches 449 and 450 to /usr/src/.
• Recompiled boot and vi (updated in patches).
• Created and built a new kernel configuration called PIDP11 (based on ZEKE, but compiled with 11/70 instructions).
• Cleaned *.o and *~ files in /usr/src/ to save space.
  
• Added a web server with CGI support in /usr/libexec/httpd. It's enabled by default in /etc/inetd.conf. Document root is /home/www/.
• Added Rene Richarz' Tektronix 4010 example programs. Log in as user 'tektronix' and look at the README in the home dir.
• Fixed the Y2K bug and a few other bugs in /usr/local/welcome.

Sources for httpd, welcome, and a few other programs are included in /home/user/src/.

Sources for the Tektronix programs are in /home/tektronix/.

Please try this out and let me know if you find any bugs or have any suggestions. Thanks!

--Chase

[Chase Covello]

Hi everyone,

I've created a GitHub repo for this disk image project:

https://github.com/chasecovello/211bsd-pidp11/

[Rene Richarz]

Chase,

I have tested your image, and it works very well. Thanks for your work, which I appreciate very much.

Unfortunately there is as always a little problem, most likely my fault: All the compiled binaries in /home/tektronix/tek are corrupted. I have already removed these binaries from my repo and added a "make" in the instructions. Nevertheless if you fix other things in the image, can you please do as user tektronix in the directory tek:

  touch *.c

  make

to fix this on the distribution image. Please remove tek4010demo/08_warandpiece.plt too. It also appears to be corrupted.

Thanks, Rene

[Chase Covello]

Hmm, I'm not sure what happened. The included binaries worked for me. Anyway, I recompiled them, deleted 08_warandpeace.plt, and posted an updated image to GitHub.

[Jeff Thieleke]

Thank you for leading this effort! 

My only suggestions would be to comment out lpd in /etc/rc since probably no one uses this and it produces errors that need to be explained away.  The other suggestion would be to create a user level account, by default, which the instructions could reference instead of root.

Jeff

[Chase Covello]

I agree, the lpd messages are annoying. I've uploaded a new image with that commented out.

I'd like to eventually get lpd working, but after looking at what Rene has written, it appears to be very system and printer specific. Maybe the best option for a default configuration is to set up a printer in /etc/printcap that connects to a print server running on Raspbian. I'd appreciate any help on that because I don't know anything about setting that up.

As for the user account, there already is one. It's called 'user' and has no password by default, just like root and tektronix. Oscar, maybe you can update the instructions to recommend the following:

• Set passwords for those user accounts since there are a lot of network services on by default.
• Optionally, change root's shell to tcsh for ease of use. Use 'chsh root' (or 'vipw' to edit /etc/master.passwd directly).
  
• Optionally, change the username and home dir to something you prefer. For example, on my system I changed 'user' to 'chase'. Don't forget to rename the home dir if you change it.
• Optionally, add the user to the 'staff' group so you can su to root.
  

--Chase

[Richard Stofer]

Yes, the message is a bit bothersome but lpd is the first service I set up.  /etc/hosts and /etc/printcap along with the spool directory get set up early in the customization process.

[Jeff Thieleke]

I'm honestly curious...what do you print and to what kind of device?

[Jeff Thieleke]

FWIW, I downloaded your latest image (d3636ed78848dd3d77898b528b8d909cbfe6258f), logged in a 'user', and built both the new welcome and httpd binaries. 

I'm getting in the weeds here, but if someone would write a quick ~user/readme.txt with some info like "welcome to 2.11BSD -- here are some cool things you can do like building a Y2K compliant MOTD app (and here's how we fixed that and also implemented a CGI version) and here's how you can run a web server on your PiDP-11, that would be super cool.  Even just copy and pasting forum posts (with links) would be a gentle introduction into old school BSD.  I'd like a readme for the tek4010 stuff, for example, because the YouTube videos look awesome. 

[Jeff Thieleke]

And after posting this, I noticed you already mentioned the 'tektronix' user and it has its own README already.  So maybe just connecting the pieces in one location.

[Jeff Thieleke]

Linking to https://groups.google.com/forum/#!topic/pidp-11/Qqrp5RwJsoc  or including that info would be awesome as well.

[Chase Covello]

Sure, I can put together a README for new users exploring the system. It will take a little while to pull everything together from these posts.

In the meantime, I've uploaded a new image with lpd re-enabled. I figured out how to get it to print to an lpd server on the host Pi. Rene provided helpful guidance on this and I got it set up.

As a result and for my convenience in testing, I've changed the default network configuration on 2.11BSD to match my home network. Make sure you edit /etc/netstart and /etc/hosts with your correct network configuration. lpd expects to connect to a host called 'rpi', and /etc/hosts should point to its IP. You will also need to edit the name of the CUPS printer in /etc/printcap.

Here's what you need to do to set up the cups-lpd server on the host:

Install cups (and optionally the graphical configuration utility) on Raspbian:

sudo apt install cups system-config-printer

Create /lib/systemd/system/cups-lpd.socket with the following:

[Unit]
Description=CUPS LPD Server Socket
PartOf=cups-lpd.service

[Socket]
ListenStream=515
Accept=true

[Install]
WantedBy=sockets.target

Create /lib/systemd/system/cups-lpd@.service with the following:

[Unit]
Description=CUPS LPD server
Documentation=man:cups-lpd(8)

[Service]
ExecStart=/usr/lib/cups/daemon/cups-lpd -n -o job-sheets=none,none -o document-format=application/octet-stream
StandardInput=socket

[Install]
WantedBy=multi-user.target

Enable cups-lpr:

sudo systemctl enable cups-lpd.socket

sudo systemctl start cups-lpd.socket

Then use the printer setup tool to set up your printer, make sure it's set as shared, and make sure the name is the same as the one in printcap on BSD. cups-lpd doesn't appear to do any authentication, so it's probably also a good idea to set up a firewall to only accept incoming connections to port 515/tcp from your 2.11BSD IP.

--Chase

[Richard Stofer]

First up, I like to print the changed configuration files and there are several including /etc/hosts, /etc/printcap and /etc/netstart.  Printed copies to my PiDP11 binder.

Second, I do a bit of Fortran code in support of my grandson's Differential Equations class.  I have to try to keep up!  I print the source/output and keep it in a binder.

I don't see any advantage in printing through the Pi as I already have networking.  I just create the /etc/hosts and /etc/printcap to get the job done.

The printer is an ordinary HP LaserJet with a duplex unit and multiple trays.  I have no idea how to use those extra features with printcap so I just ignore the features and settle for plain text on one side only.

/etc/hosts:

127.0.0.1 localhost

192.168.1.1 router.rstofer.lan router

192.168.1.106   laserjet.rstofer.lan laserjet  <=====

192.168.1.127   frambus.rstofer.lan frambus

192.168.1.128   widget.rstofer.lan widget

192.168.1.129   pdp11.rstofer.lan pdp11

/etc/printcap

#

# Copyright (c) 1983 Regents of the University of California.

# All rights reserved.  The Berkeley software License Agreement

# specifies the terms and conditions for redistribution.

#

# @(#)etc.printcap 5.1.1 (2.11BSD) 1996/10/25

#

lp|laserjet|HP LaserJet P2550dn:\

   sd=/usr/spool/lpr/lj:\

   rp=text:rm=laserjet:\     <=====

   sh

It's pretty easy to specify the remote printer as rm=laserjet in /etc/printcap and somehow the system finds the IP in /etc/hosts.

[Chase Covello]

Hi all,

I've posted an expanded readme/new user guide to GitHub, and included it in the system image as well. I'd be interested to know if others have success with getting lpd set up as described there.

--Chase

[bmeyer29]

Chase:

Many thanks for all you've done on BSD2.11 for PiDP11! 

I love how much easier you've made to do a number of things. I haven't yet tried to connect to a printer, but that is next on my list.

Since you asked for comments, I would be interested in seeing patch 451 also included in your image. It is available here: ftp://ftp.2bsd.com/2.11BSD and provides an option to allow reading of the front panel switches and writing to the display register while using BSD 2.11. There were a number of folks that helped me figure out what was needed, and Johnny Billquist submitted a patch request to Steven Shultz which was implemented in December, 2018.

This fix requires a specific command to be entered while in single user mode, so this change will have no impact on those not interested in this capability. See the earlier thread "Drive the LEDs from a program" if you are interested in the details. For those following along, this is related to Oscar's "hack" of adding temp and pressure input through an i2c device.

Best regards,

Bob Meyer

On Tuesday, August 27, 2019 at 12:20:47 AM UTC-5, Chase Covello wrote:

[Jeff Thieleke]

I'll echo the thanks for taking on this task!

I was going to get all preachy about having httpd enabled by default, but then I realized that telnetd, ftpd, and rlogind all are as well so hopefully people aren't putting their PiDP11's directly on the Internet... :)

My only minor suggestion would be to default netstart to the more common 192.168.1.1 default router IP address.  But otherwise, I tested this out for a little today and it all looks good.

[Richard Stofer]

What are the advantages of printing through the Pi?  There just has to be a reason and I'm missing it...

lpd is automatically started in the previous 2.11BSD image (and I assume it still is) and all that is required is a simple entry in /etc/printcap, a printer IP address in /etc/hosts and a spool directory in /usr/spool/lpr/<printer name> with permissions of 775 and owner daemon.  As shown above, the printer in my case is called 'lj'.

Everything works right out of the box.

Now, if the goal is to get the Pi to print then cups comes into play.  But, to me, this seems like the long way around.

I'm missing something - again...

[Chase Covello]

No problem. I pushed a new disk image with 451 applied and the kernel rebuilt.

[Chase Covello]

Yeah, a lot of now-insecure stuff is on by default, but that's part of the experience. :) Anyone who's interested in running BSD on a PDP-11 and putting it on the Internet probably knows how to use a firewall, or can figure it out. I'd have a good laugh if someone bothered to hack into my system, and then I'd restore a backup image.

The default network setup is for my ease of use at the moment, so I can start it up and ftp changed files over without editing files in single-user mode with ed. Once the image is ready for inclusion in systems.tar.gz, I can change the default settings. On the other hand, maybe it's a good idea to ship it with nonstandard network settings so a new user has to affirmatively connect it to the network -- I don't know.

[Chase Covello]

Printing through the Pi works if you have a printer that's either not networked or doesn't support lpd. I think Rene said he has a new printer that doesn't have an lpd server, which is why we tried this method. I have a Brother laser printer that's supposed to support lpd, but when I tried printing to it directly it just printed blank pages.

[Johnny Billquist]

If the printer even reacted, then the lpd daemon and network connection
work just fine.

What you more probably have a problem with next is the actual format of
whatever you are trying to print. The printed might be expecting
postscript, while the 2.11BSD printing system is probably just sending
plain text.
Or the printer might expect some even more esoteric format for contents
to be printed...

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-11/4518cfd0-1f31-4db7-a501-e2e318c1b848%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/4518cfd0-1f31-4db7-a501-e2e318c1b848%40googlegroups.com?utm_medium=email&utm_source=footer>.


--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Chase Covello]

That's what I figured too. I'm sure a lot of others will run into the same problems as well, so it makes sense to take advantage of the huge library of CUPS printer drivers and have a system that almost works out of the box. Maybe at some point I will troubleshoot it more and try writing a basic text to postscript filter, unless one already exists.

[Johnny Billquist]

On 2019-09-10 23:24, Chase Covello wrote:
> That's what I figured too. I'm sure a lot of others will run into the
> same problems as well, so it makes sense to take advantage of the huge
> library of CUPS printer drivers and have a system that almost works out
> of the box. Maybe at some point I will troubleshoot it more and try
> writing a basic text to postscript filter, unless one already exists.

Text to postscript already exists. Search for "a2ps". However, I'm not
sure it will work on a PDP-11. Wouldn't be surprised if it uses gobs of
memory.

As far as handling different types of output, if you have CUPS up and
running somewhere, it usually also talks lpd, and if you send output
from the PDP-11 spooling system to a CUPS system, I think it's set up so
it detects what kind of input it is, and applies the necessary tools in
order to render the expected output on the printer.

Speaking of which, if someone don't like CUPS, this can all be solved in
the normal printing system as well. But you need to setup a system of
filters, which autodetects what kind of print file it gets, and applies
various tools to convert files to different formats, in order to
eventually end up with a format the printer understands. And then of
course, you need those different tools, like a2ps. I used to have a
setup like that, but it was quite a while ago now, so I don't remember
all the details anymore. But anyone with some experience/knowledge
should be able to figure it out.
(And no, I actually don't like CUPS myself, but I've come to accept most
stupid solutions people create today, I don't have time to fix all the
problems in the world.)

So I would still use the lpd system on 2.11BSD, but I would point it at
some other machine, and not directly at the printer, unless the printed
can handle plain ASCII. I know HP printers can, but I have no idea about
Brother, for example.

Which is why I also have a spool daemon for network printed in RSX,
which also just does plain ASCII. Works towards the printer I have at
home, which is another HP laser printer. Talks PCL actually, but you
could get away with not doing any PCL stuff.

Johnny

>
> On Tuesday, September 10, 2019 at 1:35:46 PM UTC-7, Johnny Billquist wrote:
>
> If the printer even reacted, then the lpd daemon and network connection
> work just fine.
>
> What you more probably have a problem with next is the actual format of
> whatever you are trying to print. The printed might be expecting
> postscript, while the 2.11BSD printing system is probably just sending
> plain text.
> Or the printer might expect some even more esoteric format for contents
> to be printed...
>
>    Johnny
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/502bedd7-d50c-457b-b68f-eb494ef5eb7c%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/502bedd7-d50c-457b-b68f-eb494ef5eb7c%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Richard Stofer]

Got it!  I always figured there would be a problem with USB printers but I hadn't considered printers that rely on a PC resident driver rather than an industry standard embedded print server.  That's probably because our 3 primary printers are all HP LaserJets and we have just one USB printer connected to a laptop but it isn't shared or networked.  For my simple needs, lpd works fine.

I do know a bit about PCL and HPGL so I suppose I could use those commands to add features to plain text printing but it doesn't seem necessary at this point.  I just want to print source files in plain ASCII.

[Rene Richarz]

As far as I can see the latest HP printers do not support lpd anymore. At least enabling or disabling the protocol on the setup pages is gone and the printer does not seem to listen to the port. This is probably considered a security issue.

[Richard Stofer]

Fortunately, my LaserJet P20550dn and my Color LaserJet M277dw both work with lpd.  Not having that feature would be a show stopper because I have another project that uses a uC to send HPGL sentences to my P2055dn using Berkeley Sockets.

[Johnny Billquist]

On 2019-09-14 02:23, Richard Stofer wrote:
> Fortunately, my LaserJet P20550dn and my Color LaserJet M77dw both work

> with lpd.  Not having that feature would be a show stopper because I
> have another project that uses a uC to send HPGL sentences to my P2055dn
> using Berkeley Sockets.

If you are doing that, then I wonder if you actually are using lpd, or
if you are talking directly to the printer on port 9100, which is not
lpd, but just a port for direct printing.

Johnny

>
> On Friday, September 13, 2019 at 10:23:01 AM UTC-7, Rene Richarz wrote:
>
> As far as I can see the latest HP printers do not support lpd
> anymore. At least enabling or disabling the protocol on the setup
> pages is gone and the printer does not seem to listen to the port.
> This is probably considered a security issue.
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/cbe440aa-ddd5-48b5-a555-895a996fea4e%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/cbe440aa-ddd5-48b5-a555-895a996fea4e%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Rene Richarz]

On Saturday, September 14, 2019 at 11:33:50 AM UTC+2, Johnny Billquist wrote:

On 2019-09-14 02:23, Richard Stofer wrote:
> Fortunately, my LaserJet P20550dn and my Color LaserJet M77dw both work
> with lpd.  Not having that feature would be a show stopper because I
> have another project that uses a uC to send HPGL sentences to my P2055dn
> using Berkeley Sockets.

If you are doing that, then I wonder if you actually are using lpd, or
if you are talking directly to the printer on port 9100, which is not
lpd, but just a port for direct printing.

   Johnny

Good point. Port 9100 is still open on my new HP printer. See attached picture (sorry, German). Is there a way to print directly from BSD to Port 9100.

 

[Johnny Billquist]

The lpd subsystem cannot directly. But for port 9100 you essentially
just need something like netcat. So it's pretty easy to add this
possibility to 2.11BSD. Then you just, in lpd, point to which program
should be used to print the file, and all that program does is sent it
to the port on that host, and you're good.

I'd suggest using of (output filter) for this.

Another option is to write a small program that creates a Unix socket.
That gives you a filename that can be opened and written to by any
program. Then you just point lpd to that filename as the device to open
(the lp parameter in printcap). Then your small program just reads from
that socket, and sends to the printer on port 9100. Again very simple,
and then it's even more straight forward from the lpd point of view.
You can even remove /dev/lp, and just let your small program create
/dev/lp as the Unix socket.

Johnny

On 2019-09-14 11:54, Rene Richarz wrote:
>
>
> On Saturday, September 14, 2019 at 11:33:50 AM UTC+2, Johnny Billquist
> wrote:
>
> On 2019-09-14 02:23, Richard Stofer wrote:
> > Fortunately, my LaserJet P20550dn and my Color LaserJet M77dw
> both work
> > with lpd.  Not having that feature would be a show stopper because I
> > have another project that uses a uC to send HPGL sentences to my
> P2055dn
> > using Berkeley Sockets.
>
> If you are doing that, then I wonder if you actually are using lpd, or
> if you are talking directly to the printer on port 9100, which is not
> lpd, but just a port for direct printing.
>
>    Johnny
>

> IMG_0212.jpeg
>
>
> Good point. Port 9100 is still open on my new HP printer. See attached
> picture (sorry, German). Is there a way to print directly from BSD to
> Port 9100.
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/026aa5f7-cf90-42bb-ab0a-02725383ea02%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/026aa5f7-cf90-42bb-ab0a-02725383ea02%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Richard Stofer]

You're right, I am using port 9100 for my plotter.  I use lpr/lpd from 2.11BSD.

The long version:  I have an FPGA implementation of the IBM 1130 computer I first used in '70.  One of the more important peripherals was the Calcomp 1627 drum plotter.  You can see how a budding EE would want to tie the plotter to the IBM Electronic Circuit Analysis Program (ECAP) for Bode' plots and such.  Well, I just had to have one for my project so I used an mbed LPC1768 uC to capture the 6 bit step commands via SPI (one for each 0.01" of motion), convert them to HPGL commands (accumulating steps, etc) and send them to the LaserJet via the network.

I wrote the code about 8 years ago but looking at it, I can see where I am making the connection to port 9100.  Clearly, I didn't  implement anything like lpr on that uC.  Just a simple socket connection to the server inside the LaserJet and that's it.

For debugging, I wrote a bit of server code on a Linux box to make it look like the LaserJet.  It just listened for a connection on port 9100 and then dumped the sentences to the console and ultimately a file for later review.

In terms of 2.11BSD, I simply use lpr with the appropriate printcap and hosts entries.  The magic of BSD ties everything together but I have never looked at the internals to see how it works.

Totally off topic:  The mbed LPC1768 board only needs a MagJack to connect to a network and the compiler/libraries at mbed.org provides an implementation of lwIP.  Adding networking to a project is as easy as creating a state machine to track the connection and transfers.  If anybody ever needs a simple way to network a uC.

[Rene Richarz]

I have tested using netcat in Raspbian to Port 9100 of my printer, and indeed this still works on my latest HP OfficeJet Pro. This port is obviously still open and not secured in any way, while port 515 is not and cannot be opened anymore. I'm not sure how difficult it would be to port an early version of netcat or nc to 2.11 BSD, but having netcat available would definitely be nicer than just hacking a minimal tool.

[Richard Stofer]

This is way above my pay grade but this security article seems to imply that port 515 could be opened if it is closed by default:

https://itsecurity.uiowa.edu/sites/itsecurity.uiowa.edu/files/how_to_secure_network_printers.pdf

I could see the port being closed by default because CUPS prints to port 9100 and lpd is scarce but by no means obsolete.  It might be worth a couple of minutes to check out the Telnet process.

[Richard Stofer]

On my P2055 LaserJet, I can Telnet to the IP address and select Main Menu -> TCP/IP Menu -> Print Options to enable of disable LPD (among other things).  Pretty archaic...

On the M277dw Color LaserjJet, I can connect to the IP address with a web browser and there are a LOT of setting including the ability to enable or disable LPD.

In the case of both of these printers, LPD is enabled.

I had no idea all this stuff was there...

ETA:  I can also hit the P2055 with a browser.

[Johnny Billquist]

Well, netcat can already be a pretty minimal tool. :-)

As such, it's not hard to write, nor is it particularly large, as
programs go. Should not really be any problems at all under 2.11BSD.

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/8ff3c543-d1d3-400d-a59b-cc9af756c12a%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/8ff3c543-d1d3-400d-a59b-cc9af756c12a%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Johnny Billquist]

Well, the only thing it says is that for some HP printer, there is (was)
telnet access, without much security, through which you could admin the
printer, including turning on and off any protocol.

There are no further implications from this, except that if someone have
admin access, they can admin your printer.

Johnny

> On Saturday, September 14, 2019 at 2:54:38 AM UTC-7, Rene Richarz wrote:
>
>
>
> On Saturday, September 14, 2019 at 11:33:50 AM UTC+2, Johnny
> Billquist wrote:
>
> On 2019-09-14 02:23, Richard Stofer wrote:
> > Fortunately, my LaserJet P20550dn and my Color LaserJet M77dw
> both work
> > with lpd.  Not having that feature would be a show stopper
> because I
> > have another project that uses a uC to send HPGL sentences to
> my P2055dn
> > using Berkeley Sockets.
>
> If you are doing that, then I wonder if you actually are using
> lpd, or
> if you are talking directly to the printer on port 9100, which
> is not
> lpd, but just a port for direct printing.
>
>    Johnny
>

> IMG_0212.jpeg
>
>
> Good point. Port 9100 is still open on my new HP printer. See
> attached picture (sorry, German). Is there a way to print directly
> from BSD to Port 9100.
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/ffecacfb-75b1-4f3b-9d7b-67af28a32089%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/ffecacfb-75b1-4f3b-9d7b-67af28a32089%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Richard Stofer]

By default, for my printers, there is no login required.  Telnet goes straight to a menu and HTTP pops up a web page.  I didn't actually try to change values but I'm guessing that if you get past the login (which doesn't exist), you're in.

One of the things you can do from either interface is jack up the security.  Since my printers are behind NAT, I didn't bother to look at security.  There is an entry to restore factory default values but if somebody created an admin account, I'm not sure how to get around it.

But, in terms of lpd, it should be possible to enable it should it happen to be disabled for security.  Assuming it exists as a protocol at all.  Since I have lpd working on both printers, I'm all set for 2.11BSD.  I don't have to consider printing through the Pi although that is a clever way to get around the lack of lpd at the printer.

[oscarv]

Chase, all,

Just to let you know that I just added the updated 211BSD disk image to the standard distribution (systems.tar.gz).

Let me know if anyone notices any problems with the updated disk image, but I'm pretty sure it's all solid.

Chase, thank you for all the work! Much appreciated.

Kind regards,

Oscar.

[Mike Katz]

Oscar,

Is there an easy way to update an existing system or should I just download and uncompress the entire systems.tar.gz.

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/4a4b5ed6-f7e0-4906-b59b-6850bf7c8d7f%40googlegroups.com.

[Chase Covello]

You can just grab the 2.11BSD disk image from here:

https://github.com/chasecovello/211bsd-pidp11/

Oscar pointed out that the 'user' account had a password on the old image, so the version I just uploaded has no password.

--Chase

On Tuesday, October 8, 2019 at 6:32:00 AM UTC-7, Mike Katz wrote:

Oscar,

Is there an easy way to update an existing system or should I just download and uncompress the entire systems.tar.gz.

On 10/8/2019 8:30 AM, oscarv wrote:

Chase, all,

Just to let you know that I just added the updated 211BSD disk image to the standard distribution (systems.tar.gz).

Let me know if anyone notices any problems with the updated disk image, but I'm pretty sure it's all solid.

Chase, thank you for all the work! Much appreciated.

Kind regards,

Oscar.

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pid...@googlegroups.com.

[Richard Stofer]

I have tried various incantations of tar including -Jxvf and I can't seem to extract the file.  I wandered around the Internet without finding a solution.

Suggestions?

[Jonathan Morton]

> On 9 Oct, 2019, at 3:07 am, Richard Stofer <Richard...@comcast.net> wrote:
>
> I have tried various incantations of tar including -Jxvf and I can't seem to extract the file. I wandered around the Internet without finding a solution.
> Suggestions?

I think -J is what you use for bzip2 archives, as -z is what you use for gzip and -Z is for BSD compress. The more general option in GNU tar is -a, which supports decompressing multiple types of archive including lzma and xz. You can also pipe the archive through a decompressor explicitly: xzcat archive.tar.xz | tar xv. Use this if you have a version of tar that doesn't support -a or can't identify the correct decompressor.

All of this assumes it's actually a tarball. But the filename here is 2.11BSD_rq.dsk.xz, which suggests you should just use unxz on it, resulting in a .dsk image.

- Jonathan Morton

[Richard Stofer]

unxz worked perfectly!

Thanks

On Tuesday, October 8, 2019 at 6:02:08 PM UTC-7, Jonathan Morton wrote:

[Chase Covello]

I've uploaded a new version of the 2.11BSD disk image for the PiDP-11. It is now at patch 456. The following has changed:

• Patch 452: srandom(3) and initstate(3) bug fix to provide 32 bit seed values for random(3)
• Patch 453: floating-point simulation code crash fix; tcsh 'here' document crash fix; welcome Y2K bug fix
  
• Patch 454: kernel timezone struct deprecated; changes to date command
• Patch 455: timezone file dump utility installed
• Patch 456: implement filesystem clean flag to skip fsck at boot if filesystem was cleanly unmounted
  

Patch 456 is especially helpful if you rebuild the bootloader to automatically boot in multiuser mode (see the README at the Github link below). It will save about 10 minutes (on a Pi 3B+) of disk chacking after a clean shutdown.

See the patches under /usr/src/patch/ for the full set of changes and explanation.

The new images is available at:

https://github.com/chasecovello/211bsd-pidp11

--Chase

[Johnny Billquist]

On 2019-11-25 16:55, Chase Covello wrote:
> I've uploaded a new version of the 2.11BSD disk image for the PiDP-11.
> It is now at patch 456. The following has changed:
>

> * Patch 452: srandom(3) and initstate(3) bug fix to provide 32 bit
> seed values for random(3)
> * Patch 453: floating-point simulation code crash fix; tcsh 'here'

> document crash fix; welcome Y2K bug fix

> * Patch 454: kernel timezone struct deprecated; changes to date command
> * Patch 455: timezone file dump utility installed
> * Patch 456: implement filesystem clean flag to skip fsck at boot if

> filesystem was cleanly unmounted
>
> Patch 456 is especially helpful if you rebuild the bootloader to
> automatically boot in multiuser mode (see the README at the Github link
> below). It will save about 10 minutes (on a Pi 3B+) of disk chacking
> after a clean shutdown.

I would strongly suggest/recommend that your image already modifies the
bootloader to automatically boot to multiuser. If anyone really wants to
get to single user, they can both interrupt the boot process with ^C at
fsck, or they could also just stop the countdown at the bootloader, and
say "unix -s" to get to single user.

Very nice of you to provide an updated image of the system for others to
use. Thanks.

Johnny

[Chase Covello]

I would strongly suggest/recommend that your image already modifies the
bootloader to automatically boot to multiuser. If anyone really wants to
get to single user, they can both interrupt the boot process with ^C at
fsck, or they could also just stop the countdown at the bootloader, and
say "unix -s" to get to single user.

Sure, why not. Hanging on to the old behavior really doesn't gain anything. I've updated the image and the README accordingly.

 

Very nice of you to provide an updated image of the system for others to
use. Thanks.

Sure! It's a lot of fun to play with this stuff and I've learned a lot more about UNIX than I ever did just running Linux on my laptop. Unfortunately, the simplicity of BSD has emphasized how annoying systemd is to me on modern Linux systems.

Thanks for pointing me to the recent patches I missed.

--Chase

[Johnny Billquist]

On 2019-11-26 01:55, Chase Covello wrote:
> I would strongly suggest/recommend that your image already modifies the
> bootloader to automatically boot to multiuser. If anyone really
> wants to
> get to single user, they can both interrupt the boot process with ^C at
> fsck, or they could also just stop the countdown at the bootloader, and
> say "unix -s" to get to single user.
>
>
> Sure, why not. Hanging on to the old behavior really doesn't gain
> anything. I've updated the image and the README accordingly.

Yeah. Steven likes the old behavior, so it's the default way of things.
But I personally cannot at all see the point of having it that way. :-)

> Very nice of you to provide an updated image of the system for
> others to
> use. Thanks.
>
>
> Sure! It's a lot of fun to play with this stuff and I've learned a lot
> more about UNIX than I ever did just running Linux on my laptop.

It does get to the basics and forces you to check and understand some
stuff, which really helps. And that same knowledge is mostly just as
applicable on a modern system.

> Unfortunately, the simplicity of BSD has emphasized how annoying systemd
> is to me on modern Linux systems.

systemd is just about the most horrible thing anyone have ever done.

> Thanks for pointing me to the recent patches I missed.

No problem. There is another patch in the pipeline, but it's more of a
cosmetic thing, and it might be a little time before we get it out. But
just so you know...

[Jeff Thieleke]

I'll give a plug for NetBSD.  I've been running it since I had a souped up Amiga 500 with a 60030 sidecar back in the early-ish days (maybe 0.8?).  2.11BSD is obviously primitive, but it disklabel etc. didn't really feel that much different.  Modern NetBSD has a nice setup app and you don't have to worry that stuff now, but it will feel familiar.

[Chase Covello]

I'll give a plug for NetBSD.  I've been running it since I had a souped up Amiga 500 with a 60030 sidecar back in the early-ish days (maybe 0.8?).  2.11BSD is obviously primitive, but it disklabel etc. didn't really feel that much different.  Modern NetBSD has a nice setup app and you don't have to worry that stuff now, but it will feel familiar.

I thought about trying Free or NetBSD, but I have a Surface Book 2 which has a lot of weird hardware. It works well with Linux, but it requires a set of non-mainline kernel patches for basic things like battery status and sleep mode, not to mention the touchscreen and base detachment system. I haven't really looked into it, but I assumed the BSDs didn't support any of that.

At some point I may switch over to a non-systemd Linux distro, but at the moment everything works so I don't have a lot of motivation to start breaking my main system.

--Chase

[Digby R.S. Tarvin]

I spent a bit of time over the weekend giving Chase's new image a try... It all works pretty smoothly - but I thought I would share my notes in case it is of use to anyone else...

In case it is a bit long, here is a brief summary:

- first boot is worryingly slow because it goes to multiuser without a chance to configure the network first

- I opted to use a front panel switch to select between multi-user and traditional booting now

- Adding a second MSCP unit is very useful for transferring files or recovering an unbootable system

- There seems to be a problem trying to boot from a non-default kernel image (hard wired /netnix)

- Network activity can really heavily load a PiDP11 BSD system.

The first item is the only one really related to changes in the new image - the rest apply generally to upgrades to a new BSD 211 image.

1. Initial Boot

The only issue I had here was that it was very slow. This was a combination of the network being configured with a default configuration that won't usually be correct on first install, and the new default 'boot straight to multi user' default meaning there is no opportunity to correct the settings from single user mode. Normally the boot procedure can be interrupted, but this is pretty hard to do if the PiDP11 is being started automatically with the pi startup...  It is ok if you know to wait, but I was starting to worry if it was going to finish booting. This could probably be addressed by a warning in the documentation.

There are obviously going to be differences of opinion over which boot option is better. I was quite happy having to press a return and control-d to get to multi-user, because it meant that I didn't boot the BSD system unless I wanted to use it, and I didn't have to decide at the time I powered up the Pi.

I decided to make a trivial change to boot.c to give me the best of both worlds:

20c20
< #define AUTOMULTIUSER 2       /* 0 = old behaviour, !0 = new (automatic) behaviour */
---
> #define AUTOMULTIUSER 1               /* 1 =  auto multi-user, 2 = SW(15) determines behavior, else traditional */
185,187d184
< #elif AUTOMULTIUSER == 2
< #define SW    ((short *)0177570)
<               bootopts = (*SW & 0100000)? RB_ASKNAME | RB_SINGLE : 0;
190a188
>

With that modification, normal switch settings produce Chase's modified behaviour, but setting switch 15 will cause traditional behaviour.

After all, as we have a cool front panel, we might as well use it for this sort of control - boot options are something front panel switches were intended for :)

2. Copying files from old to new system..

This turned out to be more complicated than I though. The initial plan was create a tar archive with all my changes and personal directory

in the old system, use ftp to transfer it to another system. Then boot the new image and perform the reverse process. Slightly complicated by the need to use an external computer as simh can't support network communications directly between host and simulated system.

The tar archive turned out to be aboutt 30MB, but the initial ftp out failed. I'm still not sure why, but every attempt failed after a few kb with:

426 Data Conection: no buffer space available.

I decided to take a shortcut and copied the tar file out of the disk image using a previosly written tool (intended for exploring the 211BSD filesystem without having to boot it), which completed in a few seconds (v71k h:digbyt/archive.tar archive.tar)

I then booted the new system and tried copying the archive into it using ftp (to see it it would be any more successful). This did work, but was very slow (4.20 Kbytes/sec, taking just under 2 hours for the 20MB).

I decided I needed a better way to transfer files between systems, and so far the best way that I have come up with is to add some lines to boot.ini

to mount my old disk image file as a second MSCP unit:

set rq1 rauser=1000

attach rq1 <name of my old image>

After doing that I could mount my old filesystems eg

# mount /dev/ra1a /mnt

This turned out to be invaluable for my next test also...

3. Building a new kernel

My final test to confirm that I had a usable system (after using the old filesystem to install my personal files and copy across other config

changes I had made) was to build a new kernel.

I changed to /usr/src/sys/conf, copied PIDP11 to DIGBYT so that I would have a custom build to experiment with, made no change other than to change the IDENT field to match the new config name. Then ran ./config DIGBYT to make the new build directory.

I then ran a 'make clean;make' in the DIGBYT directory, which completed without error.

Finally, being cautious, I save the original /unix and /netnix to /unix.orig and /netnix.orig and installed by new system files as /unix.new and /netnix.new

intending to change them to the default names after confirming that the new system at least booted far enough to switch back if I needed.

After a reboot, I interrupted the boot process and specified the new kernel with:

:  ra(0,0,0)unix.new

This, unfortunately, failed with a mysterious panic:

                Boot: bootdev=02400 bootcsr=0172150

                2.11 BSD UNIX #1: Sat Nov 30 22:18:41 GMT+1100 2019
                    root@elec70:/usr/src/sys/DIGBYT

                ra0: Ver 3 mod 3
                ra0: RA82  size=1954000
                net panic: miobase
                panic: Network crashed
                syncing disks... done

                dumping to dev 2401 off 1024
                dump succeeded

                HALT instruction, PC: 007046 (JSR R5,3162)

I couldn't find any cause, but there seemed to be no way cause the boot procedure to use netnix.new instead of netnix, so it seemed it might be come copatability issue. It would have been risky to test knowing that if I changed the new system to default and it paniced the same way, I very likely wouldnt be able to book unix.orig either. But fortunately I now had the ability to boot back into my old system with the new system as unit 1, so that would allow a recovery. So I tried moving unix.new to unix and netnix.new to netnix and trying a boot to the new default system...

Happily the new kernel did start correctly, but that does seem to raise the question - what use is the bootloaders ability to specify a different kernel unless there were also a way to specify a different netix?

After that I re-introduced my several kernal hacks and it rebuilt and restarted without problem. I will have a look at putting console read/write in cons.c,

but I still think the system calls make for a really nice first kernel hack project - very simple change with a very useful result. I am wondering if it could form the basis of a kernel hacking tutorial exercise. 

One last comment on the new image - I am still not sure of its proginy. I assume it was build from the original PiDP image, but does anyone know where that came from? It would be really nice to know what steps would be needed to get from Stephen's 'officially maintained' image to what we are running on the PiDP11.

4. Incidental Discoveries

As an aside, I had noticed that for some time my BSD 2.11 system had stopped producing the familair pattern on the front panel lights. But I first noticed it after moving something on my desk that had been obscuring the panel, and so had no idea what I had changed that might have affected things.

When I first booted the new image, I noticed that the front panel display was behaving normally again, initially suggesting that it was something I had done and that I would have to keep an eye on it while re-implementing all of my changes to see what the culprit was...

However as soon as I updated netstart and hosts, the pattern went away again. So it seems that it was not something I did, but a symptom of some change to the pattern of activity on the LAN here. As a test, I rebooted the old system, then removed the network cable - and sure enough, the old pattern came back.

So my conclusion is that there is something in the network implementation that means a busy network can cause the BSD system to get very heavily loaded. As it is connected to a switch and nobody is talking to it directly, I suspect there must be a lot of broadcast activity. This probably warants some further investigation. 

Regards,

DigbybT

--

You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/1ebad009-9a91-470a-a84e-786d74d40bbd%40googlegroups.com.

[Chase Covello]

Thanks for your comments! I can address a few of them below.

1. Initial Boot

The only issue I had here was that it was very slow. This was a combination of the network being configured with a default configuration that won't usually be correct on first install, and the new default 'boot straight to multi user' default meaning there is no opportunity to correct the settings from single user mode. Normally the boot procedure can be interrupted, but this is pretty hard to do if the PiDP11 is being started automatically with the pi startup...  It is ok if you know to wait, but I was starting to worry if it was going to finish booting. This could probably be addressed by a warning in the documentation.

Yeah, I mentioned this in the README. Since not everyone's network is the same, the first boot is going to be slow until you configure the network. It's possible to eliminate the long timeout by background starting sendmail, ntpd, and ntp in /etc/rc.local, but I don't know if that will cause weird behavior if the clock suddenly changes from Dec 31 1969 to the present time after a user is logged in. It's probably fine. Here's are the relevant lines in rc.local if you want to try it:

/usr/sbin/sendmail -bd -q1h & echo -n ' sendmail'>/dev/console 2>&1

ntpd & echo -n ' ntpd'  >/dev/console 2>&1
echo '.'                >/dev/console 2>&1

ntp -sf pool.ntp.org &

 

With that modification, normal switch settings produce Chase's modified behaviour, but setting switch 15 will cause traditional behaviour.

After all, as we have a cool front panel, we might as well use it for this sort of control - boot options are something front panel switches were intended for :)

I like this. Maybe it can be included as an official patch.

 

The tar archive turned out to be aboutt 30MB, but the initial ftp out failed. I'm still not sure why, but every attempt failed after a few kb with:

426 Data Conection: no buffer space available.

I decided to take a shortcut and copied the tar file out of the disk image using a previosly written tool (intended for exploring the 211BSD filesystem without having to boot it), which completed in a few seconds (v71k h:digbyt/archive.tar archive.tar)

I then booted the new system and tried copying the archive into it using ftp (to see it it would be any more successful). This did work, but was very slow (4.20 Kbytes/sec, taking just under 2 hours for the 20MB).

I wonder if the buffer and speed issues are limited to ftp or ftpd. I've been able to transfer a 30 MB file at about 100 KB/sec using the web server, which seems to be limit for the emulated system.

One last comment on the new image - I am still not sure of its proginy. I assume it was build from the original PiDP image, but does anyone know where that came from? It would be really nice to know what steps would be needed to get from Stephen's 'officially maintained' image to what we are running on the PiDP11.

I started with the BSD image included in the PiDP-11 systems.tar.gz and just made the changes listed in this thread. I'm not sure where it came from, but the original kernel config was named "ZEKE" if that helps narrow it down.

 

So my conclusion is that there is something in the network implementation that means a busy network can cause the BSD system to get very heavily loaded. As it is connected to a switch and nobody is talking to it directly, I suspect there must be a lot of broadcast activity. This probably warants some further investigation. 

I haven't observed this, but I'm using proxy ARP on wifi, rather than a direct ethernet connection. I thought maybe it had to do with SIMH putting the NIC into promiscuous mode and then passing every packet to the emulated system, but if your system is connected through a switch, it shouldn't be able to see packets not addressed to its MAC, right?

--Chase

[Johnny Billquist]

On 2019-12-01 12:07, Digby R.S. Tarvin wrote:
> I spent a bit of time over the weekend giving Chase's new image a try...
> It all works pretty smoothly - but I thought I would share my notes in
> case it is of use to anyone else...
>
> In case it is a bit long, here is a brief summary:
> - first boot is worryingly slow because it goes to multiuser without a
> chance to configure the network first

I assume that is because you do not have a terminal hooked to the
console? Otherwise, there are no problems stopping the system from going
to multiuser.

> - I opted to use a front panel switch to select between multi-user and
> traditional booting now

Interesting solution. Maybe not that bad, but is limited to only be
usable on machines with front panels, which is a rather small subset
consisting of possibly a few real machines, and then PiDP-11 users.

> - Adding a second MSCP unit is very useful for transferring files or
> recovering an unbootable system

Always. :-)

> - There seems to be a problem trying to boot from a non-default kernel
> image (hard wired /netnix)

Yes. That is a known issue.

> - Network activity can really heavily load a PiDP11 BSD system.

Of course. It all depends on what you are doing...

> The first item is the only one really related to changes in the new
> image - the rest apply generally to upgrades to a new BSD 211 image.

Right.

> 1. Initial Boot
> The only issue I had here was that it was very slow. This was a
> combination of the network being configured with a default configuration
> that won't usually be correct on first install, and the new default
> 'boot straight to multi user' default meaning there is no opportunity to
> correct the settings from single user mode. Normally the boot procedure
> can be interrupted, but this is pretty hard to do if the PiDP11 is being
> started automatically with the pi startup...  It is ok if you know to
> wait, but I was starting to worry if it was going to finish booting.
> This could probably be addressed by a warning in the documentation.
>
> There are obviously going to be differences of opinion over which boot
> option is better. I was quite happy having to press a return and
> control-d to get to multi-user, because it meant that I didn't boot the
> BSD system unless I wanted to use it, and I didn't have to decide at the
> time I powered up the Pi.

If you are able to see the console output, then you can also avoid
booting to multiuser. Just hit a key during the initial countdown at the
boot prompt, and then enter "unix -s" to boot to singleuser.

Or else, when the system gets to the fsck phase, just hit ^C.

> I decided to make a trivial change to boot.c to give me the best of both
> worlds:
> 20c20
> < #define AUTOMULTIUSER 2       /* 0 = old behaviour, !0 = new
> (automatic) behaviour */
> ---
> > #define AUTOMULTIUSER 1               /* 1 =  auto multi-user, 2 =
> SW(15) determines behavior, else traditional */
> 185,187d184
> < #elif AUTOMULTIUSER == 2
> < #define SW    ((short *)0177570)
> <               bootopts = (*SW & 0100000)? RB_ASKNAME | RB_SINGLE : 0;
> 190a188
> >
>
> With that modification, normal switch settings produce Chase's modified
> behaviour, but setting switch 15 will cause traditional behaviour.
> After all, as we have a cool front panel, we might as well use it for
> this sort of control - boot options are something front panel switches
> were intended for :)

Right. With the caveat that most PDP-11s didn't have a front panel. But
on the other hand, for those machines, this change also don't hurt anything.

I'll see if we can't get this into the 2.11BSD sources...

> 2. Copying files from old to new system..
> This turned out to be more complicated than I though. The initial plan
> was create a tar archive with all my changes and personal directory
> in the old system, use ftp to transfer it to another system. Then boot
> the new image and perform the reverse process. Slightly complicated by
> the need to use an external computer as simh can't support network
> communications directly between host and simulated system.
>
> The tar archive turned out to be aboutt 30MB, but the initial ftp out
> failed. I'm still not sure why, but every attempt failed after a few kb
> with:
>
> 426 Data Conection: no buffer space available.

That sounds broken somewhere.

> I decided to take a shortcut and copied the tar file out of the disk
> image using a previosly written tool (intended for exploring the 211BSD
> filesystem without having to boot it), which completed in a few seconds
> (v71k h:digbyt/archive.tar archive.tar)
>
> I then booted the new system and tried copying the archive into it using
> ftp (to see it it would be any more successful). This did work, but was
> very slow (4.20 Kbytes/sec, taking just under 2 hours for the 20MB).

That speed is way below anything I would expect. What kind of network
are you using here, and what kind of setup?
You should see at least 10 times that number, even on real hardware.
Depending on the host for the simulated system you would possibly be
expecting 100 times that speed, or even more.

> I decided I needed a better way to transfer files between systems, and
> so far the best way that I have come up with is to add some lines to
> boot.ini
> to mount my old disk image file as a second MSCP unit:
>
> set rq1 rauser=1000
> attach rq1 <name of my old image>
>
> After doing that I could mount my old filesystems eg
>
> # mount /dev/ra1a /mnt
>
> This turned out to be invaluable for my next test also...

A second disk would probably have been my first choice for somewhere to
place files to transfer if I'm wiping a disk.

Yeah, this is ugly.
netnix and unix knows the innards of each other intimately. And you
cannot point to a different filename than /netnix, and the
initialization is always done right at the startup.
I wonder if I maybe should try and add something for this...

> Happily the new kernel did start correctly, but that does seem to raise
> the question - what use is the bootloaders ability to specify a
> different kernel unless there were also a way to specify a different netix?

It's an artifact of that networking was added later. Before then, there
was nothing problematic of having different kernels around.
And at the moment, if you don't have a /netnix, things are also ok. But
there is no way of avoiding sucking in /netnix, if it does exist.

> After that I re-introduced my several kernal hacks and it rebuilt and
> restarted without problem. I will have a look at putting console
> read/write in cons.c,
> but I still think the system calls make for a really nice first kernel
> hack project - very simple change with a very useful result. I am
> wondering if it could form the basis of a kernel hacking tutorial exercise.

I think it might.

I'd like to know how your network setup looks like, since you seem to
have multiple issues with the network. The transfer rates you are seeing
don't make any sense either.
Is the machine throttled somehow?

[Jonathan Morton]

> On 1 Dec, 2019, at 7:11 pm, Chase Covello <cha...@gmail.com> wrote:
>
> So my conclusion is that there is something in the network implementation that means a busy network can cause the BSD system to get very heavily loaded. As it is connected to a switch and nobody is talking to it directly, I suspect there must be a lot of broadcast activity. This probably warants some further investigation.
>
> I haven't observed this, but I'm using proxy ARP on wifi, rather than a direct ethernet connection. I thought maybe it had to do with SIMH putting the NIC into promiscuous mode and then passing every packet to the emulated system, but if your system is connected through a switch, it shouldn't be able to see packets not addressed to its MAC, right?

The switch will also pass through any traffic to a broadcast or multicast address. An *expensive* switch might filter out some of the multicast traffic, but the cheap ones won't. If there's a lot of modern PCs, Macs, and/or phones on the LAN, they'll be merrily spamming it with ARPs, multicast DNS, and zeroconf rubbish, none of which BSD has any interest in, but it still has to receive and parse it all to figure that out.

- Jonathan Morton

[Digby R.S. Tarvin]

Hi Johnny,

On Mon, 2 Dec 2019 at 12:23, Johnny Billquist <b...@softjar.se> wrote:

> - first boot is worryingly slow because it goes to multiuser without a
> chance to configure the network first

I assume that is because you do not have a terminal hooked to the
console? Otherwise, there are no problems stopping the system from going
to multiuser.

 I do at home, but whilst I managed to fit my PiDP11 console into my suitcase, a vt220 would have pushed me over my baggage allowance.

I do have a hacked pidp11.sh which starts simh with the console on vt8 and switches to it - which is gives me a more physically portable terminal like setup, but I thought it testing a PiDP11 image I should really revert back to Oscar's standard configuration (which I assume most new users would be employing) which uses screen for the console. Logging into the gui and then running screen before the simulated PDP has gotten past the boot delay proved a bit difficult.

 

> 1. Initial Boot
> The only issue I had here was that it was very slow. This was a
> combination of the network being configured with a default configuration
> that won't usually be correct on first install, and the new default
> 'boot straight to multi user' default meaning there is no opportunity to
> correct the settings from single user mode. Normally the boot procedure
> can be interrupted, but this is pretty hard to do if the PiDP11 is being
> started automatically with the pi startup...  It is ok if you know to
> wait, but I was starting to worry if it was going to finish booting.
> This could probably be addressed by a warning in the documentation.
>
> There are obviously going to be differences of opinion over which boot
> option is better. I was quite happy having to press a return and
> control-d to get to multi-user, because it meant that I didn't boot the
> BSD system unless I wanted to use it, and I didn't have to decide at the
> time I powered up the Pi.

If you are able to see the console output, then you can also avoid
booting to multiuser. Just hit a key during the initial countdown at the
boot prompt, and then enter "unix -s" to boot to singleuser.

Or else, when the system gets to the fsck phase, just hit ^C.

As you say, easy on a terminal. I don't recall it doing an fsck on first boot - I think it skipped them because the filesystem was clean.

The only way I could try interrupting the boot was to wait for the first boot to multi-user to finish, then reboot and run 'do boot.ini' from the simh prompt so that I could catch it in time.

Also, I didn't need a 'unix -s', if the boot was interrupted, it subsequently always seems to stop in single user after resuming. I assumed that was intended behaviour.

 

> I decided to make a trivial change to boot.c to give me the best of both
> worlds:
> 20c20
> < #define AUTOMULTIUSER 2       /* 0 = old behaviour, !0 = new
> (automatic) behaviour */
> ---
>  > #define AUTOMULTIUSER 1               /* 1 =  auto multi-user, 2 =
> SW(15) determines behavior, else traditional */
> 185,187d184
> < #elif AUTOMULTIUSER == 2
> < #define SW    ((short *)0177570)
> <               bootopts = (*SW & 0100000)? RB_ASKNAME | RB_SINGLE : 0;
> 190a188
>  >
>
> With that modification, normal switch settings produce Chase's modified
> behaviour, but setting switch 15 will cause traditional behaviour.
> After all, as we have a cool front panel, we might as well use it for
> this sort of control - boot options are something front panel switches
> were intended for :)

Right. With the caveat that most PDP-11s didn't have a front panel. But
on the other hand, for those machines, this change also don't hurt anything.

I'll see if we can't get this into the 2.11BSD sources...

That would be nice. As you say, the option does no harm in general, and it could be made default on the PiDP11 image as it is reasonable to assume that will be running with a front panel. (I havn't tried, but I believe that simh allows you to specify switch settings if you do happen to be running without a blinkenlight interfaced front panel.. 

 

> The tar archive turned out to be aboutt 30MB, but the initial ftp out
> failed. I'm still not sure why, but every attempt failed after a few kb
> with:
>
>     426 Data Conection: no buffer space available.

That sounds broken somewhere

Absolutely, but I didn't want to get distracted onto tracking it down at the time. It may be something resulting from the horribly slow speed, leading to a an overflowing or running out somewhere. 

  

> I decided to take a shortcut and copied the tar file out of the disk
> image using a previosly written tool (intended for exploring the 211BSD
> filesystem without having to boot it), which completed in a few seconds
> (v71k h:digbyt/archive.tar archive.tar)
>
> I then booted the new system and tried copying the archive into it using
> ftp (to see it it would be any more successful). This did work, but was
> very slow (4.20 Kbytes/sec, taking just under 2 hours for the 20MB).

That speed is way below anything I would expect. What kind of network
are you using here, and what kind of setup?
You should see at least 10 times that number, even on real hardware.
Depending on the host for the simulated system you would possibly be
expecting 100 times that speed, or even more

Well, at least it did work eventually, so not as bad as the ftp out situation.   My suspicion is that is it just sensitive to the the type of traffic on the local network here. 

> I decided I needed a better way to transfer files between systems, and
> so far the best way that I have come up with is to add some lines to
> boot.ini
> to mount my old disk image file as a second MSCP unit:
>
>     set rq1 rauser=1000
>     attach rq1 <name of my old image>
>
> After doing that I could mount my old filesystems eg
>
>     # mount /dev/ra1a /mnt
>
> This turned out to be invaluable for my next test also...

A second disk would probably have been my first choice for somewhere to
place files to transfer if I'm wiping a disk.

It will probably be mine next time. It just hadn't occured to me till I looked and saw that I could add another unit without any need to reconfigure the kernel.

I think even without the need to copy an old systems files, it would still be very useful to add, for example, a small RK05 removeable device for emergency booting or testing. Plus I could practice building and initializing filesystems..

 

>[booting alternate kernels]

> I couldn't find any cause, but there seemed to be no way cause the boot
> procedure to use netnix.new instead of netnix, so it seemed it might be
> come copatability issue. It would have been risky to test knowing that
> if I changed the new system to default and it paniced the same way, I
> very likely wouldnt be able to book unix.orig either. But fortunately I
> now had the ability to boot back into my old system with the new system
> as unit 1, so that would allow a recovery. So I tried moving unix.new to
> unix and netnix.new to netnix and trying a boot to the new default system...

Yeah, this is ugly.
netnix and unix knows the innards of each other intimately. And you
cannot point to a different filename than /netnix, and the
initialization is always done right at the startup.
I wonder if I maybe should try and add something for this...

The simplest solution I could think of would be to supply a 'backup' kernel that is built without networking. That would be enough to get the system to boot to the point of allowing a previous kernel version to be reverted after a default boot fail...

Of course it would be nicer if it could be fixed such that, for example, booting from unix.x always selected netnix.x

  

> Happily the new kernel did start correctly, but that does seem to raise
> the question - what use is the bootloaders ability to specify a
> different kernel unless there were also a way to specify a different netix?

It's an artifact of that networking was added later. Before then, there
was nothing problematic of having different kernels around.
And at the moment, if you don't have a /netnix, things are also ok. But
there is no way of avoiding sucking in /netnix, if it does exist.

Yes, that seems reasonable. I guess it is documented somewhere and I just missed it.

 

> After that I re-introduced my several kernal hacks and it rebuilt and
> restarted without problem. I will have a look at putting console
> read/write in cons.c,
> but I still think the system calls make for a really nice first kernel
> hack project - very simple change with a very useful result. I am
> wondering if it could form the basis of a kernel hacking tutorial exercise.

I think it might

I'll try and put something together. It would have the benefit of not only helping others, but also letting other people scrutinize what I did and leeting me know what I am doing incorrectly, or at least not optimally.

> So my conclusion is that there is something in the network
> implementation that means a busy network can cause the BSD system to get
> very heavily loaded. As it is connected to a switch and nobody is
> talking to it directly, I suspect there must be a lot of broadcast
> activity. This probably warants some further investigation.

I'd like to know how your network setup looks like, since you seem to
have multiple issues with the network. The transfer rates you are seeing
don't make any sense either.
Is the machine throttled somehow?

My network setup is

1. netstart 

hostname=elec70

netmask=255.255.252.0

broadcast=172.25.96.0
default=172.25.99.11
localhost=127.0.0.1

2. hosts

127.0.0.1       localhost
172.25.99.11    router.tmeic.com.au router
172.25.97.50    elec70.tmeic.com.au elec70
172.25.98.2     printer.tmeic.com.au printer

The network is an office network. Lots of Windows machines, servers, Gb connections, PLCs, remote desktops etc. Its not under my control, so I don't really know how all the routers are configured. But as mentioned previously, wireshark suggests I am seeing quite a bit of traffic, which presumably isn't playing well with a slowish machine in promiscuous mode.

DigbyT

[Digby R.S. Tarvin]

Sure, broadcast traffic I can't do much about, but if the host adapter supports multicast in hardware (I don't know if the Pi's interface does) that would at least mean that I wouldn't see any of the unicast packets that are not intended for any of my locally configured IP addresses.

Plus a switch should fairly quickly learn where to route packets destined for specific addresses, which is usually a problem when trying to diagnose network problems with wireshark, but is helpful when it comes to shielding slow machines from traffic not directed to them.

It may be that the routers here have been configured not to do that because it is an engineering environment and needing to use wireshark is quire common.

I'm not too concerned - unless I continue to see problems when I am back on my home network in a couple of weeks.

DigbyT

 

[Johnny Billquist]

I have a hard time believing that there would be that much broadcast
traffic. And no, an expensive switch will not filter out any more than a
cheap one. A switch have to pass all broadcast traffic to all ports, all
the time.

[Johnny Billquist]

Hi.

On 2019-12-02 03:14, Digby R.S. Tarvin wrote:
> Hi Johnny,
>
> On Mon, 2 Dec 2019 at 12:23, Johnny Billquist <b...@softjar.se
> <mailto:b...@softjar.se>> wrote:
>
>
> > - first boot is worryingly slow because it goes to multiuser
> without a
> > chance to configure the network first
>
> I assume that is because you do not have a terminal hooked to the
> console? Otherwise, there are no problems stopping the system from
> going
> to multiuser.
>
>
>  I do at home, but whilst I managed to fit my PiDP11 console into my
> suitcase, a vt220 would have pushed me over my baggage allowance.

Ah. :-)

When the file system is clean,the window is really small, but you can
still abort fsck with ^C.

> The only way I could try interrupting the boot was to wait for the first
> boot to multi-user to finish, then reboot and run 'do boot.ini' from the
> simh prompt so that I could catch it in time.

Or just do "reboot -s" from the shell? :-)

> Also, I didn't need a 'unix -s', if the boot was interrupted, it
> subsequently always seems to stop in single user after resuming. I
> assumed that was intended behaviour.

Hum? You mean if you interrupt the countdown, and then hit enter, it
goes to single user?
I wouldn't have expected that, but this might be one of those typical
cases that I've forgotten how the behavior is.

It might be that you can give a value for the switch register in simh. I
can't remember ever looking for such a thing.

> > The tar archive turned out to be aboutt 30MB, but the initial ftp
> out
> > failed. I'm still not sure why, but every attempt failed after a
> few kb
> > with:
> >
> >     426 Data Conection: no buffer space available.
>
> That sounds broken somewhere
>
>
> Absolutely, but I didn't want to get distracted onto tracking it down at
> the time. It may be something resulting from the horribly slow speed,
> leading to a an overflowing or running out somewhere.

Well. I think that should be hunted down. It is very odd, and very
possibly related to your transfer speed issues.

> > I decided to take a shortcut and copied the tar file out of the disk
> > image using a previosly written tool (intended for exploring the
> 211BSD
> > filesystem without having to boot it), which completed in a few
> seconds
> > (v71k h:digbyt/archive.tar archive.tar)
> >
> > I then booted the new system and tried copying the archive into
> it using
> > ftp (to see it it would be any more successful). This did work,
> but was
> > very slow (4.20 Kbytes/sec, taking just under 2 hours for the 20MB).
>
> That speed is way below anything I would expect. What kind of network
> are you using here, and what kind of setup?
> You should see at least 10 times that number, even on real hardware.
> Depending on the host for the simulated system you would possibly be
> expecting 100 times that speed, or even more
>
>
> Well, at least it did work eventually, so not as bad as the ftp out
> situation. My suspicion is that is it just sensitive to the the type of
> traffic on the local network here.

That is something that I don't really understand. I find it weird and
possibly unlikely that any other traffic on the network should have any
big impact on the PiDP-11.

Yes.

> Of course it would be nicer if it could be fixed such that, for example,
> booting from unix.x always selected netnix.x

A bit trickier, maybe. Not sure we have the filename for the kernel at
that point. But I think it might also be possible to add some switch to
boot, to make it ask for the name of the netnix file. I'll look into
what can be done.

> > Happily the new kernel did start correctly, but that does seem to
> raise
> > the question - what use is the bootloaders ability to specify a
> > different kernel unless there were also a way to specify a
> different netix?
>
> It's an artifact of that networking was added later. Before then, there
> was nothing problematic of having different kernels around.
> And at the moment, if you don't have a /netnix, things are also ok. But
> there is no way of avoiding sucking in /netnix, if it does exist.
>
>
> Yes, that seems reasonable. I guess it is documented somewhere and I
> just missed it.

Not sure what the documentation might say. I only looked at sources...

> > So my conclusion is that there is something in the network
> > implementation that means a busy network can cause the BSD system
> to get
> > very heavily loaded. As it is connected to a switch and nobody is
> > talking to it directly, I suspect there must be a lot of broadcast
> > activity. This probably warants some further investigation.
>
> I'd like to know how your network setup looks like, since you seem to
> have multiple issues with the network. The transfer rates you are
> seeing
> don't make any sense either.
> Is the machine throttled somehow?
>
>
> My network setup is
> 1. netstart
> hostname=elec70
> netmask=255.255.252.0
> broadcast=172.25.96.0
> default=172.25.99.11
> localhost=127.0.0.1
> 2. hosts
> 127.0.0.1       localhost

> 172.25.99.11 router.tmeic.com.au <http://router.tmeic.com.au> router
> 172.25.97.50 elec70.tmeic.com.au <http://elec70.tmeic.com.au> elec70
> 172.25.98.2 printer.tmeic.com.au <http://printer.tmeic.com.au> printer

>
> The network is an office network. Lots of Windows machines, servers, Gb
> connections, PLCs, remote desktops etc. Its not under my control, so I
> don't really know how all the routers are configured. But as mentioned
> previously, wireshark suggests I am seeing quite a bit of traffic, which
> presumably isn't playing well with a slowish machine in promiscuous mode.

Yes, but...
You have simh. So is it running on some slow or fast RPi? I think it
sounds as if you are using physical ethernet. But how are things hooked
up? Is your whole network using physical ethernet, or is there WiFi
somewhere? How is that all connected together? What about MAC address.
Are you making sure you don't have a collision on those?

Most traffic on a network, at any time, is not broadcast traffic, but
targeting individual machines. Switches will only forward such packets
to the correct port, so even in promiscuous mode, you will not get a lot
of traffic. The only thing that happens is that it allows you to fake
that you have more than one MAC address, and a switch deals with that
just fine.

[Chase Covello]

I do have a hacked pidp11.sh which starts simh with the console on vt8 and switches to it - which is gives me a more physically portable terminal like setup, but I thought it testing a PiDP11 image I should really revert back to Oscar's standard configuration (which I assume most new users would be employing) which uses screen for the console. Logging into the gui and then running screen before the simulated PDP has gotten past the boot delay proved a bit difficult.

One thing you could do to speed up the time to get to the SIMH console is use raspi-config to disable starting X and enable auto-login to console as the pi user. Assuming you're not using a graphical terminal emulator like the VT11 or Tek4010, there's not much reason to start the GUI. Just use screen and create extra windows if you want to telnet into the other console lines.

--Chase

[Chase Covello]

Hum? You mean if you interrupt the countdown, and then hit enter, it
goes to single user?
I wouldn't have expected that, but this might be one of those typical
cases that I've forgotten how the behavior is.

Out of curiosity, I just tried this, and yes it boots to single-user if you interrupt the countdown and press enter.

--Chase

[Johnny Billquist]

On 2019-12-03 00:33, Digby R.S. Tarvin wrote:
> Hi,

>
> On Mon, 2 Dec 2019 at 20:37, Johnny Billquist <b...@softjar.se
> <mailto:b...@softjar.se>> wrote:
>
>
> > As you say, easy on a terminal. I don't recall it doing an fsck
> on first
> > boot - I think it skipped them because the filesystem was clean.
>
> When the file system is clean,the window is really small, but you can
> still abort fsck with ^C.
>
>

>  I must be missing somethine here - if the filesystem is clean, there
> is no fsck to interrupt.  Or are you just saying that it is an option if
> the filesystem is not clean?

fsck needs to run in order to detect that the file systems are clean. So
there is a window to abort fsck. It's just rather short.

> > The only way I could try interrupting the boot was to wait for
> the first
> > boot to multi-user to finish, then reboot and run 'do boot.ini'
> from the
> > simh prompt so that I could catch it in time.
>
> Or just do "reboot -s" from the shell? :-)
>
>

> No, that is equivalent to doing a reboot which automatically requests
> single user. It would only work if reboot can work.
>
> In both cases, for me, reboot or reboot -s  end up back at the simh>
> prompt.

Really? That's weird. That does not happen for me.
If I type reboot, the system is rebooted, without ever getting back to simh.

> Perhaps there is a simh setting which controls this?

No idea. I should look, but I don't think 2.11BSD is exiting back to
simh, or a boot routine in some ROM on real hardware. It would appear it
actually loads and starts the boot program, in a similar way to how the
boot rom starts the system.

> > Also, I didn't need a 'unix -s', if the boot was interrupted, it
> > subsequently always seems to stop in single user after resuming. I
> > assumed that was intended behaviour.
>
> Hum? You mean if you interrupt the countdown, and then hit enter, it
> goes to single user?
> I wouldn't have expected that, but this might be one of those typical
> cases that I've forgotten how the behavior is.
>
>

> Thats what it has always done for me. Let me know if you see anything
> different.
> The behaviour seemed reasonable because I am pretty sure my old BSD/OS
> system behaves the same way.

Seems that is indeed the way it works.

> > That would be nice. As you say, the option does no harm in
> general, and
> > it could be made default on the PiDP11 image as it is reasonable to
> > assume that will be running with a front panel. (I havn't tried,
> but I
> > believe that simh allows you to specify switch settings if you do
> happen
> > to be running without a blinkenlight interfaced front panel..
>
> It might be that you can give a value for the switch register in
> simh. I
> can't remember ever looking for such a thing
>
>

>  I think I saw it documented somewhere, but couldn't find it, but a bit
> of experimentation showed that the command "simh>d sr x" is accepted,
> and seems to store the value when simh is not connected to a console.
>
> It makes sense to me  - otherwise booting an operating system that uses
> front panel switch settings to control boot behaviour would be
> problematic for people without a physical front panel connected.

Well, since most PDP-11s ever sold never had a front panel, pretty much
any operating system are not dependent on front panel switches in the
first place... :-)

> You can also use "simh>e dr" to see what has been written to the display
> register if you don't have a front panel (I expect it works just as well
> if you do).

Makes sense. Thanks.

> >      > The tar archive turned out to be aboutt 30MB, but the
> initial ftp
> >     out
> >      > failed. I'm still not sure why, but every attempt failed
> after a
> >     few kb
> >      > with:
> >      >
> >      >     426 Data Conection: no buffer space available.
> >
> >     That sounds broken somewhere
> >
> > Absolutely, but I didn't want to get distracted onto tracking it
> down at
> > the time. It may be something resulting from the horribly slow
> speed,
> > leading to a an overflowing or running out somewhere.
>
> Well. I think that should be hunted down. It is very odd, and very
> possibly related to your transfer speed issues.
>
>

> Yes, probably true. I will put that on my list of things to look at.

Good luck.

> > Well, at least it did work eventually, so not as bad as the ftp out
> > situation. My suspicion is that is it just sensitive to the the
> type of
> > traffic on the local network here.
>
> That is something that I don't really understand. I find it weird and
> possibly unlikely that any other traffic on the network should have any
> big impact on the PiDP-11.
>
>

> I am suprised at how big an impact, but the traffic is quite heavy. As
> mentioned in a previous email, wireshark showed 25,370 packets in 60
> seconds. An ifconfig shows 57 GiB received in 2 days uptime (3.2 GiB
> transmitted).
>
> What I am not sure of is if this is keeping the BSD system busy, or if
> the simh program is being kept busy and that has the effect of less time
> in the idle loop, or if it is the Pi3 overall which is being kept busy.
>
> Top shows simh as occupying 97.5 of a core, but pulling out the network
> cable so that the panel display goes back to normal does not make it any
> less busy, so clearly simh uses as much processing power as it can get,
> which is not surprising for am simulator.
>
> I would probably have to look at the DE0 simulation to see if the
> packets are getting through to the pdp11 driver, or being filtered out
> by simh.

If simh have things properly simulated, the packets should never hit the
PDP-11 driver, as a DEUNA or DELUA would normally filter packets out for
you as well. You should only ever see packets addressed to your MAC
address, or a ethernet multicast address which you have enabled, unless
promiscuous mode have been enabled in the DEUNA/DELUA, which normally
should not be the case.

But 500 packets a second is rather high. Something is definitely not
well on your network in general if you have that much traffic. Unless
you are doing some really heavy networking.

You might be getting the RPi down on its knees actually.

> ...

> >     It's an artifact of that networking was added later. Before
> then, there
> >     was nothing problematic of having different kernels around.
> >     And at the moment, if you don't have a /netnix, things are
> also ok. But
> >     there is no way of avoiding sucking in /netnix, if it does exist.
> >
> >
> > Yes, that seems reasonable. I guess it is documented somewhere and I
> > just missed it.
>
> Not sure what the documentation might say. I only looked at sources...
>
>

> I could see that from the sources that the name is fixed. But I don't
> understand enough about the linkage between /unix and /netnix to had
> deduced that recompiling the same source with (presumably) the only
> change being the string recording the build date and directory would
> have been enough to make created a compatability issue with the earlier
> netnix.

It's a problem of the values of symbols, and the actual addresses of stuff.
unix and netnix gets symbols resolved across to each other at build
time. Any change, as much as a single byte added on either side can mess
up the addresses, and that cause issues on the other side.

> It is certainly a 'gotcha' that isn't obvious to someone not familiar
> with the way the kernel is split on a PDP11.

Yes.

> It is a Rapsberry Pi 3 with wired just a wired connection. No WiFi
> available.
> Mac address is as assigned by the manufacturer, so I would not expect
> any collision.

But your simulated PDP-11 also have a MAC address, and that one is
assigned by you. Do you have multiple simh instances running?

> Most traffic on a network, at any time, is not broadcast traffic, but
> targeting individual machines. Switches will only forward such packets
> to the correct port, so even in promiscuous mode, you will not get a
> lot
> of traffic. The only thing that happens is that it allows you to fake
> that you have more than one MAC address, and a switch deals with that
> just fine.
>
>

> Looking at a wireshark capture, the bulk of the traffic seems to be UDP
> packets directed to port 11999 on the PDP11's IP address (followed by
> ICMP rejection messages indicating that the port is unreachable). The
> packets are originating from two different hosts.
>
> So as SIMH won't know what services the BSD system is running, I would
> guess that these packets are getting through to the BSD system and it is
> having to do the rejections. Filtering on those packets shows about
> 12,000 per minute. Should be relatively easy to reproduce that on a
> controlled network to verify if it is sufficient to see the effect I am
> observing.
>
> I tracked it down to two systems that sending data logging packets to
> the wrong IP address. Fixed the, and now the PDP11 front panel looks
> normal again. Nice that the front panel was able to alert me to it
> though. Were it a regular bland PC, I would never have noticed the
> network issue slowing things down.

Front panels are good. :-)

[Digby R.S. Tarvin]

On Tue, 3 Dec 2019 at 12:38, Johnny Billquist <b...@softjar.se> wrote:

>   I must be missing somethine here - if the filesystem is clean, there
> is no fsck to interrupt.  Or are you just saying that it is an option if
> the filesystem is not clean?

fsck needs to run in order to detect that the file systems are clean. So
there is a window to abort fsck. It's just rather short.

Ah, ok. I see what you mean now. I was thinking of that situation as fsck determining that no check was needed. In any case, yes, rather a small window - I wouldn't think it would add much to the countdown.

 

> In both cases, for me, reboot or reboot -s  end up back at the simh>
> prompt.

Really? That's weird. That does not happen for me.
If I type reboot, the system is rebooted, without ever getting back to simh.

> Perhaps there is a simh setting which controls this?

No idea. I should look, but I don't think 2.11BSD is exiting back to
simh, or a boot routine in some ROM on real hardware. It would appear it
actually loads and starts the boot program, in a similar way to how the
boot rom starts the system.

I had assumed it was expected behaviour. If not, I'll have to take a closer look. 

  

>      > Also, I didn't need a 'unix -s', if the boot was interrupted, it
>      > subsequently always seems to stop in single user after resuming. I
>      > assumed that was intended behaviour.
>
>     Hum? You mean if you interrupt the countdown, and then hit enter, it
>     goes to single user?
>     I wouldn't have expected that, but this might be one of those typical
>     cases that I've forgotten how the behavior is.
>

>  <simulated switch register>

>   I think I saw it documented somewhere, but couldn't find it, but a bit
> of experimentation showed that the command "simh>d sr x" is accepted,
> and seems to store the value when simh is not connected to a console.
>
> It makes sense to me  - otherwise booting an operating system that uses
> front panel switch settings to control boot behaviour would be
> problematic for people without a physical front panel connected.

Well, since most PDP-11s ever sold never had a front panel, pretty much
any operating system are not dependent on front panel switches in the
first place... :-)

Oh, you mean PDP11/70 class machines were sold without front panels? I didn't know that.

I was assuming that if you had an operarating system which used MMU and seperate I&D then you would be able to assue a front panel, or on the later machines terminal based replacements would have a way to set a switch register value. I have never used one of the latter, so don't have any first hand experience. 

 

If simh have things properly simulated, the packets should never hit the
PDP-11 driver, as a DEUNA or DELUA would normally filter packets out for
you as well. You should only ever see packets addressed to your MAC
address, or a ethernet multicast address which you have enabled, unless
promiscuous mode have been enabled in the DEUNA/DELUA, which normally
should not be the case.

But 500 packets a second is rather high. Something is definitely not
well on your network in general if you have that much traffic. Unless
you are doing some really heavy networking.

You might be getting the RPi down on its knees actually.

As now discovered, the problem was with packets that were addressed to the PDP-11, so the behaviour was reasonable.

The simulated PDP is noticeably faster without the network load..

 

> I could see that from the sources that the name is fixed. But I don't
> understand enough about the linkage between /unix and /netnix to had
> deduced that recompiling the same source with (presumably) the only
> change being the string recording the build date and directory would
> have been enough to make created a compatability issue with the earlier
> netnix.

It's a problem of the values of symbols, and the actual addresses of stuff.
unix and netnix gets symbols resolved across to each other at build
time. Any change, as much as a single byte added on either side can mess
up the addresses, and that cause issues on the other side.

Makes sense. It seems like a pretty neat trick to get around some of the memory restrictions. I'll have to look more closely some time to see how it works.

 

>     You have simh. So is it running on some slow or fast RPi? I think it
>     sounds as if you are using physical ethernet. But how are things hooked
>     up? Is your whole network using physical ethernet, or is there WiFi
>     somewhere? How is that all connected together? What about MAC address.
>     Are you making sure you don't have a collision on those?
>
>
> It is a Rapsberry Pi 3 with wired just a wired connection. No WiFi
> available.
> Mac address is as assigned by the manufacturer, so I would not expect
> any collision.

But your simulated PDP-11 also have a MAC address, and that one is
assigned by you. Do you have multiple simh instances running

Good point - I had forgotten about that. Is there a command that shows the MAC address. I dont see it in a BSD ifconfig. 

And no, only a single simh on the network (as far as I know).

Anyway, turned out to be a useful exercise going through the new image test. I learned more than I expected to :)

DigbyT

[Chase Covello]

No idea. I should look, but I don't think 2.11BSD is exiting back to
simh, or a boot routine in some ROM on real hardware. It would appear it
actually loads and starts the boot program, in a similar way to how the
boot rom starts the system.

I had assumed it was expected behaviour. If not, I'll have to take a closer look. 

I've never been able to reboot the OS from simh either. It drops back to the sim> console with the message:

HALT instruction, PC: 007112 (JSR R5,3162)

 

Johnny, maybe you can share your simh config file so we can try to figure this out? Maybe you're using a different boot program or something?

Good point - I had forgotten about that. Is there a command that shows the MAC address. I dont see it in a BSD ifconfig.

I haven't figured out how to get it from BSD, but from simh, 'show xu' will get you the network interface configuration. 'show config' will show all the hardware configuration.

--Chase

[Digby R.S. Tarvin]

On Tue, 3 Dec 2019 at 17:01, Chase Covello <cha...@gmail.com> wrote:

No idea. I should look, but I don't think 2.11BSD is exiting back to
simh, or a boot routine in some ROM on real hardware. It would appear it
actually loads and starts the boot program, in a similar way to how the
boot rom starts the system.

I had assumed it was expected behaviour. If not, I'll have to take a closer look. 

I've never been able to reboot the OS from simh either. It drops back to the sim> console with the message:

HALT instruction, PC: 007112 (JSR R5,3162)

 

Johnny, maybe you can share your simh config file so we can try to figure this out? Maybe you're using a different boot program or something?

Almost the same for me:

HALT instruction, PC: 007046 (JSR R5,3162)  

PC values are sufficiently close that I think there is a good chance they would have been the same if I hadn't rebuilt my kernel to add the SR/DR system calls.

Being able to reboot without interacting with simh would certainly be an improvement if we can work out how Johnny is doing it..

Good point - I had forgotten about that. Is there a command that shows the MAC address. I dont see it in a BSD ifconfig.

I haven't figured out how to get it from BSD, but from simh, 'show xu' will get you the network interface configuration. 'show config' will show all the hardware configuration.

Ah yes, didn't think of that - thanks.  MAC=08:00:2B:45:0D:28. 

I can see that the 08:00:2B part is hardwired, so suppose the last three octets are randomly generated in some way.

Regards,

DIgbyT

[Johnny Billquist]

On 2019-12-03 03:41, Digby R.S. Tarvin wrote:
> On Tue, 3 Dec 2019 at 12:38, Johnny Billquist <b...@softjar.se
> <mailto:b...@softjar.se>> wrote:
>
> >   I must be missing somethine here - if the filesystem is clean,
> there
> > is no fsck to interrupt.  Or are you just saying that it is an
> option if
> > the filesystem is not clean?
>
> fsck needs to run in order to detect that the file systems are
> clean. So
> there is a window to abort fsck. It's just rather short.
>
>
> Ah, ok. I see what you mean now. I was thinking of that situation as
> fsck determining that no check was needed. In any case, yes, rather a
> small window - I wouldn't think it would add much to the countdown.

Yes. Interrupting at the countdown is easier. It was just a reflection
if you came to the console after the countdown finished.

> > In both cases, for me, reboot or reboot -s  end up back at the simh>
> > prompt.
>
> Really? That's weird. That does not happen for me.
> If I type reboot, the system is rebooted, without ever getting back
> to simh.
>
> > Perhaps there is a simh setting which controls this?
>
> No idea. I should look, but I don't think 2.11BSD is exiting back to
> simh, or a boot routine in some ROM on real hardware. It would
> appear it
> actually loads and starts the boot program, in a similar way to how the
> boot rom starts the system.
>
>
> I had assumed it was expected behaviour. If not, I'll have to take a
> closer look.

Do that. I would not expect what you are observing.

Most certainly. The 11/70 was pretty much the last with a large front
panel. There were a couple of models after with a digital front panel,
but then they all went away.
A very common machine was the 11/83 and 11/84, which had no front panel
at all, and definitely were 11/70 "class" machines.

> I was assuming that if you had an operarating system which used MMU and
> seperate I&D then you would be able to assue a front panel, or on the
> later machines terminal based replacements would have a way to set a
> switch register value. I have never used one of the latter, so don't
> have any first hand experience.

No, there isn't even any virtual front panel to set a value on with a
command on the late machines.

> If simh have things properly simulated, the packets should never hit
> the
> PDP-11 driver, as a DEUNA or DELUA would normally filter packets out
> for
> you as well. You should only ever see packets addressed to your MAC
> address, or a ethernet multicast address which you have enabled, unless
> promiscuous mode have been enabled in the DEUNA/DELUA, which normally
> should not be the case.
>
> But 500 packets a second is rather high. Something is definitely not
> well on your network in general if you have that much traffic. Unless
> you are doing some really heavy networking.
>
> You might be getting the RPi down on its knees actually.
>
>
> As now discovered, the problem was with packets that were addressed to
> the PDP-11, so the behaviour was reasonable.
> The simulated PDP is noticeably faster without the network load..

Right. And that was quite a load.

> > I could see that from the sources that the name is fixed. But I
> don't
> > understand enough about the linkage between /unix and /netnix to had
> > deduced that recompiling the same source with (presumably) the only
> > change being the string recording the build date and directory would
> > have been enough to make created a compatability issue with the
> earlier
> > netnix.
>
> It's a problem of the values of symbols, and the actual addresses of
> stuff.
> unix and netnix gets symbols resolved across to each other at build
> time. Any change, as much as a single byte added on either side can
> mess
> up the addresses, and that cause issues on the other side.
>
>
> Makes sense. It seems like a pretty neat trick to get around some of the
> memory restrictions. I'll have to look more closely some time to see how
> it works.

Well, it's not a plain workaround for memory restrictions. The
networking code is in supervisor mode. But there are no way to
expressing such a thing to the linker, which is why this trick is needed.

So it has to be linked as two separate programs. But since they do call
across to each other, they need to know addresses of things on the other
side.

A bit like dynamic libraries today, except the symbol resolving is done
statically before loading.

[Digby R.S. Tarvin]

p.s. I just tried modifying my /opt/pidp11/bin/pidp11.sh script as follows (to work with the modified boot.c):

30,32c30,32

<               # get low 18 bits and high 4 bits

<               #hi=`expr $sw / 262144`

<               lo=`expr $sw % 262144`

---

>               # get low 12 bits and high 10 bits

>               #hi=`expr $sw / 4096`

>               lo=`expr $sw % 4096`

Oscar's original used the low 18 bits for bootscript selection, and the upper 4 were reserved for 'future special functions' which is reasonable except that while linux can access 22 switches, the PDP11 software can only read SW0-15 from the SR, so there was no provision for PDP11 special functions. (at least as far as I know - If anyone knows otherwise, please let let me know).

With this change and the modification to /usr/src/sys/pdpstand/boot.c:

# diff boot.c.orig boot.c

20c20,21

< #define AUTOMULTIUSER 1               /* 0 = old behaviour, !0 = new (automatic) behaviour */

---

> #define AUTOMULTIUSER 2       /* 0 = old behaviour, 1 = new (automatic) behaviour, 2 = SW(15) selects */

> #define SW    ((short *)0177570)

184a186,187

> #elif AUTOMULTIUSER == 2

>               bootopts = (*SW & 0100000)? RB_ASKNAME | RB_SINGLE : 0;

I can select the old manual boot by setting SW(15) to 1 before powering on.

So question is, does anyone feel that 12 bits (4096 selections) is not enough for OS selection? Would it be worth suggesting a change to Oscar? Even without the change to boot.c, it would be nice to have a few switches that available for application use that would not have to be resotored before restarting the RPi..

I can think of alternative options. For example, SW(21) set means select OS using low 18 bits as now, otherwise repeat the last selection made. The script would be more complex, but you have 16 switches to play with without affecting your boot operation, so long as SW(21) is off.

For now I would be happy with any option that reserves at least SW(15) for boot action select. 

Regards,

DigbyT

[Ville Laitinen]

sorry for the clutter, this might be caused by incomplete kernel config.

BOOTDEV is 'none' by default forcing exit to monitor on reboot.

[Digby R.S. Tarvin]

Ah! Thanks for that!

Now that you mention it, I do recall being puzzled by the BOOTDEV setting (I was obviously booting successfully with a config that has BOOTDEV configured that way, but it made me wonder what it was there for in that case..).

If that is indeed the cause, then it suggests that a reboot will always revert to the default device, no the one currently booted from (unless there is some BOOTDEV setting which does that..)

Also suggests that Johhny is not using a configuration that is either not based on the one distributed with PiDP11, or he has made significant changes to it. Any comment Johhny?

Regards,

DigbyT 

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/76d75593-2c10-4423-9ed9-844b3312faa6%40googlegroups.com.

[Chase Covello]

I see. I can change that in the default kernel config, but I need some guidance here. The disk image is configured for a RQ boot disk, but that's not an option in BSD. Are any of the available options compatible with RQ?

The following are available (corresponding to the bootloader files in /sys/conf/boot/):

#BOOTDEV        dvhp                    # DIVA Comp/V boot device
#BOOTDEV        hk6                     # rk06 boot device
#BOOTDEV        hk7                     # rk07 boot device
#BOOTDEV        ra                      # MSCP boot device
#BOOTDEV        rl                      # rl01/02 boot device
#BOOTDEV        rm                      # rm02/03/05 boot device
#BOOTDEV        br                      # Eaton BR1537/BR1711 boot device
#BOOTDEV        sc11                    # Emulex SC11/B boot device
#BOOTDEV        sc21                    # Emulex SC21 boot device
#BOOTDEV        si                      # si 9500 boot device

--Chase

[Ville Laitinen]

Hi, 

BOOTDEV ra

should be correct, you can actually sort of guess that from the boot process:

sim> boot rq

70Boot from ra(0,0,0) at 0172150

Press <CR> to boot, or any other key to abort: 0

: ra(0,0,0)unix

Boot: bootdev=02400 bootcsr=0172150

and of course the "df" command will show the root drive to be /dev/ra0 

br,

-Ville

[Chase Covello]

Thanks! Automatic reboots now work. I've rebuilt the kernel on the test image and pushed it to Github.

--Chase

[Johnny Billquist]

On 2019-12-03 07:48, Digby R.S. Tarvin wrote:
>
>
> On Tue, 3 Dec 2019 at 17:01, Chase Covello <cha...@gmail.com
> <mailto:cha...@gmail.com>> wrote:
>
> No idea. I should look, but I don't think 2.11BSD is exiting
> back to
> simh, or a boot routine in some ROM on real hardware. It
> would appear it
> actually loads and starts the boot program, in a similar way
> to how the
> boot rom starts the system.
>
>
> I had assumed it was expected behaviour. If not, I'll have to
> take a closer look.
>
>
> I've never been able to reboot the OS from simh either. It drops
> back to the sim> console with the message:
>

> *HALT instruction, PC: 007112 (JSR R5,3162)*

> Johnny, maybe you can share your simh config file so we can try to
> figure this out? Maybe you're using a different boot program or
> something?
>
>
> Almost the same for me:
>
> HALT instruction, PC: 007046 (JSR R5,3162)
>
> PC values are sufficiently close that I think there is a good chance
> they would have been the same if I hadn't rebuilt my kernel to add the
> SR/DR system calls.
>
> Being able to reboot without interacting with simh would certainly be an
> improvement if we can work out how Johnny is doing it..

Hum. Now I'm starting to wonder if I did some change to the code at some
point, totally forgot about it, and have not gotten that distributed...
I need to investigate. Hang on... I'll get back on this in a day or three...

But just to get things straight here. If you type "reboot" at the shell
prompt, you get a HALT, and then are back at the simh prompt?

[Johnny Billquist]

On 2019-12-03 22:50, Digby R.S. Tarvin wrote:
> Ah! Thanks for that!
>
> Now that you mention it, I do recall being puzzled by the BOOTDEV
> setting (I was obviously booting successfully with a config that has
> BOOTDEV configured that way, but it made me wonder what it was there for
> in that case..).
>
> If that is indeed the cause, then it suggests that a reboot will always
> revert to the default device, no the one currently booted from (unless
> there is some BOOTDEV setting which does that..)
>
> Also suggests that Johhny is not using a configuration that is either
> not based on the one distributed with PiDP11, or he has made significant
> changes to it. Any comment Johhny?

Well, I thought it was clear since a long time that I've never been
using any of the distributions supplied with PiDP-11. Nor do I even
download, or base any of my work on any of those images...

Johnny

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-11/76d75593-2c10-4423-9ed9-844b3312faa6%40googlegroups.com

> <https://groups.google.com/d/msgid/pidp-11/76d75593-2c10-4423-9ed9-844b3312faa6%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/CACo5X5geFRPw_hFEVNzW3Syy8jGJb9bbzA%2B-njVYa7MnCfXGRA%40mail.gmail.com
> <https://groups.google.com/d/msgid/pidp-11/CACo5X5geFRPw_hFEVNzW3Syy8jGJb9bbzA%2B-njVYa7MnCfXGRA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Johnny Billquist]

On 2019-12-03 23:55, Chase Covello wrote:
> Thanks! Automatic reboots now work. I've rebuilt the kernel on the test
> image and pushed it to Github.

If you haven't, you should grab patch 457 as well.

[Johnny Billquist]

It's a kind of weird thing that simh likes to call MSCP disks RQ. It's a
sortof carryover from the small disks on Qbus machines hooked up through
an RQDX controller. But it makes limited sense, since the actual disks
there are the RD series of disks. And DEC never used the 'rq' name for
any of them. It's just the controller that have those letters in there.

But I guess we just have to live with one more weird thing in simh... :-)

Once you know, it's in the end pretty straight forward to just remember
the naming used.

Johnny

On 2019-12-03 23:18, Ville Laitinen wrote:
> Hi,
> BOOTDEV ra
> should be correct, you can actually sort of guess that from the boot
> process:
>
> sim> boot rq
>
>
> 70Boot from ra(0,0,0) at 0172150
>
> Press <CR> to boot, or any other key to abort: 0
>
> : ra(0,0,0)unix
>
> Boot: bootdev=02400 bootcsr=0172150
>
>
> and of course the "df" command will show the root drive to be /dev/ra0
>
>
>
>
> br,
>
> -Ville
>
>
> tiistai 3. joulukuuta 2019 23.59.43 UTC+2 Chase Covello kirjoitti:
>
> I see. I can change that in the default kernel config, but I need
> some guidance here. The disk image is configured for a RQ boot disk,
> but that's not an option in BSD. Are any of the available options
> compatible with RQ?
>
> The following are available (corresponding to the bootloader files
> in /sys/conf/boot/):

> *
> *
> *#BOOTDEV        dvhp                    # DIVA Comp/V boot device

> #BOOTDEV        hk6                     # rk06 boot device
> #BOOTDEV        hk7                     # rk07 boot device
> #BOOTDEV        ra                      # MSCP boot device
> #BOOTDEV        rl                      # rl01/02 boot device
> #BOOTDEV        rm                      # rm02/03/05 boot device
> #BOOTDEV        br                      # Eaton BR1537/BR1711 boot
> device
> #BOOTDEV        sc11                    # Emulex SC11/B boot device
> #BOOTDEV        sc21                    # Emulex SC21 boot device

> #BOOTDEV        si                      # si 9500 boot device*
>
> --Chase

>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/56099dea-67f1-4f44-ade9-1d67a7cafef2%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/56099dea-67f1-4f44-ade9-1d67a7cafef2%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Johnny Billquist]

On 2019-12-03 23:55, Chase Covello wrote:

> Thanks! Automatic reboots now work. I've rebuilt the kernel on the test
> image and pushed it to Github.

And d'oh! Looking in the config file, it's even documented that this is
used for automatic booting... My memory isn't what it used to be...

[Chase Covello]

If you haven't, you should grab patch 457 as well.

Thanks. I'll do that and push an update out in a bit.

[Digby R.S. Tarvin]

Actually, I think the description is a bit confusing.  It autoboots just fine with BOOTDEV set to NONE.. What it doesn't do is what I would have called an 'auto-reboot'.. Thats probably why it didn't occur to me to change it. 

Anyway, now updated. I assume after a config file change it is necessary to do a 'make clean', ie:

./config CONFIGFILE

cd ../CONFIGFILE

make clean;make

Patch 457 now applied, thanks!

Regards,

DigbyT

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/6d59e83b-6750-f12b-31b5-a7c633742bf1%40softjar.se.

[Chase Covello]

Patch 457 is now included in the test image.

--Chase

[Jeff Thieleke]

Maybe it is common knowledge and I'm just slow, but what is the official site/source of the 450+ patches?

[Johnny Billquist]

I think I posted that only a couple of days ago, but to repeat the blurb
in the patches:

This and previous updates to 2.11BSD are available at the following
locations:

ftp://ftp.update.uu.se/pub/pdp11/2.11BSD

http://www.tuhs.org/Archive/PDP-11/Distributions/ucb/2.11BSD/Patches
ftp://ftp.2bsd.com/2.11BSD

However, tuhs.org has not always been that up to date when I have checked...

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/e175dbce-eb6e-4803-bbcb-fad9e4db72de%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/e175dbce-eb6e-4803-bbcb-fad9e4db72de%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Johnny Billquist]

On 2019-12-05 02:36, Johnny Billquist wrote:
> I think I posted that only a couple of days ago, but to repeat the blurb
> in the patches:
>
>         This and previous updates to 2.11BSD are available at the
> following
>         locations:
>
>         ftp://ftp.update.uu.se/pub/pdp11/2.11BSD
>
> http://www.tuhs.org/Archive/PDP-11/Distributions/ucb/2.11BSD/Patches
>         ftp://ftp.2bsd.com/2.11BSD
>
> However, tuhs.org has not always been that up to date when I have
> checked...

Checked now, and tuhs.org have caught up, however, the URL provided in
the patches themselves are no longer correct. The correct URL is
https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patches/

Johnny

[Jeff Thieleke]

One patch in 2015, two patches in 2016, one patch in 2018, and then six patches this year?!?  2.11BSD is so hot right now!

[Adam Thornton]

> On Dec 4, 2019, at 7:53 PM, Jeff Thieleke <jeff.t...@gmail.com> wrote:
>
> One patch in 2015, two patches in 2016, one patch in 2018, and then six patches this year?!? 2.11BSD is so hot right now!
>

I imagine that the Fiftieth Anniversary and the PiDP-11 might have something to do with that.

Adam

[Johnny Billquist]

On 2019-12-05 03:53, Jeff Thieleke wrote:
> One patch in 2015, two patches in 2016, one patch in 2018, and then six
> patches this year?!?  2.11BSD is so hot right now!

Yes, it's been quite a year of activity. Quite a lot more than in the
past. I think the PiDP-11 is at least partially the reason for this.

Johnny

>
>
> On Wednesday, December 4, 2019 at 7:39:55 PM UTC-6, Johnny Billquist wrote:
>
> On 2019-12-05 02:36, Johnny Billquist wrote:
> > I think I posted that only a couple of days ago, but to repeat
> the blurb
> > in the patches:
> >
> >          This and previous updates to 2.11BSD are available at the
> > following
> >          locations:
> >
> > ftp://ftp.update.uu.se/pub/pdp11/2.11BSD

> <ftp://ftp.update.uu.se/pub/pdp11/2.11BSD>
> >
> >
> http://www.tuhs.org/Archive/PDP-11/Distributions/ucb/2.11BSD/Patches
> <http://www.tuhs.org/Archive/PDP-11/Distributions/ucb/2.11BSD/Patches>
> > ftp://ftp.2bsd.com/2.11BSD
> >
> > However, tuhs.org <http://tuhs.org> has not always been that up

> to date when I have
> > checked...
>

> Checked now, and tuhs.org <http://tuhs.org> have caught up, however,

> the URL provided in
> the patches themselves are no longer correct. The correct URL is
> https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patches/
> <https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patches/>
>
>    Johnny
>
> --
> Johnny Billquist                  || "I'm on a bus
>                                    ||  on a psychedelic trip

> email: b...@softjar.se <javascript:>             ||  Reading murder

> books
> pdp is alive!                     ||  tryin' to stay hip" - B. Idol
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/8f0e88cd-1a74-4279-a17c-5093ff85ba83%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/8f0e88cd-1a74-4279-a17c-5093ff85ba83%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Johnny Billquist]

Very little, if any at all. I am not aware of any activity because of
that thing, which isn't until next year anyhow.

But sure, that could also be a reason. But the fact that more people
have started using 2.11BSD is the main reason I'd say. And that is
because lately more people have gotten PDP-11 machines, in the form of
the PiDP-11, and the pre-configured disk images.

[Chase Covello]

I've put a new disk image at the Github repo. 2.11BSD is now at patch level 458. Changes are:

1) Filesystem no longer writes the modification date to the superblock on mount. On a PDP-11 without a hardware clock (like the emulated PiDP-11 here), the correct time has not yet been set when the root FS is mounted, so it was always updating the modified time to 1970. The kernel has been recompiled.

2) Optimizations to reduce the size of the tcsh binary.

See /usr/src/patch/458 for details. The new image can be found at:

https://github.com/chasecovello/211bsd-pidp11/

[Frank Wortner]

Tuhs.org now has the latest 2.11BSD patches.

[Chase Covello]

Patch 460 is now included with this disk image.

[Antoni Villalonga i Noceras]

Hi Chase,

Thanks for the update. I'll test the new image ASAP.

Tonight I was trying to apply all pending patches by myself for the first time.
Now I'm working with Johnny Billquist's fsck patch (456). It involves rebuild
kernel on (/usr/src/sys/PIDP11) if I'm not wrong.

I have some beginner thoughts about current patch delivery format:
 * Why it's so weird?
 * Some patches seems to contain minor errors in the instructions. For sure
   you'll faced them all already. Probably that kind of errors could be found
   before releases if there were an automated way to apply them.
 * Can't "patches" be a single sh script?
   May be a script that creates few files:
    - xxx.changes
    - xxx-rm.sh (if needed)
    - xxx.diff
    - xxx-apply.sh (wrapper script to run xxx-rm.sh, patch and all
                build/install commands)...

   The syadmin will only need to run:
    # sh /tmp/XXX
    # cat /tmp/XXX.changes
    # sh /tmp/XXX-apply.sh
 * File checksums (md5/sha1/...)? PGP-like signature?

Thanks for your time!

PS: For sure my proposal is not rocket science and probably is already largely discussed.

--
Antoni Villalonga
http://friki.cat/

[Frank Wortner]

On Monday, January 13, 2020 at 10:47:46 PM UTC-5, Antoni Villalonga i Noceras wrote:

I have some beginner thoughts about current patch delivery format:
 * Why it's so weird?

Welcome to 1989!  ;-)

Please send suggestions and patches to Steven M. Schultz.  You can find his email address in the sendbug program in 2.11BSD.  He creates the patches.  There has been a lot of activity in 2.11BSD lately, no doubt fueled by the popularity of the PiDP-11.

[Johnny Billquist]

On 2020-01-14 04:47, Antoni Villalonga i Noceras wrote:
> I have some beginner thoughts about current patch delivery format:
>  * Why it's so weird?

What is so weird about it?

>  * Some patches seems to contain minor errors in the instructions. For sure
>    you'll faced them all already. Probably that kind of errors could be
> found
>    before releases if there were an automated way to apply them.

Errors are always unfortunate. But it's hard to automate things fully,
since there are quite some difference in what is needed for different
patches.

>  * Can't "patches" be a single sh script?
>    May be a script that creates few files:
>     - xxx.changes
>     - xxx-rm.sh (if needed)
>     - xxx.diff
>     - xxx-apply.sh (wrapper script to run xxx-rm.sh, patch and all
>                 build/install commands)...
>
>    The syadmin will only need to run:
>     # sh /tmp/XXX
>     # cat /tmp/XXX.changes
>     # sh /tmp/XXX-apply.sh

I would sortof be hesitant about that. I really want to check each step
and see if there are anything that goes wrong before doing the next step.

>  * File checksums (md5/sha1/...)? PGP-like signature?

Not sure what that would add, except potential messes. These are not
binaries usually, but source changes.

Johnny

[Antoni Villalonga]

Hi,

I've written an script to apply 2.11BSD patches.
By now it can only update systems running 450 or newer.

https://github.com/frikiluser/211BSDupdater

Comments and patches are welcomed.

Antoni Villalonga i Noceras
#Bloc# ~> http://friki.cat/
#Twitter# ~> @friki

[Jeff Thieleke]

I had some issues getting this to work, but I also gave up too quickly and didn't really follow through on the problems, might have just been Windows CRLF vs. Unix LF issues.  Packaging up your releases as TAR files would be nice improvement to avoid any file transfer issues.  I'll definitely be following the progress on this project, though!

One observation/FYI: after manually updating from Version 458 to 461, I noticed that my kernel build was broken.  I think patch 460 changed cc preprocessor's handling of #define strings that start with a digit - my kernel config was called "211BSD" and I got a "<command line>:2: error: bad #define" error, which turned out to be caused by "-D211BSD".  It was an easy fix to just modify the Makefile and prefix that a character, and modern gcc has a similar behavior, but this might potentially be a breaking change for some historic code.

[Antoni Villalonga]

On Mon, Feb 10, 2020 at 1:51 AM Jeff Thieleke wrote:
>
> I had some issues getting this to work, but I also gave up too quickly and didn't really follow through on the problems, might have just been Windows CRLF vs. Unix LF issues. Packaging up your releases as TAR files would be nice improvement to avoid any file transfer issues. I'll definitely be following the progress on this project, though!

Hi Jeff,

Please find attached 'wip' branch, with new and untested update
scripts starting from 420. Patches also included, so no network
required.

To update the system, unpack and run ./updater.sh as root.

How can I get an ancient 211BSD image? I've seen install tapes at FTP,
but stuck with some problems. Is it possible to found a 211BSD "patch
level 0" image?


Thanks!

[Will Senn]

So, when I download the disk and boot from it, I get a read error on ra0h:

Sun Aug  9 10:21:49 PDT 2020
/dev/ra0a: file system is clean; not checking
ra0 st=1 sb=E0 fl=0 en=21
ra0h: hard error sn2 status 16001
/dev/rra0g: file system is clean; not checking
/dev/rra0h: CANNOT READ: BLK 1
/dev/rra0h: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
Automatic reboot failed... help!
erase, kill ^U, intr ^C

So, curious as to what might be on the rra0g and rra0h partitions:

cat /etc/fstab
/dev/ra0a       /       ufs     rw              1       1
/dev/ra0b       none    swap    sw              0       0
/dev/ra0g       /usr    ufs     rw              1       2
/dev/ra0h       /home   ufs     rw              1       2

well /usr's pretty important, so is this expected behavior? It does the same thing on the pl 469, 457, and whatever the first version was of the rq. 2.11 boots, but what's up with the partitions scheme.

Here's what I've got in my simh.ini

set CPU 11/93, 4M
set CPU IDLE
set tto 7b

set dz lines=8
set dz 7b
attach -am dz 4000

set ts enable
set rq enable

set RK disable
set HK disable
set TC disable
set TM disable
att ts0 ts0.tap

SET XQ ENABLED
SET XQ TYPE=DEQNA
SET XQ MAC=08-00-4b-13-37-12
ATTACH XQ tap:tap0

attach rq 2.11BSD_rq.dsk
boot rq

I'm not on a pi, but I don't know why that would effect the way the partitions look in 211bsd...

Thanks,

Will

On Tuesday, August 27, 2019 at 12:20:47 AM UTC-5, Chase Covello wrote:

I've prepared an updated 2.11BSD image for testing:
http://chasecovello.com/2.11BSD_rq.dsk.xz

It has the following changes from the one currently included in systems.tar.gz:

• Applied 2.11BSD patches 449 and 450 to /usr/src/.
• Recompiled boot and vi (updated in patches).
• Created and built a new kernel configuration called PIDP11 (based on ZEKE, but compiled with 11/70 instructions).
• Cleaned *.o and *~ files in /usr/src/ to save space.
  
• Added a web server with CGI support in /usr/libexec/httpd. It's enabled by default in /etc/inetd.conf. Document root is /home/www/.
• Added Rene Richarz' Tektronix 4010 example programs. Log in as user 'tektronix' and look at the README in the home dir.
• Fixed the Y2K bug and a few other bugs in /usr/local/welcome.

Sources for httpd, welcome, and a few other programs are included in /home/user/src/.

Sources for the Tektronix programs are in /home/tektronix/.

Please try this out and let me know if you find any bugs or have any suggestions. Thanks!

--Chase

[Johnny Billquist]

Hum. "disklabel /dev/ra0a" maybe could be interesting to see the output
from. (or if that should be rra0a, I can't remember, or test, right now...)

Johnny

> * Applied 2.11BSD patches 449 and 450 to /usr/src/.
> * Recompiled boot and vi (updated in patches).
> * Created and built a new kernel configuration called PIDP11

> (based on ZEKE, but compiled with 11/70 instructions).

> * Cleaned *.o and *~ files in /usr/src/ to save space.
> * Added a web server with CGI support in /usr/libexec/httpd. It's

> enabled by default in /etc/inetd.conf. Document root is /home/www/.

> * Added Rene Richarz' Tektronix 4010 example programs. Log in as

> user 'tektronix' and look at the README in the home dir.

> * Fixed the Y2K bug and a few other bugs in /usr/local/welcome.

>
> Sources for httpd, welcome, and a few other programs are included in
> /home/user/src/.
> Sources for the Tektronix programs are in /home/tektronix/.
>
> Please try this out and let me know if you find any bugs or have any
> suggestions. Thanks!
>
> --Chase
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/3a56fca1-82b2-43f7-a462-05a172edcabfo%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/3a56fca1-82b2-43f7-a462-05a172edcabfo%40googlegroups.com?utm_medium=email&utm_source=footer>.

[jeff.t...@gmail.com]

It wouldn't hurt to start with the default PiDP boot.ini and just comment out the realcons stuff at the end to see if that does anything.

Also, make sure simh has full read/write permissions on the .dsk file.  Maybe run it as root just to see if that helps.

[August Treubig]

Simh under linux has to be run as root for the network to work using pcap.   

Aug

Sent from my iPad

On Aug 9, 2020, at 8:24 PM, jeff.t...@gmail.com <jeff.t...@gmail.com> wrote:



--

You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/df5df396-1f17-435f-9de8-ee222eeb95dcn%40googlegroups.com.