On Thu, May 20, 2021 at 09:40:57PM -0400, George Koehler wrote:
[..]
> Those of you who applied the older diff will probably get a conflict
> from cvs update, like "C sys/arch/powerpc/powerpc/lock_machdep.c".
> I would either clean it like "cvs up -C lock_machdep.c", or just rm(1)
> it and cvs(1) up again.
>
> I have no trouble fitting the src tree into the default 2G /usr/src.
Ditto. It even has enough space to have the 6.9 src.tar.gz and sys.tar.gz in
there as well.
> > As far as the 2GB memory limit in macppc is concerned I had to search a
> > little
> > for this proof, I think I have found the right spot but it may turn out the
> > wrong spot if someone more experienced with kernel programming reads this.
> > I have a G5 btw that has 4GB of RAM and only 2GB get detected. Now for the
> > source.. macppc is really a sub-arch of powerpc (just like octeon is a
> > sub-arch
> > of mips64) and in powerpc in the pmap.c routines I found this at the bottom
> > of
> > /usr/src/sys/arch/powerpc/powerpc/pmap.c line 1612: function
> > pmap_bootstrap():
> >
> > for (mp = pmap_avail; mp->size; mp++) {
> > if (mp->start > 0x80000000)
> > continue;
> > if (mp->start + mp->size > 0x80000000)
> > mp->size = 0x80000000 - mp->start;
> > uvm_page_physload(atop(mp->start), atop(mp->start+mp->size),
> > atop(mp->start), atop(mp->start+mp->size), 0);
> > }
>
> That's part of it. /sys/arch/macppc/macppc/ofw_machdep.c line 174 is
> another part. It ignores RAM ">= 1ULL << 32" which is outside the
> 32-bit range. My G5 has 5G of RAM split this way:
>
> 2G RAM at physical addresses 0x0000_0000 .. 0x7fff_ffff
> 3G RAM at physical addresses 0x1_0000_0000 .. 0x1_bfff_ffff
>
> The code in ofw_machdep.c discards the higher 3G and passes only the
> lower 2G to the code in pmap.c.
>
> The kernel virtual address space has 2 halves: the 1st half
> 0x0000_0000 .. 0x7fff_ffff, is a direct map of all RAM up to 2G. The
> 2nd half 0x8000_0000 .. 0xffff_ffff is for other kernel mappings. If
> there is RAM > 0x8000_0000, then it doesn't fit in the direct map, so
> the kernel can't use it. Therefore, pmap.c would limit us to 2G RAM
> even if ofw_machdep.c would pass more than 2G.
Awesome! and Oops! I knew I didn't find the right spot, well at least I got
50% right if even.
> > The rest, if there is more memory, is not mapped. Really there is a few
> > drawbacks to having more than 2GB memory in the machine if it's dedicated to
> > OpenBSD (one having to do with partitioning, in the past /tmp was not
> > created
> > because the system had trouble detecting memory (really it was becuse of
> > swap))
>
> The /tmp bug got fixed by Theo de Raadt before OpenBSD 6.9,
> https://marc.info/?l=openbsd-cvs&m=161526563325599&w=2
Absolutely awesome! I think I may reinstall my macppc in a bit. I finally
got a shipment of keyboards this morning at 9AM so my G5 is back in action.
> --George
>
Best Regards,
-peter
