Date: Thu, 12 Sep 2002 11:00:20 -0700 From: Maxime Henrion <mux@freebsd.org> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: Panic during reboot in vflush() Message-ID: <20020912180020.GR86074@elvis.mu.org> In-Reply-To: <3D80CA46.1AF0CA4A@FreeBSD.org> References: <3D8045D3.35A3DECE@FreeBSD.org> <20020912080531.GQ86074@elvis.mu.org> <3D80CA46.1AF0CA4A@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Maxim Sobolev wrote: > Maxime Henrion wrote: > > > > Maxim Sobolev wrote: > > > Any ideas? > > > > Looks like some other processes was modifying the mountlist while > > vfs_unmountall() was running. Is this an SMP box ? > > No, it's UP. > > > It would be nice if > > you could check in gdb which other process was holding the mountlist_mtx > > mutex if any. > > Sure, if you will provide me with instruction on how to do in. You could know it by looking at the struct mtx, but after having read the stacktrace more carefully, I think my wild guesses were incorrect. I've seen a NULL mp pointer in the args and thought it was because of a corrupted mountlist but it seems it can't be that. devfs_unmount() gets called with a valid mp pointer and gdb tells us it then calls vflush() with a NULL mp, but devfs_unmount() just call vflush() with the same mp without modifying it. It looks like it's a bug in gdb and the bug is much more likely to be in vflush() like with the stacktraces from the bento cluster kris has been reporting. I expect this bug to be fixed with jeff's patch. I'm still unsure about how things are done in vfs_unmountall() but I doubt it could be the cause of your problems. Cheers, Maxime To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020912180020.GR86074>