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/25/2003 17:37:55
Andrey Petrov wrote:
> On Sat, Jun 21, 2003 at 12:44:35PM -0400, leam wrote:
> 
>>Still using dump, sorry.  :) Trying to use the dump script to write to a 
>>cleanly made partition and I get:
>>
>> extract file ./tar_files/base.tgz
>>   DUMP: readBlocks: lseek fails: Invalid argument
>>   DUMP: rawread: lseek fails
>>This works in 1.6T. I thought 1.6.1 had fixed the dump issue. Or am I 
>>hitting something else?
>>
> 
> 
> The problem I'm aware was manifested in silent data corruption during
> dump, and it was iommu streaming cache or in other words ultra2 for sure
> and other higher models. I didn't requested pullup for that primarily
> because I didn't have 1.6 system handy and time to make 'full circle'.
> So that problem is still in 1.6.1 (unless I missed Martin's requests).
> 
> Your problem appears differently.
> Is there a possibility that you're trying 16T executable against
> 1.6.1 kernel? I'd try ktrace on dump to see what's going on with
> those lseek arguments.
> 
> 	Andrey

Andrey;

Well, I'm on a U1, and the kernel and userland is 1.6.1 as of a couple 
days ago. I'm getting some of the "355" lines into a file, but it sounds 
like you're saying I'd be better off moving this machine to -current?

    355 dump     CALL  read(0x3,0x40205008,0x1000)
    355 dump     GIO   fd 3 read 4096 bytes
    355 dump     RET   read 4096/0x1000
    355 dump     CALL  flock(0x3,0x8)
    355 dump     RET   flock 0
    355 dump     CALL  flock(0x3,0x2)
    355 dump     RET   flock 0
    355 dump     CALL  lseek(0x3,0,0x51ea8000,0)
    355 dump     RET   lseek 1374322688/0x51ea800

ciao!

leam