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>