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(a)vanheusden.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(a)gmail.com> To "Folkert van Heusden" <folkert(a)vanheusden.com> Cc "The Eunuchs Hysterical Society" <tuhs(a)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(a)vanheusden.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.

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)

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 &lt;folkert(a)vanheusden.com&gt; 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)

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: [ this suggestion came from Kenneth's 2nd reply, added in this message to prevent a lot of reply-mails by me ]