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