Adding new option to ktrace

[Robert Watson]

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 <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.
>