From owner-cvs-all Tue Aug 21 13:16: 0 2001 Delivered-To: cvs-all@freebsd.org Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by hub.freebsd.org (Postfix) with ESMTP id 32DDF37B407; Tue, 21 Aug 2001 13:15:52 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@[147.11.46.201]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA19025; Tue, 21 Aug 2001 13:15:40 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010821134601.J81307@elvis.mu.org> Date: Tue, 21 Aug 2001 13:15:46 -0700 (PDT) From: John Baldwin To: Alfred Perlstein Subject: Re: cvs commit: src/sys/kern kern_condvar.c kern_synch.c src/sys Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 21-Aug-01 Alfred Perlstein wrote: > * John Baldwin [010821 13:42] wrote: >> jhb 2001/08/21 11:42:46 PDT >> >> Modified files: >> sys/kern kern_condvar.c kern_synch.c >> sys/sys proc.h >> Log: >> - Fix a bug in the previous workaround for the tsleep/endtsleep race. >> callout_stop() would fail in two cases: >> 1) The timeout was currently executing, and >> 2) The timeout had already executed. >> We only needed to work around the race for 1). We caught some instances >> of 2) via the PS_TIMEOUT flag, however, if endtsleep() fired after the >> process had been woken up but before it had resumed execution, >> PS_TIMEOUT would not be set, but callout_stop() would fail, so we >> would block the process until endtsleep() resumed it. Except that >> endtsleep() had already run and couldn't resume it. This adds a new >> flag >> PS_TIMOFAIL to indicate the case of 2) when PS_TIMEOUT isn't set. >> - Implement this race fix for condition variables as well. > > How likely are these sort of fixes going to be able to help > the perceived instability of -current? Is -current noticeably > unstable or do we just have the usual crowd of people screaming > sort of like what was going on a couple of months ago. This fixes the recent (< 2 weeks) problems with sound or USB processes hanging. It might fix other hangs that started with my Aug 10th commit as well. > "current is broken" > "no it's not" > "yes it is" > "give me a crashdump" > ":P" "it panics trying to get a crashdump" "use ddb" "i don't have a serial console" "i can't reproduce this on any of my 6 testboxes *bang head on desk*" > etc. :-) -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message