9 Apr
2025
9 Apr
'25
3:11 a.m.
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(a)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)