Kernel Hacking...

[Digby R.S. Tarvin]

I gave the PDP11 BSD system a try for the first time a couple of days ago, and am really impressed with how usable it is for a 16 bit address space system.

However, I have this neat PiDP11 console to play with, and I noticed that the getsw() system call that was present in some of the earlier Bell Unix systems seems to be missing. 

getsw() just reads the current value of the switch register (ie front panel switch settings), which can be a fun was to control a program. I also rather wanted a way to make better use of the display register (displayed when the lower rotary switch is on 'DISPLAY REGISTER') which is currently always zero.

I was able to read the switch register without too much trouble using /dev/mem, but it has the disadvantage of requiring the user or program to have elevated privilege. 

I was also able to write to the display register using /dev/mem, but only in single user mode because /dev/mem is readonly at other times.

Anyway, as an interesting exercise in rebuilding the kernel, I added the two system calls that I wanted, and also while I was at it, did some other customizing as follows:

a. New getsw/setsr system calls for user land front panel access
b. Configured for PDP 11/70 instead of default 11/44
c. TIMEZONE changed from 480 to zero (PST to GMT)
d. LINEHZ changed from 60 to 50 (need 'set CLK 50HZ' in /opt/pidp11/systems/211bsd/boot.ini)
e. fixed a small bug in the panel display in mch_xxx.s and halved the update rate so I know which kernel I am running...

Some of those choices might not suit everyone, but 50HZ looks normal to me (I last used a PDP11/70 in Australia) and it just reduces the clock interrupts (and hence idle display update rate) by 20% and for some reason fixed a problem I was having with inaccurate timekeeping. The PST timezone meant having to add an inconvenient offset to the date command when setting that date. I think selecting the 11/70 processor sacrifices portability with earlier architectures for the ability to use the more efficient instructions for crossing address space boundaries. 

The idea was that when debugging or wanting some feedback from a program, I can write directly to the display register with a putdr(v) in my program and switch the console to show the display register. Likewise, when needing to make a decision (verbose logging, for example) I can read the switches and check a switch setting to make the decision. So basically an excuse to play with the front panel :)

Rebuilding the kernel was enlightening. The kernel overlay technique is clever, but a pain when you overflow and have to rearrange things. The kernel start to panic after a fairly innocuous change, and it continued to happen even after reversing the change. It turned out that the build number shown in the kernel identification string:

BSD pdp11 2.11 2.11 BSD UNIX #2: Fri Jun 21 04:20:07 BST 2019      root@pdp11:/usr/src/sys/DIGBYT  pdp11

had increased to 10, and the extra byte required to hold the extra digit had pushed me over the size limit...

The addition to machine/kern_pdp.c was:

