From owner-freebsd-bugs Fri Sep 20 10:30:06 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA22883 for bugs-outgoing; Fri, 20 Sep 1996 10:30:06 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA22858; Fri, 20 Sep 1996 10:30:03 -0700 (PDT) Resent-Date: Fri, 20 Sep 1996 10:30:03 -0700 (PDT) Resent-Message-Id: <199609201730.KAA22858@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, sja@tekla.fi 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 ; 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 X-Send-Pr-Version: 3.2 Subject: kern/1658: ktrace/kdump flaky - corrupted ktrace.out file Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Number: 1658 >Category: kern >Synopsis: ktrace/kdump flaky - corrupted ktrace.out file >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Sep 20 10:30:02 PDT 1996 >Last-Modified: >Originator: Sakari Jalovaara >Organization: Ministry of Information, Information Retrieval >Release: FreeBSD 2.2-960801-SNAP i386 >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: >Audit-Trail: >Unformatted: