Bug 24882

Summary: ktrace not syncing .out file before panic
Product: Base System Reporter: thomas.stratmann <thomas.stratmann>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description thomas.stratmann 2001-02-05 19:30:01 UTC 
Tried to follow bug in mount which caused panic. Did ktrace on mount
call -> empty ktrace.out (zero bytes)

Fix: 

kernel tracing does not sync writing to .out-file. If VOP_FSync call is
added inside ktrwrite function in kern_ktrace.c, it works well: I saw
the actual kernel call which caused the panic as the last line output
from kdump. Syncing must be done just before unflocking, of course. The
line of code I added is out of reach for me now - anyway it probably is
pretty useless as I lack kernel hacking experience and did not care
deeply about the exact meanings of the arguments.

As syncing is generally a speed vs. reliability tradeoff, it should be
considered to introduce an option to ktrace which toggles syncing -
if the manpage then is elaborate enough about the issue, even less
experienced users will be able to give more precise error postings.

btw the problem appeared on a 4.1-Stable I ran, but the part inside the
ktrwrite function seemed unchanged to me when I looked at kern_ktrace.c
on my 4.2-Stable box.

This is my first posting here - would me delighted to get mail if anyone
takes care about it to see for myself how useful this is. Thanx alot!
How-To-Repeat: Call ktrace something, where something causes kernel panic.
After reboot, look at ktrace.out inside last pwd
Comment 1 Robert Watson freebsd_committer freebsd_triage 2008-03-08 20:44:37 UTC 
State Changed
From-To: open->closed

First off, apologies for the several years it has taken for someone to look 
at this PR.  Unfortunately, I'm going to go ahead and close it, and point 
you at the kern.sync_on_panic sysctl, which determines whether or not the 
system tries to sync file systems on panic.  As you point out, it is a 
constant trade-off between performance and stability of data, and ktrace is 
not generally a tool that is intended to operate properly in the presence 
of kernel data corruption/panic.  What we might want to consider doing is 
allowing a bound on the amount of un-written ktrace data, sized by data or 
time, but I'm not sure that will necessarily help the case of usin ktrace 
to debug things leading up to a panic.  Recent FreeBSD versions include a 
tool, KTR, to help trace those scenarios, and shortly DTrace will also be 
available.