Should 2.11 BSD Patch 493 be applied to PiDP11/70 installations?

[Richard McDonald]

In reading through Patch 493, I am very confused about if (and how) to rebuild the kernel for my PiDP11/70.

This patch refers to ... a system with a 8-line DHQ11 set to DHU11 mode ... as part of the reason for the patch.

I don't believe that my stock PiDP11/70 implements this series of cards.  So should I:

• Apply the patch and try to rebuild the kernel (need LOTS of HELP!);
• Apply the patch but don't try to rebuild the kernel; or
• Skip the patch altogether?

Cheers,

Rich

[terry-...@glaver.org]

All the DHx11 patch does is optionally allow the building of kernels with

support for 8-port multiplexors. Even after applying the patch, you'd need

to edit your kernel configuration file and re-build to get the new behavior. 

simh allows the creation of "impractical in real life" configurations (for

example, attaching Q-bus controllers to a Unibus system). In the real world,

this would require something like an Able QNIVERTER and a fair amount

of head-scratching. So it is theoretically possible to have an 11/70 with a
DHV11, either real or emulated, and in that situation you'd want to enable

the 8-port option. But normal Unibus DHx11 cards all provide 16 ports.

You want the patch for its various other fixes (be aware that 494 is needed

to fix some typos introduced in 493).

Most patches don't involve re-building the kernel. Those that do (like the

ones in the latest set of 4) contain instructions for re-building the kernel

(simple but time-consuming). For example, from 493:

cd /sys/YOURKERNEL
make
install -m 644 -o root -g wheel unix /
install -m 644 -o root -g wheel netnix /

You can find out your kernel's name with 'uname -n', like this:

# uname -n
spc11e

So in the above case, my kernel is called SPC11E.

Note that major configuration changes to the kernel may require edit-

ing a Makefile to change the assignment of features to overlays. But

almost all 2BSD patches don't do that on their own - it happens when

you "add" a new controller to your emulated 11/70.

There is a lingering issue that seems to have started in patch 490 that

breaks ARP handling (necessary for any TCP/IP operations) if the kernel

build directory is cleaned before you build the kernel. As long as you don't

clean the build directory, the problematic code in if_ether.c won't be re-

compiled. This and another ARP-related fix will likely appear relatively

soon.

[Steven A. Falco]

It is really a personal decision.

As you say, building a kernel might require some coaching, but it really shouldn't be too hard. My main advice would be to first shut down BSD, then make a copy of the disk image (in /opt/pidp11/systems/211bsd or perhaps 211bsd+) BEFORE APPLYING any patch. That way, if something goes wrong, you can easily recover and try again.

The problem with skipping patches is that they sometimes build on each other, meaning that you might run into trouble if a later patch requires an earlier one that you skipped.

I personally like to keep my machine current, but because of the recent problems with patch 490, I'm staying on 489 until that issue is sorted out.

Steve

On 8/17/25 02:03 PM, Richard McDonald wrote:
> In reading through Patch 493, I am very confused about if (and how) to rebuild the kernel for my PiDP11/70.
>

> This patch refers to *... a system with a 8-line DHQ11 set to DHU11 mode ...* as part of the reason for the patch.

>
> I don't believe that my stock PiDP11/70 implements this series of cards.  So should I:
>

> * Apply the patch and try to rebuild the kernel (need LOTS of HELP!);
> * Apply the patch but don't try to rebuild the kernel; or
> * Skip the patch altogether?
>
> Cheers,
> Rich
>
> --
> 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 visit https://groups.google.com/d/msgid/pidp-11/cd678a72-3909-4594-bcfa-3cbc88f0a233n%40googlegroups.com <https://groups.google.com/d/msgid/pidp-11/cd678a72-3909-4594-bcfa-3cbc88f0a233n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Malcolm Ray]

Are you sure you don't mean 'uname -v'? My hostname is 211bsd, but my kernel is PIDP11:

# uname -n

211bsd

# uname -v

2.11 BSD UNIX #15: Sun Aug 17 16:17:44 BST 2025 root@211bsd:/usr/src/sys/PIDP11

