From owner-freebsd-current Sun May 20 2:33: 6 2001 Delivered-To: freebsd-current@freebsd.org Received: from sol.serv.u-szeged.hu (sol.serv.u-szeged.hu [160.114.51.3]) by hub.freebsd.org (Postfix) with ESMTP id 27CE437B424 for ; Sun, 20 May 2001 02:33:01 -0700 (PDT) (envelope-from sziszi@petra.hos.u-szeged.hu) Received: from petra.hos.u-szeged.hu by sol.serv.u-szeged.hu (8.9.3+Sun/SMI-SVR4) id LAA08247; Sun, 20 May 2001 11:32:41 +0200 (MEST) Received: from sziszi by petra.hos.u-szeged.hu with local (Exim 3.12 #1 (Debian)) id 151PZo-0000pu-00; Sun, 20 May 2001 11:32:40 +0200 Date: Sun, 20 May 2001 11:32:40 +0200 From: Szilveszter Adam To: Alfred Perlstein Cc: current@FreeBSD.ORG Subject: Re: panic: mutex vm not owned... Message-ID: <20010520113240.A2706@petra.hos.u-szeged.hu> Mail-Followup-To: Szilveszter Adam , Alfred Perlstein , current@FreeBSD.ORG References: <20010519225319.A10701@petra.hos.u-szeged.hu> <20010519215626.W7118@superconductor.rush.net> <20010519220825.X7118@superconductor.rush.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010519220825.X7118@superconductor.rush.net>; from bright@rush.net on Sat, May 19, 2001 at 10:08:25PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello Alfred, hello everybody, On Sat, May 19, 2001 at 10:08:25PM -0400, Alfred Perlstein wrote: > * Alfred Perlstein [010519 21:57] wrote: > > * Szilveszter Adam [010519 16:53] wrote: > > > Hello everybody, > > > > > > I guess I was just being too happy so it had to get me this time:-) I was > > > building Mozilla when it struck. Today's -CURRENT, kernel & world in sync, > > > no softupdates. > > > > > > panic: mutex vm not owned at ../../vm/vm_page.h:328 > > > Debugger("panic") > ... > > > > Thanks for the traceback, can you apply this patch then try > > to get your machine to swap? > > Oh, yeah, thanks for being brave, I've got a lot of other developers > telling me they're not upgrading past the vm mutex patch point which > is pretty stupid as it's doing to more harm then good without a > thorough workout. :( I'm afraid I don' understand this one exactly. Did other developers oppose that you give this patch to me? Why? If they have not yet upgraded, that's fine. I was not asking to solve this problem here and now (although a solution is great:-) I was trying to help narrow it down since appearently I am the one with this problem right now. There is no hurry, this machine is play-box, which normally does nothing important, just a surf terminal. Being able to use X would be nice however, but more on that later:-) So, anyways, thanks for trying to help, I applied the patch nevertheless. I have since discovered a sure-fire method to cause a freeze and reboot, however, and maybe this may shed some light. Unfortunately, the method involves starting X, which makes debugging difficult. As soon as I attempt to start it, the screen enters SVGA mode and turns dark but the X server is never actually started it seems or at least never comes but the whole machine hangs for a couple of secs and then reboots itself. Unfortunately, while in this wedged state, it doesn't seem to be interested in me:-( Note that this effect is not dependent on the patch, but only appeared with yesterday's build, earlier X always worked fine. What effect, if any, the patch will have will show hopefully during the course of the day. Another interesting nit: - It seems that if I power-cycle the machine and start up clean, it can do approx 1-1,5 hours of compiling at which point it will panic like posted. This time the trace was: Debugger panic _mtx_assert swp_pager_async_iodone _iodone bufdone bufdonebio ad_interrupt ata_intr ithread_loop fork_exit fork_trampoline and it did not even attempt to dump, just froze at "synching disks" I had to reset it. - However, if after this I bring it up in single-user, do a manual fsck, and continue in multi-user, than it could do compiles and more (eg I restarted the Mozilla build after my initial report and hit the hay, and by morning the machine was still up, the compile finished successfully and even the periodic script runs caused apperently no problem.) So this seems rather interesting of a locking issue... however, some other info I did not give: this is an UP system, which may be important. As usual, I am more than happy to provide info, test, etc. BTW this appears to be recent and possibly related to the problem: ---------.----------- cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstri ct-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fform at-extensions -ansi -g -nostdinc -I- -I. -I../.. -I../../dev -I../../../include -I../../contrib/dev/acpica/Subsystem/Include -D_KERNEL -include opt_global.h - elf -mpreferred-stack-boundary=2 ../../ddb/db_watch.c In file included from ../../ddb/db_watch.c:41: ../../vm/vm_map.h: In function `_vm_map_lock_upgrade': ../../vm/vm_map.h:265: warning: implicit declaration of function `mtx_lock' and cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstri ct-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fform at-extensions -ansi -g -nostdinc -I- -I. -I../.. -I../../dev -I../../../include -I../../contrib/dev/acpica/Subsystem/Include -D_KERNEL -include opt_global.h - elf -mpreferred-stack-boundary=2 ../../kern/link_elf.c In file included from ../../kern/link_elf.c:52: ../../vm/vm_map.h: In function `_vm_map_lock_upgrade': ../../vm/vm_map.h:265: warning: implicit declaration of function `mtx_lock' ------------------------- it also happens in the ibcs2 and fpu modules. Of course this may be pure BS, I am not a kernel hacker, just speculate. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message