digbyt[21] % diff kern_pdp.c.orig kern_pdp.c
27a28,47
>  * Provide user access to PDP11 front panel display and switch registers
>  */
> #define SW    ((short *)0177570)
>
> pdpgetsw()
> {
>       u.u_r.r_val1 = *SW;
> }
>
> pdpsetdr()
> {
>         register struct a {
>                 int     swval;
>         } *uap = (struct a *)u.u_ap;
>
>       *SW = uap->swval;
> }
>
> /*

I havn't bothered adding the new calls to the C library yet. They can be accessed with the following trivial piece of assembler:

        .globl  _getsw,_setdr

_getsw:

        sys     151.

        rts     pc

_setdr:

        sys     147.

        rts     pc

Where 147 and 151 were the last two unused system call entries.

I put the results on my web site here if anyone wants to try it:

http://skaro.afraid.org:4280/software/bsd211

If anyone wants to try building the kernel themselves, I can put the modified kernel source files and some instructions up as well. 

If anyone else has tinkered with the kernel, I would be interested to hear what you did.

Regards,

DigbyT

[Steve Haflich]

What's wrong with giving a custom (and arguably safe) kmem-reading program root permission with setuid/chmod?  One of the premises of Unix is that programs and humans are similar and should use similar techniques and be capable of similar abilities and permissions.  Rebuilding the kernel is a valuable exercise to prove you can do it when necessary, but it shouldn't be necessary for this case.

I'll speculate that this switch-reg-reading "program" could even be implemented as a privileged shell script that emits the 16-bit word either in binary or decimal to stdout.  Such a shell script would look something like

#!/bin/sh

dd if=/dev/kmem skip=0177570 bs=2 count=1

chown and chmod, and it's done.  (Pipe into od for ascii output.)  Not sure od understands octal.  A similar script could write its arg into the display reg (which I don't remember the 11/45 having).  Sorry, don't have an appropriate machine on which to test any of this.

[Digby R.S. Tarvin]

There are a couple of reasons that make it seem worth adding switch/display register access via a dedicated system call.

Using the memory device was my first thought, and the programs that do that are also on my web site (cons_mem.tar) . 

The main thing that is wrong with it is that writing to the display register only works in single user mode - the mem device is read-only when the system in security level 1, and even root can't write to it.  Changing that seemed an unjustiable reduction in system security.

The other reason why a system call is preferable is that providing access to the switch and display registers is pretty benign, even to normal users. But general access to the memory device requires a  very significant level of trust. Providing access via a privileged (suid) program might be ok for shell scripting, but it doesn't provide a low overhead diagnostic tool for general programming the way the system call does, and every suid program is a potential security hole.

Another consideration is that on the PiDP11, the front panel is a big part of the reason for running the 11/70 simulation, so convenient programmer access to it is rather desirable.

And finally, having had the system call included by Dennis Richie and Ken Thompson in the Bell version of Unix on PDP11 seemed enough of a precedent. I expect it was used for tools like the dsw program on version 6.

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/CALPcpNqcWsm2v3jPmKSH7mx2QdfOFEg11551sVh9Zq95cxJFSA%40mail.gmail.com.

[Johnny Billquist]

On 2019-06-21 17:49, Digby R.S. Tarvin wrote:
> I gave the PDP11 BSD system a try for the first time a couple of days
> ago, and am really impressed with how usable it is for a 16 bit address
> space system.

It is a fairly decent, modern (sortof) and nice BSD system, yes.

> However, I have this neat PiDP11 console to play with, and I noticed
> that the getsw() system call that was present in some of the earlier
> Bell Unix systems seems to be missing.

Right. No such thing around...

> I was able to read the switch register without too much trouble using
> /dev/mem, but it has the disadvantage of requiring the user or program
> to have elevated privilege.
>
> I was also able to write to the display register using /dev/mem, but
> only in single user mode because /dev/mem is readonly at other times.

That is, unless you change the security level to -1 before going multiuser.

> Anyway, as an interesting exercise in rebuilding the kernel, I added the
> two system calls that I wanted, and also while I was at it, did some
> other customizing as follows:
>
> a. New getsw/setsr system calls for user land front panel access

Fair enough. Another option would have been to create a device for it.
The problem with this is, of course, that you can have several programs
using the system call, since they will overwrite each others values.

> b. Configured for PDP 11/70 instead of default 11/44

What default? Are you talking about some system someone have prepared
for you before.

> c. TIMEZONE changed from 480 to zero (PST to GMT)

Everyone have their own preference, of course. But this is only relevant
at startup before the system is properly up and running, since after
that the time zone handling is done in a different way.

> d. LINEHZ changed from 60 to 50 (need 'set CLK 50HZ' in /opt/pidp11/systems/211bsd/boot.ini)

I usually prefer to run at 50 Hz, but that is also just an arbitrary
preference. As long as it matches between simh config and the kernel
config everything will be fine.

> e. fixed a small bug in the panel display in mch_xxx.s and halved the update rate so I know which kernel I am running...
>
> Some of those choices might not suit everyone, but 50HZ looks normal to me (I last used a PDP11/70 in Australia) and it just reduces the clock interrupts (and hence idle display update rate) by 20% and for some reason fixed a problem I was having with inaccurate timekeeping. The PST timezone meant having to add an inconvenient offset to the date command when setting that date.

Not sure what you mean by the update rate. I would not expect that to be
related to the simulated clock rate of the PDP-11.

> I think selecting the 11/70 processor sacrifices portability with earlier architectures for the ability to use the more efficient instructions for crossing address space boundaries.

Uh, that was a bit of a confusing statement. We are talking about
2.11BSD here. Any model that can run 2.11BSD is compatible enough that
it don't really make a difference. So pick whatever model. It will work
on the other models as well. There are no portability or compatibility
issues to talk about.

In comparing the 11/44 and 11/70, the 11/44 is actually a later
architecture, and it has some features and functionality the 11/70 lack,
while the 11/70 have some more capabilities in the MMU, which no
software ever used (which is why later models dropped them).

You can essentially divide PDP-11s into four groups. 16-bit addressing,
18-bit addressing and 22-bit addressing with either Unibus or Qbus.
Within each of these groups the models are very much compatible.
With the 22-bit addressing machines, there are a difference between
Unibus and Qbus, since all DMA on Unibus machines are still only using
18-bit addressing, so an additional layer of address translation is
needed, which is called the Unibus map. But most systems running on
22-bit machine dynamically decide if they have a Unibus map, or Qbus.
And 2.11BSD only runs on 22-bit machines.

> The idea was that when debugging or wanting some feedback from a program, I can write directly to the display register with a putdr(v) in my program and switch the console to show the display register. Likewise, when needing to make a decision (verbose logging, for example) I can read the switches and check a switch setting to make the decision. So basically an excuse to play with the front panel :)
>
> Rebuilding the kernel was enlightening. The kernel overlay technique is clever, but a pain when you overflow and have to rearrange things. The kernel start to panic after a fairly innocuous change, and it continued to happen even after reversing the change. It turned out that the build number shown in the kernel identification string:
>

> BSD pdp11 2.11 2.11 BSD UNIX*#2*: Fri Jun 21 04:20:07 BST 2019      root@pdp11:/usr/src/sys/DIGBYT  pdp11

>
> had increased to 10, and the extra byte required to hold the extra digit had pushed me over the size limit...

Oh joy... That was ugly. However, I would have expected that you should
have gotten an error at the link stage in this case.

> The addition to machine/kern_pdp.c was:
>
> digbyt[21] % diff kern_pdp.c.orig kern_pdp.c
> 27a28,47
>>  * Provide user access to PDP11 front panel display and switch registers
>>  */
>> #define SW    ((short *)0177570)
>>
>> pdpgetsw()
>> {
>>       u.u_r.r_val1 = *SW;
>> }
>>
>> pdpsetdr()
>> {
>>         register struct a {
>>                 int     swval;
>>         } *uap = (struct a *)u.u_ap;
>>
>>       *SW = uap->swval;
>> }
>>
>> /*

That could be cleaned up a little. Why the struct a thingy for example?
But otherwise, it's a simple enough extension...

> I havn't bothered adding the new calls to the C library yet. They can be accessed with the following trivial piece of assembler:

It would be very easy to add the system calls as well. All you need is
adding it to the Makefile.

> Where 147 and 151 were the last two unused system call entries.

Any particular reason why you picked those two ones then? There are
other, earlier numbers also unused, not to mention everything above 155.

> If anyone else has tinkered with the kernel, I would be interested to hear what you did.

Phew. Bug fixes, device driver changes, boot changes... I can't
remember. Various things.

Johnny

--
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 2019-06-21 19:14, Steve Haflich wrote:
> What's wrong with giving a custom (and arguably safe) kmem-reading
> program root permission with setuid/chmod?  One of the premises of Unix
> is that programs and humans are similar and should use similar
> techniques and be capable of similar abilities and permissions.
> Rebuilding the kernel is a valuable exercise to prove you can do it when
> necessary, but it shouldn't be necessary for this case.

Would work for reading, but might not be entirely satisfying for
writing, as you would be prevented from that unless the system was
booted insecure.

> I'll speculate that this switch-reg-reading "program" could even be
> implemented as a privileged shell script that emits the 16-bit word
> either in binary or decimal to stdout.  Such a shell script would look
> something like
>
> #!/bin/sh
> dd if=/dev/kmem skip=0177570 bs=2 count=1
>
> chown and chmod, and it's done.  (Pipe into od for ascii output.)  Not
> sure od understands octal.  A similar script could write its arg into
> the display reg (which I don't remember the 11/45 having).  Sorry, don't
> have an appropriate machine on which to test any of this.

Basically such a shellscript should definitely work.

And you do know what the 'o' in od stands for, right? :-)
But od will be getting binary input. But then again, the tool is about
displaying binary input in various output representations. So it don't
"understand" any input at all. It just reads whatever and then do
transformations on it for output.

[Digby R.S. Tarvin]

Hi,

On Fri, 21 Jun 2019 at 20:52, Johnny Billquist <b...@softjar.se> wrote:

 

> I was able to read the switch register without too much trouble using
> /dev/mem, but it has the disadvantage of requiring the user or program
> to have elevated privilege.
>
> I was also able to write to the display register using /dev/mem, but
> only in single user mode because /dev/mem is readonly at other times.

That is, unless you change the security level to -1 before going multiuser.

Ah, is that how you do that? Would have been handy to know to simplify experimentation,

but as a long term solution I think it is better not to have to run insecure.

 

> Anyway, as an interesting exercise in rebuilding the kernel, I added the
> two system calls that I wanted, and also while I was at it, did some
> other customizing as follows:
>
> a. New getsw/setsr system calls for user land front panel access

Fair enough. Another option would have been to create a device for it.
The problem with this is, of course, that you can have several programs
using the system call, since they will overwrite each others values.

A driver based solution would have had the virtue of allowing access to be regulated using file permissions,

and, as you say, making it possible to provide exclusive access if desired.

I probably would have done that except for there having been a precedent for implementing it as a system call,

there is only ever one instance of a front panel, and I don't really mind if competing processes over-write each other, and I think

the driver would have been a little more complicated to implement.

I don't think there is any need to regulate access to the switches, but if it was a real system and I wanted to use

the switch register for something other than experimenting, it should probably test and reject requests with non-zero euid.

But if I want to able to use it during development and testing, I don't want to do that with elevated privilege.

Its trivial to add if anyone wants it.. 

Other possible additions would be a way to and/or values into the display register. The hardware is write only, so it

would be necessary to maintain an image in the kernel to make that work. It would allow different processes to be

allocated different subsets of bits. For now it I was happy to keep it simple.

 

> b. Configured for PDP 11/70 instead of default 11/44

What default? Are you talking about some system someone have prepared
for you before.

Sorry - by 'default' I meant the sys/conf/ZEKE configuration from which the 'out of the box' kernel was built.

 

> c. TIMEZONE changed from 480 to zero (PST to GMT)

Everyone have their own preference, of course. But this is only relevant
at startup before the system is properly up and running, since after
that the time zone handling is done in a different way.

That's what I would have though - but it seemed to effect the operation of /bin/date, such that on the original system I had to subtract 8 hours

from the time I wanted in order to set the system date (or alternatively leave the system using a PST timezone file).

I don't recall that problem with BSD 4.4, so just assumed it was a 2.11 thing..

If anyone knows if this behavior is normal for 2.11 I would be interested to know.

 

> d. LINEHZ changed from 60 to 50 (need 'set CLK 50HZ' in /opt/pidp11/systems/211bsd/boot.ini)

I usually prefer to run at 50 Hz, but that is also just an arbitrary
preference. As long as it matches between simh config and the kernel
config everything will be fine.

It seemed to fix a clock problem I had, but I havn't gone back to 60HZ to see if I can reproduce the original issues, so it might

just have been coincidence (when I first set up the system, I noticed the clock stopped ticking after a couple of days, and after

re-booting, ran very slowly. The change to 50HZ was an experiment to see if it made a difference, and for some reason I had

no further problems after that).

 

> e. fixed a small bug in the panel display in mch_xxx.s and halved the update rate so I know which kernel I am running...
>
> Some of those choices might not suit everyone, but 50HZ looks normal to me (I last used a PDP11/70 in Australia) and it just reduces the clock interrupts (and hence idle display update rate) by 20% and for some reason fixed a problem I was having with inaccurate timekeeping. The PST timezone meant having to add an inconvenient offset to the date command when setting that date.

Not sure what you mean by the update rate. I would not expect that to be
related to the simulated clock rate of the PDP-11.

The rotating pattern on the 'Data Paths' display is implemented by updating the pattern variable and loading it into R0 immediately before the WAIT instruction on an idle system,  repeats on each clock interrupt until a process becomes schedulable. The WAIT instruction apparently leaves the value in the R0 register displayed. This is the code:

INT(LOCAL, rdisply, 0377)               / idle pattern

INT(LOCAL, wcount, 2)                   / rotate rdisply every wcount calls

ENTRY(idle)

        mov     PS,-(sp)                / save current SPL, indicate that no

        mov     $1,_noproc              /   process is running

        dec     wcount                  / if (--wcount <= 0) {

        bgt     1f

        mov     $2,wcount               /   wcount = 2

        clc                             /   rdisply <<= 1

        rol     rdisply

        bpl     1f                      /   if (``one shifted out'')

        bis     $1,rdisply              /     rdisply |= 1

1:                                      / }

        mov     rdisply,r0              / wait displays contents of r0

        SPLLOW                          / set SPL low so we can be interrupted

        wait                            / wait for something to happen

        mov     (sp)+,PS                / restore previous SPL

        rts     pc                      /   and return

I couldn't find that WAIT side effect documented in the processor handbook, but I have read that explanation somewhere, and I'm not sure how else that code would work.

I would do some experiments to confirm if that is the case, but there didn't seem much point as all it would prove is what the emulator does, not real hardware.

> I think selecting the 11/70 processor sacrifices portability with earlier architectures for the ability to use the more efficient instructions for crossing address space boundaries.

Uh, that was a bit of a confusing statement. We are talking about
2.11BSD here. Any model that can run 2.11BSD is compatible enough that
it don't really make a difference. So pick whatever model. It will work
on the other models as well. There are no portability or compatibility
issues to talk about.

In comparing the 11/44 and 11/70, the 11/44 is actually a later
architecture, and it has some features and functionality the 11/70 lack,
while the 11/70 have some more capabilities in the MMU, which no
software ever used (which is why later models dropped them).

You can essentially divide PDP-11s into four groups. 16-bit addressing,
18-bit addressing and 22-bit addressing with either Unibus or Qbus.
Within each of these groups the models are very much compatible.
With the 22-bit addressing machines, there are a difference between
Unibus and Qbus, since all DMA on Unibus machines are still only using
18-bit addressing, so an additional layer of address translation is
needed, which is called the Unibus map. But most systems running on
22-bit machine dynamically decide if they have a Unibus map, or Qbus.
And 2.11BSD only runs on 22-bit machines.

Thanks. I was going by the comments in the source as follows:

# PDP-11 machine type; allowable values are GENERIC, 44, 70, 73.  GENERIC

# should only be used to build a distribution kernel.  The only use of this

# option is to select the proper in-line PS instructions (references to the

# PSW use 'spl', 'mfps/mtps' or 'movb' instructions depending on the cpu type).

#PDP11          GENERIC                 # distribution kernel

PDP11           44                      # PDP-11/44

#PDP11          70                      # PDP-11/70,45,50,55

#PDP11          73                      # PDP-11/73,53,83,93,84,94

The setting in the PiDP distribution came set for a 44, as shown above. I should probably change it to GENERIC if I wanted to make my

binary generally available. 

I have read through the code to verify exactly what differences the choice makes. 

> The idea was that when debugging or wanting some feedback from a program, I can write directly to the display register with a putdr(v) in my program and switch the console to show the display register. Likewise, when needing to make a decision (verbose logging, for example) I can read the switches and check a switch setting to make the decision. So basically an excuse to play with the front panel :)
>
> Rebuilding the kernel was enlightening. The kernel overlay technique is clever, but a pain when you overflow and have to rearrange things. The kernel start to panic after a fairly innocuous change, and it continued to happen even after reversing the change. It turned out that the build number shown in the kernel identification string:
>
> BSD pdp11 2.11 2.11 BSD UNIX*#2*: Fri Jun 21 04:20:07 BST 2019      root@pdp11:/usr/src/sys/DIGBYT  pdp11
>
> had increased to 10, and the extra byte required to hold the extra digit had pushed me over the size limit...

Oh joy... That was ugly. However, I would have expected that you should
have gotten an error at the link stage in this case.

I did sometimes get a linker error - for example immediately after running configure to generate the build directory from the config file,

because the generated Makefile needs to have the overlay distribution re-organized. Small overflows don't seem to be reliably detected

though - I just got a Panic in the networking code, which had me tearing my hair out for a little while...

 

> The addition to machine/kern_pdp.c was:
>
> digbyt[21] % diff kern_pdp.c.orig kern_pdp.c
> 27a28,47
>>  * Provide user access to PDP11 front panel display and switch registers
>>  */
>> #define SW    ((short *)0177570)
>>
>> pdpgetsw()
>> {
>>       u.u_r.r_val1 = *SW;
>> }
>>
>> pdpsetdr()
>> {
>>         register struct a {
>>                 int     swval;
>>         } *uap = (struct a *)u.u_ap;
>>
>>       *SW = uap->swval;
>> }
>>
>> /*

That could be cleaned up a little. Why the struct a thingy for example?
But otherwise, it's a simple enough extension...

I picked an existing comparable function (such as setuid). That 'struct a' organization seems to followed universally

in the existing source - I suppose for consistency, because it makes more sense for system calls with multiple arguments.

So I decided to stick with existing practice.

 

> I havn't bothered adding the new calls to the C library yet. They can be accessed with the following trivial piece of assembler:

It would be very easy to add the system calls as well. All you need is
adding it to the Makefile.

You mean the makefile in /usr/src/lib/libc/pdp/sys? I think you are right, but the Makefile is very 'clever' and generates the source

for the various system calls on the fly (just from the syscall name and a bunch of macros in SYS.h) and pipes it through the preprocessor

and assembler.  I didn't want to mess with it till I had time to understand it fully. And making a new libc would make it harder for anyone

else to reproduce my system - unless I wanted to make a complete alternate distribution. 

 

> Where 147 and 151 were the last two unused system call entries.

Any particular reason why you picked those two ones then? There are
other, earlier numbers also unused, not to mention everything above 155.

 

Call numbers 151-180 are reserved for 'vendor specific' system calls, so first attempt was

to use the next free above 155, but that tripped over the same paging induced overflow panic,

so it seemed easier to recyle currently unused but existing entries.

Of the syscall numbers for which space was already allocated, 151 was the only one that

was free - ie

        0, nosys,                       /* 151 = unused */