Of course, you might name your kernel configuration after your hostname, but that's not required.

[terry-...@glaver.org]

On Sunday, August 17, 2025 at 3:44:01 PM UTC-4 Sheepless wrote:

Are you sure you don't mean 'uname -v'? My hostname is 211bsd, but my kernel is PIDP11:

# uname -n

211bsd

# uname -v

2.11 BSD UNIX #15: Sun Aug 17 16:17:44 BST 2025 root@211bsd:/usr/src/sys/PIDP11

Of course, you might name your kernel configuration after your hostname, but that's not required.

You are correct - in trying to simplify the command (I initially used "uname -a" in the example before deciding it was too complex) I just latched onto a uname option that gave me a one-word answer, saw it worked on my system and mistakenly assumed it would be true everywhere.

[Johnny Billquist]

The DH device in simh is actually either a DHU, DHV or DHQ, and is
supported (it is *not* a DH11).

You don't need to rebuild the kernel unless you actually have such
terminal lines, though. But applying the patch as such is a good idea,
since if any later patches come along that affect the same files, they
might get into trouble if that patch have not been applied.

Johnny

On 2025-08-17 20:03, Richard McDonald wrote:
> In reading through Patch 493, I am very confused about if (and how) to
> rebuild the kernel for my PiDP11/70.
>

> This patch refers to *... a system with a 8-line DHQ11 set to DHU11
> mode ...* as part of the reason for the patch.

>
> I don't believe that my stock PiDP11/70 implements this series of
> cards.  So should I:
>

> * Apply the patch and try to rebuild the kernel (need LOTS of HELP!);
> * Apply the patch but don't try to rebuild the kernel; or
> * Skip the patch altogether?
>
> Cheers,
> Rich
>

> --
> 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 visit https://groups.google.com/d/msgid/pidp-11/
> cd678a72-3909-4594-bcfa-3cbc88f0a233n%40googlegroups.com <https://
> groups.google.com/d/msgid/pidp-11/cd678a72-3909-4594-
> bcfa-3cbc88f0a233n%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

[Johnny Billquist]

On 2025-08-17 20:56, terry-...@glaver.org wrote:
> All the DHx11 patch does is optionally allow the building of kernels with
> support for 8-port multiplexors. Even after applying the patch, you'd need
> to edit your kernel configuration file and re-build to get the new
> behavior.

4, 8 or 16 ports, depending on which controller we're talking about. :-)

> simh allows the creation of "impractical in real life" configurations (for
> example, attaching Q-bus controllers to a Unibus system). In the real world,
> this would require something like an Able QNIVERTER and a fair amount
> of head-scratching. So it is theoretically possible to have an 11/70 with a
> DHV11, either real or emulated, and in that situation you'd want to enable
> the 8-port option. But normal Unibus DHx11 cards all provide 16 ports.

I think you'll get into trouble if you try attaching a Qbus controller
to a Unibus machine. Unless simh is doing something very sneaky and not
matching the hardware, the Qbus controller expects to do DMA to 22-bit
addresses, while Unibus only have 18 address bits, and have a Unibus map
if you have a 22-bit address machine. That's why the Qniverter existed,
since you can't just connect the wires (even ignoring that Qbus
multiplex data and address on the same pins).

As for this specific topic, for the Unibus it's only the DHU-11. There
are no other controllers with that programming interface.
For the Qbus there is both the DHV-11 and DHQ-11, which use the same
programming interface.

> You want the patch for its various other fixes (be aware that 494 is needed
> to fix some typos introduced in 493).

Indeed.

> Most patches don't involve re-building the kernel. Those that do (like the
> ones in the latest set of 4) contain instructions for re-building the kernel
> (simple but time-consuming). For example, from 493:
>
> cd /sys/YOURKERNEL
> make
> install -m 644 -o root -g wheel unix /
> install -m 644 -o root -g wheel netnix /
>
> You can find out your kernel's name with 'uname -n', like this:
>
> # uname -n
> spc11e
>
> So in the above case, my kernel is called SPC11E.

