On 10/17/24 18:10, Christian Schulte wrote: > On 10/17/24 17:03, Stuart Henderson wrote: >> On 2024-10-17, Christian Schulte <c...@schulte.it> wrote: >>> On 10/17/24 09:40, Stuart Henderson wrote: >>>> On 2024-10-16, Christian Schulte <c...@schulte.it> wrote: >>>>> >>>>> No. That's what seems to went wrong when going from i386 to amd64. >>>>> The 3GB hard limit of i386 was in the range of available physical >>>>> memory (4GB) without swap. The 128GB on amd64 do not. Changing this >>>>> to what "memory" reads, makes no difference, though. >>>> >>>> A 32-bit architecture allows for 2^32 bytes, or 4GB, of address space >>>> in a process. Memory addresses are stored in 32-bit variables - a >>>> single process can't use memory beyond this. Even on OS which use PAE >>>> to allow for larger _overall_ memory, and regardless of whether that >>>> memory is RAM or swap space on disk, the maximum that a single 32-bit >>>> process can use is still 4GB. >>>> >>> >>> Could really need some guidance on this. Trying to make the mails as >>> small as possible. >>> >>> We are talking about this commit, right? >>> >>> <https://github.com/openbsd/src/commit/b426ab7bc6c256bfb7af9a9f082a20534b39a28b> >> >> That's nothing to do with the paragraph of mine quoted above. >> >>> Reading all of this takes a lot of time. So I "switched" to a brute >>> force approach. Make it panic and drop to the debugger. This diff: >>> >>> >>> Index: sys/arch/amd64/amd64/machdep.c >>> =================================================================== >>> RCS file: /cvs/src/sys/arch/amd64/amd64/machdep.c,v >>> retrieving revision 1.297 >>> diff -u -p -u -r1.297 machdep.c >>> --- sys/arch/amd64/amd64/machdep.c 21 Sep 2024 19:06:07 -0000 1.297 >>> +++ sys/arch/amd64/amd64/machdep.c 17 Oct 2024 10:55:05 -0000 >>> @@ -214,7 +214,9 @@ struct vm_map *phys_map = NULL; >>> >>> /* UVM constraint ranges. */ >>> struct uvm_constraint_range isa_constraint = { 0x0, 0x00ffffffUL }; >>> -struct uvm_constraint_range dma_constraint = { 0x0, 0xffffffffUL }; >>> +// struct uvm_constraint_range dma_constraint = { 0x0, 0xffffffffUL }; >>> +struct uvm_constraint_range dma_constraint = { 0x0, (paddr_t)-1 }; >>> + >>> struct uvm_constraint_range *uvm_md_constraints[] = { >>> &isa_constraint, >>> &dma_constraint, >> >> Here lie dragons. I don't understand this area particularly well but >> think you are definitely in "you get to keep the broken fragments >> of your filesystem if things go badly wrong" territory. I recommend >> backups.
Ok. Just tell me what I need to do to make a kernel with that diff applied panic and drop to the debugger. A make build in parallel with Gimp opened up a ton of images to make the system swap still does not drop me to the debugger. -- Christian