So I used that, then went back and found the next highest unused number which was 147.

It was a fairly arbitrary choice (apart from deciding not to allocate new entries - that was a pragmatic choice).

Let me know if there is a better way to select syscall numbers to use.

> If anyone else has tinkered with the kernel, I would be interested to hear what you did.

Phew. Bug fixes, device driver changes, boot changes... I can't
remember. Various things.

Sounds as though you have a lot more experience than I do. I had tinkered with BSD/OS many years ago, but this was my first

hack at BSD211 or Unix in general on a PDP11/70.

Regards,

DigbyT

[Johnny Billquist]

Hi.

On 2019-06-22 00:14, Digby R.S. Tarvin wrote:
> Hi,
> On Fri, 21 Jun 2019 at 20:52, Johnny Billquist <b...@softjar.se
> <mailto:b...@softjar.se>> wrote:
>
> > I was able to read the switch register without too much trouble
> using
> > /dev/mem, but it has the disadvantage of requiring the user or
> program
> > to have elevated privilege.
> >
> > I was also able to write to the display register using /dev/mem, but
> > only in single user mode because /dev/mem is readonly at other times.
>
> That is, unless you change the security level to -1 before going
> multiuser.
>
>
> Ah, is that how you do that? Would have been handy to know to simplify
> experimentation,
> but as a long term solution I think it is better not to have to run
> insecure.

It was introduced/fixed only in patch #450. So if you're not totally up
to date, it's not possible to do that way. Earlier, you had to recompile
the kernel (or if it was init) in order to be able to keep insecure when
going multiuser.

Path #450 is the last/latest patch for 2.11BSD.

> > b. Configured for PDP 11/70 instead of default 11/44
>
> What default? Are you talking about some system someone have prepared
> for you before.
>
>
> Sorry - by 'default' I meant the sys/conf/ZEKE configuration from which
> the 'out of the box' kernel was built.

Oho. That is not a configuration I have on my system, so it's something
that have been provided/made by someone down the line.

> > c. TIMEZONE changed from 480 to zero (PST to GMT)
>
> Everyone have their own preference, of course. But this is only
> relevant
> at startup before the system is properly up and running, since after
> that the time zone handling is done in a different way.
>
>
> That's what I would have though - but it seemed to effect the operation
> of /bin/date, such that on the original system I had to subtract 8 hours
> from the time I wanted in order to set the system date (or alternatively
> leave the system using a PST timezone file).
>
> I don't recall that problem with BSD 4.4, so just assumed it was a 2.11
> thing..
>
> If anyone knows if this behavior is normal for 2.11 I would be
> interested to know.

Local time is usually handled by /etc/localtime, which normally would be
a symbolic link to /usr/share/zoneinfo/<whatever>. In my case, I point
it at /usr/share/zoneinfo/CET .

This is not unique to 2.11BSD. Pretty much all Unix systems does it this
way. I think even Linux does it the same. Anyway, any kernel defined
offsets would commonly only be used to manage an offset to some time
stored in an RTC, but it might also be applied if no /etc/localtime exists.

> > d. LINEHZ changed from 60 to 50 (need 'set CLK 50HZ' in
> /opt/pidp11/systems/211bsd/boot.ini)
>
> I usually prefer to run at 50 Hz, but that is also just an arbitrary
> preference. As long as it matches between simh config and the kernel
> config everything will be fine.
>
>
> It seemed to fix a clock problem I had, but I havn't gone back to 60HZ
> to see if I can reproduce the original issues, so it might
> just have been coincidence (when I first set up the system, I noticed
> the clock stopped ticking after a couple of days, and after
> re-booting, ran very slowly. The change to 50HZ was an experiment to see
> if it made a difference, and for some reason I had
> no further problems after that).

Sounds weird if you observed some problem which really was related to
this. The only things happening based on this would be how fast the
clock on the emulated PDP-11 OS is running. If simh is set to 60 Hz, and
the PDP-11 OS set to 50 Hz, time will run too fast. If simh is set to 50
Hz and the PDP-11 OS to 60 Hz, time will run slow. If both agree, time
will run right, and all the difference will be how long a clock tick is.

Nothing else knows or cares about this.

> > e. fixed a small bug in the panel display in mch_xxx.s and halved
> the update rate so I know which kernel I am running...
> >
> > Some of those choices might not suit everyone, but 50HZ looks
> normal to me (I last used a PDP11/70 in Australia) and it just
> reduces the clock interrupts (and hence idle display update rate) by
> 20% and for some reason fixed a problem I was having with inaccurate
> timekeeping. The PST timezone meant having to add an inconvenient
> offset to the date command when setting that date.
>
> Not sure what you mean by the update rate. I would not expect that
> to be
> related to the simulated clock rate of the PDP-11.
>
>
> The rotating pattern on the 'Data Paths' display is implemented by
> updating the pattern variable and loading it into R0 immediately before
> the WAIT instruction on an idle system,  repeats on each clock interrupt
> until a process becomes schedulable. The WAIT instruction apparently
> leaves the value in the R0 register displayed. This is the code:

[...]

Yes, the behavior of the WAIT instruction is documented, but I can't
properly remember where right now.

Anyway, the rotation of the pattern isn't done at every clock tick, or
it would all just be a dim pattern. But the speed of the rotation might
be different depending on the clock, if the OS just use a fixed value
independent of the clock frequency. Can't remember if that is the case
in 2.11BSD, but your code snipped would suggest that it indeed is a
hardcoded value causing the rotation speed to differ depending on the
clock frequency.

By the way, the WAIT is just putting R0 on the data bus. Which is why
you need to have the display selector set to that, and not the display
register.

> > I think selecting the 11/70 processor sacrifices portability with
> earlier architectures for the ability to use the more efficient
> instructions for crossing address space boundaries.
>
> Uh, that was a bit of a confusing statement. We are talking about
> 2.11BSD here. Any model that can run 2.11BSD is compatible enough that
> it don't really make a difference. So pick whatever model. It will work
> on the other models as well. There are no portability or compatibility
> issues to talk about.
>
> In comparing the 11/44 and 11/70, the 11/44 is actually a later
> architecture, and it has some features and functionality the 11/70
> lack,
> while the 11/70 have some more capabilities in the MMU, which no
> software ever used (which is why later models dropped them).
>
> You can essentially divide PDP-11s into four groups. 16-bit addressing,
> 18-bit addressing and 22-bit addressing with either Unibus or Qbus.
> Within each of these groups the models are very much compatible.
> With the 22-bit addressing machines, there are a difference between
> Unibus and Qbus, since all DMA on Unibus machines are still only using
> 18-bit addressing, so an additional layer of address translation is
> needed, which is called the Unibus map. But most systems running on
> 22-bit machine dynamically decide if they have a Unibus map, or Qbus.
> And 2.11BSD only runs on 22-bit machines.
>
>
> Thanks. I was going by the comments in the source as follows:

Right. There are a couple of more differences between the models, but
they are all 22-bit machines. But rotational light don't make sense on
an 11/44 for example. And, as mentioned, there are some different
possibilities in dealing with the PSW depending on model. But that
becomes a question of some possible optimizations. You can build the
generic kernel which works on them all.

And the 11/44 is newer than the 11/70. The numbering scheme don't really
give any hints to the relative age of the different models.

> The setting in the PiDP distribution came set for a 44, as shown above.
> I should probably change it to GENERIC if I wanted to make my
> binary generally available.

Right. GENERIC would be the proper choice if you want it to work on all
models without any fuzz. Makes no sense to do a PiDP-11 selecting the
11/44 model, since the 11/44 have a more or less non-existing front
panel. No fun at all. By then, DEC had moved to a serial console which
could control all aspects of the CPU.

> > I havn't bothered adding the new calls to the C library yet. They
> can be accessed with the following trivial piece of assembler:
>
> It would be very easy to add the system calls as well. All you need is
> adding it to the Makefile.
>
>
> You mean the makefile in /usr/src/lib/libc/pdp/sys? I think you are
> right, but the Makefile is very 'clever' and generates the source
> for the various system calls on the fly (just from the syscall name and
> a bunch of macros in SYS.h) and pipes it through the preprocessor
> and assembler.  I didn't want to mess with it till I had time to
> understand it fully. And making a new libc would make it harder for anyone
> else to reproduce my system - unless I wanted to make a complete
> alternate distribution.

Right. The makefile is rather clever, and you really only have to add
the "file" to the makefile to make it all add up. Of course, you could
also add a "prototype" of the function to some header file, but this is
all pre ANSI-C anyhow, so not much of function prototypes anyway.

> > If anyone else has tinkered with the kernel, I would be
> interested to hear what you did.
>
> Phew. Bug fixes, device driver changes, boot changes... I can't
> remember. Various things.
>
>
> Sounds as though you have a lot more experience than I do. I had
> tinkered with BSD/OS many years ago, but this was my first
> hack at BSD211 or Unix in general on a PDP11/70.

