Date: Fri, 9 Mar 2007 14:52:27 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Michal Mertl <mime@traveller.cz> Cc: freebsd-current <freebsd-current@freebsd.org>, Rong-en Fan <grafan@gmail.com> Subject: Re: Kernel panic - page fault in inodedep_find Message-ID: <20070309125227.GB73957@deviant.kiev.zoral.com.ua> In-Reply-To: <1173422820.1211.3.camel@genius.i.cz> References: <1173353693.1523.7.camel@genius.i.cz> <20070308121301.GR10453@deviant.kiev.zoral.com.ua> <1173422820.1211.3.camel@genius.i.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
--PmA2V3Z32TCmWXqI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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 chan=
ce
> > > to see it and when dump works) is attached. I have got crash dump so =
can
> > > provide more details as required.
> > >=20
> > > The panic seem to be provoked by heavier disk activity (running cvsup=
or
> > > similar).
> > >=20
> > > The machine is AMD64 SMP.
> > >=20
> > > Thanks
> > >=20
> > > Michal
> > >=20
> > >=20
> > > Fatal trap 12: page fault while in kernel mode
> > > cpuid =3D 1; apic id =3D 01
> > > fault virtual address =3D 0x50
> > > fault code =3D supervisor read data, page not present
> > > instruction pointer =3D 0x8:0xffffffff8059c175
> > > stack pointer =3D 0x10:0xffffffffaf6b8380
> > > frame pointer =3D 0x10:0xffffffffaf6b8390
> > > code segment =3D base 0x0, limit 0xfffff, type 0x1b
> > > =3D DPL 0, pres 1, long 1, def32 0, gran 1
> > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0
> > > current process =3D 1194 (cvs)
> > > trap number =3D 12
> > > panic: page fault
> > > cpuid =3D 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 =3D 0xffffffff8059c175, rsp =3D 0xffffffffaf6b8380,=
rbp =3D
> > > 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 =3D 0x8013b8c7c, rsp =3D
> > > 0x7fffffffe0a8, rbp =3D 0x10 ---
> > > Uptime: 1m40s
> > > Physical memory: 2034 MB
> > > Dumping 213 MB: 198 182 166 150 134 118 102 86 70 54 38 22 6
> > >=20
> > >=20
> > > --------------------------
> > >=20
> > > #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=3D260)
> > > at ../../../kern/kern_shutdown.c:409
> > > #2 0xffffffff804383b7 in panic (fmt=3D0xffffffff80690d22 "%s")
> > > at ../../../kern/kern_shutdown.c:563
> > > #3 0xffffffff8063ebc9 in trap_fatal (frame=3D0xc,
> > > eva=3D18446742975751987856) at ../../../amd64/amd64/trap.c:696
> > > #4 0xffffffff8063ef39 in trap_pfault (frame=3D0xffffffffaf6b82d0,
> > > usermode=3D0) at ../../../amd64/amd64/trap.c:614
> > > #5 0xffffffff8063f16e in trap (frame=3D0xffffffffaf6b82d0)
> > > at ../../../amd64/amd64/trap.c:382
> > > #6 0xffffffff806278ee in calltrap ()
> > > at ../../../amd64/amd64/exception.S:169
> > > #7 0xffffffff8059c175 in inodedep_find (inodedephd=3D0xffffffff8106d=
660,
> > > fs=3D0xffffff0061a4d800, inum=3D168358, inodedeppp=3D0xffff ffffaf6b8=
3e0)
> > > at ../../../ufs/ffs/ffs_softdep.c:1246
> > Please, from this frame (#7) do
> > p/x *inodedep
> > p/x *inodedephd
>=20
> 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 =3D {lh_first =3D 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 conversat=
ion.
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 addre=
ss
(modulo the usual races, that should be not important in that case).
--PmA2V3Z32TCmWXqI
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQFF8ViKC3+MBN1Mb4gRAo6BAKDiYN7jRMKhAwsA6DGUN9gIdpwJFACdEJfZ
F/35OvLQKlnXC6uZXdrfpHU=
=rPY9
-----END PGP SIGNATURE-----
--PmA2V3Z32TCmWXqI--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070309125227.GB73957>