On Thu, 20 May 2021 08:19:18 +0200 "Peter J. Philipp" <p...@delphinusdns.org> wrote:
> Hi Tony, > > 2G for /usr/src is not enough for binaries with source, but it is enough for > source. Your binaries that get compiled usually go in /usr/obj. However if > you get reject files it's probably not worth it, depending on your level and > expertise to fix these up. My gut feeling tells me that if you wait a few > days and then try a snapshot that this patch will be in there, once you get > a snapshot and it runs well bring your sources tree up to date with CVS as > well, you don't have to delete the sources you have now, just run cvs udpdate > over them: https://www.openbsd.org/anoncvs.html look under "Updating an > existing tree". I committed this diff after adding a 2nd membar_exit(), https://marc.info/?l=openbsd-tech&m=162154279522379&w=2 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. > 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. > 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 --George
