Subject: Re: SIGSEGV on 1.6.1 dump
To: port-sparc64 <port-sparc64@netbsd.org>
From: leam <leam@reuel.net>
List: port-sparc64
Date: 06/26/2003 16:42:16
leam wrote:
> Andrey Petrov wrote:
>
>> On Thu, Jun 26, 2003 at 03:36:33PM -0400, leam wrote:
>>
>>> Is there a way to cut down the kdump output? Last night I had *lots*
>>> of "\0\0\0" lines. I'll read up on kdump and report back when I have
>>> something.
>>>
>>
>>
>> You can exclude data transferred back and forth in syscalls by specifying
>> -t flags. Something like '-t cnis' should give you smaller trace. I'd
>> also
>> create small filesystem for test.
>>
>> Andrey
>
>
> Hmm... on the other hand, I was just forcibly reminded of something. The
> dump seems to work on the smaller filesystem (221M) but dies on the
> larger one (1.3G). However, I was just compiling bind and got a "virtual
> memory exhausted" error. The machine has 128 physical and 256 swap, and
> right now wasn't doing much beside the compile.
>
> Could this be an issue for dump as well?
>
> ciao!
>
> leam
Hmm.. okay, so it's probably not that. I just put another 256M (real) in
and it still pukes at sha1.c, the function "transform". I'll still try
the dump and see, and track the bind issue in a seperate thread.
(a few minutes later.......)
Heh, probably found the answer. As I had said, the small filesystem
worked but the large one, where large tar files were stored, died.
Things like comp.tgz and netbsd.gdb. Well, I just tried it again and it
died on the *small* filesystem. On a 90M file called "ktrace.out". :)
It is probably working on the U2/-current as it has (had) 1G physical ram.
ciao!
leam