From owner-freebsd-current Tue Oct 13 14:56:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA05387 for freebsd-current-outgoing; Tue, 13 Oct 1998 14:56:10 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA05346 for ; Tue, 13 Oct 1998 14:56:02 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.1/8.9.1) id IAA05333; Wed, 14 Oct 1998 08:00:27 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199810132200.IAA05333@cimlogic.com.au> Subject: Re: Recent 3.0's are Depressing In-Reply-To: <199810132130.RAA06806@highwind.com> from HighWind Software Information at "Oct 13, 98 05:30:58 pm" To: info@highwind.com (HighWind Software Information) Date: Wed, 14 Oct 1998 08:00:27 +1000 (EST) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (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 HighWind Software Information wrote: > We are an "aout" binary and have even tried STATICALLY linking with our > libc_r. It still goes into this loop. > > Any ideas what could have happened to cause this. It WAS working fine. Now, > after a little progress, we get into an infinite loop. > > Typhoon uses lots of disk and network I/O. What could we have tripped on? > > Seems to me, statically linking in libc_r would have eliminated any of > the recent changes in libc_r from blame. > > I'm a bit lost as to what to do. I guess we could upgrade our FreeBSD > machine and begin banging our heads against the wall. > > I'm wondering if anyone on this list would have a guess as to what new > changes to the kernel may have caused this. The recent changes mostly affect signal handling with sigwait(). There was one change to the thread kernel, but I doubt that would be a problem. I don't see what a static link would buy you compared to a dynamic one. I also don't see what this has to do with the FreeBSD kernel since this is a user-space thread implementation. I suggest that you use CVSup's cvs mode to track the cvs repository and then checkout sources based on date to isolate which changes have bitten you. There are test programs in the tree that were submitted by the author of the signal handling changes. You should try to duplicate your problem using those tests. Providing a ktrace without a thread status dump is useless IMO. All that you've shown is that the thread scheduler can't find a thread to run. The thread status dump should tell you why. I explained that to you many months ago. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message