- Don't bother taking a trace message if we have panic'd since doing so

  can lead to further panics.
- Call getnanotime() instead of nanotime() for the timestamp.  nanotime()
  is more precise, but it also calls into the timer code, which results
  in mutex operations on the i386 arch.  If KTR_LOCK is turned on, then
  ktr_tracepoint() recurses on itself until it exhausts the kernel stack.
  Eventually this should change to use get_cyclecount() instead, but that
  can't happen if get_cyclecount() is calling nanotime() instead of
  getnanotime().

1 files changed, 3 insertions, 1 deletions

diff --git a/sys/kern/kern_ktr.c b/sys/kern/kern_ktr.c
index cb4039a..63f80ef 100644
--- a/sys/kern/kern_ktr.c
+++ b/sys/kern/kern_ktr.c
@@ -107,6 +107,8 @@ ktr_tracepoint(u_int mask, char *format, u_long arg1, u_long arg2, u_long arg3,
 	va_list ap;
 #endif
 
+	if (panicstr)
+		return;
 	if ((ktr_mask & mask) == 0)
 		return;
 #ifdef KTR_EXTEND
@@ -121,7 +123,7 @@ ktr_tracepoint(u_int mask, char *format, u_long arg1, u_long arg2, u_long arg3,
 	} while (atomic_cmpset_rel_int(&ktr_idx, saveindex, newindex) == 0);
 	entry = &ktr_buf[saveindex];
 	restore_intr(saveintr);
-	nanotime(&entry->ktr_tv);
+	getnanotime(&entry->ktr_tv);
 #ifdef KTR_EXTEND
 	strncpy(entry->ktr_filename, filename, KTRFILENAMESIZE - 1);
 	entry->ktr_filename[KTRFILENAMESIZE - 1] = '\0';