copied to userspace. Failing to do this would result in entries at the bottom
of the ktrdump output to be more recent than entries at the top.
With this change the timestamps are monotonically decreasing going from the
top to the bottom of the ktrdump output.
KTR buffer.
This happens when 'i' tries to wrap around from 0 to 'entries - 1'. Since 'i'
is a signed integer the modulo operation actually returns a negative number.
Fix this by computing the next index to use "by hand" instead of relying
on the modulo operator.
- Implement a function to ensure that all preempted threads have switched
back out at least once. Use this to make sure there are no stale
references to the old ktr_buf or the lock profiling buffers before
updating them.
Reviewed by: marius (sparc64 parts), attilio (earlier patch)
Sponsored by: EMC / Isilon Storage Division
case. It seems entries are in reverse order when read from the kernel
memory but in the right order when read from a file (i.e. ALQ). Handle
both cases.
MFC after: 1 day
with "-t" rather than absolute timestamps. This allows the reader
to get a better sense of latency between events, such as time to
schedule an interrupt thread from time the interrupt occurred. Assert
a copyright on ktrdump.c since I seem to be modifying it more than I
thought.
"file and line" field consistently; previously, a 32-character field
length was used for the table header, which resulted in the header
not lining up with the table.