Possibly. But I think it's a good exercise to give into the 2.11BSD
kernel, so all kudos to you for doing just that.

Nice to see.

[Johnny Billquist]

One more thing...

On 2019-06-22 00:38, Johnny Billquist wrote:
> Hi.
>
> On 2019-06-22 00:14, Digby R.S. Tarvin wrote:
>>      > c. TIMEZONE changed from 480 to zero (PST to GMT)
>>
>>     Everyone have their own preference, of course. But this is only
>>     relevant
>>     at startup before the system is properly up and running, since after
>>     that the time zone handling is done in a different way.
>>
>>
>> That's what I would have though - but it seemed to effect the
>> operation of /bin/date, such that on the original system I had to
>> subtract 8 hours
>> from the time I wanted in order to set the system date (or
>> alternatively leave the system using a PST timezone file).
>>
>> I don't recall that problem with BSD 4.4, so just assumed it was a
>> 2.11 thing..
>>
>> If anyone knows if this behavior is normal for 2.11 I would be
>> interested to know.
>
> Local time is usually handled by /etc/localtime, which normally would be
> a symbolic link to /usr/share/zoneinfo/<whatever>. In my case, I point
> it at /usr/share/zoneinfo/CET .
>
> This is not unique to 2.11BSD. Pretty much all Unix systems does it this
> way. I think even Linux does it the same. Anyway, any kernel defined
> offsets would commonly only be used to manage an offset to some time
> stored in an RTC, but it might also be applied if no /etc/localtime exists.

By the way, this is all documented in ctime(3). If you read there you'll
find that if the TZ environment variable isn't set, and /etc/localtime
does not exist, the system will try to make use of the value compiled
into the kernel. Which probably matches what you have been observing.

And reading that man-page on for example OSX, you'll find that it works
the same way, but goes through one additional step, which is a function
called tzset(), which programs are supposed to call before calling other
time functions, which does the whole file processing work.

I suspect tzset() is implicitly called if you haven't called it before
other time functions though, so it ends up behaving exactly the same.

And the TZ variable can points to other files, if you want a different
time zone than the system have globally.

[Digby R.S. Tarvin]

Hi again,

On Fri, 21 Jun 2019 at 23:38, Johnny Billquist <b...@softjar.se> wrote:

>
>     That is, unless you change the security level to -1 before going
>     multiuser.
>
>
> Ah, is that how you do that? Would have been handy to know to simplify
> experimentation,
> but as a long term solution I think it is better not to have to run
> insecure.

It was introduced/fixed only in patch #450. So if you're not totally up
to date, it's not possible to do that way. Earlier, you had to recompile
the kernel (or if it was init) in order to be able to keep insecure when
going multiuser.

Path #450 is the last/latest patch for 2.11BSD.

Is there an easy way to check what my patch level is? And is there an official site for

patches and the latest distributions?

 

>      > b. Configured for PDP 11/70 instead of default 11/44
>
>     What default? Are you talking about some system someone have prepared
>     for you before.
>
>
> Sorry - by 'default' I meant the sys/conf/ZEKE configuration from which
> the 'out of the box' kernel was built.

Oho. That is not a configuration I have on my system, so it's something
that have been provided/made by someone down the line

 I'm not sure of its history. It is just what came with the 

PiDP image.

 

>      > c. TIMEZONE changed from 480 to zero (PST to GMT)
>
>     Everyone have their own preference, of course. But this is only
>     relevant
>     at startup before the system is properly up and running, since after
>     that the time zone handling is done in a different way.
>
>
> That's what I would have though - but it seemed to effect the operation
> of /bin/date, such that on the original system I had to subtract 8 hours
> from the time I wanted in order to set the system date (or alternatively
> leave the system using a PST timezone file).
>
> I don't recall that problem with BSD 4.4, so just assumed it was a 2.11
> thing..
>
> If anyone knows if this behavior is normal for 2.11 I would be
> interested to know.

Local time is usually handled by /etc/localtime, which normally would be
a symbolic link to /usr/share/zoneinfo/<whatever>. In my case, I point
it at /usr/share/zoneinfo/CET .

This is not unique to 2.11BSD. Pretty much all Unix systems does it this
way. I think even Linux does it the same. Anyway, any kernel defined
offsets would commonly only be used to manage an offset to some time
stored in an RTC, but it might also be applied if no /etc/localtime exists.

I think the was a kernel timezone in BSD/OS, but my understanding was 

that it was mainly to define how the battery backed hardware clock was to be

interpreted. Usually GMT for dedicated machines, but when dual booting with 

an OS that assumed local time, it allowed them to share.

My BSD 211 came with a PST timezone file /etc. I replaced that with

a symlink to what is appropriate for me (BST) and I think that is

where I started seeing a problem. It seemed that the user land timezone

file was used for display but the compiled in offset was used when setting

the time. Seems odd as it means that changing the symlinked timezone file

in etc implies the need to rebuild the kernel.

 

>      > d. LINEHZ changed from 60 to 50 (need 'set CLK 50HZ' in
>     /opt/pidp11/systems/211bsd/boot.ini)
>
>     I usually prefer to run at 50 Hz, but that is also just an arbitrary
>     preference. As long as it matches between simh config and the kernel
>     config everything will be fine.
>
>
> It seemed to fix a clock problem I had, but I havn't gone back to 60HZ
> to see if I can reproduce the original issues, so it might
> just have been coincidence (when I first set up the system, I noticed
> the clock stopped ticking after a couple of days, and after
> re-booting, ran very slowly. The change to 50HZ was an experiment to see
> if it made a difference, and for some reason I had
> no further problems after that).

Sounds weird if you observed some problem which really was related to
this. The only things happening based on this would be how fast the
clock on the emulated PDP-11 OS is running. If simh is set to 60 Hz, and
the PDP-11 OS set to 50 Hz, time will run too fast. If simh is set to 50
Hz and the PDP-11 OS to 60 Hz, time will run slow. If both agree, time
will run right, and all the difference will be how long a clock tick is.

Nothing else knows or cares about this.

Yeah - a bit of a mystery which will be hard to investigate unless it 

comes back. 

> The rotating pattern on the 'Data Paths' display is implemented by
> updating the pattern variable and loading it into R0 immediately before
> the WAIT instruction on an idle system,  repeats on each clock interrupt
> until a process becomes schedulable. The WAIT instruction apparently
> leaves the value in the R0 register displayed. This is the code:

[...]

Yes, the behavior of the WAIT instruction is documented, but I can't
properly remember where right now.

Anyway, the rotation of the pattern isn't done at every clock tick, or
it would all just be a dim pattern. But the speed of the rotation might
be different depending on the clock, if the OS just use a fixed value
independent of the clock frequency. Can't remember if that is the case
in 2.11BSD, but your code snipped would suggest that it indeed is a
hardcoded value causing the rotation speed to differ depending on the
clock frequency.

That code fragment included  the counter which caused the update to

occur on every second WAIT instruction. That would be a complete rotation

every 16/25 seconds, which seems about right

By the way, the WAIT is just putting R0 on the data bus. Which is why
you need to have the display selector set to that, and not the display
register.

That makes sense.

 

[C library]

>     It would be very easy to add the system calls as well. All you need is
>     adding it to the Makefile.
>
>
> You mean the makefile in /usr/src/lib/libc/pdp/sys? I think you are
> right, but the Makefile is very 'clever' and generates the source
> for the various system calls on the fly (just from the syscall name and
> a bunch of macros in SYS.h) and pipes it through the preprocessor
> and assembler.  I didn't want to mess with it till I had time to
> understand it fully. And making a new libc would make it harder for anyone
> else to reproduce my system - unless I wanted to make a complete
> alternate distribution.

Right. The makefile is rather clever, and you really only have to add
the "file" to the makefile to make it all add up. Of course, you could
also add a "prototype" of the function to some header file, but this is
all pre ANSI-C anyhow, so not much of function prototypes anyway.

The lack of ANSI function parameters define syntax seems like the 

most common issue when porting modern source back to 211.

 

>      > If anyone else has tinkered with the kernel, I would be
>     interested to hear what you did.
>
>     Phew. Bug fixes, device driver changes, boot changes... I can't
>     remember. Various things.
>
>
> Sounds as though you have a lot more experience than I do. I had
> tinkered with BSD/OS many years ago, but this was my first
> hack at BSD211 or Unix in general on a PDP11/70.

Possibly. But I think it's a good exercise to give into the 2.11BSD
kernel, so all kudos to you for doing just that.

Nice to see.

Thanks. The kernel build seems much more elegant than the linux approach.  

One other question springs to mind while I am talking to someone with a bit

more knowledge of this system - do you know what the '/netnix' file does?

I see it is built along with the '/unix' file when making the kernel, but I don't recall

anything similar on other BSD systems I have used.

Regards,

Digby

[Johnny Billquist]

Hi.

On 2019-06-22 03:07, Digby R.S. Tarvin wrote:
> Hi again,
>
> On Fri, 21 Jun 2019 at 23:38, Johnny Billquist <b...@softjar.se
> <mailto:b...@softjar.se>> wrote:
>
> >
> >     That is, unless you change the security level to -1 before going
> >     multiuser.
> >
> >
> > Ah, is that how you do that? Would have been handy to know to
> simplify
> > experimentation,
> > but as a long term solution I think it is better not to have to run
> > insecure.
>
> It was introduced/fixed only in patch #450. So if you're not totally up
> to date, it's not possible to do that way. Earlier, you had to
> recompile
> the kernel (or if it was init) in order to be able to keep insecure
> when
> going multiuser.
>
> Path #450 is the last/latest patch for 2.11BSD.
>
>
> Is there an easy way to check what my patch level is? And is there an
> official site for
> patches and the latest distributions?

You should have a /VERSION file, which tells.

There are several official sites.

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/pub/2.11BSD

And I was misremembering. The fix for the securelevel was patch 451,
which is the latest.

Hmm. I have never actually looked at this in detail before. You are
right. date does not use /etc/localtime when setting the time. Instead
it actually pulls out what the kernel configured time difference is.
However, date can actually also change the kernel configured time
difference, so you do not actually need to rebuild the kernel.
-d and -t are the two flags relevant here.

But I think date is broken. It really should use information from
/etc/localtime when possible. But it will require some rewriting for
that to work right. Bletch. I'll bring it up with Steven, and see what
he thinks.

