Re: Memory upgrade

On 2024-10-17, Christian Schulte <cs@schulte.it> wrote:
> On 10/17/24 09:40, Stuart Henderson wrote:
>> On 2024-10-16, Christian Schulte <cs@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.