panic: merge_inode_lists+0x86: movl %eax,0x10(%edx)
Just upgraded to latest sources, doesn't look like the swap issue ... was
performing a 'make -j16 buildworld' when it panic'd ...
Fataltrap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0x11
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc020d646
stack pointer = 0x10:0xcce9ac04
frame pointer = 0x10:0xcce9ac0c
code segmnt = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 62131 (sh)
kernel: type 12 trap, code=0
Stopped at merge_inode_lists+0x86: movl%eax,0x10(%edx)
db> trace
merge_inode_lists+0x86
softdep_setup_freeblocks+0x21c
ffs_truncate+0x1d0
ufs_inactive+0x9a
ufs_vnoperate+0x15
vrele+0x16e
ufs_close+0x198
ufs_vnoperate+0x15
vn_close+0x40
vn_closefile+0x23
fdrop+0xb9
closef+0x9b
fdfree+0x44
exit1+0x5eb
sys_exit+0x15
syscall+0x645
syscall_with_err_pushed+0x1b
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I broke swapping
John Baldwin wrote: > If I have swap (i.e. I've run swapon on a swap partition) the program is kill ed > by the system fine. If I don't have swap, then both the memkill process adn > the swapper process (proc0) are stuck in the "vmwait" wait channel used by > VM_WAIT. Any ideas? This may not be a new problem. I have seen a lot of machines hit this sort of thing at work. It can end up in the majority of processes on the system in this state. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: HEADS UP: I broke swapping
On 22-May-01 John Baldwin wrote: > > On 20-May-01 Alfred Perlstein wrote: >> I broke swapping with the vm mutex. >> >> Hopefully I should have this fixed up within a couple of days tops. >> >> No, I'm not heading off to Aruba or someplace after this intrusive >> change, I am working on it. Your kernel may panic, but I hope you >> all keep a level head about this and don't follow suit. :) >> >> Patches, suggestions and crashdumps would be helpful. >> >> Bruce has been giving me some helpful tracebacks that I'm planning >> to use to stabilize the system. > > I am currently running X on my laptop with a current kernel with the patch > http://www.FreeBSD.org/~jhb/patches/vm.patch. It is swapping, and I've > tested > out exhausting all the swap and mem at least which worked. Well, I've cleaned out all but one lock order reversal (the race between faultin() and swapout() needs to be fixed in a more proper fashion) and tried to push Giant back down some by re-enabling all the MPSAFE syscalls in Alfred's commit, but now I can deadlock (well, livelock actually) my laptop in single user via a simple memkill program that basically does this: for (;;) *(char *)malloc(1) = 1; If I have swap (i.e. I've run swapon on a swap partition) the program is killed by the system fine. If I don't have swap, then both the memkill process adn the swapper process (proc0) are stuck in the "vmwait" wait channel used by VM_WAIT. Any ideas? -- 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: HEADS UP: I broke swapping
On 22-May-01 John Baldwin wrote: > > On 20-May-01 Alfred Perlstein wrote: >> I broke swapping with the vm mutex. >> >> Hopefully I should have this fixed up within a couple of days tops. >> >> No, I'm not heading off to Aruba or someplace after this intrusive >> change, I am working on it. Your kernel may panic, but I hope you >> all keep a level head about this and don't follow suit. :) >> >> Patches, suggestions and crashdumps would be helpful. >> >> Bruce has been giving me some helpful tracebacks that I'm planning >> to use to stabilize the system. > > I am currently running X on my laptop with a current kernel with the patch > http://www.FreeBSD.org/~jhb/patches/vm.patch. It is swapping, and I've > tested > out exhausting all the swap and mem at least which worked. Also, to clarify a point here and vindicate Alfred some since some people are calling for his head: Alfred didn't entirely break swapping, I helped. Revision 1.112 #if 0'd out code to lock the vm_map of a process when we were swapping it out. At the time I thought that we locked the map and immediately released the lock. However, we also bumped the refcount on the vmspace, but didn't call vmspace_free() until later after swapout(). I #if 0'd out the bump of the refcount, but not the vmspace_free(), thus when swapping out processes, we would release a vmspace out from under a process giving vmdaemon a heart attack later on. I think we still leak a vmspace refcount if we fail the swap_idle_threadhold2 test in swapout_procs(), and I'm going to test out a fix for that as well. -- 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: HEADS UP: I broke swapping
On 20-May-01 Alfred Perlstein wrote: > I broke swapping with the vm mutex. > > Hopefully I should have this fixed up within a couple of days tops. > > No, I'm not heading off to Aruba or someplace after this intrusive > change, I am working on it. Your kernel may panic, but I hope you > all keep a level head about this and don't follow suit. :) > > Patches, suggestions and crashdumps would be helpful. > > Bruce has been giving me some helpful tracebacks that I'm planning > to use to stabilize the system. I am currently running X on my laptop with a current kernel with the patch http://www.FreeBSD.org/~jhb/patches/vm.patch. It is swapping, and I've tested out exhausting all the swap and mem at least which worked. > swapinfo Device 1K-blocks UsedAvail Capacity Type /dev/ad0s2b266112 16 266096 0%Interleaved > vmstat -s 659683 cpu context switches 547856 device interrupts 5289 software interrupts 269300 traps 1492219 system calls 26 kernel threads created 710 fork() calls 59 vfork() calls 0 rfork() calls 15 swap pager pageins 17 swap pager pages paged in 524 swap pager pageouts 7923 swap pager pages paged out 803 vnode pager pageins 6173 vnode pager pages paged in 0 vnode pager pageouts 0 vnode pager pages paged out 253 page daemon wakeups ... vm.vm_faults_no_vm_mtx: 209859 vm.vm_faults_no_giant: 0 vm.stats.vm.v_vm_faults: 227165 The patch still needs some cleanups, and there are some lock order reversals I still need to work on, but it might be worth testing. :) -- 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: What's causing troubles with pcm?
On Tue, May 22, 2001 at 04:13:47PM +0200, Vallo Kallaste wrote: > Playing mp3's with mpg123 has been quite satistfactory until now. > Today I've discovered that every execution of sync(8) distorts > music by means of "stretching" musical phrase. The obvious answer would be to not run sync(8) :^) Likely, what you're seeing is the combo of the pcm driver being pretty sensitive to other interrupt activity and the ata driver turning off write caching by default. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world broken (vinum)
On Tuesday, 22 May 2001 at 17:30:57 +0200, Szilveszter Adam wrote: > On Tue, May 22, 2001 at 05:22:12PM +0200, Szilveszter Adam wrote: >> Hello Greg and others, >> >> Well I cannot find that file (/usr/src/sys/dev/vinum/vinumutil.h) there, it >> is not there in the cvsweb interface either. However, I can confirm that >> >> /usr/src/sys/dev/vinum/vinumhdr.h >> >> contains a reference to it. >> >> So? > > More than that, according to cvsweb annotate, that particular line > > #include > > was only added in the latest revision. Maybe a private tree mixup? Aargh, no, only blindness. But not only mine: what I found (and documented) there was vinumutil.c, which has been there for a long time. vinumutil.h is new, and it wasn't there. I've committed it now. /me adds to his pile of pointy hats. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new function for libdevstat
Sergey A. Osokin writes: > I have rewritten devstat_compute_statistics(). > Please see the attachment. Add ``break'' in each ``case''. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world broken
In answer to Greg's query "What happens if you try building in sys/modules/vinum?": dhcp-133[3] pushd sys/modules/vinum/ /usr/src/sys/modules/vinum /usr/src dhcp-133[4] make Warning: Object directory not changed from original /usr/src/sys/modules/vinum @ -> /usr/src/sys machine -> /usr/src/sys/i386/include touch opt_vinum.h perl @/kern/vnode_if.pl -h @/kern/vnode_if.src cc -O -pipe -DVINUMDEBUG -g -O -D_KERNEL -Wall -Wredundant-decls -Wnested-exte rns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qu al -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/. ./include -I/usr/include -mpreferred-stack-boundary=2 -Wall -Wredundant-decls - Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winli ne -Wcast-qual -fformat-extensions -ansi -c /usr/src/sys/modules/vinum/../../de v/vinum/vinum.c In file included from /usr/src/sys/modules/vinum/../../dev/vinum/vinum.c:44: @/dev/vinum/vinumhdr.h:78: dev/vinum/vinumutil.h: No such file or directory *** Error code 1 Stop in /usr/src/sys/modules/vinum. dhcp-133[5] [The good news is that, although I wasn't yet willing to try building -CURRENT under X, I was able to get through the buildworld in multi- user mode OK.] Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src Makefile.inc1
Bruce Evans wrote: > On 21 May 2001, Cyrille Lefevre wrote: [snip] > I don't need it myself (I only ran it to see if it supported Linux > extended partitions (it didn't, at least in it's list of known partition > types)). This is for the old Linux fdisk with a dumb terminal interface > which hadn't changed much (in 1997) since it was first implemented in > 1991 or 1992. It doesn't have a good interface, but I rather like it > since most of it was apparently copied from the one I implemented in > Minix fdisk in 1988 or 1989 :-). Others might prefer a more graphical > interface. Which version did you port? the ones from util-linux-2.10s.tar.gz (or .src.rpm?) cfdisk and fdisk seems to work good. for instance, sfdisk make a core! I did need it in the past, but in fact, I've done what I want w/ the bsd one. it was when I upgrade MaxBlast which is a software BIOS to see large drives. it changed the IDs of all (DOS?) primary and partitions to 0x55 and FreeBSD didn't like it at all. the problem is that ID didn't make a difference between primary (0xC) and extended (0xF) partitions... CC shortened. Cyrille. -- home: mailto:[EMAIL PROTECTED] UNIX is user-friendly; it's just particular work: mailto:[EMAIL PROTECTED] about who it chooses to be friends with. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world broken (vinum)
On Tue, May 22, 2001 at 05:22:12PM +0200, Szilveszter Adam wrote: > Hello Greg and others, > > Well I cannot find that file (/usr/src/sys/dev/vinum/vinumutil.h) there, it > is not there in the cvsweb interface either. However, I can confirm that > > /usr/src/sys/dev/vinum/vinumhdr.h > > contains a reference to it. > > So? More than that, according to cvsweb annotate, that particular line #include was only added in the latest revision. Maybe a private tree mixup? -- 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: world broken (vinum)
>Date: Tue, 22 May 2001 17:22:12 +0200 >From: Szilveszter Adam <[EMAIL PROTECTED]> >Well I cannot find that file (/usr/src/sys/dev/vinum/vinumutil.h) there, it >is not there in the cvsweb interface either. However, I can confirm that >/usr/src/sys/dev/vinum/vinumhdr.h >contains a reference to it. Confirmed over here, as well. Recent CVSup history: CVSup begin from cvsup14.freebsd.org at Sun May 20 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Sun May 20 03:53:25 PDT 2001 CVSup begin from cvsup14.freebsd.org at Mon May 21 03:47:01 PDT 2001 CVSup ended from cvsup14.freebsd.org at Mon May 21 03:52:21 PDT 2001 CVSup begin from cvsup14.freebsd.org at Tue May 22 03:47:01 PDT 2001 CVSup ended from cvsup14.freebsd.org at Tue May 22 03:52:32 PDT 2001 Thanks, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world broken (vinum)
Hello Greg and others, Well I cannot find that file (/usr/src/sys/dev/vinum/vinumutil.h) there, it is not there in the cvsweb interface either. However, I can confirm that /usr/src/sys/dev/vinum/vinumhdr.h contains a reference to it. So? -- 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: New strategy of locking a process group
On 22-May-01 Seigo Tanimura wrote: > On Tue, 22 May 2001 04:48:38 -0700 (PDT), > John Baldwin <[EMAIL PROTECTED]> said: > > John> On 22-May-01 Seigo Tanimura wrote: >>> For now, p_mtx protects p_pgrp in struct proc. This is quite >>> troublesome for the following reason: > > John> Err, it doesn't really. It's mostly undecided at this point. Also, > have you > John> looked at the BSD/OS code on builder? They have process groups and > sessions > John> already locked not using global locks but using per-data structure > locks. > > If you do not protect both p_pgrp and p_pglist in struct proc by an > identical lock, you end up with breaking either setpgid(2) or kill(2) > for a process group. The following scenario depicts an example of the > breakage: I'll have to look over the code in more detail, but I would encourage you to check the BSD/OS code. > Finally, a fact missing in my last mail. psignal() actually checks for > the parent of a process, possibly sending SIGCHLD to it. This implies > that we have to slock proctree_lock so that the process hierarchy does > not change. Now that psignal() calls for both pgrpsess_lock and > proctree_lock, it should be cheaper to have only proctree_lock than > both of them. Actually, psignal does _not_ use proctree_lock. p_pptr is locked by both p_mtx and the proctree lock (writes to it require both locks) so either lock is sufficient to read the value. As a result, psignal() simply acquires p_mtx and doesn't go near proctree. -- 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: cvs commit: src Makefile.inc1
On 21 May 2001, Cyrille Lefevre wrote: > Bruce Evans <[EMAIL PROTECTED]> writes: > > > > Debian CDs on FreeBSD with linux emulation way better than you can build > > > say a -STABLE release on a -CURRENT box... ) > > > > I just tried a Linux fdisk binary built in 1997 under FreeBSD-current. > > It seemed to run perfectly except it couldn't determine the disk geometry > > automatically. > > some times ago, I've ported linux fdisk to native freebsd. if you > really need it, I could make it a port ? I don't need it myself (I only ran it to see if it supported Linux extended partitions (it didn't, at least in it's list of known partition types)). This is for the old Linux fdisk with a dumb terminal interface which hadn't changed much (in 1997) since it was first implemented in 1991 or 1992. It doesn't have a good interface, but I rather like it since most of it was apparently copied from the one I implemented in Minix fdisk in 1988 or 1989 :-). Others might prefer a more graphical interface. Which version did you port? Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's causing troubles with pcm?
On Tue, May 22, 2001 at 04:13:47PM +0200, Vallo Kallaste <[EMAIL PROTECTED]> wrote: > I know that -current is very fragile to say at least, but what's > specifically causing it? Using simple for ((i=1;i<=300;i++)); do sync; done does the trick, my system spends more than 50% in system, according to top. Vmstat shows ~300 page faults per second and about same for freed pages. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
What's causing troubles with pcm?
Hi Playing mp3's with mpg123 has been quite satistfactory until now. Today I've discovered that every execution of sync(8) distorts music by means of "stretching" musical phrase. In example what normally sounds like "How do" sounds now "Hhhooowww ddd" with a bit of added noise or something similar. Hard to describe. Happens even with textmode only, no X. Log into two virtual terminals, fire up mpg123 "yourfavoritesong" and execute sync in a row in other. In case hardware matters it's dual PIII with SCSI and IDE disks, mp3 in question was on SCSI. AudioPCI ES1373-B. No shared IRQ's between devices. I know that -current is very fragile to say at least, but what's specifically causing it? -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: New strategy of locking a process group
On Tue, 22 May 2001 21:58:10 +0900, Seigo Tanimura said: Seigo> On Tue, 22 May 2001 04:48:38 -0700 (PDT), Seigo> John Baldwin <[EMAIL PROTECTED]> said: John> On 22-May-01 Seigo Tanimura wrote: >>> For now, p_mtx protects p_pgrp in struct proc. This is quite >>> troublesome for the following reason: John> Err, it doesn't really. It's mostly undecided at this point. Also, have you John> looked at the BSD/OS code on builder? They have process groups and sessions John> already locked not using global locks but using per-data structure locks. Seigo> If you do not protect both p_pgrp and p_pglist in struct proc by an Seigo> identical lock, you end up with breaking either setpgid(2) or kill(2) Seigo> for a process group. The following scenario depicts an example of the Seigo> breakage: BSD/OS seems to solve that problem by having p_session in struct proc, and protecting p_pgrp by the mutex of both a process and a session. Then you have to lock a session as well as a process prior to reading p_pgrp, as I locked proctree_lock. I chose proctree_lock because deleting a process group may call funsetown(), which calls free(9). Maybe we can reconsider protecting by a session lock when free(9) becomes not to lock lockmgr. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: New strategy of locking a process group
On Tue, 22 May 2001 04:48:38 -0700 (PDT), John Baldwin <[EMAIL PROTECTED]> said: John> On 22-May-01 Seigo Tanimura wrote: >> For now, p_mtx protects p_pgrp in struct proc. This is quite >> troublesome for the following reason: John> Err, it doesn't really. It's mostly undecided at this point. Also, have you John> looked at the BSD/OS code on builder? They have process groups and sessions John> already locked not using global locks but using per-data structure locks. If you do not protect both p_pgrp and p_pglist in struct proc by an identical lock, you end up with breaking either setpgid(2) or kill(2) for a process group. The following scenario depicts an example of the breakage: There is a process p that belongs to a process group G. A process q issues setpgid(2) to move p into a process group H, when the process p sends a signal to the process group to which p belongs by kill(2) with pid of zero. In this case, if p takes its new p_pgrp (which points to H) during which q attempts to remove p from G (this is possible if we lock p and G individually), p might fail to send the signal to p itself and the processes in H might receive a spurious signal. You might state that locking p_pgrp of p by p_mtx first and pg_members in G by pg_mtx (process group mutex) next should solve that problem. This method actually breaks kill(2) for a process group because our start point is now not a process but a process group. In this case, we should lock a process group first, followed by a process. The result is a lock order reversal and potential deadlock between setpgid(2) and kill(2). Of course, not all members of struct pgrp needs to be locked by a global lock. A lock per a process group is enough to protect pg_sigiolst and pg_jobc. Implementation of per-data structure locks is done for pgrp and in progress for session. Finally, a fact missing in my last mail. psignal() actually checks for the parent of a process, possibly sending SIGCHLD to it. This implies that we have to slock proctree_lock so that the process hierarchy does not change. Now that psignal() calls for both pgrpsess_lock and proctree_lock, it should be cheaper to have only proctree_lock than both of them. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: New strategy of locking a process group
On 22-May-01 Seigo Tanimura wrote: > For now, p_mtx protects p_pgrp in struct proc. This is quite > troublesome for the following reason: Err, it doesn't really. It's mostly undecided at this point. Also, have you looked at the BSD/OS code on builder? They have process groups and sessions already locked not using global locks but using per-data structure locks. -- 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
No Subject
Hey there, I found a great retail site with all kinds of products. Home decor, office decor, travel, outdoors, kitchen, etc... Take a look around at http://www.merchandisewholesale.com just click on the images of the product to enlarge it for a better view. Sincerely, John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world broken
On Tuesday, 22 May 2001 at 3:42:08 -0500, Storms of Perfection wrote: > Latest CVS (about 30 minutes ago) > > In file included from /usr/src/sbin/vinum/commands.c:56: > /usr/src/sbin/vinum/vext.h:77: dev/vinum/vinumutil.h: No such file or directory > mkdep: compile failed > *** Error code 1 Did you update that part of the tree? I haven't changed that file, and the repo on freefall shows that it's there. What happens if you try building in sys/modules/vinum? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
world broken
Latest CVS (about 30 minutes ago) In file included from /usr/src/sbin/vinum/v.c:57: /usr/src/sbin/vinum/vext.h:77: dev/vinum/vinumutil.h: No such file or directory In file included from /usr/src/sbin/vinum/list.c:59: /usr/src/sbin/vinum/vext.h:77: dev/vinum/vinumutil.h: No such file or directory In file included from /usr/src/sbin/vinum/../../sys/dev/vinum/vinumutil.c:44: /usr/src/sbin/vinum/../../sys/dev/vinum/vinumhdr.h:78: dev/vinum/vinumutil.h: No such file or directory In file included from /usr/src/sbin/vinum/commands.c:56: /usr/src/sbin/vinum/vext.h:77: dev/vinum/vinumutil.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/sbin/vinum. *** Error code 1 Stop in /usr/src/sbin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 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 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
