Den 2023-03-07 kl. 18:23, skrev Johnny Billquist:
On 2023-03-07 18:01, Mouse wrote:I guess that with 0.5 GB, it's hitting memory boundaries between S0/1 and P0/1, but I haven't yet dived deep into the NetBSD source code.Maybe. That shouldn't be a problem, for two reasons. One is that as I understand it the P0/P1/system/reserved distinction is a virtual address thing, not applicable to physical addresses. The other is that each of those four (P0, P1, system, reserved) is a full gig, so half a gig should fit with room to spare. I do think NetBSD likes to map all physical memory into kernel VM, so the "it's a VM thing" might matter, but even then that shouldn't cause trouble unless it maps it all twice or some such, or puts KERNBASE well above the 0x8000000 I'd expect.Guys, slow down! The P0/P1/S0/S1 space is in virtual space.The 512M is physical memory. Physical address space is a total of just 1G, with half dedicated to memory, and half to I/O space.So 512M is the absolute maximum the machines can have. And there is some problem with this in NetBSD.But don't go mixing the P0/P1/S0 space in here, because that is only virtual addresses.I have booted VMS under simh (using an 8650) with 512M, and it works fine. I can kick that off right now if anyone wants me to.With NetBSD I have had problems even with less than 512M, but the exact mode of failure might vary. But something goes wrong when there is too much memory. 128M works fine. I seem to remember that I've never even got 256M to boot with any version.I doubt it's anything recent. I think the problem have been there since before the dawn of time with NetBSD/vax.When I have some time, I'd be happy to help out a bit more, and try to dig through my memory of things around this that I've done in the past, but a little short on time right now.I think I might have talked with Ragge about it in the past as well, and it might be that he have some more ideas...
Maybe.It just sounds odd to me as well, but there is one thing that should not affect the kernel, but maybe - the kernel maps all of physical memory onto S0 space. I don't know how that would affect the CAS code.
You were involved in writing the CAS code Johnny, weren't you? -- R