Date: Wed, 13 Sep 2000 09:42:57 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: John Baldwin <jhb@pike.osd.bsdi.com> Cc: alpha@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/alpha trap.c Message-ID: <Pine.BSF.4.21.0009130939260.86297-100000@salmon.nlsystems.com> In-Reply-To: <200009122323.QAA12225@pike.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 12 Sep 2000, John Baldwin wrote: > 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? I have done this already, mainly to increase the pressure on Giant. I still think that its not the right thing to do, even for SMP machines. Also, there is clearly a race for recursing a mutex if it can be recursed from an irq context since the "m->mtx_recurse++" statement could be interrupted. > 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. :( Hmm. At #132, it appears to be enabling interrupts too which is bad. > > 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 I'll start staring at the spin lock code and see if I can spot something. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8348 3944 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0009130939260.86297-100000>