From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 18 22:09:53 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7477137B401; Fri, 18 Jul 2003 22:09:53 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA57143F3F; Fri, 18 Jul 2003 22:09:52 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38lc0tp.dialup.mindspring.com ([209.86.3.185] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19djyh-0007J1-00; Fri, 18 Jul 2003 22:09:52 -0700 Message-ID: <3F18D263.1BFE6BE3@mindspring.com> Date: Fri, 18 Jul 2003 22:08:51 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4fb8433fd8142f2f6ff195a0e0b00dd0c387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: Robert Watson Subject: Re: running 5.1-RELEASE with no procfs mounted (lockups?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2003 05:09:53 -0000 John Baldwin wrote: > Since ktrace logs all syscall entries and exits, it should seem that > a kdump after the process had exited would show which syscall returned > EAGAIN quite easily. This works if the process exits after the EAGAIN; that would only work for the specific error that people are seeing currently. If the process does what it's supposed to do when it sees EAGAIN, and repeats the call, you could get in a tight loop. The ktrace output could be examined after killing the process, but until the process exits, there's really no output that can be examined using kdump. The problem is that ktrace/kdump rendesvous at a file; truss does not, so it has some capabilities that ktrace does not. In some circumstances (e.g. a system crash, where kdump doesn't get a chance to get at the file, because it's "cleaned up" and not even fully written, when it's not "cleaned up") ktrace loses utterly. This is not to say that it's not a useful tool (I use it myself); just that truss has some utility in situations where a tighter coupling between the tracing and the display of the trace information is useful. My second example is a much better case; my first one was mostly designed for a current discussion about EAGAIN, whereas the most utility for truss over ktrace involves an actual system crash, and/or an application that doesn't exit [ab]normally, thus giving you a synchronized trace file to play with. It's really all about loosely couple synchronization (ktrace) vs. tightl couple synchronization (truss). With truss, you can even expect that in many circumstances, you will at least get boundary information, even in the face of a system crash -- this is a situation that ktrace would lose for sure, if the crash couldn't sync. -- Terry