Re: Memory upgrade

On 10/17/24 18:10, Christian Schulte wrote:
> On 10/17/24 17:03, Stuart Henderson wrote:
>> 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.

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