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