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. -- Please keep replies on the mailing list.