The instructions for each patch do explain what needs to be rebuilt. But
when it comes to the kernel, if it affects some device driver, and you
don't even have that configured, then there is absolutely no need to
rebuilt anything.

And others already commented on the uname detail. :-)

> Note that major configuration changes to the kernel may require edit-
> ing a Makefile to change the assignment of features to overlays. But
> almost all 2BSD patches don't do that on their own - it happens when
> you "add" a new controller to your emulated 11/70.

If you change the actual 2.11BSD config file, then you need to run
config to generate a new makefile along with some other files. After
that you need to run make, which hopefully have the dependencies all
set, so things get rebuilt as needed (although I did get a report a
while ago that there might be some dependencies missing).

> There is a lingering issue that seems to have started in patch 490 that
> breaks ARP handling (necessary for any TCP/IP operations) if the kernel
> build directory is cleaned before you build the kernel. As long as you don't
> clean the build directory, the problematic code in if_ether.c won't be re-
> compiled. This and another ARP-related fix will likely appear relatively
> soon.

It is being looked into. But poking at the innards of pcc isn't the most
trivial thing. Hopefully soon fixed, though, yes.

Johnny

>
> On Sunday, August 17, 2025 at 2:03:56 PM UTC-4 ranc...@gmail.com wrote:
>
> In reading through Patch 493, I am very confused about if (and how)
> to rebuild the kernel for my PiDP11/70.
>

> This patch refers to *... a system with a 8-line DHQ11 set to DHU11
> mode ...* as part of the reason for the patch.

>
> I don't believe that my stock PiDP11/70 implements this series of
> cards.  So should I:
>

> * Apply the patch and try to rebuild the kernel (need LOTS of HELP!);
> * Apply the patch but don't try to rebuild the kernel; or
> * Skip the patch altogether?
>
> Cheers,
> Rich
>

> --
> 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 visit https://groups.google.com/d/msgid/

> pidp-11/4f3857f9-09f6-4816-9e86-044461c4f000n%40googlegroups.com
> <https://groups.google.com/d/msgid/
> pidp-11/4f3857f9-09f6-4816-9e86-044461c4f000n%40googlegroups.com?

[terry-...@glaver.org]

On Sunday, August 17, 2025 at 4:38:15 PM UTC-4 b...@softjar.se wrote:

The instructions for each patch do explain what needs to be rebuilt. But
when it comes to the kernel, if it affects some device driver, and you
don't even have that configured, then there is absolutely no need to
rebuilt anything. 

I agree about the rebuild not normally being needed. However, the patch

instructions don't always mention rebuilding the kernel (for example, they

are missing from 494, even though 494 fixes the kernel DZ driver).

I happen to have my own patch management system which records a bit

more detail. As Steve says, "It would be a good idea - if we'd started doing

it a long time ago".

Patch 482 applied Tue Apr  1 01:00:48 EDT 2025
Patch 483 applied Tue Apr  1 01:00:57 EDT 2025
Patch 484 applied Tue Apr  1 01:04:13 EDT 2025
Patch 485 applied Tue Apr  1 01:04:58 EDT 2025
Patch 486 applied Tue Apr  1 01:05:13 EDT 2025
Patch 487 applied Tue Apr  1 01:05:49 EDT 2025
Patch 488 applied Tue Apr  1 01:06:40 EDT 2025
Patch 489 applied Tue Apr  1 15:37:03 EDT 2025
Patch 490 applied Wed Apr 16 22:37:54 EDT 2025
Patch 491 applied Thu Aug 14 21:04:07 EDT 2025
Patch 492 applied Thu Aug 14 21:06:47 EDT 2025
Patch 493 applied Thu Aug 14 21:07:39 EDT 2025
Patch 494 applied Thu Aug 14 21:15:29 EDT 2025

> Note that major configuration changes to the kernel may require edit-
> ing a Makefile to change the assignment of features to overlays. But
> almost all 2BSD patches don't do that on their own - it happens when
> you "add" a new controller to your emulated 11/70.

