[..] > I tried applying the patch to stable and current last night, both > resulting in failed apply and reject files. I don't think I have a > big enough partition for my /usr/src directory to actually compile the > kernel. The auto-layout created 2G, but I don't have much leftover > when bringing down the source tree. At this point, I may just > re-install and give myself plenty more space for the source partition. > > I tried searching the mailing list archive, I didn't find an answer to > why macppc is limited to 2G memory? > > Thanks, > Tony
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". 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); } This seems to go through available memory which has a start memory address and a size so it discards everything over 2GB (0x80000000) in the continue, and if anything starts below the 2GB and grows beyond 2GB it will adjust the size to be exactly at 2GB end. Then it will uvm_page_physload() all these regions. 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)) Hope this helps, -peter
