Re: install/56582: port-atari freeze on installation when extracting base.tgz

[David Ross <randomdross00%gmail.com@localhost>]

Thanks!  I thought ntpd might be useful for keeping the time sync'd,
but I didn't realize how much memory it's eating.  And probably
ntpdate is sufficient if I just want to keep the system time in sync
with Internet time (?).  I'll stop running ntpd now.

It appears that right now at least the 9.2 kernel may in fact be
stable on this machine.  That makes me have faith in Michael van
Elst's suggestion that the freeze during install could be simply due
to a lack of memory.

I'll be experimenting with a few solutions going forward:
  - Getting a memory card for my TT030 that is >16MB and runs stable.
  - Cross-building netbsd for atari with -Os and using the sysinst.fs
and ataritt kernel that it generates for the install.  I can also
remove some things from my build of the ataritt kernel, which could
help.

It might make sense to use this PR to track any potential changes that
could help get 9.2 to install successfully on a 16MB TT030.  The most
common RAM board for the TT (the Atari branded board) will do 16MB
max, and in my experience many >16MB RAM boards don't run stable with
netbsd.

Dave

On Thu, Dec 30, 2021 at 6:49 AM Jason Thorpe <thorpej%me.com@localhost> wrote:
>
>
> > On Dec 30, 2021, at 12:10 AM, Michael van Elst <mlelstv%serpens.de@localhost> wrote:
>
> > mlockall() returns ENOMEM when the system- or per-process-limit is exceeded,
> > you can ignore it. Worst thing is that ntpd gets swapped out and cannot
> > sync time anymore.
> >
> > ntpd uses about 7MB RAM (about 3MB shared). You probably don't want
> > to have this locked in memory on a small machine. Adding
> >
> > rlimit memlock -1
> >
> > to ntp.conf should prevent it from trying.
>
> I wonder if we should add a heuristic in ntpd to auto-tune for this.
>
> -- thorpej
>