If you change the actual 2.11BSD config file, then you need to run
config to generate a new makefile along with some other files. After
that you need to run make, which hopefully have the dependencies all
set, so things get rebuilt as needed (although I did get a report a
while ago that there might be some dependencies missing).

True. I was going on the assumption that it was an existing kernel that

just needed re-compilation of a few modified files. If making a new kernel,
the steps you provided are needed. Otherwise, just run make.

What I was referring to was the potential for some code to overflow its
overlay (which is quite unlikely unless an overlay is REALLY close to full).
The documentation says something like "move modules between over-

lays until you get a clean link, but don't move these specific modules..."

 

It is being looked into. But poking at the innards of pcc isn't the most
trivial thing. Hopefully soon fixed, though, yes. 

Someone posted an initial analysis where a register variable that uses

R2 is getting clobbered during hash lookups because the compiler is

generating code that uses R2 during shifts.

I'm not sure if wrapping the offending hash lookup with a PUSH/POP of

R2 would give a functioning kernel. It certainly isn't a 'fix' - the compiler

should keep track of register assignments and not clobber ones that have

user variables. This is likely to appear elsewhere in the future, so some-

with detailed knowledge of the C compiler should see what's causing it

to 'forget' that a register holds a user (or system, for that matter) variable.

[Johnny Billquist]

On 2025-08-17 23:52, terry-...@glaver.org wrote:
> On Sunday, August 17, 2025 at 4:38:15 PM UTC-4 b...@softjar.se wrote:
>
> The instructions for each patch do explain what needs to be rebuilt.
> But
> when it comes to the kernel, if it affects some device driver, and you
> don't even have that configured, then there is absolutely no need to
> rebuilt anything.
>
>
> I agree about the rebuild not normally being needed. However, the patch
> instructions don't always mention rebuilding the kernel (for example, they
> are missing from 494, even though 494 fixes the kernel DZ driver).

To be fair, 493 was the initial patching of dz, but it contained an
error, so the kernel could not be built. 494 fixes the error introduced
in 493, so it's basically an extension of 493 (and that is pointed out),
and 493 do contain the explanation on how to rebuild the kernel.

> I happen to have my own patch management system which records a bit
> more detail. As Steve says, "It would be a good idea - if we'd started doing
> it a long time ago".

:-)

> > Note that major configuration changes to the kernel may require
> edit-
> > ing a Makefile to change the assignment of features to overlays.But
> > almost all 2BSD patches don't do that on their own - it happens when
> > you "add" a new controller to your emulated 11/70.
>
> If you change the actual 2.11BSD config file, then you need to run
> config to generate a new makefile along with some other files. After
> that you need to run make, which hopefully have the dependencies all
> set, so things get rebuilt as needed (although I did get a report a
> while ago that there might be some dependencies missing).
>
>
> True. I was going on the assumption that it was an existing kernel that
> just needed re-compilation of a few modified files. If making a new kernel,
> the steps you provided are needed. Otherwise, just run make.

Well, you did say "major configuration changes to the kernel". :-)
But yes, we are in agreement.

> What I was referring to was the potential for some code to overflow its
> overlay (which is quite unlikely unless an overlay is REALLY close to full).
> The documentation says something like "move modules between over-
> lays until you get a clean link, but don't move these specific modules..."

Some day, we really should write a small document explaining how to
understand and move things around between the overlays. It's actually
pretty simple, but I've never seen any documentation going through it.

Historically, overlay 6 (I think it was) was almost always getting too
big. I think/hope things got changed around some and this now isn't
usually a problem. But moving almost anything around is not a problem.
You might possibly want to consider performance issues, and be careful
if passing pointers to functions in different overlays.

> It is being looked into. But poking at the innards of pcc isn't the
> most
> trivial thing. Hopefully soon fixed, though, yes.
>
>
> Someone posted an initial analysis where a register variable that uses
> R2 is getting clobbered during hash lookups because the compiler is
> generating code that uses R2 during shifts.
>
> I'm not sure if wrapping the offending hash lookup with a PUSH/POP of
> R2 would give a functioning kernel. It certainly isn't a 'fix' - the
> compiler
> should keep track of register assignments and not clobber ones that have
> user variables. This is likely to appear elsewhere in the future, so some-
> with detailed knowledge of the C compiler should see what's causing it
> to 'forget' that a register holds a user (or system, for that matter)
> variable.

