Re: Memory upgrade

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.
>

I just don't get the point for trying to support 32bit hardware on a
64bit system. If the hardware does not support 64bit but is limited to
32bit, use i386. If the hardware supports 64bit, just don't limit it to
32bit. Does not make sense to me making a 64bit OS support 32bit
devices. Of course, there is an upgrade path. amd64 just should fail to
boot on any hardware not 100% 64bit capable. For such hardware use i386.
Either the hardware is fully 64bit ready, or it is not. In my opinion
amd64 should really give up on anything 32bit and should really just
refuse to boot non 100% 64bit capable systems at all.

--
Christian