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.
Kevin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
