From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 7 15:24:33 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 624C316A41F for ; Wed, 7 Sep 2005 15:24:33 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id F131B43D45 for ; Wed, 7 Sep 2005 15:24:30 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 271D946B0D; Wed, 7 Sep 2005 11:24:30 -0400 (EDT) Date: Wed, 7 Sep 2005 16:24:30 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Nikhil Dharashivkar In-Reply-To: <17db6d3a05090708104ff98a7c@mail.gmail.com> Message-ID: <20050907162312.J4961@fledge.watson.org> References: <17db6d3a0509051000622868bc@mail.gmail.com> <431C8D5B.7080309@samsco.org> <431C92F2.9090104@persistent.co.in> <431C93DD.20402@samsco.org> <17db6d3a0509052203b1da14a@mail.gmail.com> <20050906081855.GA26550@cirb503493.alcatel.com.au> <17db6d3a050906014048e2045b@mail.gmail.com> <20050906125754.Y51625@fledge.watson.org> <17db6d3a05090708104ff98a7c@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Peter Jeremy , freebsd-hackers@freebsd.org Subject: Re: Adding new option to ktrace X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2005 15:24:33 -0000 On Wed, 7 Sep 2005, Nikhil Dharashivkar wrote: > I went through the ktr and ktrdump options. I compiled the kernel > with options ktr. I found that ktr support is mostly for lock and > schedule. We can trace drivers using mask KTR_DEV and some CTR* > statements in dirver. > But This ktr support is from freebsd 5. I am aslo using freebsd 4.10 > and older. For this case, do I need to port KTR code for older version ? > or is there any other solution ? KTR(9) was a facility added as part of the SMPng work to the 5.x branch, and has not been backported to the 4.x branch at this point. It would not be difficult to either backport it, or to add a light-weight trace ring buffer of similar nature to fix, especially as 4.x doesn't have in-kernel parellelism. Robert N M Watson > > > On 9/6/05, Robert Watson wrote: >> On Tue, 6 Sep 2005, Nikhil Dharashivkar wrote: >> >>> Yes, it is ok if i loose data in ktrace queue when crash occurs. >>> Basically, I want to give an Disk IO trace support to ktrace on FreeBSD. >>> So, what I am thinking to use struct dio in dastrategy routine to >>> trace the IO. I 'll use this struct to generate ktr_request. Throught >>> ktr_writerequest it will be written in ktrace.out . >>> Is it possible ? >> >> Try taking a look at KTR(9) and ktrdump(8) for information on ktr, the >> in-kernel trace facility. ktrace(1) is almost entirely about tracing >> process level system call behavior, and not structured for kernel event >> tracing except in that context. I think you'll find KTR(9) is much more >> what you're looking for, and among other things, you can extract the >> results from both live kernels and kernel crash dumps. >> >> Robert N M Watson >> >> >>> >>> >>> >>> On 9/6/05, Peter Jeremy wrote: >>>> On Tue, 2005-Sep-06 10:33:53 +0530, Nikhil Dharashivkar wrote: >>>>> Thanks for replying me. Basically what happend, while testing >>>>> scsi driver on freebsd, at some point it crashes. So, there is no way >>>>> to know how much IO is performed. To know the IO state just before the >>>>> driver fails, i selected ktrace to print IO information whatever i ll >>>>> get from dastrategy routine. >>>> >>>> It's not clear how ktrace is going to help here. The ktrXXX(9) >>>> functions place ktr_request events in a queue. A kernel thread then >>>> dumps the queue entries into a file via the normal buffer cache. The >>>> data on disk is typically about 30 seconds behind real time. If the >>>> system crashes, you will lose any events that are still in the buffer >>>> cache or ktr_todo queue. >>>> >>>> Another problem is that since ktrace generates disk I/O, it is likely >>>> to disturb your testing. >>>> >>>> A better approach would seem to be to build a circular buffer and >>>> store the I/O requests in the buffer. When the system crashes, you >>>> can look at the last entries in the buffer. >>>> >>>> -- >>>> Peter Jeremy >>>> >>> >>> >>> -- >>> Thanks and Regards, >>> Nikhil. >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >>> >> > > > -- > Thanks and Regards, > Nikhil. >