From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 19 20:15:25 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 95CDB16A41F for ; Mon, 19 Sep 2005 20:15:25 +0000 (GMT) (envelope-from nikhildharashivkar@gmail.com) Received: from qproxy.gmail.com (qproxy.gmail.com [72.14.204.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57CBD43D5A for ; Mon, 19 Sep 2005 20:15:13 +0000 (GMT) (envelope-from nikhildharashivkar@gmail.com) Received: by qproxy.gmail.com with SMTP id e11so218956qbe for ; Mon, 19 Sep 2005 13:15:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gVTWroe07V0ElV+IN3hrY0+ltdl4nwYlkU8hNPEsUg80LXF3CLMTKYWmoz1TutnGVdUXpx1NmSvcx8UeqUK7w8Uc8DwB2Ou6YNpp3S3u5Yd3yb7iunoSMprP6yCHNSaXAxknKHlUhetv2KCtOUS72H08FI2rkOdPM7GQGrXTVjg= Received: by 10.65.22.16 with SMTP id z16mr54142qbi; Mon, 19 Sep 2005 11:28:07 -0700 (PDT) Received: by 10.65.22.7 with HTTP; Mon, 19 Sep 2005 11:28:07 -0700 (PDT) Message-ID: <17db6d3a05091911287aa14fb0@mail.gmail.com> Date: Mon, 19 Sep 2005 23:58:07 +0530 From: Nikhil Dharashivkar To: Robert Watson In-Reply-To: <20050907162312.J4961@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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> <20050907162312.J4961@fledge.watson.org> 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 Reply-To: nikhildharashivkar@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2005 20:15:25 -0000 Hi, I am able to backport kern_ktr.c and related files and ktrdump to versions older than 5.0 specially 4.1 with non-SMP configuration file kern_ktr.c file is compiled=20 successfully. But with SMP configuration file it is giving an assembly errors as follows = : cc -c -O -march=3Dpentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../../BSD4.1/sys -I../../../include -I../../../../BSD4.1/include -DNILA -D_KERNEL -DNILA -include opt_global.h -elf -mpreferred-stack-boundary=3D2 ../../kern/kern_ktr.c ../../kern/kern_ktr.c:290: warning: no previous prototype for `ktr_tracepoi= nt' /tmp/ccW68912.s: Assembler messages: /tmp/ccW68912.s:218: Error: Rest of line ignored. First ignored character is `"'. /tmp/ccW68912.s:218: Error: Rest of line ignored. First ignored character is `"'. I am not getting this error ? what is this meant ? On 9/7/05, Robert Watson wrote: >=20 > On Wed, 7 Sep 2005, Nikhil Dharashivkar wrote: >=20 > > 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.1= 0 > > and older. For this case, do I need to port KTR code for older version = ? > > or is there any other solution ? >=20 > 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 no= t > 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. >=20 > Robert N M Watson >=20 >=20 > > > > > > 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 FreeB= SD. > >>> 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 even= t > >> tracing except in that context. I think you'll find KTR(9) is much mo= re > >> 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. Th= e > >>>> 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 buffe= r > >>>> cache or ktr_todo queue. > >>>> > >>>> Another problem is that since ktrace generates disk I/O, it is likel= y > >>>> 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. > > >=20 --=20 Thanks and Regards, Nikhil.