1.\"- 2.\" Copyright (c) 2002 Chad David 3.\" All rights reserved. 4.\" 5.\" Redistribution and use in source and binary forms, with or without 6.\" modification, are permitted provided that the following conditions 7.\" are met: 8.\" 1. Redistributions of source code must retain the above copyright 9.\" notice, this list of conditions and the following disclaimer. 10.\" 2. Redistributions in binary form must reproduce the above copyright 11.\" notice, this list of conditions and the following disclaimer in the 12.\" documentation and/or other materials provided with the distribution. 13.\" 14.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND 15.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 16.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 17.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE 18.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 19.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 20.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 21.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 22.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 23.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 24.\" SUCH DAMAGE. 25.\" 26.\" $FreeBSD: src/usr.bin/ktrdump/ktrdump.8,v 1.7 2005/03/08 06:58:56 hmp Exp $ 27.\" $DragonFly: src/usr.bin/ktrdump/ktrdump.8,v 1.7 2006/03/27 16:45:44 swildner Exp $ 28.\" 29.Dd May 5, 2004 30.Dt KTRDUMP 8 31.Os 32.Sh NAME 33.Nm ktrdump 34.Nd print kernel ktr trace buffer 35.Sh SYNOPSIS 36.Nm 37.Op Fl acfinpqrstx 38.Op Fl N Ar execfile 39.Op Fl M Ar corefile 40.Op Fl o Ar outfile 41.Sh DESCRIPTION 42The 43.Nm 44utility is used to dump the contents of the kernel ktr trace buffer. 45.Pp 46The following options are available: 47.Bl -tag -width ".Fl N Ar execfile" 48.It Fl a 49Print all fields. Implies all print options. 50.It Fl c 51Print the CPU number that each entry was logged from. 52.It Fl f 53Print the file and line number that each entry was logged from. 54.It Fl i 55Print the ID string field, identifying the facility being logged. 56.It Fl n 57.Nm 58normally tries to translate the caller fields and (when easily parsed) 59trace arguments into symbols. This option forces hex values to be 60displayed instead. This option will also cause relative timestamps to 61be displayed as TSC timestamps rather then converted to microseconds. 62.It Fl p 63Print the trace data. 64.It Fl q 65Quiet mode; do not print the column header. 66.It Fl r 67Print relative timestamps in microseconds, rather than absolute TSC 68timestamps. 69.It Fl s 70Attempt to merge the KTR logs for all cpus into a single time-sorted 71log. For the numbers to make any sense you probably want to turn 72on the 73.Va debug.ktr.resynchronize 74sysctl variable. 75.It Fl x 76Print the call chain leading up to the procedure which issued 77the KTR. 78.It Fl t 79Print the timestamp for each entry. 80.Xr ktr 4 81manual page. 82.It Fl N Ar execfile 83The kernel image to resolve symbols from. 84The default is the value returned via 85.Xr getbootfile 3 . 86.It Fl M Ar corefile 87The core file or memory image to read from. 88The default is 89.Pa /dev/mem . 90.It Fl o Ar outfile 91The file to write the output to. 92The default is standard output. 93.El 94.Sh OPERATIONAL NOTES 95Users of 96.Nm 97should keep in mind that the act of trace logging will itself effect 98execution overheads. On a 2Ghz cpu a logging call can take anywhere 99from 40ns to 150ns to run. 100.Pp 101The TSC counter is used on cpus equipped with it (which is all modern cpus). 102The TSC counters may not be synchronized on SMP systems and may drift even 103between cores on multi-core cpus. Enabling synchronization between cpus 104via the 105.Va debug.ktr.resynchronize 106sysctl will impose additional system overheads and will generally only be 107accurate to within 100ns or so (and perhaps not even that good). 108Resynchronization only occurs 10 times a second and serious drift will 109cause a great deal of measurement noise when trying to compare events occuring 110on two different cpus. 111.Pp 112Users using the 113.Fl s 114option should be aware that events for each cpu are independantly logged 115and one cpu might have more events logged then another, causing earlier 116events to be discarded sooner then other cpus. The beginning portion of 117the sorted output may thus show MP related events for one cpu with no 118corresponding events for other cpus. 119.Pp 120It is possible to somewhat characterize KTR logging overheads by setting 121the 122.Va debug.ktr.testlogcnt 123sysctl and then observing test logging events in the KTR output. Tests 1-3 124log four dummy arguments while tests 4-6 log no arguments. 125.Pp 126It is possible to characterize IPI messaging latencies by setting the 127.Va debug.ktr.testipicnt 128sysctl. A small number between 1 and 1000 is recommended. This will 129cause the system to ping pong a single IPI message between cpu 0 and cpu 1 130asynchronously that number of times, as fast as it can. A 131.Nm 132should be performed almost immediately after setting the sysctl or you 133might miss the logged events. 134.Sh SEE ALSO 135.Xr ktr 4 , 136.Xr ktr 9 137.Sh HISTORY 138The 139.Nm 140utility first appeared in 141.Fx 5.0 . 142.Sh AUTHORS 143.An -nosplit 144The 145.Nm 146utility was originally implemented by 147.An Jake Burkholder Aq jake@FreeBSD.org . 148This manual page was originally written by 149.An Chad David Aq davidc@FreeBSD.org . 150The program and manual page were rewritten pretty much from 151scratch by 152.An Matthew Dillon 153for 154.Dx . 155