From sja@sja.home.tekla.fi  Fri Sep 20 10:24:55 1996
Received: from sja.home.tekla.fi (ppp8.tekla.fi [192.98.7.98])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA19719
          for <FreeBSD-gnats-submit@freebsd.org>; Fri, 20 Sep 1996 10:24:45 -0700 (PDT)
Received: (from root@localhost) by sja.home.tekla.fi (8.7.5/8.7.3) id UAA01147; Fri, 20 Sep 1996 20:24:16 +0300 (EET DST)
Message-Id: <199609201724.UAA01147@sja.home.tekla.fi>
Date: Fri, 20 Sep 1996 20:24:16 +0300 (EET DST)
From: sja@tekla.fi
Reply-To: sja@tekla.fi
To: FreeBSD-gnats-submit@freebsd.org
Subject: ktrace/kdump flaky - corrupted ktrace.out file
X-Send-Pr-Version: 3.2

>Number:         1658
>Category:       kern
>Synopsis:       ktrace/kdump flaky - corrupted ktrace.out file
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Sep 20 10:30:02 PDT 1996
>Closed-Date:    Sat May 23 02:28:57 PDT 1998
>Last-Modified:  Sat May 23 02:29:04 PDT 1998
>Originator:     Sakari Jalovaara
>Release:        FreeBSD 2.2-960801-SNAP i386
>Organization:
Ministry of Information, Information Retrieval
>Environment:

	P6/200, Asus P6NP5 m/b Natoma chipset, IDE disk

>Description:

	ktrace(1) or ktrace(2) acts strangely.  Maybe the dump file
	is not flushed to the disk?

	Sometimes ktrace+kdump work ok, but a few seconds later the
	dump file is spontaneously corrupted.

	The corrupted dump file often has lots of NUL bytes.  The scary
	question is: where, if anywhere, on the disk does the real data
	end up?

>How-To-Repeat:

	Run ktrace + kdump several times.  Trace different commands
	at different times; if you trace the same command several times,
	the dump file seems to "settle down"?  Big dump files seem to get
	trashed easier.

	"ktrace -p" fails similarly.

	Dump file corruption seems to be triggered by disk activity.
	Get a ktrace, do something on the disk, then kdump.

	~ (sja@estabur) 112> /bin/rm ktrace.out ; ktrace wc /bin/ls > /dev/null ; kdump | tail -2
   	998 wc       RET   write 33/0x21
   	998 wc       CALL  exit(0)
	~ (sja@estabur) 113> kdump | tail -2
	kdump: bogus length 0xe0f43d83
        	\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
	1688299074 }       RET
	~ (sja@estabur) 114>


	~ (sja@estabur) 135> /bin/rm ktrace.out ; ktrace od -c /kernel > /dev/null ; kdump | tail -2
  	1055 od       RET   write 15694/0x3d4e
  	1055 od       CALL  exit(0)
	~ (sja@estabur) 136> kdump | tail -2
  	1055 od       RET   write 15694/0x3d4e
  	1055 od       CALL  exit(0)
	~ (sja@estabur) 137> cp /kernel junkfile
	~ (sja@estabur) 138> kdump | tail -2
	kdump: bogus length 0xc3c95f5e
        	\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
	~ (sja@estabur) 139> 

>Fix:
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: phk 
State-Changed-When: Sat May 23 02:28:57 PDT 1998 
State-Changed-Why:  

As part of our PR auditing campaign, this PR has been closed due to it's 
age and lack of activity on the PR.   

There is a good chance that the problem reported have been solved  
as part of other activities. 

If this is not the case, please reopen this PR with fresh information 
on the manifestation of the bug. 

Sorry about the late reaction to this PR. 
>Unformatted:
