Re: Memory upgrade

On 10/12/24 18:33, Philip Guenther wrote:
> On Sat, Oct 12, 2024 at 3:58 AM Christian Schulte <cs@schulte.it> wrote:
>>
>> On 10/11/24 15:05, Claudio Jeker wrote:
>>> On Fri, Oct 11, 2024 at 03:00:23PM +0200, Christian Schulte wrote:
>>>> On 10/11/24 13:57, Stuart Henderson wrote:
>>>>> On 2024-10-09, obsdml@loopw.com <obsdml@loopw.com> wrote:
>>>>>>> In a second server I have upgraded from 7.5 i386 to 7.6 i386 but server sees only 4GB of RAM
>>>>>>
>>>>>>> Is anybody with similar experiences? Any ideas how to fix RAM?
>>>>>>
>>>>>> run 64bit OpenBSD
>>>>>>
>>>>>> 32bit address space is limited to a max of 4GB**, and some of that is eaten up by PCI devices, etc.
>>>>>> ** PAE can work around this, but I'm not sure if OpenBSD supports PAE at all (and theres other issues/caveats with using PAE of course, including speed and security)
>>>>>
>>>>> OpenBSD does support PAE on i386, but not for increasing address space,
>>>>> just for W^X. See /sys/arch/i386/i386/pmapae.c r1.28.
>>>>>
>>>>>
>>>>
>>>> Hmm. Why not give up on i386 and make that i686 instead (Pentium Pro)?
>>>> What I mean by this. Rename the current i386 to i686 by compiling it for
>>>> i686 and update the pmap to support more than 4GB physical RAM (PAE).
>>>> Supporting i386 is like supporting 68030.
>>>
>>> That's such a trivial task you should be able to finish it over the
>>> weekend. We all wait for your diff on Monday.
>>
>> Is this irony, or would someone really wait for a diff from me and use
>> it? Take i386. Compile it with something -march=i686 or pentiumpro by
>> default. That's it. Add support for the various PAE MMU options. You get
>> a 32 bit OS supporting more than 4GB of physical RAM.
>
> Your list two things to do, both of which are either already done or
> trivial, and fail to mention either where the real work would be
> needed (adapting UVM for sizeof(paddr_t) > sizeof(vaddr_t)) or, more
> importantly, what the long term costs of maintaining that support when
> i386 would be the only arch using it.

Touching machine independent interfaces/implementations for this, of
course, would not be that ideal. No one can predict the future. Maybe
there will come a time when current 64 bit CPUs will start doing
something similar to PAE before a new 128 bit era or such. That
sizeof(paddr_t) == sizeof(vaddr_t) invariant maybe sometime in the far
future need to be rethought of anyway. Who knows?

> Your obsolete boxes do not merit our paying the costs into the far future.

Fair enough. No useless efforts from me on this then. The original
author of this thread got told to just give up on i386. I got told to
give up on i386. What boxes is i386 used on not obsolete because not
supporting amd64? You could even pull the plug from i386, no? Who is
using it and why? Buy a new device supporting amd64 and be done with it.

--
Christian