From owner-freebsd-current Thu Mar 2 16:42:44 2000 Delivered-To: freebsd-current@freebsd.org Received: from hda.hda.com (hda.bicnet.net [208.220.68.243]) by hub.freebsd.org (Postfix) with ESMTP id A4F1137B9D9 for ; Thu, 2 Mar 2000 16:42:27 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.9.3/8.9.3) id TAA42128; Thu, 2 Mar 2000 19:45:18 -0500 (EST) (envelope-from dufault) From: Peter Dufault Message-Id: <200003030045.TAA42128@hda.hda.com> Subject: Re: ntpd hanging machine In-Reply-To: from Bruce Evans at "Mar 3, 2000 11:15:52 am" To: Bruce Evans Date: Thu, 2 Mar 2000 19:45:18 -0500 (EST) Cc: Matthew Dillon , Wes Morgan , Ollivier Robert , freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Thu, 2 Mar 2000, Matthew Dillon wrote: > > > :> > merge. Until that point I was using the stock ntp4 from udel with no > > :> > problems. But I tried the one shipping with 4.0 and it locks up completely > > > rtprio (and idprio) is virtually guarenteed to lockup your machine > > eventually. Don't use either. > > Unfortunately, ntpd in -current uses rtprio by default. > > Perter Dufault's recent changes fixed some related things, but not the > priority inversion problems. My guess is that the new ntpd now does something while it is rtpriod and it didn't used to. As far as I can tell the rtprio does nothing except maybe resume ntpd in preference to other readied kernel processes. The rtprio should be taken out of ntpd, it also (as I've talked over with Bruce) screws up the kernel priorities. This illustrates the danger of using it at all. With no way to bail out if you get upside down, any mods to the program are dangerous. It's probably almost safe to run a program rtprio or idprio if all you do is compute during that time and go back to time sharing before doing anything else, but be sure you're paged in, don't handle signals that way, etc... My "solution" would be to make rtprio lower priority than regular time sharing and if it needs to use any time sharing resources fault it or temporarily boost it up to time sharing. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message