> > The rotating pattern on the 'Data Paths' display is implemented by
> > updating the pattern variable and loading it into R0 immediately
> before
> > the WAIT instruction on an idle system,  repeats on each clock
> interrupt
> > until a process becomes schedulable. The WAIT instruction apparently
> > leaves the value in the R0 register displayed. This is the code:
>
> [...]
>
> Yes, the behavior of the WAIT instruction is documented, but I can't
> properly remember where right now.
>
> Anyway, the rotation of the pattern isn't done at every clock tick, or
> it would all just be a dim pattern. But the speed of the rotation might
> be different depending on the clock, if the OS just use a fixed value
> independent of the clock frequency. Can't remember if that is the case
> in 2.11BSD, but your code snipped would suggest that it indeed is a
> hardcoded value causing the rotation speed to differ depending on the
> clock frequency.
>
>
> That code fragment included  the counter which caused the update to
> occur on every second WAIT instruction. That would be a complete rotation
> every 16/25 seconds, which seems about right

Yup. Or 16/30 if you are running on a 60 Hz clock.

> By the way, the WAIT is just putting R0 on the data bus. Which is why
> you need to have the display selector set to that, and not the display
> register.
>
>
> That makes sense.
>
> [C library]
> >     It would be very easy to add the system calls as well. All
> you need is
> >     adding it to the Makefile.
> >
> >
> > You mean the makefile in /usr/src/lib/libc/pdp/sys? I think you are
> > right, but the Makefile is very 'clever' and generates the source
> > for the various system calls on the fly (just from the syscall
> name and
> > a bunch of macros in SYS.h) and pipes it through the preprocessor
> > and assembler.  I didn't want to mess with it till I had time to
> > understand it fully. And making a new libc would make it harder
> for anyone
> > else to reproduce my system - unless I wanted to make a complete
> > alternate distribution.
>
> Right. The makefile is rather clever, and you really only have to add
> the "file" to the makefile to make it all add up. Of course, you could
> also add a "prototype" of the function to some header file, but this is
> all pre ANSI-C anyhow, so not much of function prototypes anyway.
>
>
> The lack of ANSI function parameters define syntax seems like the
> most common issue when porting modern source back to 211.

That is usually one of the big ones, yes. The other being the limited
space available. Especially for data.

> >      > If anyone else has tinkered with the kernel, I would be
> >     interested to hear what you did.
> >
> >     Phew. Bug fixes, device driver changes, boot changes... I can't
> >     remember. Various things.
> >
> >
> > Sounds as though you have a lot more experience than I do. I had
> > tinkered with BSD/OS many years ago, but this was my first
> > hack at BSD211 or Unix in general on a PDP11/70.
>
> Possibly. But I think it's a good exercise to give into the 2.11BSD
> kernel, so all kudos to you for doing just that.
>
> Nice to see.
>
> Thanks. The kernel build seems much more elegant than the linux approach.

Agreed. Linux is most of the time a rather ugly hack.

> One other question springs to mind while I am talking to someone with a bit
> more knowledge of this system - do you know what the '/netnix' file does?
>
> I see it is built along with the '/unix' file when making the kernel,
> but I don't recall
> anything similar on other BSD systems I have used.

/netnix contains all the parts of TCP/IP. Because of the way the system
is done, all the networking is in a separate image that gets loaded by
the kernel along the way, and is not mapped into the kernel.

If you build a system without networking, this part does not exist.

I probably should go back and check details, but I seem to remember that
all the networking is running in supervisor mode.

[Digby R.S. Tarvin]

On Sat, 22 Jun 2019 at 11:05, Johnny Billquist <b...@softjar.se> wrote:

> Is there an easy way to check what my patch level is? And is there an
> official site for
> patches and the latest distributions?

You should have a /VERSION file, which tells.

Ah yes, so there is:Current Patch Level: 448

Date: January 5, 2010

 

There are several official sites.

         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/pub/2.11BSD

And I was misremembering. The fix for the securelevel was patch 451,
which is the latest.

It seems I have some patching to do...

Or perhaps it would be better to just grab a new,current source tree (or even full

installation image)  from one of the official sites and build a new system from that. 

The system I am running seems ok, but I don't really know its history, so I will

be holding my breath while applying patches.

Well, maybe it would be an opportunity to get my first fix into BSD 2.11 ;)

I think I managed to submit the last patch to the CDC6600 NOS2 operating system (to fix a Y2.1K issue)...

 

>  
> That code fragment included  the counter which caused the update to
> occur on every second WAIT instruction. That would be a complete rotation
> every 16/25 seconds, which seems about right

Yup. Or 16/30 if you are running on a 60 Hz clock.

My hacked kernel bumped the delay from 2 to 4 - just to provide a visual indication

that I am running my modified system. I wanted to make a more interesting change,

but anything that increased the size pushed me over a segment limit and I havn't 

built up the courage to go too deeply into trying to understand the overlay system.

 

>     [C library]
>      >     It would be very easy to add the system calls as well. All
>     you need is
>      >     adding it to the Makefile.
>      >
>      >
>      > You mean the makefile in /usr/src/lib/libc/pdp/sys? I think you are
>      > right, but the Makefile is very 'clever' and generates the source
>      > for the various system calls on the fly (just from the syscall
>     name and
>      > a bunch of macros in SYS.h) and pipes it through the preprocessor
>      > and assembler.  I didn't want to mess with it till I had time to
>      > understand it fully. And making a new libc would make it harder
>     for anyone
>      > else to reproduce my system - unless I wanted to make a complete
>      > alternate distribution.
>
>     Right. The makefile is rather clever, and you really only have to add
>     the "file" to the makefile to make it all add up. Of course, you could
>     also add a "prototype" of the function to some header file, but this is
>     all pre ANSI-C anyhow, so not much of function prototypes anyway.
>
>
> The lack of ANSI function parameters define syntax seems like the
> most common issue when porting modern source back to 211.

That is usually one of the big ones, yes. The other being the limited
space available. Especially for data.

Are there any compilers or interpreters that you know for BSD 2.11 which attempt

to alleviate the memory space restrictions? I think I recall that one of the DEC OS's

have a compiler that manipulated the MMU to implement some sort of transparent

overlay scheme.

I suppose to do that in memory (rather than by paging from a disk file) it would be

necessary to add some system calls allowing user land MMU manipulation. Something

like a memmap() where address space memory segments can be remapped arbitrarily

into a larger physical memory allocated to the process.  

 

Are there any repositories of third party software for BSD 211 that I should check and/or add to?

I would like some tools to help monitor things like memory usage and swap usage to get an

of where my bottle necks are. But it would be better not to re-invent anything that already exists.

>
> Thanks. The kernel build seems much more elegant than the linux approach.

Agreed. Linux is most of the time a rather ugly hack.

I actually miss the whole /usr/src structure from my old BSD system. It was much easier

to keep all of my sources available and find them when needed than in Linux where the

package management systems provide no easy way to say 'I want to hold the source for

every binary I am running'. If I want a definitive definition of what a program does, or to

tweak it, I want to be able to change to its source directory and type 'make'... on Linux

I need a network connection and a few hours reading through documentation for the

 package management system on the current distribution.

I even tried GENTOO, thinking that if everything was built from source then I would have

all the sources - but the model was to unpack, build and then discard sources.

The other thing I miss most was the bsdi mailing list. There was an incredible  amount

of expertise on that list, and a very high signal to noise ratio. 

> One other question springs to mind while I am talking to someone with a bit
> more knowledge of this system - do you know what the '/netnix' file does?
>
> I see it is built along with the '/unix' file when making the kernel,
> but I don't recall
> anything similar on other BSD systems I have used.

/netnix contains all the parts of TCP/IP. Because of the way the system
is done, all the networking is in a separate image that gets loaded by
the kernel along the way, and is not mapped into the kernel.

If you build a system without networking, this part does not exist.

I probably should go back and check details, but I seem to remember that
all the networking is running in supervisor mode.

That rather rather neat, and I suppose explains why there are some things that don't work when you

boot off something other than the default /unix. Presumably specifying ra(0,0,0)newunix does not 

result in the kernel being able to locate /newnetnix...   

Anyway, thanks for the insights. This has been most enlightening.

Regards,

DigbyT

[Johnny Billquist]

Hi. This is getting rather technical, so people, let me know if me and
Digby should take this off the list...

On 2019-06-22 14:22, Digby R.S. Tarvin wrote:
>
>
> On Sat, 22 Jun 2019 at 11:05, Johnny Billquist <b...@softjar.se
> <mailto:b...@softjar.se>> wrote:
>
>
> > Is there an easy way to check what my patch level is? And is
> there an
> > official site for
> > patches and the latest distributions?
>
> You should have a /VERSION file, which tells.
>
>
> Ah yes, so there is:Current Patch Level: 448
> Date: January 5, 2010

Ah. That is a bit outdated, yes... :-)

> There are several official sites.
>
> 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/pub/2.11BSD
>
> And I was misremembering. The fix for the securelevel was patch 451,
> which is the latest.
>
>
> It seems I have some patching to do...

Indeed.

> Or perhaps it would be better to just grab a new,current source tree (or
> even full
> installation image)  from one of the official sites and build a new
> system from that.
> The system I am running seems ok, but I don't really know its history,
> so I will
> be holding my breath while applying patches.

I think that even if you grab the "latest" source tree, some patching
will still be required.

I guess I should maybe create new sets at some point, if Steven don't do it.
I rather just also realized that some people might be helped if I
created a virtual tape already in order for doing an installation from
scratch. All the bits and pieces are there on the ftp site, but unless
you have some system with a tape drive, it might be hard to create a
tape, or even a virtual tape, for doing the installation.

I'll see if I can't create an installation distribution tape at least in
the next few days...

Indeed. Please try. And if you get something working, feel free to send
me or Steven a patch with it, and we'll create patch #452.

> I think I managed to submit the last patch to the CDC6600 NOS2 operating
> system (to fix a Y2.1K issue)...

The rate of fixes on 2.11BSD have gone down over the years, but it's
still actively being supported, and patches are welcome.

> > That code fragment included  the counter which caused the update to
> > occur on every second WAIT instruction. That would be a complete
> rotation
> > every 16/25 seconds, which seems about right
>
> Yup. Or 16/30 if you are running on a 60 Hz clock.
>
>
> My hacked kernel bumped the delay from 2 to 4 - just to provide a visual
> indication
> that I am running my modified system. I wanted to make a more
> interesting change,
> but anything that increased the size pushed me over a segment limit and
> I havn't
> built up the courage to go too deeply into trying to understand the
> overlay system.