Yeah. This needs to be fixed proper. And Ragge (not sure if most people
know who he is), is working on it. He did the ansification/C89 work on
pcc for 2.11BSD a couple of years ago. I'm happy to leave it primarily
up to him to figure this out. He was the one that did 490 as well.
Unfortunate that this problem wasn't spotted, but the changes were
needed because the compiler previously could generate broken code in
some other circumstances.

Johnny

[terry-...@glaver.org]

On Sunday, August 17, 2025 at 6:04:46 PM UTC-4 b...@softjar.se wrote:

On 2025-08-17 23:52, terry-...@glaver.org wrote:
> What I was referring to was the potential for some code to overflow its
> overlay (which is quite unlikely unless an overlay is REALLY close to full).
> The documentation says something like "move modules between over-
> lays until you get a clean link, but don't move these specific modules..."

Some day, we really should write a small document explaining how to
understand and move things around between the overlays. It's actually
pretty simple, but I've never seen any documentation going through it.

I though I saw a "just shuffle stuff until it fits" document recommending

looking at the sizes of the .o files to see if one could go in a different over-

lay. 

Historically, overlay 6 (I think it was) was almost always getting too
big. I think/hope things got changed around some and this now isn't
usually a problem. But moving almost anything around is not a problem.
You might possibly want to consider performance issues, and be careful
if passing pointers to functions in different overlays. 

It depends on what version of 'config'  wrote the Makefile. GENERIC has an

ID of  "2.14 (2.11BSD) 2001/8/3" while 'config SPC11E' produces a Makefile

with an ID of "2.10 (2.11BSD GTE) 1997/11/28". Odd.

Anyway, my SPC11E Makefile has a very misleading comment:
# OV6 gets the (hopefully) never used routines
OV6=    clock.o dn.o init_main.o kern_pdp.o machdep2.o subr_prf.o syscalls.o \
        subr_log.o vm_swp.o

Part of that would seem to be rather commonly used code. I have a weird
overlay structure for SPC11E as it is based on the Chase Covello sort-of-

482* kit which expects RA disks and TU tapes, but I'm moving it to RM05/
TU77 drives for more historical accuracy (the Unibus on an 11/70 is a last

resort for high-speed peripherals like a UDA50). So I put the xp driver in

base and demoted the [T]MSCP stuff to OV9, pending removal complete-

ly.

* The kit has patch 482 applied, but at least some of the post-patch in-

structions were not performed (like installing the new disktab). 

 

Yeah. This needs to be fixed proper. And Ragge (not sure if most people
know who he is), is working on it. He did the ansification/C89 work on
pcc for 2.11BSD a couple of years ago. I'm happy to leave it primarily
up to him to figure this out. He was the one that did 490 as well.
Unfortunate that this problem wasn't spotted, but the changes were
needed because the compiler previously could generate broken code in
some other circumstances. 

In that case, he deserves our thanks for past (and future) work.

Until CPUs developed an unmanageable number of registers (or

small windows into a larger number of registers) a common tech-

nique was for the compile to maintain a "scoreboard" of what reg-

isters are in use (sometimes with more info) and keep it updated 

as the compilation progresses. If that's what the 2BSD C compiler 

does, then some compiler routine apparently forgot to tell the 

scoreboard about the variable in R2. 

[Johnny Billquist]

