Re: Kernel panic - page fault in inodedep_find

From: Rong-en Fan <grafan_at_gmail.com>
Date: Fri, 9 Mar 2007 21:01:32 +0800
On 3/9/07, Kostik Belousov <kostikbel_at_gmail.com> wrote:
> 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:
[...]
> > > > #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).

First of all, thank you for answering me. However, due to previous crash
during installworld. I reinstalled by amd64 laptop with 200702 snapshot
and updated latest current (as of today). I will try to reproduce the crash
again.

Regards,
Rong-En Fan
Received on Fri Mar 09 2007 - 12:01:34 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:06 UTC