The overlay system in 2.11BSD is both very simple, and somewhat limited.
For the kernel, each overlay cannot exceed 8Kbyte (4Kword), but apart
from that, code can pretty much be moved around anywhere without
restrictions.
I usually move code around quite a lot from the default.

That is, move things between different overlays as you see fit. Don't
move things out from base into overlays.

And if you do a "size" on the kernel, you'll see the sizes of the
different overlays, and see where you have plenty of space left, and
where there is a squeeze. Then just edit the Makefile and move things
between the overlays. I usually move the toy out of OV6 to OV9 for example.

> > The lack of ANSI function parameters define syntax seems like the
> > most common issue when porting modern source back to 211.
>
> That is usually one of the big ones, yes. The other being the limited
> space available. Especially for data.
>
>
> Are there any compilers or interpreters that you know for BSD 2.11 which
> attempt
> to alleviate the memory space restrictions? I think I recall that one of
> the DEC OS's
> have a compiler that manipulated the MMU to implement some sort of
> transparent
> overlay scheme.

Since there are no real mechanisms for playing with the MMU in 2.11BSD,
there isn't much you can do. What is possible to do is to play with
overlays also for user level stuff.
And overlays in 2.11BSD are done using the MMU in the end. And it is
pretty much fully transparent. You can call from anywhere to anywhere
without concern. However, it only helps you getting more than 64K of
instruction. It is not applicable to data.

DEC OSes and software have a more complex and capable overlay scheme,
but instead imposes some restrictions on how you can call from one place
to another. DEC OSes also allows you to play with memory in a more
flexible way, giving you something very similar to mmap, meaning you can
have more than 64K data.

So for both 2.11BSD and DEC OSes you can have overlays that are managed
by manipulating the MMU, and it's all done transparent to the program
itself.

> I suppose to do that in memory (rather than by paging from a disk file)
> it would be
> necessary to add some system calls allowing user land MMU manipulation.
> Something
> like a memmap() where address space memory segments can be remapped
> arbitrarily
> into a larger physical memory allocated to the process.
> Are there any repositories of third party software for BSD 211 that I
> should check and/or add to?
> I would like some tools to help monitor things like memory usage and
> swap usage to get an
> of where my bottle necks are. But it would be better not to re-invent
> anything that already exists.

In 2.11BSD, if you have a program image with the right magic number, it
is an overlaid program, and the kernel will use the MMU to remap as
needed. It's all done outside of the awareness of the program itself,
unless you start playing in assembler, at which point it is visible.

So what you are looking for is already there, as far as addressing more
than 64K goes.

I'm not aware of any memory analysis or statistics software, but I
haven't really looked much. You can, of course, use profiling, and if
you know where different pieces are, you can tell how much moving around
there is. But since overlays are only done using the MMU, there is
essentially no bottleneck in there. You do have swapping, but that swaps
whole processes in and out. And you can, of course, see how much
swapping is going on.
vmstat is your friend here.

> > One other question springs to mind while I am talking to someone
> with a bit
> > more knowledge of this system - do you know what the '/netnix'
> file does?
> >
> > I see it is built along with the '/unix' file when making the
> kernel,
> > but I don't recall
> > anything similar on other BSD systems I have used.
>
> /netnix contains all the parts of TCP/IP. Because of the way the system
> is done, all the networking is in a separate image that gets loaded by
> the kernel along the way, and is not mapped into the kernel.
>
> If you build a system without networking, this part does not exist.
>
> I probably should go back and check details, but I seem to remember
> that
> all the networking is running in supervisor mode.
>
>
> That rather rather neat, and I suppose explains why there are some
> things that don't work when you
> boot off something other than the default /unix. Presumably specifying
> ra(0,0,0)newunix does not
> result in the kernel being able to locate /newnetnix...

I can't remember, but it might be that it looks for a name based on the
kernel, but I might just not remember much of this right. I would have
to go and look at the sources...

I guess it is neat in one way, but it is sortof just a result of the
limitations of the system as well, which would be different if the
limitations and restrictions were different.

> Anyway, thanks for the insights. This has been most enlightening.

Always fun to talk PDP-11.

[Digby R.S. Tarvin]

On Sat, 22 Jun 2019 at 21:04, Johnny Billquist <b...@softjar.se> wrote:

Hi. This is getting rather technical, so people, let me know if me and
Digby should take this off the list...

I've trimmed it a bit - I hope I am not boring too many people with these

questions, but nobody has complained yet so I'll keep it on list for now..

 

On 2019-06-22 14:22, Digby R.S. Tarvin wrote:

> [patching]

> The system I am running seems ok, but I don't really know its history,
> so I will
> be holding my breath while applying patches.

I think that even if you grab the "latest" source tree, some patching
will still be required.

I guess I should maybe create new sets at some point, if Steven don't do it.
I rather just also realized that some people might be helped if I
created a virtual tape already in order for doing an installation from
scratch. All the bits and pieces are there on the ftp site, but unless
you have some system with a tape drive, it might be hard to create a
tape, or even a virtual tape, for doing the installation.

I'll see if I can't create an installation distribution tape at least in
the next few days...

Let me know if you do get around to it. Otherwise I am sure that doing it myself will be

a useful learning exercise.

The rate of fixes on 2.11BSD have gone down over the years, but it's
still actively being supported, and patches are welcome

It is really nice that it is still being maintained. The PDP11's were great machines both

architecturally and aesthetically. And whilst the historic Unix releases are interesting to 

run on it, it is a lot more interesting to have a usable system and see how far it is possible

to go in keeping it current.

As the networking seems fairly complete, I am now wondering if anyone has X11 running on

it. I would quite like to connect my NXD XTerminal, which hasn't really been used in anger 

since my BSD/OS system was my main server (it runs on a fully expanded 486 with 64MB of ram!).

Linux seems to broken X11 by making it too dependent on assumptions of high bandwidth local

display hardware - I have to replace the IDE with something like fvwm to have any chance, and

often the display manager no longer works  properly with XDMCP.

> My hacked kernel bumped the delay from 2 to 4 - just to provide a visual
> indication
> that I am running my modified system. I wanted to make a more
> interesting change,
> but anything that increased the size pushed me over a segment limit and
> I havn't
> built up the courage to go too deeply into trying to understand the
> overlay system.

The overlay system in 2.11BSD is both very simple, and somewhat limited.
For the kernel, each overlay cannot exceed 8Kbyte (4Kword), but apart
from that, code can pretty much be moved around anywhere without
restrictions.
I usually move code around quite a lot from the default.

That is, move things between different overlays as you see fit. Don't
move things out from base into overlays.

And if you do a "size" on the kernel, you'll see the sizes of the
different overlays, and see where you have plenty of space left, and
where there is a squeeze. Then just edit the Makefile and move things
between the overlays. I usually move the toy out of OV6 to OV9 for example.

Ah, ok. At the moment I am getting:

digbyt[348] % size /unix

text    data    bss     dec     hex

57024   6270    33148   96442   178ba   total text: 116352

        overlays: 7808,7488,7872,7296,4544,6336,4992,5696,7296

So my base seems to be pretty close to full. Perhaps that is where I have been running into trouble.

What are you supposed to do if something in base needs to grow?

[memory management]

So what you are looking for is already there, as far as addressing more
than 64K goes.

I'm not aware of any memory analysis or statistics software, but I
haven't really looked much. You can, of course, use profiling, and if
you know where different pieces are, you can tell how much moving around
there is. But since overlays are only done using the MMU, there is
essentially no bottleneck in there. You do have swapping, but that swaps
whole processes in and out. And you can, of course, see how much
swapping is going on.
vmstat is your friend here.

 That is very interesting.

Are there any papers or documentation that describes the techniques used to overcome some

of the limitations of the 16 bit architecture? Or perhaps the history of 2.11 BSD. 

I dug out my old 'Design and Implementation of 4.3BSD UNIX', and I think a lot of things apply,

but it seems to be mainly concerned with the VAX era, and the PDP11 workarounds would be

unwanted complexity in a general OS description.

I also have my Lions 'Unix Level 6 source code and commentary', which is PDP11 based, but

small enough not to need the workarounds.

Anyway, I had a look a vmstat, and how it uses nlist(3) and mem(4) to obtain information from

kernel structures. So I will tinker with writing some tools to give me better visibility into the

internals. (X11 would be good here for graphical displays).

Here is the result of my first little hack to get a feel for resource utilization:

 digbyt[459] % free -s

mem:  28861/61440 (46%) free, 57/122 (46%) coremap entries free
swap: 14731/16719 (88%) free, 91/109 (83%) swapmap entries free
 entry  Size   Start
    0:    12   00000001 ($000001)
    1:     1   00000155 ($00006d)
    2:    11   00000227 ($000097)
    3:     2   00000352 ($0000ea)
    4:    12   00000430 ($000118)
    5:     3   00000530 ($000158)
    6:    25   00000614 ($00018c)
    7:    22   00000734 ($0001dc)
    8:    37   00001031 ($000219)
    9:    22   00001211 ($000289)
   10:    23   00001640 ($0003a0)
   11:    29   00002260 ($0004b0)
   12:     2   00002434 ($00051c)
   13:    38   00003130 ($000658)
   14:     7   00003524 ($000754)
   15:    56   00003675 ($0007bd)
   16:    80   00004131 ($000859)
   17: 14349   00004503 ($000943)

> [/netnix]

> That rather rather neat, and I suppose explains why there are some
> things that don't work when you
> boot off something other than the default /unix. Presumably specifying
> ra(0,0,0)newunix does not
> result in the kernel being able to locate /newnetnix...

I can't remember, but it might be that it looks for a name based on the
kernel, but I might just not remember much of this right. I would have
to go and look at the sources...

I guess it is neat in one way, but it is sortof just a result of the
limitations of the system as well, which would be different if the
limitations and restrictions were different.

 Well, it seems nice to have the three privilege levels that the 11/70 provides being used.

It may be primarily motivated bya need to extend the Kernel address space to accommodate

the networking code, but I can see arguments for separating the network and other higher level functions

from low level kernel, even without the address space constraints. Almost like a rudimentary microkernel approach. 

Regards,

Digby

[Johnny Billquist]

Hi.

On 2019-06-23 16:32, Digby R.S. Tarvin wrote:
> On Sat, 22 Jun 2019 at 21:04, Johnny Billquist <b...@softjar.se
> <mailto:b...@softjar.se>> wrote:
>
> Hi. This is getting rather technical, so people, let me know if me and
> Digby should take this off the list...
>
>
> I've trimmed it a bit - I hope I am not boring too many people with these
> questions, but nobody has complained yet so I'll keep it on list for now..

