Re: Kernel panic - page fault in inodedep_find

On Fri, Mar 09, 2007 at 07:47:00AM +0100, Michal Mertl wrote:
> Kostik Belousov wrote:
> > On Thu, Mar 08, 2007 at 12:34:53PM +0100, Michal Mertl wrote:
> > > For a couple of days I am getting panics/freezes with GENERIC kernel (~2
> > > days old as well as up-to-date CURRENT). The trace (when I get a chance
> > > to see it and when dump works) is attached. I have got crash dump so can
> > > provide more details as required.
> > > 
> > > The panic seem to be provoked by heavier disk activity (running cvsup or
> > > similar).
> > > 
> > > The machine is AMD64 SMP.
> > > 
> > > Thanks
> > > 
> > > Michal
> > > 
> > > 
> > > Fatal trap 12: page fault while in kernel mode
> > > cpuid = 1; apic id = 01
> > > fault virtual address   = 0x50
> > > fault code              = supervisor read data, page not present
> > > instruction pointer     = 0x8:0xffffffff8059c175
> > > stack pointer           = 0x10:0xffffffffaf6b8380
> > > frame pointer           = 0x10:0xffffffffaf6b8390
> > > code segment            = base 0x0, limit 0xfffff, type 0x1b
> > >                         = DPL 0, pres 1, long 1, def32 0, gran 1
> > > processor eflags        = interrupt enabled, resume, IOPL = 0
> > > current process         = 1194 (cvs)
> > > trap number             = 12
> > > panic: page fault
> > > cpuid = 1
> > > KDB: stack backtrace:
> > > db_trace_self_wrapper() at db_trace_self_wrapper+0x3a
> > > panic() at panic+0x22f
> > > trap_fatal() at trap_fatal+0x2a9
> > > trap_pfault() at trap_pfault+0x235
> > > trap() at trap+0x22e
> > > calltrap() at calltrap+0x8
> > > --- trap 0xc, rip = 0xffffffff8059c175, rsp = 0xffffffffaf6b8380, rbp =
> > > 0xffffffffaf6b8390 ---
> > > inodedep_find() at inodedep_find+0x12
> > > inodedep_lookup() at inodedep_lookup+0x81
> > > softdep_setup_inomapdep() at softdep_setup_inomapdep+0x48
> > > ffs_nodealloccg() at ffs_nodealloccg+0x3a6
> > > ffs_hashalloc() at ffs_hashalloc+0x62
> > > ffs_valloc() at ffs_valloc+0xde
> > > ufs_makeinode() at ufs_makeinode+0x6b
> > > ufs_create() at ufs_create+0x28
> > > VOP_CREATE_APV() at VOP_CREATE_APV+0x72
> > > vn_open_cred() at vn_open_cred+0x4b1
> > > kern_open() at kern_open+0x101
> > > syscall() at syscall+0x1f0
> > > Xfast_syscall() at Xfast_syscall+0xab
> > > --- syscall (5, FreeBSD ELF64, open), rip = 0x8013b8c7c, rsp =
> > > 0x7fffffffe0a8, rbp = 0x10 ---
> > > Uptime: 1m40s
> > > Physical memory: 2034 MB
> > > Dumping 213 MB: 198 182 166 150 134 118 102 86 70 54 38 22 6
> > > 
> > > 
> > > --------------------------
> > > 
> > > #0  doadump () at pcpu.h:141
> > > 141     pcpu.h: No such file or directory.
> > >         in pcpu.h
> > > (kgdb) bt
> > > #0  doadump () at pcpu.h:141
> > > #1  0xffffffff80438920 in boot (howto=260)
> > > at ../../../kern/kern_shutdown.c:409
> > > #2  0xffffffff804383b7 in panic (fmt=0xffffffff80690d22 "%s")
> > > at ../../../kern/kern_shutdown.c:563
> > > #3  0xffffffff8063ebc9 in trap_fatal (frame=0xc,
> > > eva=18446742975751987856) at ../../../amd64/amd64/trap.c:696
> > > #4  0xffffffff8063ef39 in trap_pfault (frame=0xffffffffaf6b82d0,
> > > usermode=0) at ../../../amd64/amd64/trap.c:614
> > > #5  0xffffffff8063f16e in trap (frame=0xffffffffaf6b82d0)
> > > at ../../../amd64/amd64/trap.c:382
> > > #6  0xffffffff806278ee in calltrap ()
> > > at ../../../amd64/amd64/exception.S:169
> > > #7  0xffffffff8059c175 in inodedep_find (inodedephd=0xffffffff8106d660,
> > > fs=0xffffff0061a4d800, inum=168358, inodedeppp=0xffff	ffffaf6b83e0)
> > > at ../../../ufs/ffs/ffs_softdep.c:1246
> > Please, from this frame (#7) do
> > p/x *inodedep
> > p/x *inodedephd
> 
> 1246            LIST_FOREACH(inodedep, inodedephd, id_hash)
> Current language:  auto; currently c
> (kgdb) p/x *inodedep
> Cannot access memory at address 0x18
> (kgdb) p/x *inodedephd
> $1 = {lh_first = 0x18}

Ok, this seems to be exactly the same problem as Rong-en' one, even the
corrupted value is the same.

For start, could you, please, show your dmesg ?

Rong-en, it seems that I forgot to answer your question about the way to
find whether the given kernel address is mapped, that stalled the conversation.
I apologize for that.  It looks that the easiest would be to use
	pmap_extract(vmspace_pmap(curproc->p_vmspace), addr)
to check validity of address addr, that shall return 0 for non-mapped address
(modulo the usual races, that should be not important in that case).