From owner-freebsd-smp Sat Apr 4 23:51:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA10092 for freebsd-smp-outgoing; Sat, 4 Apr 1998 23:51:00 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA10086 for ; Sat, 4 Apr 1998 23:50:56 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id PAA07051; Sun, 5 Apr 1998 15:50:50 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199804050750.PAA07051@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Peter Wemm cc: smp@FreeBSD.ORG Subject: Re: beware! -current under SMP is "not looking good". In-reply-to: Your message of "Sun, 05 Apr 1998 14:35:30 +0800." <199804050635.OAA06176@spinner.netplex.com.au> Date: Sun, 05 Apr 1998 15:50:49 +0800 From: Peter Wemm Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Peter Wemm wrote: > The latest time commit has busted -current under SMP. I'm not sure of the > exact circumstances, but it causes a hang when ntpdate is run. The process > sits in the "running" state but doesn't gain any cpu time. Trying to break > into DDB causes a deadlock. It seems that doing a 'setpriority()' is the last thing that happens before the hang with ntpdate. I wonder if the posix4 stuff is having an effect here? > > The code just prior to this was also broken. select() wasn't working > properly, although there is evidence that something _else_ is causing it > and select is just the scapegoat. It looks like interruptable sleeps are > not being interrupted by signals somehow. (sigalrm and siginfo at least > were being blocked for the duration of the select()). > > Other funny things were happening too, eg: cron will not run jobs on my > system when built from an april 2 kernel. This was from the bug added to nanosleep() that caused it to fail and return EAGAIN/EWOULDBLOCK on a successful sleep and caused sleep(3) to fail. Cheers, -Peter -- Peter Wemm Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message