Sounds good. If people want to, we can move it offlist later.

> On 2019-06-22 14:22, Digby R.S. Tarvin wrote:
> > [patching]
> > The system I am running seems ok, but I don't really know its
> history,
> > so I will
> > be holding my breath while applying patches.
>
> I think that even if you grab the "latest" source tree, some patching
> will still be required.
>
> I guess I should maybe create new sets at some point, if Steven
> don't do it.
> I rather just also realized that some people might be helped if I
> created a virtual tape already in order for doing an installation from
> scratch. All the bits and pieces are there on the ftp site, but unless
> you have some system with a tape drive, it might be hard to create a
> tape, or even a virtual tape, for doing the installation.
>
> I'll see if I can't create an installation distribution tape at
> least in
> the next few days...
>
>
> Let me know if you do get around to it. Otherwise I am sure that doing
> it myself will be
> a useful learning exercise.

I created a tape. Check ftp://ftp.update.uu.se/pub/pdp11/2.11BSD/2bsd.tap.gz

I did it from my system, and I later realized that it might actually
then run my kernel, and not the generic one if you install it. But it
has all the files, in the order documented if you read the 2BSD
installation documentation. So there you have all binaries, as well as
all sources, up to the latest patches.

Also might then have an account file that is not totally virgin either.
If there are any funniness, let me know. It's easy to create the file as
such.

> The rate of fixes on 2.11BSD have gone down over the years, but it's
> still actively being supported, and patches are welcome
>
>
> It is really nice that it is still being maintained. The PDP11's were
> great machines both
> architecturally and aesthetically. And whilst the historic Unix releases
> are interesting to
> run on it, it is a lot more interesting to have a usable system and see
> how far it is possible
> to go in keeping it current.

Heh... I could possibly argue that running something else than Unix
might be even more interesting. But it do depend on where your interests
lay...

> As the networking seems fairly complete, I am now wondering if anyone
> has X11 running on
> it. I would quite like to connect my NXD XTerminal, which hasn't really
> been used in anger
> since my BSD/OS system was my main server (it runs on a fully expanded
> 486 with 64MB of ram!).
> Linux seems to broken X11 by making it too dependent on assumptions of
> high bandwidth local
> display hardware - I have to replace the IDE with something like fvwm to
> have any chance, and
> often the display manager no longer works  properly with XDMCP.

I seriously doubt you can get anything X11-like to run on it. Most
things just require way too much data.

I wouldn't expect that you'd do much that would grow base, but if you
do, then you need to figure out which parts can be moved into overlays.
I think a lot of the stuff in base can move out, but there are some
things that might be bad. Also, there is of course some slight overhead
cost when switching overlays, even if it is just manipulating the MMU.
But for most things I would just move it around without worrying too
much. Just experiment. :-)

You have something like six overlays which are totally empty, which you
can stuff with things...

> [memory management]
>
> So what you are looking for is already there, as far as addressing more
> than 64K goes.
>
> I'm not aware of any memory analysis or statistics software, but I
> haven't really looked much. You can, of course, use profiling, and if
> you know where different pieces are, you can tell how much moving
> around
> there is. But since overlays are only done using the MMU, there is
> essentially no bottleneck in there. You do have swapping, but that
> swaps
> whole processes in and out. And you can, of course, see how much
> swapping is going on.
> vmstat is your friend here.
>
>
>  That is very interesting.
>
> Are there any papers or documentation that describes the techniques used
> to overcome some
> of the limitations of the 16 bit architecture? Or perhaps the history of
> 2.11 BSD.

I can't remember seeing any papers, but there might be.

> I dug out my old 'Design and Implementation of 4.3BSD UNIX', and I think
> a lot of things apply,
> but it seems to be mainly concerned with the VAX era, and the PDP11
> workarounds would be
> unwanted complexity in a general OS description.

Some things do apply, but much of it would be unrelated to 2BSD.

> I also have my Lions 'Unix Level 6 source code and commentary', which is
> PDP11 based, but
> small enough not to need the workarounds.

Yeah, that is so much further back in the past that many things in 2BSD
had not yet happened.

> Anyway, I had a look a vmstat, and how it uses nlist(3) and mem(4) to
> obtain information from
> kernel structures. So I will tinker with writing some tools to give me
> better visibility into the
> internals. (X11 would be good here for graphical displays).
>
> Here is the result of my first little hack to get a feel for resource
> utilization:

[...]

Nice. So now you are starting to dig into the innards. Keep at it. :-)

> > [/netnix]
> > That rather rather neat, and I suppose explains why there are some
> > things that don't work when you
> > boot off something other than the default /unix. Presumably
> specifying
> > ra(0,0,0)newunix does not
> > result in the kernel being able to locate /newnetnix...
>
> I can't remember, but it might be that it looks for a name based on the
> kernel, but I might just not remember much of this right. I would have
> to go and look at the sources...
>
> I guess it is neat in one way, but it is sortof just a result of the
> limitations of the system as well, which would be different if the
> limitations and restrictions were different.
>
>
>  Well, it seems nice to have the three privilege levels that the 11/70
> provides being used.
> It may be primarily motivated bya need to extend the Kernel address
> space to accommodate
> the networking code, but I can see arguments for separating the network
> and other higher level functions
> from low level kernel, even without the address space constraints.
> Almost like a rudimentary microkernel approach.

It's definitely only motivated by address space constraints, and it is
not setup so that it actually protects anything from the kernel code.
I seem to remember that the networking also have full access to
everything. Which is not hard to do on a PDP-11. If the I/O page is
mapped read/write, then you can do whatever you want, including
remapping your address space any way you want to.

It's very far from a microkernel approach in the end. If you want
something more in that path, I'd look at RSX if I were you...

[Richard Stofer]

Please don't take this offline.  I'll take all the free education I can get.

 

For no particularly good reason, I seem to want to rebuild the kernel (ZEKE).  Having direct access to the display register and console switches seems like a good thing.  I can't think of a machine that had switches that didn't have direct access clear back to the IBM1130.  A display register wasn't always part of the design and, in the case of the 1130, the solution was to put some value in the Accumulator and issue a WAIT instruction.  Of course, this was a single user operating system so using WAIT was a non-issue.  Having a separate display register is pretty nice.

As to the rest, I'll probably print off the thread and keep it for reference.

[Digby R.S. Tarvin]

I'd suggest creating a new configuration using ZEKE as the starting point. Ie

# cd /usr/src/sys/conf

# cp ZEKE MYCONFIG

# vi MYCONFIG

make any config changes you want... Mine were:

digbyt[493] % diff ZEKE DIGBYT

30,31c30,31

< #LINEHZ               50                      # clock frequency European

< LINEHZ                60                      # clock frequency USA

---

> LINEHZ                50                      # clock frequency European

> #LINEHZ               60                      # clock frequency USA

38,39c38,39

< PDP11         44                      # PDP-11/44

< #PDP11                70                      # PDP-11/70,45,50,55

---

> #PDP11                44                      # PDP-11/44

> PDP11         70                      # PDP-11/70,45,50,55

46c46

< IDENT         ZEKE                    # machine name

---

> IDENT         DIGBYT                  # machine name

67c67,68

< TIMEZONE      480                     # PST

---

> #TIMEZONE     480                     # PST

> TIMEZONE      0                       # GMT

then

# ./config MYCONFIG

# cd ../MYCONFIG

# make

The above make will fail until you tweak the new Makefile.. For me moving clock.o and init_main.o from BASE to OV6

did the trick. I copied the changes from what was done for ZEKE. I don't know how good the choice is, but I didn't feel

experienced enough to decide I knew better than ZEKE... :)

digbyt[486] % diff Makefile Makefile.orig

72c72

<       sys_pipe.o clock.o init_main.o

---

>       sys_pipe.o

74c74

< OV6=  dn.o kern_pdp.o machdep2.o subr_prf.o syscalls.o \

---

> OV6=  clock.o dn.o init_main.o kern_pdp.o machdep2.o subr_prf.o syscalls.o \

Once the build succeeds, install and test to verify your kernel build works. If all is well, you are ready to add the new calls...

Good luck

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/799cf8fd-9e19-4c0b-90a8-f4e6da31810f%40googlegroups.com.

[Digby R.S. Tarvin]

I had another look at the mysterious panics I was getting if I run a new kernel that was built in a way that increases its size...

For this test, I made no changes to any source code - all I did was to increase the length of the hostname of the build machine by one character. 

Because the hostname of the build system is compiled into the kernel, as shown by uname:

BSD elec70 2.11 2.11 BSD UNIX #2: Fri Jun 21 04:20:07 BST 2019      root@pdp11:/usr/src/sys/DIGBYT  pdp11

this will increase the size of the kernel. In the above case the hostname is 'pdp11', and in the new kernel it is 'elec70'.

The new kernel was copied to /newunix, and the new and old sizes are:

                # size /unix

                text    data    bss     dec     hex
                57024   6270    33148   96442   178ba   total text: 116352
                        overlays: 7808,7488,7872,7296,4544,6336,4992,5696,7296

                # size /newunix

                text    data    bss     dec     hex

                57024   6272    33148   96444   178bc   total text: 116352
                        overlays: 7808,7488,7872,7296,4544,6336,4992,5696,7296
So the text areas are the same, but the data size has increased by two bytes.

Booting to /newunix gives:

                : ra(0,0,0)newunix
                Boot: bootdev=02400 bootcsr=0172150

                2.11 BSD UNIX #3: Tue Jun 25 02:59:33 BST 2019
                    root@elec70:/usr/src/sys/DIGBYT

                ra0: Ver 3 mod 3
                ra0: RA82  size=1954000
                ka6 4602 aps 147474
                pc 56050 ps 30340
                ov 5
                cpuerr 120
                trap type 0
                panic: trap
                syncing disks... done

                dumping to dev 2401 off 1024
                dump succeeded

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

So no link error, but a minimal increase in kernal data size does seem to have proved fatal. 

Any ideas?

Regards,

DigbyT

[Johnny Billquist]

There must be something else that is going on here, which is the problem.

Exactly what is the question, though.

How did you build the whole thing? From start... What config, which
command to generate the build system, how did you do the actual build of
the kernel...

Johnny

> email: b...@softjar.se <mailto:b...@softjar.se>             ||

[Sytse van Slooten]

I was thinking that it might help to try and locate the address that the trap occurs at.

