Re: panic: mutex vm not owned
On 22-May-01 Bob Bishop wrote: > Hi, > > I've seem to have the swap-related variety of this one: > > panic: mutex vm not owned at ../../vm/vm_page.h:328 > > ...from a kernel cvsup approx 0300 GMT on Sunday. > > But I'm surprised. This box has 128MB and will rarely swap building world > (which is what it was doing). The only other oddity is that it had just had > a brief "not responding...alive again" episode with the NFS server dishing > up sources. > > Anyway, here's the abridged backtrace from DDB: > > panic() > _mtx_assert() > swp_pager_async_iodone() > bufdone() > bufdonebio() > ad_interrupt() > ata_intr() > ithread_loop() > fork_exit() > fork_trampoline() > > I'll keep the box in DDB for a bit in case anyone wants more info, so dmesg > not available right now but it's a pretty unremarkable configuration > running GENERIC. The problem here is that swp_pager_*_iodone don't need to assume that the vm_mtx is held when they are called, but need to get it themselves since they are used as bio_done methods in struct bio. I've got this fixed in some untested patches on my laptop. I need to finish my first pass over the original commit and start testing things before I commit too much though. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: mutex vm not owned
Hi, I've seem to have the swap-related variety of this one: panic: mutex vm not owned at ../../vm/vm_page.h:328 ...from a kernel cvsup approx 0300 GMT on Sunday. But I'm surprised. This box has 128MB and will rarely swap building world (which is what it was doing). The only other oddity is that it had just had a brief "not responding...alive again" episode with the NFS server dishing up sources. Anyway, here's the abridged backtrace from DDB: panic() _mtx_assert() swp_pager_async_iodone() bufdone() bufdonebio() ad_interrupt() ata_intr() ithread_loop() fork_exit() fork_trampoline() I'll keep the box in DDB for a bit in case anyone wants more info, so dmesg not available right now but it's a pretty unremarkable configuration running GENERIC. -- Bob Bishop (0118) 977 4017 international code +44 118 [EMAIL PROTECTED]fax (0118) 989 4254 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: mutex vm not owned
* Dima Dorfman <[EMAIL PROTECTED]> [010521 20:02] wrote: > David Malone <[EMAIL PROTECTED]> writes: > > On Mon, May 21, 2001 at 01:44:16AM -0700, Dima Dorfman wrote: > > > > > exit1 calls shmexit with vm_mtx held on line 228 of kern_exit.c > > > (rev. 1.127). Actually, shmexit_myhook should always be called with > > > vm_mtx held, so shm_delete_mapping can't assume it isn't held. > > > > The following seems to work. It's basically your patch, but it > > removes the patch which was originally committed, adds an extra > > assert, expands on one comment and grabs a mutex in one place > > it seemed to be needed after removing the others. > > Great! I can confirm that this works for me. Alfred, any objections > to me or David committing this? I'd like to see the issues cleared up asap, if you have a delta please go ahead and commit it, just make sure you toss me a headsup about it either pre- or post- patch. Thanks for taking the time to do this. -- -Alfred Perlstein [[EMAIL PROTECTED]] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: mutex vm not owned
David Malone <[EMAIL PROTECTED]> writes: > On Mon, May 21, 2001 at 01:44:16AM -0700, Dima Dorfman wrote: > > > exit1 calls shmexit with vm_mtx held on line 228 of kern_exit.c > > (rev. 1.127). Actually, shmexit_myhook should always be called with > > vm_mtx held, so shm_delete_mapping can't assume it isn't held. > > The following seems to work. It's basically your patch, but it > removes the patch which was originally committed, adds an extra > assert, expands on one comment and grabs a mutex in one place > it seemed to be needed after removing the others. Great! I can confirm that this works for me. Alfred, any objections to me or David committing this? > + /* shm_delete_mappings requires this */ > + mtx_assert(&vm_mtx, MA_OWNED); That should be 'shm_delete_mapping'; no 's'. That's my fault. Thanks, Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: mutex vm not owned
On Mon, May 21, 2001 at 01:44:16AM -0700, Dima Dorfman wrote: > exit1 calls shmexit with vm_mtx held on line 228 of kern_exit.c > (rev. 1.127). Actually, shmexit_myhook should always be called with > vm_mtx held, so shm_delete_mapping can't assume it isn't held. The following seems to work. It's basically your patch, but it removes the patch which was originally committed, adds an extra assert, expands on one comment and grabs a mutex in one place it seemed to be needed after removing the others. David. Index: sysv_shm.c === RCS file: /cvs/FreeBSD-CVS/src/sys/kern/sysv_shm.c,v retrieving revision 1.58 diff -u -r1.58 sysv_shm.c --- sysv_shm.c 2001/05/21 18:52:02 1.58 +++ sysv_shm.c 2001/05/21 20:24:03 @@ -181,10 +181,10 @@ struct shm_handle *shm_handle; size_t size; + /* for vm_object_deallocate */ + mtx_assert(&vm_mtx, MA_OWNED); shm_handle = shmseg->shm_internal; - mtx_lock(&vm_mtx); vm_object_deallocate(shm_handle->shm_object); - mtx_unlock(&vm_mtx); free((caddr_t)shm_handle, M_SHM); shmseg->shm_internal = NULL; size = round_page(shmseg->shm_segsz); @@ -202,12 +202,12 @@ int segnum, result; size_t size; + /* for vm_map_remove and shm_deallocate_segment */ + mtx_assert(&vm_mtx, MA_OWNED); segnum = IPCID_TO_IX(shmmap_s->shmid); shmseg = &shmsegs[segnum]; size = round_page(shmseg->shm_segsz); - mtx_lock(&vm_mtx); result = vm_map_remove(&p->p_vmspace->vm_map, shmmap_s->va, shmmap_s->va + size); - mtx_unlock(&vm_mtx); if (result != KERN_SUCCESS) return EINVAL; shmmap_s->shmid = -1; @@ -233,6 +233,7 @@ { struct shmmap_state *shmmap_s; int i; + int error; if (!jail_sysvipc_allowed && jailed(p->p_ucred)) return (ENOSYS); @@ -246,7 +247,10 @@ break; if (i == shminfo.shmseg) return EINVAL; - return shm_delete_mapping(p, shmmap_s); + mtx_lock(&vm_mtx); + error = shm_delete_mapping(p, shmmap_s); + mtx_unlock(&vm_mtx); + return error; } #ifndef _SYS_SYSPROTO_H_ @@ -455,7 +459,9 @@ shmseg->shm_perm.key = IPC_PRIVATE; shmseg->shm_perm.mode |= SHMSEG_REMOVED; if (shmseg->shm_nattch <= 0) { + mtx_lock(&vm_mtx); shm_deallocate_segment(shmseg); + mtx_unlock(&vm_mtx); shm_last_free = IPCID_TO_IX(uap->shmid); } break; @@ -663,6 +669,8 @@ struct shmmap_state *shmmap_s; int i; + /* shm_delete_mappings requires this */ + mtx_assert(&vm_mtx, MA_OWNED); shmmap_s = (struct shmmap_state *)p->p_vmspace->vm_shm; for (i = 0; i < shminfo.shmseg; i++, shmmap_s++) if (shmmap_s->shmid != -1) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: mutex vm not owned
> > I tried Dima's patch (the one which Alfred has committed) and I > > get an earlier mutex recursion panic, probably when a local progam > > that uses shm forks and exits. I scribbled down this trace from > > it: > Is there such a program in the base system? Nope - it's part of a radio refclock for NTP. It doesn't do anything magic though - just shares a shm segement with ntpd and gets times from the serial port. > Attached is an untested patch to try to fix this. It's almost 02:00 > here and I have to head to bed, but it may work for you. At least it > may be a starting point for someone. I won't be able to apply the patch until I get home from work. Should I apply it on top of the other patch? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: mutex vm not owned
David Malone <[EMAIL PROTECTED]> writes: > > Please try the attached patch. I make no claims of its correctness, > > but this e-mail is coming to you via X on -current updated a few hours > > ago so it works here :-). > > I tried Dima's patch (the one which Alfred has committed) and I > get an earlier mutex recursion panic, probably when a local progam > that uses shm forks and exits. I scribbled down this trace from > it: Is there such a program in the base system? > panic+0x70 > _mtx_assert+0x67 > lockmgr+0xdc > vm_map_remove+0x42 > shm_delete_mapping+0xe1 > shmexit_myhook+0x29 > exit1+0x9eb > exit1 > > So it looks like those routines are sometime called with the mutex > already held. exit1 calls shmexit with vm_mtx held on line 228 of kern_exit.c (rev. 1.127). Actually, shmexit_myhook should always be called with vm_mtx held, so shm_delete_mapping can't assume it isn't held. Attached is an untested patch to try to fix this. It's almost 02:00 here and I have to head to bed, but it may work for you. At least it may be a starting point for someone. Hope this helps, Dima Dorfman [EMAIL PROTECTED] Index: sysv_shm.c === RCS file: /stl/src/FreeBSD/src/sys/kern/sysv_shm.c,v retrieving revision 1.56 diff -u -r1.56 sysv_shm.c --- sysv_shm.c 2001/05/19 01:28:03 1.56 +++ sysv_shm.c 2001/05/21 08:41:29 @@ -200,6 +206,8 @@ int segnum, result; size_t size; + /* for vm_map_remove */ + mtx_assert(&vm_mtx, MA_OWNED); segnum = IPCID_TO_IX(shmmap_s->shmid); shmseg = &shmsegs[segnum]; size = round_page(shmseg->shm_segsz); @@ -229,6 +237,7 @@ { struct shmmap_state *shmmap_s; int i; + int error; if (!jail_sysvipc_allowed && jailed(p->p_ucred)) return (ENOSYS); @@ -242,7 +251,10 @@ break; if (i == shminfo.shmseg) return EINVAL; - return shm_delete_mapping(p, shmmap_s); + mtx_lock(&vm_mtx); + error = shm_delete_mapping(p, shmmap_s); + mtx_unlock(&vm_mtx); + return error; } #ifndef _SYS_SYSPROTO_H_ @@ -659,6 +671,8 @@ struct shmmap_state *shmmap_s; int i; + /* shm_delete_mappings requires this */ + mtx_assert(&vm_mtx, MA_OWNED); shmmap_s = (struct shmmap_state *)p->p_vmspace->vm_shm; for (i = 0; i < shminfo.shmseg; i++, shmmap_s++) if (shmmap_s->shmid != -1) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: mutex vm not owned
> Please try the attached patch. I make no claims of its correctness, > but this e-mail is coming to you via X on -current updated a few hours > ago so it works here :-). I tried Dima's patch (the one which Alfred has committed) and I get an earlier mutex recursion panic, probably when a local progam that uses shm forks and exits. I scribbled down this trace from it: panic+0x70 _mtx_assert+0x67 lockmgr+0xdc vm_map_remove+0x42 shm_delete_mapping+0xe1 shmexit_myhook+0x29 exit1+0x9eb exit1 So it looks like those routines are sometime called with the mutex already held. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: mutex vm not owned
* Szilveszter Adam <[EMAIL PROTECTED]> [010520 17:07] wrote: > On Sun, May 20, 2001 at 01:29:22PM -0700, Dima Dorfman wrote: > > > > Please try the attached patch. I make no claims of its correctness, > > but this e-mail is coming to you via X on -current updated a few hours > > ago so it works here :-). > > OK, I've just tried this and would like to report that it works. Of course, > using X without swapping is not practically possible:-) but as a demonstration > it's all right. > > Now I hope the other problems with swapping can also be sorted out. I have > sent Alfred some traces, unfortunately this is about all, dumping is not > possible... let's hope for the best. > > Luckily, console based CD players also exist. That patch was committed to -current several hours ago. you should have version 1.57 of sys/kern/sysv_shm.c. Of course this only fixes sysv shm, not swapping. -- -Alfred Perlstein [[EMAIL PROTECTED]] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: mutex vm not owned
[cc's trimmed] Same problem, this fixed me too. On Sun, May 20, 2001 at 05:23:11PM -0400, Mike Heffner wrote: > > On 20-May-2001 Dima Dorfman wrote: > | Please try the attached patch. I make no claims of its correctness, > | but this e-mail is coming to you via X on -current updated a few hours > | ago so it works here :-). > > Thanks, it works so far (I'm running X). I'll see where it breaks next. > > > Mike > > -- > Mike Heffner <[EMAIL PROTECTED]> > Fredericksburg, VA <[EMAIL PROTECTED]> > http://filebox.vt.edu/users/mheffner > -- Michael Lucas [EMAIL PROTECTED] http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: mutex vm not owned
On 20-May-2001 Dima Dorfman wrote: | Please try the attached patch. I make no claims of its correctness, | but this e-mail is coming to you via X on -current updated a few hours | ago so it works here :-). Thanks, it works so far (I'm running X). I'll see where it breaks next. Mike -- Mike Heffner <[EMAIL PROTECTED]> Fredericksburg, VA <[EMAIL PROTECTED]> http://filebox.vt.edu/users/mheffner PGP signature
Re: panic: mutex vm not owned
On Sun, May 20, 2001 at 01:29:22PM -0700, Dima Dorfman wrote: > David Malone <[EMAIL PROTECTED]> writes: > > On Sun, May 20, 2001 at 12:59:51PM -0400, Mike Heffner wrote: > > > The machine is up for about one minute and then I ran `startx' and the > > > screen turned black and it appeared to lockup, after about 30 seconds > > > plus some banging on the keyboard it rebooted. I have 256mb ram, so it > > > shouldn't be swapping at this point. The kernel and world are cvsupd > > > to about 12am May 20 EDT, the following is the panic message: > > > > I'm getting a panic whenever I start X too (with a kernel from > > earlier today). I managed to get a DDB trace from a serial console. > > Please try the attached patch. I make no claims of its correctness, > but this e-mail is coming to you via X on -current updated a few hours > ago so it works here :-). OK, I've just tried this and would like to report that it works. Of course, using X without swapping is not practically possible:-) but as a demonstration it's all right. Now I hope the other problems with swapping can also be sorted out. I have sent Alfred some traces, unfortunately this is about all, dumping is not possible... let's hope for the best. Luckily, console based CD players also exist. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: mutex vm not owned
David Malone <[EMAIL PROTECTED]> writes: > On Sun, May 20, 2001 at 12:59:51PM -0400, Mike Heffner wrote: > > The machine is up for about one minute and then I ran `startx' and the > > screen turned black and it appeared to lockup, after about 30 seconds > > plus some banging on the keyboard it rebooted. I have 256mb ram, so it > > shouldn't be swapping at this point. The kernel and world are cvsupd > > to about 12am May 20 EDT, the following is the panic message: > > I'm getting a panic whenever I start X too (with a kernel from > earlier today). I managed to get a DDB trace from a serial console. Please try the attached patch. I make no claims of its correctness, but this e-mail is coming to you via X on -current updated a few hours ago so it works here :-). I had to manually edit out some unrelated local changes, so if you have trouble applying it fetch the full one from http://www.unixfreak.org/~dima/home/shm-full.diff. That one has local changes (new sysctls), but they (probably) won't hurt you. Thanks, Dima Dorfman [EMAIL PROTECTED] Index: sysv_shm.c === RCS file: /stl/src/FreeBSD/src/sys/kern/sysv_shm.c,v retrieving revision 1.56 diff -u -r1.56 sysv_shm.c --- sysv_shm.c 2001/05/19 01:28:03 1.56 +++ sysv_shm.c 2001/05/20 20:26:28 @@ -182,7 +186,9 @@ size_t size; shm_handle = shmseg->shm_internal; + mtx_lock(&vm_mtx); vm_object_deallocate(shm_handle->shm_object); + mtx_unlock(&vm_mtx); free((caddr_t)shm_handle, M_SHM); shmseg->shm_internal = NULL; size = round_page(shmseg->shm_segsz); @@ -203,7 +209,9 @@ segnum = IPCID_TO_IX(shmmap_s->shmid); shmseg = &shmsegs[segnum]; size = round_page(shmseg->shm_segsz); + mtx_lock(&vm_mtx); result = vm_map_remove(&p->p_vmspace->vm_map, shmmap_s->va, shmmap_s->va + size); + mtx_unlock(&vm_mtx); if (result != KERN_SUCCESS) return EINVAL; shmmap_s->shmid = -1; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: mutex vm not owned
On Sun, May 20, 2001 at 12:59:51PM -0400, Mike Heffner wrote: > The machine is up for about one minute and then I ran `startx' and the > screen turned black and it appeared to lockup, after about 30 seconds > plus some banging on the keyboard it rebooted. I have 256mb ram, so it > shouldn't be swapping at this point. The kernel and world are cvsupd > to about 12am May 20 EDT, the following is the panic message: I'm getting a panic whenever I start X too (with a kernel from earlier today). I managed to get a DDB trace from a serial console. David. panic: mutex vm not owned at ../../vm/vm_object.c:330 Debugger("panic") Stopped at Debugger+0x44: pushl %ebx db> t Debugger(c02fdbbb) at Debugger+0x44 panic(c02fcc07,c0313f10,c0315234,14a,c038fe40) at panic+0x70 _mtx_assert(c03bfb80,1,c0315234,14a) at _mtx_assert+0x49 vm_object_deallocate(c038fe40,c0de4030,c863d300,c8692f38,c01e59f3) at vm_object_ deallocate+0x1e shm_deallocate_segment(c0de4030,c8692f80,c863d300,4,c863d300) at shm_deallocate_ segment+0x12 shmctl(c863d300,c8692f84,c863d300,0,c8692fa0) at shmctl+0x117 shmsys(c863d300,c8692f80,2838d9f4,1,bfbffc80) at shmsys+0x43 syscall(2f,2f,2f,bfbffc80,1) at syscall+0x7f9 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: mutex vm not owned...
Hello, I am back with more information. The machine had been up mostly idle for about 1 1/2 hours again. I am starting to suspect that it is being idle that may also trip the wire here... maybe, given my 128megs of RAM and 300 megs of swap, that's when my computer decides that it's time to swap some stuff and boom. Alfred's patch indeed seems to have changed things a bit: It paniced after 1h37m uptime during a CVS checkout, with the following: panic: sleeping with vm_mtx held trace: Debugger panic msleep swap_pager_getpages vm_fault1 vm_fault trap_pfault trap calltrap ---trap 0xc, eip= 0x2824dc2e, esp=0xbfbfe16c, ebp=0xbfbfe160 then after 'c': syncing disks... panic: mutex vm owned at ../../kern/vfs_bio:2998 nice long trace: Debugger panic _mtx_assert vfs_busy_pages bwrite vfs_bio_awrite spec_fsync spec_vnoperate ffs_sync sync boot panic msleep swap_pager_getpages vm_fault1 vm_fault trap_pfault trap calltrap and again the same trap message like above. After hitting 'c', it freezes at the dumping: resetting devices part. This starts to become interesting... will follow up with more when found. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: mutex vm not owned...
Hello Alfred, hello everybody, On Sat, May 19, 2001 at 10:08:25PM -0400, Alfred Perlstein wrote: > * Alfred Perlstein <[EMAIL PROTECTED]> [010519 21:57] wrote: > > * Szilveszter Adam <[EMAIL PROTECTED]> [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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: mutex vm not owned...
* Alfred Perlstein <[EMAIL PROTECTED]> [010519 21:57] wrote: > * Szilveszter Adam <[EMAIL PROTECTED]> [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. :( -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: mutex vm not owned...
* Szilveszter Adam <[EMAIL PROTECTED]> [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") > > Stopped at Debugger > > trace: > Debugger > panic > _mtx_assert > swp_pager_async_iodone > _iodone > bufdone > bufdonebio > ad_interrupt > ata_intr > fork_exit > fork_trampoline > > Unfortunately, dumping still doesn't work, I get the old and familiar: > dump ata0: resetting devices... panic: witness_restore: lock (sleep mutex) > Giant not locked. > > So there is no crash dump. Thanks for the traceback, can you apply this patch then try to get your machine to swap? Index: swap_pager.c === RCS file: /home/ncvs/src/sys/vm/swap_pager.c,v retrieving revision 1.155 diff -u -r1.155 swap_pager.c --- swap_pager.c2001/05/19 01:28:08 1.155 +++ swap_pager.c2001/05/20 01:58:06 @@ -1474,8 +1474,8 @@ */ mtx_unlock(&Giant); - mtx_lock(&vm_mtx); swp_pager_async_iodone(bp); + mtx_lock(&vm_mtx); splx(s); } @@ -1554,7 +1554,7 @@ /* * remove the mapping for kernel virtual */ - + mtx_lock(&vm_mtx); pmap_qremove((vm_offset_t)bp->b_data, bp->b_npages); /* @@ -1689,6 +1689,7 @@ if (object) vm_object_pip_wakeupn(object, bp->b_npages); + mtx_unlock(&vm_mtx); /* * release the physical I/O buffer */ -- -Alfred Perlstein [[EMAIL PROTECTED]] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message