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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
Thanks and Regards,
Nikhil.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
