Date: Wed, 27 Jun 2012 13:29:14 +0800 From: Kevin Lo <kevlo@kevlo.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-fs@freebsd.org, freebsd-current <freebsd-current@freebsd.org> Subject: Re: Tmpfs panic in -current Message-ID: <1340774954.2147.3.camel@nsl> In-Reply-To: <1340763363.2147.1.camel@nsl> References: <1340589808.2192.1.camel@nsl> <20120625095548.GD2337@deviant.kiev.zoral.com.ua> <1340685505.2170.5.camel@nsl> <20120626102424.GL2337@deviant.kiev.zoral.com.ua> <1340763363.2147.1.camel@nsl>
next in thread | previous in thread | raw e-mail | index | archive | help
Kevin Lo wrote: > Konstantin Belousov wrote: > > On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote: > > > Konstantin Belousov wrote: > > > > On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote: > > > > > I've observed a panic in recent -current several times but I only > > > > > have a picture of the backtrace: > > > > > http://people.freebsd.org/~kevlo/panic_tmpfs.jpg > > > > > > > > > > Does this look at all familiar to anyone? > > > > > > > > Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address > > > > in your kernel ? > > > > > > Sure. > > > > > > > The screenshot looks strange. The instruction on which the kernel trapped > > > > is int 0x28 which should not appear in the compiled code. > > > > > > # gdb tmpfs.ko > > > (gdb) l *tmpfs_reg_resize+0x627 > > > 0xbf37 is in tmpfs_reg_resize (/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005). > > > 1000 in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c > > > > > > In tmpfs_subr.c: > > > 999 if (m != NULL) { > > > 1000 if ((m->oflags & VPO_BUSY) != 0 || > > > 1001 m->busy != 0) { > > > 1002 vm_page_sleep(m, "tmfssz"); > > > 1003 goto retry; > > > 1004 } > > > 1005 MPASS(m->valid == VM_PAGE_BITS_ALL); > > > 1006 } else if (vm_pager_has_page(uobj, idx, NULL, NU > > > LL)) { > > > > > Hm, can you get a core and > > - obtain backtrace in kgdb; > > - print the *m content for the page that triggered the assertion ? > > > > The only possible 'new size' value for the truncation from open(2) is zero, > > so I do not understand why the asserted block was executed at all. > > Thanks for looking into it. Unfortunately I can't get a crash dump > due to lack of disk space and memory. I triggered the KASSERT on a different machine in the last hour. panic: Assertion (vp) !=NULL && (vp)->v_data != NULL failed at @/fs/tmpfs/tmpfs.h:527 The bad news is my coworker rebooted that machine after panic :-( Kevin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1340774954.2147.3.camel>