Date: Tue, 12 Sep 2000 16:23:03 -0700 (PDT) From: John Baldwin <jhb@pike.osd.bsdi.com> To: Doug Rabson <dfr@nlsystems.com> Cc: alpha@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/alpha trap.c Message-ID: <200009122323.QAA12225@pike.osd.bsdi.com> In-Reply-To: <Pine.BSF.4.21.0009122357290.86297-100000@salmon.nlsystems.com> from Doug Rabson at "Sep 12, 2000 11:58:12 pm"
index | next in thread | previous in thread | raw e-mail
Doug Rabson wrote: > On Tue, 12 Sep 2000, Doug Rabson wrote: > > > dfr 2000/09/12 15:47:10 PDT > > > > Modified files: > > sys/alpha/alpha trap.c > > Log: > > Merge changes from the i386 port to allow userret() to be called both > > with and without holding the Giant mutex. > > With this change, my UP test box boots and appears happy. We will see if > it manages to complete its 'make world'. Can you turn on the Giant enter and exit's in interrupt() now? In my test code I can now see recursion happening ok, but the sched_lock recursion is doing some funny things. After my fix to swtch.s, recursion for sched_lock is being saved across cpu_switch properly, but our mutex code seems to be goofing up on mtx_enter still: 138 0:034559493 cpu0 machine/mutex.h.510 REL sched lock [0xfffffc00006662d0] at ../../kern/kern_synch.c:813 r=0 137 0:034508805 cpu0 machine/mutex.h.471 GOT sched lock [0xfffffc00006662d0] at ../../kern/kern_synch.c:785 r=0 136 0:032610555 cpu0 machine/mutex.h.471 GOT Giant [0xfffffc00006664a0] at ../../kern/kern_synch.c:958 r=0 135 0:032560177 cpu0 machine/mutex.h.510 REL Giant [0xfffffc00006664a0] at ../../alpha/alpha/interrupt.c:123 r=0 134 0:032509499 cpu0 machine/mutex.h.471 GOT Giant [0xfffffc00006664a0] at ../../alpha/alpha/interrupt.c:121 r=0 133 0:032504810 cpu0 ../../alpha/alpha/interrupt.c.115 clock interrupt 132 0:032450423 cpu0 machine/mutex.h.510 REL sched lock [0xfffffc00006662d0] at ../../kern/kern_synch.c:956 r=1 At event 132, we release a lock with a recursion count of 1, so we set the recursion depth to 0, and clear the MTX_RECURSED flag, but we still own the lock. However, when we knab the sched_lock again at 137, we don't recurse properly, and it isn't marked as recursed. Thus, when we try to do the last mtx_exit() (in await() in this case) we don't own the mutex. :( However, in other places we are recursing on it ok: 118 0:031513861 cpu0 machine/mutex.h.471 GOT sched lock [0xfffffc00006662d0] at ../../kern/kern_synch.c:898 r=1 117 0:031431686 cpu0 ../../kern/kern_synch.c.897 mi_switch: old proc 0xfffffe0009530720 (pid 16, intr6: isa), schedlock 0xfffffe 116 0:031423046 cpu0 ../../alpha/alpha/interrupt.c.581 ithd_loop pid 16: done 115 0:031374550 cpu0 machine/mutex.h.471 GOT sched lock [0xfffffc00006662d0] at ../../alpha/alpha/interrupt.c:577 r=0 > -- > Doug Rabson Mail: dfr@nlsystems.com > Nonlinear Systems Ltd. Phone: +44 20 8348 3944 -- John Baldwin <jhb@bsdi.com> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the messagehelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009122323.QAA12225>