Date: Tue, 20 Aug 1996 17:53:01 -0700 From: Darryl Okahata <darrylo@hpnmhjw.sr.hp.com> To: current@freefall.freebsd.org Subject: Re: ktrace/kdump under 2.2-960801-snap? Message-ID: <199608210053.AA227868782@hpnmhjw.sr.hp.com> In-Reply-To: Your message of "Tue, 20 Aug 1996 14:33:45 PDT."
next in thread | raw e-mail | index | archive | help
I wrote:
> Does ktrace/kdump work under the 960801-snap? Ktrace seems to work
> fine, but kdump dies with a "kdump: bogus length 0xf000ef6f" error.
A little investigation shows that the ktrace.out file is being
somehow *randomly* corrupted (i.e., it doesn't always occur, and, when
it does, it's at different places, but usually with the same bad data).
Interestingly enough, if the corruption occurs, it appears to occur on a
4K boundary. Here's an hex dump of a corrupted ktrace.out (all numbers
are in hex):
0001fe0 00 00 00 00 00 00 00 00 0c 00 00 00 02 00 00 00
0001ff0 5b 1c 00 00 63 76 73 75 70 00 00 00 00 00 00 00
0002000 6f ef 00 f0 6f ef 00 f0 c3 e2 00 f0 6f ef 00 f0
0002010 6f ef 00 f0 54 ff 00 f0 4c e1 00 f0 6f ef 00 f0
0002020 a5 fe 00 f0 87 e9 00 f0 6f ef 00 f0 6f ef 00 f0
0002030 6f ef 00 f0 6f ef 00 f0 57 ef 00 f0 6f ef 00 f0
Here, the corruption occurs starting at 0x2000 (and it usually begins
with "0xf000ef6f" -- anyone recognize this number?). With other ktrace
runs, I've seen the corruption occur at file offsets 0x0 and 0x8000.
Also, I've re-run ktrace a couple of other times, without any corruption
whatsoever.
-- Darryl Okahata
Internet: darrylo@sr.hp.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Hewlett-Packard, or of the
little green men that have been following him all day.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608210053.AA227868782>