Adding new option to ktrace

[Nikhil Dharashivkar]

Hi,
    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 ?


On 9/6/05, Robert Watson <rwatson at freebsd.org> 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 <PeterJeremy at optushome.com.au> 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 at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> >
> 


-- 
Thanks and Regards,
         Nikhil.