Date: Thu, 28 Jun 2012 10:42:33 +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: <1340851353.2151.7.camel@nsl> In-Reply-To: <20120627154233.GO2337@deviant.kiev.zoral.com.ua> 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> <1340774954.2147.3.camel@nsl> <20120627154233.GO2337@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Konstantin Belousov wrote: > On Wed, Jun 27, 2012 at 01:29:14PM +0800, Kevin Lo wrote: > > 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. > It is not 'the' KASSERT, it is something different. > > Are you sure that you do not have some systematic build issues on your > machines ? Although I do not think that tmpfs is 'ready for production use' > for arbitrary low value of this statement, there is no steady flow of > similar reports from other users. This makes me somewhat suspicious that > either you might have inconsistent build issues, or unrelated memory > corruption problems. As I mentioned, I'm running -CURRENT on a number of systems. I haven't seen tmpfs panics on machines running FreeBSD 9. Kevin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1340851353.2151.7.camel>