From owner-freebsd-alpha Mon Oct 2 16:33: 8 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from mail.rdc1.va.home.com (ha1.rdc1.va.home.com [24.2.32.66]) by hub.freebsd.org (Postfix) with ESMTP id 1AAC137B503; Mon, 2 Oct 2000 16:33:03 -0700 (PDT) Received: from laptop.baldwin.cx ([24.6.244.187]) by mail.rdc1.va.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001002233302.IJNU26082.mail.rdc1.va.home.com@laptop.baldwin.cx>; Mon, 2 Oct 2000 16:33:02 -0700 Content-Length: 2567 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 02 Oct 2000 16:33:03 -0700 (PDT) From: John Baldwin To: Doug Rabson Subject: Re: Status update Cc: alpha@freebsd.org, cp@bsdi.com, smp@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 26-Sep-00 Doug Rabson wrote: > On Tue, 26 Sep 2000, Doug Rabson wrote: > >> On Sat, 23 Sep 2000, John Baldwin wrote: >> > >> > There are also a few more weirdism's on the alpha. In a few places in >> > sys/kern, we call spl0() instead of splx(). I've added some debugging >> > code to >> > do a printf() if we aren't actually at IPL_0 (what spl0 used to do) after >> > the >> > mtx_exit(). It does trigger in several cases during /etc/rc at least, but >> > the >> > machine seems to be running stable regardless (I'll be running a >> > buildworld -j >> > 8 tonight to stress test it). My question is: is it ok for the code to >> > run >> > with some interrupts disabled or do we need to replace the calls to spl0() >> > with enable_intr()? >> >> I'm testing this now and I'm seeing a flood of diagnostic messages like: >> >> ../../kern/kern_fork.c:537:fork1() spl0 needs fixing >> >> I think these are all due to the fact that sched_lock is held at that >> point. The preceding mtx_exit() just decrements the recursion count. >> I haven't worked out exactly why sched_lock is held here because it >> shouldn't be. Possibly its because we don't clear pcb_schednest in >> cpu_fork(). > > As I suspected, clearing pcb_schednest makes this lot go away. Try this > version of vm_machdep.c: > > Index: vm_machdep.c > =================================================================== > RCS file: /home/ncvs/src/sys/alpha/alpha/vm_machdep.c,v > retrieving revision 1.33 > diff -u -r1.33 vm_machdep.c > --- vm_machdep.c 2000/09/07 01:32:39 1.33 > +++ vm_machdep.c 2000/09/26 08:38:55 > @@ -210,6 +210,13 @@ > up->u_pcb.pcb_context[2] = (u_long) p2; /* s2: a0 */ > up->u_pcb.pcb_context[7] = > (u_int64_t)switch_trampoline; /* ra: assembly magic */ > + > + /* > + * Clear the saved recursion count for sched_lock > + * since the child needs only one count which is > + * released in switch_trampoline. > + */ > + up->u_pcb.pcb_schednest = 0; > } > } The x86 code does this, so the alpha code should as well. Go ahead and commit this, it shouldnt' break anything. :-P I'll remove the extra cruft from the MTX_EXIT() assembly in mutex.h afterwards. > -- > Doug Rabson Mail: dfr@nlsystems.com -- John Baldwin -- 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 majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message