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
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
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
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
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
* 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
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...
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: -snip from kernel build log.--- 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' -end of snippet 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...
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
panic: mutex vm not owned
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: panic: mutex vm not owned at /usr/src/sys/vm/vm_object.c:330 This was the first time I've tried getting a crashdump and analyzing it, however when I follow the directions in the handbook, gdb seg. faults (could this be because it panic'd in the vm system ??) : enterprise# pwd /usr/obj/usr/src/sys/BUTTER enterprise# gdb -k GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-freebsd. (kgdb) symbol-file kernel.debug Reading symbols from kernel.debug...done. (kgdb) exec-file /var/crash/kernel.0 (kgdb) core-file /var/crash/vmcore.0 Segmentation fault (core dumped) I also have DDB in my kernel config, but it didn't drop into DDB. Is there anything else I can test? I'm willig to test any patches or whatever. Thanks, Mike -- Mike Heffner [EMAIL PROTECTED] Fredericksburg, VA [EMAIL PROTECTED] http://filebox.vt.edu/users/mheffner 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
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 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.grin -- 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
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
[cc's trimmed] aol Same problem, this fixed me too. /aol 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
* 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.grin 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
panic: mutex vm not owned...
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. Ideas? -- 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...
* 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
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
