[TUHS] running BSD 2.11 on my PDP 11/70 emulator

[TUHS] running BSD 2.11 on my PDP 11/70 emulator

[Folkert van Heusden]

Hi,

For fun I'm developing a PDP 11/70 emulator. It runs on everything from 
ESP32 microcontrollers up to linux, windows, etc
https://vanheusden.com/emulation/PDP-11/kek/
Currently it can run UNIX 7 in multi user mode.
Of course I would like it to run BSD 2.11 as well (because of the 
networking support). It boots, but after outputting the memory amounts 
it produces a lot of garbage. It does eventually complete booting and 
then allows you to log in.
I wonder if you sees this: 
https://paste.nurd.space/mqIDB_0SjoDoJoasOGkiNQ_NjpRsCufAJCnKTA7ZxUI 
(text) or 
https://imgpaste.nurd.space/pics/437bcf0d149a017168cbbf2def8560917a037a3935c5c3aa1fbea2f7e43b485a.png 
(image), does this ring a bell to anyone? I verified with simh that the 
disk-image should work.


regards

-- 
www.vanheusden.com

[TUHS] Re: running BSD 2.11 on my PDP 11/70 emulator

[Kenneth Goodwin]

[-- Attachment #1: Type: text/plain, Size: 1943 bytes --]

To me it looks like a memory issue of some sort. Setup of the MMU etc.

1. Your user memory is less than 10% of "available memory" which should be
the amount left after the kernel loads and allocates dynamic  buffers. User
memory should be alot closer to available number. Unless it is referring to
limits of mmu per process and not total available for all user level
programs.

2. The bulk of the text dump seems to just be random initialized data
dumped from Ram.
Aka - Printf() format strings.  Indicates that the wrong address in memory
is potentially being accessed.

Perhaps the pdp11 emulator configuration does not have a correct mmu for
your image file.

For example,  you are running the 11/70 emulation and the binary image you
are running is actually compiled for a pdp 11/45.

The 11/70 has an mmu supporting split instruction and data spaces. 64k
instruction,  64k data. But the kernel you are using was compiled to run on
a non split I And D version of the pdp11 supporting only 64kb of combined
user and data.

On Mon, Apr 7, 2025, 3:30 AM Folkert van Heusden <folkert@vanheusden.com>
wrote:

> Hi,
>
> For fun I'm developing a PDP 11/70 emulator. It runs on everything from
> ESP32 microcontrollers up to linux, windows, etc
> https://vanheusden.com/emulation/PDP-11/kek/
> Currently it can run UNIX 7 in multi user mode.
> Of course I would like it to run BSD 2.11 as well (because of the
> networking support). It boots, but after outputting the memory amounts
> it produces a lot of garbage. It does eventually complete booting and
> then allows you to log in.
> I wonder if you sees this:
> https://paste.nurd.space/mqIDB_0SjoDoJoasOGkiNQ_NjpRsCufAJCnKTA7ZxUI
> (text) or
>
> https://imgpaste.nurd.space/pics/437bcf0d149a017168cbbf2def8560917a037a3935c5c3aa1fbea2f7e43b485a.png
> (image), does this ring a bell to anyone? I verified with simh that the
> disk-image should work.
>
>
> regards
>
> --
> www.vanheusden.com
>

[-- Attachment #2: Type: text/html, Size: 3048 bytes --]

[TUHS] Re: running BSD 2.11 on my PDP 11/70 emulator

[Kenneth Goodwin]

[-- Attachment #1: Type: text/plain, Size: 2457 bytes --]

Something is definitely off with memory layout.
That 300000 user memory is not a reference to even the maximum  split i/d
image size.

If your bsd image has kernel dynamic buffer configuration limit
parameters,  you could tweak those down say 50% to see what happens.  (Not
a BSD kernel hacker and it's been a while since I last read over the source
code)



On Mon, Apr 7, 2025, 8:02 AM Kenneth Goodwin <kennethgoodwin56@gmail.com>
wrote:

> To me it looks like a memory issue of some sort. Setup of the MMU etc.
>
> 1. Your user memory is less than 10% of "available memory" which should be
> the amount left after the kernel loads and allocates dynamic  buffers. User
> memory should be alot closer to available number. Unless it is referring to
> limits of mmu per process and not total available for all user level
> programs.
>
> 2. The bulk of the text dump seems to just be random initialized data
> dumped from Ram.
> Aka - Printf() format strings.  Indicates that the wrong address in memory
> is potentially being accessed.
>
> Perhaps the pdp11 emulator configuration does not have a correct mmu for
> your image file.
>
> For example,  you are running the 11/70 emulation and the binary image you
> are running is actually compiled for a pdp 11/45.
>
> The 11/70 has an mmu supporting split instruction and data spaces. 64k
> instruction,  64k data. But the kernel you are using was compiled to run on
> a non split I And D version of the pdp11 supporting only 64kb of combined
> user and data.
>
> On Mon, Apr 7, 2025, 3:30 AM Folkert van Heusden <folkert@vanheusden.com>
> wrote:
>
>> Hi,
>>
>> For fun I'm developing a PDP 11/70 emulator. It runs on everything from
>> ESP32 microcontrollers up to linux, windows, etc
>> https://vanheusden.com/emulation/PDP-11/kek/
>> Currently it can run UNIX 7 in multi user mode.
>> Of course I would like it to run BSD 2.11 as well (because of the
>> networking support). It boots, but after outputting the memory amounts
>> it produces a lot of garbage. It does eventually complete booting and
>> then allows you to log in.
>> I wonder if you sees this:
>> https://paste.nurd.space/mqIDB_0SjoDoJoasOGkiNQ_NjpRsCufAJCnKTA7ZxUI
>> (text) or
>>
>> https://imgpaste.nurd.space/pics/437bcf0d149a017168cbbf2def8560917a037a3935c5c3aa1fbea2f7e43b485a.png
>> (image), does this ring a bell to anyone? I verified with simh that the
>> disk-image should work.
>>
>>
>> regards
>>
>> --
>> www.vanheusden.com
>>
>

[-- Attachment #2: Type: text/html, Size: 3958 bytes --]

[TUHS] Re: running BSD 2.11 on my PDP 11/70 emulator

[Ron Natalie]

[-- Attachment #1: Type: text/plain, Size: 2483 bytes --]

The 45 also has split I/D.    The 11/ 70 is designed that if you can put 
a kernel that is cognizant only of the lower numbers in the line, it 
will still work.


------ Original Message ------
From "Kenneth Goodwin" <kennethgoodwin56@gmail.com>
To "Folkert van Heusden" <folkert@vanheusden.com>
Cc "The Eunuchs Hysterical Society" <tuhs@tuhs.org>
Date 4/7/2025 8:02:01 AM
Subject [TUHS] Re: running BSD 2.11 on my PDP 11/70 emulator

>To me it looks like a memory issue of some sort. Setup of the MMU etc.
>
>1. Your user memory is less than 10% of "available memory" which should 
>be the amount left after the kernel loads and allocates dynamic  
>buffers. User memory should be alot closer to available number. Unless 
>it is referring to limits of mmu per process and not total available 
>for all user level programs.
>
>2. The bulk of the text dump seems to just be random initialized data 
>dumped from Ram.
>Aka - Printf() format strings.  Indicates that the wrong address in 
>memory is potentially being accessed.
>
>Perhaps the pdp11 emulator configuration does not have a correct mmu 
>for your image file.
>
>For example,  you are running the 11/70 emulation and the binary image 
>you are running is actually compiled for a pdp 11/45.
>
>The 11/70 has an mmu supporting split instruction and data spaces. 64k 
>instruction,  64k data. But the kernel you are using was compiled to 
>run on a non split I And D version of the pdp11 supporting only 64kb of 
>combined user and data.
>
>On Mon, Apr 7, 2025, 3:30 AM Folkert van Heusden 
><folkert@vanheusden.com> wrote:
>>Hi,
>>
>>For fun I'm developing a PDP 11/70 emulator. It runs on everything 
>>from
>>ESP32 microcontrollers up to linux, windows, etc
>>https://vanheusden.com/emulation/PDP-11/kek/
>>Currently it can run UNIX 7 in multi user mode.
>>Of course I would like it to run BSD 2.11 as well (because of the
>>networking support). It boots, but after outputting the memory amounts
>>it produces a lot of garbage. It does eventually complete booting and
>>then allows you to log in.
>>I wonder if you sees this:
>>https://paste.nurd.space/mqIDB_0SjoDoJoasOGkiNQ_NjpRsCufAJCnKTA7ZxUI
>>(text) or
>>https://imgpaste.nurd.space/pics/437bcf0d149a017168cbbf2def8560917a037a3935c5c3aa1fbea2f7e43b485a.png
>>(image), does this ring a bell to anyone? I verified with simh that 
>>the
>>disk-image should work.
>>
>>
>>regards
>>
>>--
>>www.vanheusden.com

[-- Attachment #2: Type: text/html, Size: 4952 bytes --]

[TUHS] Re: running BSD 2.11 on my PDP 11/70 emulator

[Kenneth Goodwin]

[-- Attachment #1: Type: text/plain, Size: 4339 bytes --]

It is the BSD kernel or the emulator setup I question as to being correct.
The clues being
An almost 4 mb available memory coupled to a roughly 300 kb user space. The
300kb doesn't make sense at all from the limits of the split i/d memory
layout. It's roughly 10% of available.
It's inferring that the kernel itself is being configured as a 3.5 mb
runtime image.
Almost as if dynamic kernel level  buffers are being over allocated by a
configuration parameter or a miscalculation.

The other clue being the dump of the printf style format strings from the
data portion of the involved user space program images as it boots. That's
the sign of a wrong address potentially being used. An address fault
causing an abend happening to multiple binaries being launched for example

These are the anomalies I see.

The solution requires someone very familiar with the bsd 2.11 boot up
sequence and the underlying executables involved. I am a V6, v7. System V
head.

Unfortunately Mr. Jolitz is no longer with us.

As I recall, the bsd folks were back porting some of the features of the
Vax virtual version of the bsd kernel as appropriate to the pdp version. I
dont recall what was involved in that effort.  The source code environment
for 2.11 would help.

I also don't know if those failure messages are coming from the bsd image
handling address faults etc. or the actual emulator underneath detecting
problems in the binary as it executes it.

So the questions to be answered are

1. Why is the user memory only 10% of the available?

2. What is dumping and the "why of it" the text strings in the data space
portion of the program image?

I don't the answer. But it all strikes me as odd.

On Mon, Apr 7, 2025, 12:15 PM Ron Natalie <ron@ronnatalie.com> wrote:

> The 45 also has split I/D.    The 11/ 70 is designed that if you can put a
> kernel that is cognizant only of the lower numbers in the line, it will
> still work.
>
>
> ------ Original Message ------
> From "Kenneth Goodwin" <kennethgoodwin56@gmail.com>
> To "Folkert van Heusden" <folkert@vanheusden.com>
> Cc "The Eunuchs Hysterical Society" <tuhs@tuhs.org>
> Date 4/7/2025 8:02:01 AM
> Subject [TUHS] Re: running BSD 2.11 on my PDP 11/70 emulator
>
> To me it looks like a memory issue of some sort. Setup of the MMU etc.
>
> 1. Your user memory is less than 10% of "available memory" which should be
> the amount left after the kernel loads and allocates dynamic  buffers. User
> memory should be alot closer to available number. Unless it is referring to
> limits of mmu per process and not total available for all user level
> programs.
>
> 2. The bulk of the text dump seems to just be random initialized data
> dumped from Ram.
> Aka - Printf() format strings.  Indicates that the wrong address in memory
> is potentially being accessed.
>
> Perhaps the pdp11 emulator configuration does not have a correct mmu for
> your image file.
>
> For example,  you are running the 11/70 emulation and the binary image you
> are running is actually compiled for a pdp 11/45.
>
> The 11/70 has an mmu supporting split instruction and data spaces. 64k
> instruction,  64k data. But the kernel you are using was compiled to run on
> a non split I And D version of the pdp11 supporting only 64kb of combined
> user and data.
>
> On Mon, Apr 7, 2025, 3:30 AM Folkert van Heusden <folkert@vanheusden.com>
> wrote:
>
>> Hi,
>>
>> For fun I'm developing a PDP 11/70 emulator. It runs on everything from
>> ESP32 microcontrollers up to linux, windows, etc
>> https://vanheusden.com/emulation/PDP-11/kek/
>> Currently it can run UNIX 7 in multi user mode.
>> Of course I would like it to run BSD 2.11 as well (because of the
>> networking support). It boots, but after outputting the memory amounts
>> it produces a lot of garbage. It does eventually complete booting and
>> then allows you to log in.
>> I wonder if you sees this:
>> https://paste.nurd.space/mqIDB_0SjoDoJoasOGkiNQ_NjpRsCufAJCnKTA7ZxUI
>> (text) or
>>
>> https://imgpaste.nurd.space/pics/437bcf0d149a017168cbbf2def8560917a037a3935c5c3aa1fbea2f7e43b485a.png
>> (image), does this ring a bell to anyone? I verified with simh that the
>> disk-image should work.
>>
>>
>> regards
>>
>> --
>> www.vanheusden.com
>>
>

[-- Attachment #2: Type: text/html, Size: 6813 bytes --]

[TUHS] Re: running BSD 2.11 on my PDP 11/70 emulator

[Phil Budne]

A fun thing 2.11BSD does is it runs networking in supervisor code
in supervisor mode so that mbufs don't need to appear in the kernel
address space.  It was the first thing that came to my mind when
you mentioned having trouble.

This is what I see booting 2.11 under SimH:

    44Boot from ra(0,0,0) at 0172150
    : unix
    Boot: bootdev=02400 bootcsr=0172150

    2.11 BSD UNIX #19: Sun Jun 17 16:44:43 PDT 2012 
	root@pdp11:/usr/src/sys/ZEKE

    ra0: Ver 3 mod 3
    ra0: RA82  size=1954000
    attaching de0 csr 174510
    attaching lo0

    phys mem  = 3932160
    avail mem = 3553344
    user mem  = 307200

    May 26 12:08:51 init: configure system

    dz 0 csr 160100 vector 310 attached
    ra 0 csr 172150 vector 154 vectorset attached
    erase, kill ^U, intr ^C
    # 

A quick look at the code (the best documentation):

"user mem" output is the result of:
    printf("user mem  = %D\n", ctob((long)MAXMEM));
in init_main.c

MAXMEM is defined in param.h:
    /*
     * MAXMEM is the maximum core per process is allowed.  First number is Kb.
    */
    #define	MAXMEM		(300*16)

So the number being output seems like the intended value.

[TUHS] Re: running BSD 2.11 on my PDP 11/70 emulator

[Folkert van Heusden]

1. sounds like a calculation bug of some sort. possible, but not likely: 
I patched simh to output a set of large JSON-files with tests and their 
outcomes so that I can verify my emulator with the gold standard of pdp 
emulation without simply copying the simh-code (hopefully one day I can 
produce that set with a real hardware pdp 11/7). sofar I fixed all 
problems I found (a few flag problems and handling of the PSW).

2. yeah I have a suspicion that it might be a problem in one of the more 
complex addressing modes (@xxx(R7) for example where some of it comes 
from I space and some of D-space). am writing tests or that now.
regarding the 11/45 versus 11/70: I set the cpu to 11/70 when verifying 
the disk-image with simh. so it should run in a 11/70.

3. if I do that, the "avail mem" goes down with it, user mem stays 
307200.

[1*: 
https://vanheusden.com/git/folkert/simh-testsetgenerator/src/branch/valgen 
look for test.c]

On 2025-04-07 14:02, Kenneth Goodwin wrote:

> To me it looks like a memory issue of some sort. Setup of the MMU etc.
> 
> 1. Your user memory is less than 10% of "available memory" which should 
> be the amount left after the kernel loads and allocates dynamic  
> buffers. User memory should be alot closer to available number. Unless 
> it is referring to limits of mmu per process and not total available 
> for all user level programs.
> 
> 2. The bulk of the text dump seems to just be random initialized data 
> dumped from Ram.
> Aka - Printf() format strings.  Indicates that the wrong address in 
> memory is potentially being accessed.
> 
> Perhaps the pdp11 emulator configuration does not have a correct mmu 
> for your image file.
> 
> For example,  you are running the 11/70 emulation and the binary image 
> you are running is actually compiled for a pdp 11/45.
> 
> The 11/70 has an mmu supporting split instruction and data spaces. 64k 
> instruction,  64k data. But the kernel you are using was compiled to 
> run on a non split I And D version of the pdp11 supporting only 64kb of 
> combined user and data.
> 

[ this suggestion came from Kenneth's 2nd reply, added in this message 
to prevent a lot of reply-mails by me ]

> 3. If your bsd image has kernel dynamic buffer configuration limit 
> parameters,  you could tweak those down say 50% to see what happens.  
> (Not a BSD kernel hacker and it's been a while since I last read over 
> the source code)

[TUHS] Re: running BSD 2.11 on my PDP 11/70 emulator

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 3483 bytes --]

Do you pass the DEC diagnostics?  They are not perfect, but they can
sometimes tease out some of the interesting corner cases, although the OS's
are known to be even better at that, albeit with less interesting
diagnostics.  Also, did you try Ultrix, which is one step farther than V7
but not quite as far as 2.11BSD?  Another thing I learned from reading your
comments that got me thinking a little: IIRC the red/yellow zone stuff for
the stack is different between PDP-11 implementations.   As Phil noted,
2.11BSD differs from V7 and Ultrix in that they tried adding more Vax logic
into it. >>I have not looked at the 2.11BSD sources<< to check, but it
possible/likely that Steven and team redid that code.  So I would check to
see what V7 is doing on a 70 when it gets a stack fault and needs to grow
it vs. the 2.11BSD code.
ᐧ

On Tue, Apr 8, 2025 at 3:11 PM Folkert van Heusden <folkert@vanheusden.com>
wrote:

> 1. sounds like a calculation bug of some sort. possible, but not likely:
> I patched simh to output a set of large JSON-files with tests and their
> outcomes so that I can verify my emulator with the gold standard of pdp
> emulation without simply copying the simh-code (hopefully one day I can
> produce that set with a real hardware pdp 11/7). sofar I fixed all
> problems I found (a few flag problems and handling of the PSW).
>
> 2. yeah I have a suspicion that it might be a problem in one of the more
> complex addressing modes (@xxx(R7) for example where some of it comes
> from I space and some of D-space). am writing tests or that now.
> regarding the 11/45 versus 11/70: I set the cpu to 11/70 when verifying
> the disk-image with simh. so it should run in a 11/70.
>
> 3. if I do that, the "avail mem" goes down with it, user mem stays
> 307200.
>
> [1*:
> https://vanheusden.com/git/folkert/simh-testsetgenerator/src/branch/valgen
> look for test.c]
>
> On 2025-04-07 14:02, Kenneth Goodwin wrote:
>
> > To me it looks like a memory issue of some sort. Setup of the MMU etc.
> >
> > 1. Your user memory is less than 10% of "available memory" which should
> > be the amount left after the kernel loads and allocates dynamic
> > buffers. User memory should be alot closer to available number. Unless
> > it is referring to limits of mmu per process and not total available
> > for all user level programs.
> >
> > 2. The bulk of the text dump seems to just be random initialized data
> > dumped from Ram.
> > Aka - Printf() format strings.  Indicates that the wrong address in
> > memory is potentially being accessed.
> >
> > Perhaps the pdp11 emulator configuration does not have a correct mmu
> > for your image file.
> >
> > For example,  you are running the 11/70 emulation and the binary image
> > you are running is actually compiled for a pdp 11/45.
> >
> > The 11/70 has an mmu supporting split instruction and data spaces. 64k
> > instruction,  64k data. But the kernel you are using was compiled to
> > run on a non split I And D version of the pdp11 supporting only 64kb of
> > combined user and data.
> >
>
> [ this suggestion came from Kenneth's 2nd reply, added in this message
> to prevent a lot of reply-mails by me ]
>
> > 3. If your bsd image has kernel dynamic buffer configuration limit
> > parameters,  you could tweak those down say 50% to see what happens.
> > (Not a BSD kernel hacker and it's been a while since I last read over
> > the source code)
>

[-- Attachment #2: Type: text/html, Size: 4554 bytes --]

[TUHS] Re: running BSD 2.11 on my PDP 11/70 emulator

[Kenneth Goodwin]

[-- Attachment #1: Type: text/plain, Size: 3601 bytes --]

Sorry I dont have time to look at source code.
Usermem is a hard coded compile time static unless ctob() is pulling in
some boot time variable from all appearances.

Compare your output from the boot to the other parties to see what is
different. As well as your emulator and bsd configurations. I think his
name was Phil... sorry in advance 😅 😔

 (Sorry. Can't split screen on this smart phone)

I am personnel curious as to WHY USER MAXMEM  has this hard coded value of
300kb
It's bigger than the 128k limit of split i/d.

Last bsd kernel I looked at years ago was 2.9
And the pieces that Pyramid Tech used for their dual universe 32 bit
virtual based on the bsd Vax releases.

Does 2.11 have some form of shared memory that is bank selected so that a
physical process can be as large as 300kb ?  Or is it limiting the
aggregate memory of user process, mbufs. Disk buffers and other kernel
resources an Individual process can utilize??


On Tue, Apr 8, 2025, 3:11 PM Folkert van Heusden <folkert@vanheusden.com>
wrote:

> 1. sounds like a calculation bug of some sort. possible, but not likely:
> I patched simh to output a set of large JSON-files with tests and their
> outcomes so that I can verify my emulator with the gold standard of pdp
> emulation without simply copying the simh-code (hopefully one day I can
> produce that set with a real hardware pdp 11/7). sofar I fixed all
> problems I found (a few flag problems and handling of the PSW).
>
> 2. yeah I have a suspicion that it might be a problem in one of the more
> complex addressing modes (@xxx(R7) for example where some of it comes
> from I space and some of D-space). am writing tests or that now.
> regarding the 11/45 versus 11/70: I set the cpu to 11/70 when verifying
> the disk-image with simh. so it should run in a 11/70.
>
> 3. if I do that, the "avail mem" goes down with it, user mem stays
> 307200.
>
> [1*:
> https://vanheusden.com/git/folkert/simh-testsetgenerator/src/branch/valgen
> look for test.c]
>
> On 2025-04-07 14:02, Kenneth Goodwin wrote:
>
> > To me it looks like a memory issue of some sort. Setup of the MMU etc.
> >
> > 1. Your user memory is less than 10% of "available memory" which should
> > be the amount left after the kernel loads and allocates dynamic
> > buffers. User memory should be alot closer to available number. Unless
> > it is referring to limits of mmu per process and not total available
> > for all user level programs.
> >
> > 2. The bulk of the text dump seems to just be random initialized data
> > dumped from Ram.
> > Aka - Printf() format strings.  Indicates that the wrong address in
> > memory is potentially being accessed.
> >
> > Perhaps the pdp11 emulator configuration does not have a correct mmu
> > for your image file.
> >
> > For example,  you are running the 11/70 emulation and the binary image
> > you are running is actually compiled for a pdp 11/45.
> >
> > The 11/70 has an mmu supporting split instruction and data spaces. 64k
> > instruction,  64k data. But the kernel you are using was compiled to
> > run on a non split I And D version of the pdp11 supporting only 64kb of
> > combined user and data.
> >
>
> [ this suggestion came from Kenneth's 2nd reply, added in this message
> to prevent a lot of reply-mails by me ]
>
> > 3. If your bsd image has kernel dynamic buffer configuration limit
> > parameters,  you could tweak those down say 50% to see what happens.
> > (Not a BSD kernel hacker and it's been a while since I last read over
> > the source code)
>

[-- Attachment #2: Type: text/html, Size: 4592 bytes --]

[TUHS] Re: running BSD 2.11 on my PDP 11/70 emulator

[Folkert van Heusden]

[-- Attachment #1: Type: text/plain, Size: 5572 bytes --]

Most of them do, the ones for instruction-emulation that is. MMU 
emulation not completely.

I'll make a note to try Ultrix.

This is also an update: I did fixes for MMR1 handling. It was reset at 
the wrong moment and not set correctly. Also I was throwing trap 4 
instead of 250 for mmu errors - that doesn't help either :-)

Now "make" starts without bus errors altough after cc fails with a 
"pushfile" error:

2.11 BSD UNIX (folkert.vanheusden.com) (console)

login: root
erase, kill ^U, intr ^C
# cd /usr/src/sys
# ls
CURLY       QT          h           netimp      pdpif       sys
FVH         autoconfig  machine     netinet     pdpmba      vaxif
GENERIC     bootrom     mdec        netns       pdpstand    vaxuba
OTHERS      conf        net         pdp         pdpuba
# cd FVH
# make
make -f Make.net I=/usr/include H=../h M=../machine AS="/bin/as -V"  
CPP="/lib/cpp -P -DKERNEL -DFVH -DINET -DSOFUB_MAP -I. -I../h 
-DSUPERVISOR" CFLAGS="-O -DKERNEL -DFVH -DINET -DSOFUB_MAP -I. -I../h 
-DSUPERVISOR"  SED="/bin/sed" ED="/bin/ed"
cc -O -DKERNEL -DFVH -DINET -DSOFUB_MAP -I. -I../h -DSUPERVISOR -S 
../net/if_loop.c
<command line>:1: warning: __BSD2_11__ redefined (previously defined at 
"<command line>" line 6)
<command line>:2: warning: BSD2_11 redefined (previously defined at 
"<command line>" line 7)
<command line>:3: warning: __pdp11__ redefined (previously defined at 
"<command line>" line 8)
<command line>:4: warning: pdp11 redefined (previously defined at 
"<command line>" line 9)
<command line>:5: warning: unix redefined (previously defined at 
"<command line>" line 10)
<command line>:6: warning: __STDC__ redefined (previously defined at 
"<command line>" line 11)
pushfile: error open >z(5\|
*** Exit 1

Stop.
*** Exit 1

Stop.

Progress!

On 2025-04-08 23:33, Clem Cole wrote:

> Do you pass the DEC diagnostics?  They are not perfect, but they can 
> sometimes tease out some of the interesting corner cases, although the 
> OS's are known to be even better at that, albeit with less interesting 
> diagnostics.  Also, did you try Ultrix, which is one step farther than 
> V7 but not quite as far as 2.11BSD?  Another thing I learned from 
> reading your comments that got me thinking a little: IIRC the 
> red/yellow zone stuff for the stack is different between PDP-11 
> implementations.   As Phil noted, 2.11BSD differs from V7 and Ultrix in 
> that they tried adding more Vax logic into it. >>I have not looked at 
> the 2.11BSD sources<< to check, but it possible/likely that Steven and 
> team redid that code.  So I would check to see what V7 is doing on a 70 
> when it gets a stack fault and needs to grow it vs. the 2.11BSD code.
> ᐧ
> 
> On Tue, Apr 8, 2025 at 3:11 PM Folkert van Heusden 
> <folkert@vanheusden.com> wrote:
> 
>> 1. sounds like a calculation bug of some sort. possible, but not 
>> likely:
>> I patched simh to output a set of large JSON-files with tests and 
>> their
>> outcomes so that I can verify my emulator with the gold standard of 
>> pdp
>> emulation without simply copying the simh-code (hopefully one day I 
>> can
>> produce that set with a real hardware pdp 11/7). sofar I fixed all
>> problems I found (a few flag problems and handling of the PSW).
>> 
>> 2. yeah I have a suspicion that it might be a problem in one of the 
>> more
>> complex addressing modes (@xxx(R7) for example where some of it comes
>> from I space and some of D-space). am writing tests or that now.
>> regarding the 11/45 versus 11/70: I set the cpu to 11/70 when 
>> verifying
>> the disk-image with simh. so it should run in a 11/70.
>> 
>> 3. if I do that, the "avail mem" goes down with it, user mem stays
>> 307200.
>> 
>> [1*:
>> https://vanheusden.com/git/folkert/simh-testsetgenerator/src/branch/valgen
>> look for test.c]
>> 
>> On 2025-04-07 14:02, Kenneth Goodwin wrote:
>> 
>>> To me it looks like a memory issue of some sort. Setup of the MMU 
>>> etc.
>>> 
>>> 1. Your user memory is less than 10% of "available memory" which 
>>> should
>>> be the amount left after the kernel loads and allocates dynamic
>>> buffers. User memory should be alot closer to available number. 
>>> Unless
>>> it is referring to limits of mmu per process and not total available
>>> for all user level programs.
>>> 
>>> 2. The bulk of the text dump seems to just be random initialized data
>>> dumped from Ram.
>>> Aka - Printf() format strings.  Indicates that the wrong address in
>>> memory is potentially being accessed.
>>> 
>>> Perhaps the pdp11 emulator configuration does not have a correct mmu
>>> for your image file.
>>> 
>>> For example,  you are running the 11/70 emulation and the binary 
>>> image
>>> you are running is actually compiled for a pdp 11/45.
>>> 
>>> The 11/70 has an mmu supporting split instruction and data spaces. 
>>> 64k
>>> instruction,  64k data. But the kernel you are using was compiled to
>>> run on a non split I And D version of the pdp11 supporting only 64kb 
>>> of
>>> combined user and data.
>>> 
>> 
>> [ this suggestion came from Kenneth's 2nd reply, added in this message
>> to prevent a lot of reply-mails by me ]
>> 
>>> 3. If your bsd image has kernel dynamic buffer configuration limit
>>> parameters,  you could tweak those down say 50% to see what happens.
>>> (Not a BSD kernel hacker and it's been a while since I last read over
>>> the source code)

-- 

www.vanheusden.com [1]

Links:
------
[1] http://www.vanheusden.com

[-- Attachment #2.1: Type: text/html, Size: 9611 bytes --]

[-- Attachment #2.2: blocked.gif --]
[-- Type: image/gif, Size: 118 bytes --]

[TUHS] Re: running BSD 2.11 on my PDP 11/70 emulator

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 2024 bytes --]

On Tue, Apr 15, 2025 at 4:05 PM Folkert van Heusden <folkert@vanheusden.com>
wrote:

> Most of them do, the ones for instruction-emulation that is. MMU emulation
> not completely
>

That is a little worrisome to me.  But of course, which ones.  While I knew
and probably worked with and thus probably have met who wrote the
diagnostics, I do not think I can not come up with a name of the guilty
party here to ask.

As I said, where to loo, the stack grow logic is the real suspect because
as the system runs, and it's not until you start to put a load on and start
to swap a little that you are getting some failures.    So some type of
pressure is occurring. I guess that a number of mallocs have caused
breaks to enlarge memory, but that happens a lot with so many commands. I
reluctantly think there is something else wonky.  Stack growth is
surprisingly rare due to how processes are created. IIRC a stack on a
separate I/D system is often about a few K to start which is  usually
"enough."    Big compiles like the kernel, however, might push that limit,
and the red/yellow zone stuff starts to get worked out.

What I don't know is if there are diagnostics for that logic.   I also know
is the best description of what is >>supposed<< to happen is pages 278-279
of my 1981 processor handbook. (a.k.a. EB-19402-20 —
https://bitsavers.org/pdf/dec/pdp11/handbooks/EB-19402-20_PDP-11_Processor_Handbook_1981.pdf
 ).

I think there are two parts to this... You have the CPU itself generating
16-bit addresses (user mode) being mapped through your MMU.  If the MMU has
a  >>slightly<< wonky corner case, I wonder if that is tripping up stack
fault logic somehow, so 2.11BSD is getting confused.      Since this is
happening to >>user space<< code (we never "grow" kernel stacks), it's not
fatal to the OS, but it will cause processes to go south.

I can not guarantee this is the issue, but it certainly would be a scenario
that would explain what you are seeing.

Clem

> ᐧ

[-- Attachment #2: Type: text/html, Size: 4681 bytes --]