Re: uvm_fault kernel: page fault trap while un-tar-ing a large file

> Usually a va like that points to a NULL pointer
dereference.
How on earth can trunc_page(any_garbage) equal 0x10?
Am I missing something?

> Did you manage to get a line number?
In what sense? The kdb_trap() call is from
arch/amd64/amd64/trap.c:237.
I don't have a backtrace. I don't even have the stack frame
of the  
original
trap handler because of the locking-against-myself-panic
during sync.
Maybe I'll be able to extract the frame from the tar
process's kernel  
stack.

Or do you mean this:
gdb netbsd.gdb
(gdb) info line *(dqget+0x118)
Line 729 of
"/var/tmp/src-4.0beta2/sys/ufs/ufs/ufs_quota.c"
    starts at address 0xffffffff8028e4df <dqget+255>
    and ends at 0xffffffff8028e4fb <dqget+283>.

On Thu, Jun 21, 2007 at 10:07:47PM +0200, Edgar Fu? wrote:
> >Usually a va like that points to a NULL pointer
dereference.
> How on earth can trunc_page(any_garbage) equal 0x10?
> Am I missing something?

Nope.  That was me.  I somehow missed the trunc_page().

> >Did you manage to get a line number?
> Or do you mean this:
> gdb netbsd.gdb
> (gdb) info line *(dqget+0x118)
> Line 729 of
"/var/tmp/src-4.0beta2/sys/ufs/ufs/ufs_quota.c"
>    starts at address 0xffffffff8028e4df
<dqget+255>
>    and ends at 0xffffffff8028e4fb <dqget+283>.

That's what I meant.

I don't see anything obvious there.  I wonder how many
people are
running with quotas on ffsv2 on amd64.

-allen

-- 
Allen Briggs  |  http://www.ninthw
onder.com/~briggs/  |  briggsninthwonder.com