From owner-freebsd-current Wed Jan 17 10:15:24 2001 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 9C93C37B6C5; Wed, 17 Jan 2001 10:15:01 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0HIDgn25079; Wed, 17 Jan 2001 10:13:42 -0800 (PST) Date: Wed, 17 Jan 2001 10:13:42 -0800 From: Alfred Perlstein To: Soren Schmidt Cc: Randell Jesup , arch@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: HEADS-UP: await/asleep removal imminent Message-ID: <20010117101342.R7240@fw.wintelcom.net> References: <20010117092109.O7240@fw.wintelcom.net> <200101171802.TAA02435@freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101171802.TAA02435@freebsd.dk>; from sos@freebsd.dk on Wed, Jan 17, 2001 at 07:02:06PM +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Soren Schmidt [010117 10:02] wrote: > It seems Alfred Perlstein wrote: > > > >> Peter Wemm and I suspect that ata doesn't need it. Right now I'm > > > >> running several make -j128 buildworlds and buildkernels with this > > > >> patch to catch any ata problems. > > > > > > Ummmm... > > > > > > It seems to me from reading the man page for asleep/await that > > > they have significant utility, and that the real issue would be one of > > > code not using them, especially as people work to remove the Giant > > > lock for SMP. > > > > > > Or is the discussion in the man page wrong in some way? > > > > The manpage is correct, but we've yet to see it used properly in > > the code with the exception of ata, and even with ata we're not > > sure if it's needed. > > Uhm, well I tried removing it here, and now -current (on SMP HW) > fails in new "interesting" ways. The problem here is that > -current is not stable on SMP HW so the question is if this > change in behavior is to the better or to the worse... > > I suggest creative manpower is used to stabilize -current, instead > of fine trimming which API's should stay or not... I started a loop of make -j128 buildworld and buildkernel last night, I still haven't seen anything odd happen on my hardware. You and Poul-Henning have to figure out what's going on, no one else is able to reproduce this instability you're talking about. There has to be a way for you guys to get us some reasonable tracebacks or diagnostics instead of just saying "it's broke". Perhaps you can explain how you're able to trigger this instability with a test script? Poul-Henning told me he just needed to do a make -j256 world, I did 10 of them without a problem... I'd also like to see what hardware you guys are running on and what kernel config. I'm pretty sure that running with a weird value for HZ causes lockups on -stable, dunno about current. Basically if you're expecting me or the SMP team to figure out what's going on without more info, you're pretty much out of luck. ...wondering if the box Paul Saab gave me is actually SMP... :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message