Date: Sat, 30 Aug 1997 14:00:29 -0600 From: Steve Passe <smp@csn.net> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: smp@freebsd.org Subject: Re: HEADS UP: another set of changes. Message-ID: <199708302000.OAA16897@Ilsa.StevesCafe.com> In-Reply-To: Your message of "Sat, 30 Aug 1997 21:44:49 %2B0200." <7453.872970289@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > >could you elaborate? Do you mean you expect my current disable_intr() > >stuff to recursively lock? I have run it for about 13 hours now, including > >a complete buildworld without problem. > > No, but I am pretty sure there are nested simple_lock() calls in the > vnode code. I am completely ignorant of the vnode code. Is this belief based on observed lockups? I tried using your(?) recursive MPgetlock stuff in place of simple locks for the disable_intr() code, but it locked b4 the first message came out of the boot sequence. I suspect its called well before cpuid is valid, which is necessary for that flavor to work. I'm pondering another variation of simplelock that looks something like: top: attempt to get the binary lock if successful set holder_id and return if fail compare holder_id to cpuid if same panic, we shouldn't be holding and asking for a binary lock else if legal (0 < holder_id < mp_ncpus) goto top else if smp_active panic, this shouldn't be else ignore, we're just early -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708302000.OAA16897>