On 2025-08-18 01:03, terry-...@glaver.org wrote:
> On Sunday, August 17, 2025 at 6:04:46 PM UTC-4 b...@softjar.se wrote:
>
> On 2025-08-17 23:52, terry-...@glaver.org wrote:
> > What I was referring to was the potential for some code to
> overflow its
> > overlay (which is quite unlikely unless an overlay is REALLY
> close to full).
> > The documentation says something like "move modules between over-
> > lays until you get a clean link, but don't move these specific
> modules..."
>
> Some day, we really should write a small document explaining how to
> understand and move things around between the overlays. It's actually
> pretty simple, but I've never seen any documentation going through it.
>
>
> I though I saw a "just shuffle stuff until it fits" document recommending
> looking at the sizes of the .o files to see if one could go in a
> different over-
> lay.

Of course, that can be done. But it's not a very good way of doing
things. When you get the error about an oversized overlay (heck, you can
check even when none is oversized), you should run size on unix.
Output will look something like this:

simh:/home/bqt> size /unix
text data bss dec hex
54976 6118 33768 94862 1728e total text: 114304
overlays: 7744,7488,8128,7296,2240,8064,4928,5696,7744

(of course, you should check unix in the current directory, and not the
one at root if compile fails).
There you see the size of each overlay, and each overlay can, for the
kernel, not be larger than 8K. So that way you see which overlays needs
something moved away.

And then you check the Makefile, where you have all these

OV1= sys_generic.o ufs_syscalls.o vfs_vnops.o
OV2= kern_acct.o kern_exec.o kern_exit.o kern_fork.o kern_resource.o
OV3= kern_time.o sys_process.o ufs_mount.o ufs_subr.o uipc_syscalls.o
OV4= dkbad.o kern_sig.o mem.o subr_xxx.o trap.o tty_pty.o tty_tty.o
OV5= quota_kern.o quota_ufs.o quota_sys.o ufs_bmap.o \
sys_pipe.o

(and a bunch more)

And then pick something reasonable from the oversized overlay and move
it somewhere else. There are plenty of overlays with lots of free space,
and a bunch that aren't even having a single byte in them. So that is
fairly simple. (You can use anything up to OV15.)

> Historically, overlay 6 (I think it was) was almost always getting too
> big. I think/hope things got changed around some and this now isn't
> usually a problem. But moving almost anything around is not a problem.
> You might possibly want to consider performance issues, and be careful
> if passing pointers to functions in different overlays.
>
>
> It depends on what version of 'config'  wrote the Makefile. GENERIC has an
> ID of  "2.14 (2.11BSD) 2001/8/3" while 'config SPC11E' produces a Makefile
> with an ID of "2.10 (2.11BSD GTE) 1997/11/28". Odd.

Maybe it's time we did some update/correction to config itself? :-)
The difference is because different bits of makefile gets picked up from
/sys/config depending on what kernel you configure.
So it's not any difference in config itself that cause this.

> Anyway, my SPC11E Makefile has a very misleading comment:
> # OV6 gets the (hopefully) never used routines
> OV6=    clock.o dn.o init_main.o kern_pdp.o machdep2.o subr_prf.o
> syscalls.o \
>         subr_log.o vm_swp.o
>
> Part of that would seem to be rather commonly used code. I have a weird
> overlay structure for SPC11E as it is based on the Chase Covello sort-of-
> 482* kit which expects RA disks and TU tapes, but I'm moving it to RM05/
> TU77 drives for more historical accuracy (the Unibus on an 11/70 is a last
> resort for high-speed peripherals like a UDA50). So I put the xp driverin
> base and demoted the [T]MSCP stuff to OV9, pending removal complete-
> ly.

Agreed. Comment is very misleading.
Moving things to base is fine, as long as it stays below 56K in size.
Parts of ufs, as well as parts of syscalls are also in overlays, so it's
difficult to tell what actually will generate a more efficient system.
Overlays aren't extremely costly anyway, as it's just a few instructions
to potentially change the MMU mapping, and then call.
And the one really nice things about overlays in 2.11BSD is that you can
freely call between any overlays, and also at return, the mapping is
adjusted as well, so in that sense it's way simpler than overlays in DEC
OSes.

[Richard McDonald]

Thanks Johnny, Terry, et. al. for explanations that are useful as well as informative.

I will take the middle ground of installing Patch 493 but not rebuilding my kernel.

Cheers,

Rich