One thing on my mind also is that apparently you use a custom size RA driver. Can you replicate the issue with a standard disk and driver?

I’m pretty sure it has nothing to do with the length of the version string, mine is way longer for instance - I include the full domain name.

> --
> 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/06531389-f43c-ecbf-f5aa-f2a5929880e9%40softjar.se.

[Digby R.S. Tarvin]

Hi,

On Tue, 25 Jun 2019 at 23:41, Sytse van Slooten <sy...@sytse.net> wrote:

I was thinking that it might help to try and locate the address that the trap occurs at.

Agreed. I think that is the fallback option if inspired guessing doesnt work :)

 

One thing on my mind also is that apparently you use a custom size RA driver. Can you replicate the issue with a standard disk and driver?

Ah, am I? I'm new to BSD 2.11 so I was using the system as supplied with the PiDP11 distribution as my starting point. Unfortunately I don't know the degree to which it has diverged from the 'official' distribution.

To be specific, the procedure I followed to rebuild the kernel was:

a. copy /usr/src/sys/conf/ZEKE to /usr/src/sys/conf/DIGBYT and edit - changes as follows:

30,31c30,31

< #LINEHZ               50                      # clock frequency European

< LINEHZ                60                      # clock frequency USA

---

> LINEHZ                50                      # clock frequency European

> #LINEHZ               60                      # clock frequency USA

38,39c38,39

< PDP11         44                      # PDP-11/44

< #PDP11                70                      # PDP-11/70,45,50,55

---

> #PDP11                44                      # PDP-11/44

> PDP11         70                      # PDP-11/70,45,50,55

46c46

< IDENT         ZEKE                    # machine name

---

> IDENT         DIGBYT                  # machine name

67c67,68

< TIMEZONE      480                     # PST

---

> #TIMEZONE     480                     # PST

> TIMEZONE      0                       # GMT

b. run './config  DIGBYT' to generate the new build directory

c. cd ../DIGBYT and fix the link error by copying the changes in ZEKE/Makefile - ie move clock.o and init_main.o from BASE to OV6

d. make clean;make

e. install with

                install -c -o root -g kmem -m 744 unix /unix

                install -c -o root -g kmem -m 744 netnix /netnix

 

Although I always initially copy to /newunix and do a test boot before actually replacing /unix.

Is the ZEKE configuration something you know of, or something divergent which has appeared in the PiDP11 image?

It is looking as though I should probably do the clean install (that I was planning anyway). It might not be worth spending too much time on unless the problem can be reproduced in a built of know progeny.

I’m pretty sure it has nothing to do with the length of the version string, mine is way longer for instance - I include the full domain name. 

How does the kernel data size compare on your system when you run with a longer version string? I know it is now specific to the version string. I have also seen the issue if I actually define a new data variable in the kernel. I just used the version string length as it rules out what you would otherwise be justified in suspecting - that it was my kernel modification itself which was flawed.

 

Regards,

DigbyT

[Sytse van Slooten]

# size unix

text    data    bss     dec     hex

49920   5314    43224   98458   1809a   total text: 106240

        overlays: 7808,7488,7872,7360,6912,8192,4992,5696

I don’t see anything out of the very ordinary in the changes you made to the config. I don’t know what’s in the rest of it though - there must be a couple extras in there, considering the rather big difference in text size.

In both cases the text size confuses me a bit - I was kind of thinking that the maximum would be 48K to allow room for the overlays to be mapped. Maybe Johnny can explain that bit?

--
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/CACo5X5j%2Bf2qvawkOw9gdmf2WPc1Fh5DuzDo6aom%3Dojwh-1DGqg%40mail.gmail.com.

[Johnny Billquist]

You don't need the i/o page mapped in the instruction space. So 56k plus 8 for overlays.

Johnny

Sytse van Slooten <sy...@sytse.net> skrev: (26 juni 2019 13:12:59 CEST)

--
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.

[Richard Stofer]

I decided to create a duplicate ZEKE kernel.  First, to see if it would build at all and, second, to see if it matched the existing kernel in, at least, size.  It would be a plus if it actually ran.

No joy!  The linker threw an error saying the payload was too large for a type 413 file, whatever that means.

Here's another thing:  Above, it was mentioned that various .o files needed to move.  Well, in my ZEKE Makefile, sys_pipe.o is in OV5, not BASE, and clock.c and init_main.o are already in OV6

I wonder if there are different distributions of ZEKE.

 

[David Richards]

Greetings Digby,

If you compare the newly created makefile with the original you will probably see a difference in the overlay allocations. I did when I tried to recompile, I had to copy the makefile from the previous build into the new build directory to get a successful linkage. Since then I have found this tool to automate the process of generating the overlays in the makefile - I haven't needed to use it yet though. 

 http://www.retrocmp.com/how-tos/installing-211bsd-unix-on-pdp-1144/120-installing-211bsd-kernel-setup

I discovered the problem by searching for the meaning of the 413 error.

The essence of the problem is that the makefile template does not suit the newly created build, it needs amending after the configuration is created.

Kind regards, David.

[Digby R.S. Tarvin]

Hi David,

On Wed, 26 Jun 2019 at 20:46, David Richards <richard...@gmail.com> wrote:

Greetings Digby,

If you compare the newly created makefile with the original you will probably see a difference in the overlay allocations. I did when I tried to recompile, I had to copy the makefile from the previous build into the new build directory to get a successful linkage. Since then I have found this tool to automate the process of generating the overlays in the makefile - I haven't needed to use it yet though. 

 http://www.retrocmp.com/how-tos/installing-211bsd-unix-on-pdp-1144/120-installing-211bsd-kernel-setup

I discovered the problem by searching for the meaning of the 413 error.

The essence of the problem is that the makefile template does not suit the newly created build, it needs amending after the configuration is created.

Kind regards, David.

Yes, that sounds right. What I did was copy the re-arangment  make by whoever put together the supplied ZEKE config (ie copied the makefile from the ZEKE build direcory).

It seems to build and run fine, so long as I don't increase the size of the code or data from what it was with the original build. But it isnt obvious to me from the kernel sizes why I am at a limit, and why it is a limit that the linker is not detecting...

Regards,

Digby 

[Digby R.S. Tarvin]

On Wed, 26 Jun 2019 at 19:41, Richard Stofer <Richard...@comcast.net> wrote:

I decided to create a duplicate ZEKE kernel.  First, to see if it would build at all and, second, to see if it matched the existing kernel in, at least, size.  It would be a plus if it actually ran.

No joy!  The linker threw an error saying the payload was too large for a type 413 file, whatever that means.

Yep, I had the same thing. I copied ZEKE and did a ./config on the copy, which produced the 413. Then I copied the Makefile from the original ZEKE directory and the build worked. So you need to do a manual juggle with the overlays after using config to create the new build directory.

If you did a ./config of the original ZEKE, that would probably have overwriten the one you need to copy, which would complicate things. 

  

Here's another thing:  Above, it was mentioned that various .o files needed to move.  Well, in my ZEKE Makefile, sys_pipe.o is in OV5, not BASE, and clock.c and init_main.o are already in OV6

I wonder if there are different distributions of ZEKE

I think the initial Makefile is generic, not associated with the config file you created it with. So if your Makefile differed from mine, it could be that your BSD system is at a different patch level to mine.  

Regards,

Digby

[Johnny Billquist]

Eh... Don't copy makefiles from other directories over. It is a file
generated by config, and you should be using the right one...

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/ef52f750-4d99-469f-ac7f-dfa55bcbfb66%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/ef52f750-4d99-469f-ac7f-dfa55bcbfb66%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Digby R.S. Tarvin]

Sorry - when I said I copied it, I meant I copied the changes. I didn't blindly Replace the generated Makefile with what was in the ZEKE build directory.

That is I diff'd the Makefile generated in the DIGBYT build directory with the one that existed in the ZEKE directory, and saw that the only difference other than the machine name (I couldn't find that used anywhere, by the way) was the two object files moved from CORE to OV6. So I duplicated the object file move and that allowed the link to succeed.

As it happens, just copying the Makefile would have been OK, but I certainly wouldn't have done that without checking first to see what was different.

Regards

DigbyT

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/751f2932-4639-d69e-26e9-10201376c1a7%40softjar.se.

[Johnny Billquist]

On 2019-06-26 22:33, Digby R.S. Tarvin wrote:
> On Wed, 26 Jun 2019 at 19:41, Richard Stofer <Richard...@comcast.net
> <mailto:Richard...@comcast.net>> wrote:
>
> I decided to create a duplicate ZEKE kernel. First, to see if it would build at all and, second, to see if it matched the existing kernel in, at least, size. It would be a plus if it actually ran.
>
>
> No joy!  The linker threw an error saying the payload was too large
> for a type 413 file, whatever that means.
>
>
> Yep, I had the same thing. I copied ZEKE and did a ./config on the copy,
> which produced the 413. Then I copied the Makefile from the original
> ZEKE directory and the build worked. So you need to do a manual juggle
> with the overlays after using config to create the new build directory.

Note that you get this error if either the base is too large, or any of
the overlays are too large. I got it as well, even when I had trimmed
the kernel down, since OV6 was too big.
When you get this error, just do a size unix.o, to see what the
situation looks like.

> If you did a ./config of the original ZEKE, that would probably have
> overwriten the one you need to copy, which would complicate things.
>
> Here's another thing:  Above, it was mentioned that various .o files
> needed to move.  Well, in my ZEKE Makefile, sys_pipe.o is in OV5,
> not BASE, and clock.c and init_main.o are already in OV6
>
> I wonder if there are different distributions of ZEKE
>
>
> I think the initial Makefile is generic, not associated with the config
> file you created it with. So if your Makefile differed from mine, it
> could be that your BSD system is at a different patch level to mine.

I don't think the different patches affect the kernel size much.

Johnny

[vlai...@gmail.com]

Hi, i added some examples of possible interfaces 

https://github.com/vlait/2.11BSD-swreg-ioctl

1. syscall as in this thread

2. sysctl

3. file descriptor access for /dev/panel (or rather c major 1, minor 4) allowing both

regular fd io and ioctl regulated access

individual tar files with examples and patches to apply against a vanilla 211bsd481/482

.. and a disk image to test without having to compile anything.

[Ville Laitinen]

and meh.. forgot to thank GrandmasterJ for advice and guidance in the
previous email

> --
> 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 visit https://groups.google.com/d/msgid/pidp-11/896b433f-4847-475c-ab52-6d41f8afa247n%40googlegroups.com.