NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



The following reply was made to PR port-atari/56582; it has been noted by GNATS.

From: David Ross <randomdross00%gmail.com@localhost>
To: Jason Thorpe <thorpej%me.com@localhost>
Cc: gnats-bugs%netbsd.org@localhost, port-atari-maintainer%netbsd.org@localhost, 
	gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: install/56582: port-atari freeze on installation when extracting base.tgz
Date: Thu, 30 Dec 2021 10:44:22 -0800

 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
 >
 



Home | Main Index | Thread Index | Old Index