<div dir="auto"><div>Sorry I dont have time to look at source code.</div><div dir="auto">Usermem is a hard coded compile time static unless ctob() is pulling in some boot time variable from all appearances.<br><div dir="auto"><br></div><div dir="auto">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 😅 😔 </div><div dir="auto"><br></div><div dir="auto"> (Sorry. Can't split screen on this smart phone)</div><div dir="auto"><br></div><div dir="auto">I am personnel curious as to WHY USER MAXMEM  has this hard coded value of 300kb</div><div dir="auto">It's bigger than the 128k limit of split i/d.</div><div dir="auto"><br></div><div dir="auto">Last bsd kernel I looked at years ago was 2.9</div><div dir="auto">And the pieces that Pyramid Tech used for their dual universe 32 bit virtual based on the bsd Vax releases.</div><div dir="auto"><br></div><div dir="auto">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??</div><br><br><div class="gmail_quote gmail_quote_container" dir="auto"><div dir="ltr" class="gmail_attr">On Tue, Apr 8, 2025, 3:11 PM Folkert van Heusden <<a href="mailto:folkert@vanheusden.com">folkert@vanheusden.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">1. sounds like a calculation bug of some sort. possible, but not likely: <br>
I patched simh to output a set of large JSON-files with tests and their <br>
outcomes so that I can verify my emulator with the gold standard of pdp <br>
emulation without simply copying the simh-code (hopefully one day I can <br>
produce that set with a real hardware pdp 11/7). sofar I fixed all <br>
problems I found (a few flag problems and handling of the PSW).<br>
<br>
2. yeah I have a suspicion that it might be a problem in one of the more <br>
complex addressing modes (@xxx(R7) for example where some of it comes <br>
from I space and some of D-space). am writing tests or that now.<br>
regarding the 11/45 versus 11/70: I set the cpu to 11/70 when verifying <br>
the disk-image with simh. so it should run in a 11/70.<br>
<br>
3. if I do that, the "avail mem" goes down with it, user mem stays <br>
307200.<br>
<br>
[1*: <br>
<a href="https://vanheusden.com/git/folkert/simh-testsetgenerator/src/branch/valgen" rel="noreferrer noreferrer" target="_blank">https://vanheusden.com/git/folkert/simh-testsetgenerator/src/branch/valgen</a> <br>
look for test.c]<br>
<br>
On 2025-04-07 14:02, Kenneth Goodwin wrote:<br>
<br>
> To me it looks like a memory issue of some sort. Setup of the MMU etc.<br>
> <br>
> 1. Your user memory is less than 10% of "available memory" which should <br>
> be the amount left after the kernel loads and allocates dynamic  <br>
> buffers. User memory should be alot closer to available number. Unless <br>
> it is referring to limits of mmu per process and not total available <br>
> for all user level programs.<br>
> <br>
> 2. The bulk of the text dump seems to just be random initialized data <br>
> dumped from Ram.<br>
> Aka - Printf() format strings.  Indicates that the wrong address in <br>
> memory is potentially being accessed.<br>
> <br>
> Perhaps the pdp11 emulator configuration does not have a correct mmu <br>
> for your image file.<br>
> <br>
> For example,  you are running the 11/70 emulation and the binary image <br>
> you are running is actually compiled for a pdp 11/45.<br>
> <br>
> The 11/70 has an mmu supporting split instruction and data spaces. 64k <br>
> instruction,  64k data. But the kernel you are using was compiled to <br>
> run on a non split I And D version of the pdp11 supporting only 64kb of <br>
> combined user and data.<br>
> <br>
<br>
[ this suggestion came from Kenneth's 2nd reply, added in this message <br>
to prevent a lot of reply-mails by me ]<br>
<br>
> 3. If your bsd image has kernel dynamic buffer configuration limit <br>
> parameters,  you could tweak those down say 50% to see what happens.  <br>
> (Not a BSD kernel hacker and it's been a while since I last read over <br>
> the source code)<br>
</blockquote></div></div></div>