From owner-freebsd-smp Sun Mar 10 2:18:14 2002 Delivered-To: freebsd-smp@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 80EBB37B416; Sun, 10 Mar 2002 02:18:11 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g2AAIBu30595; Sun, 10 Mar 2002 02:18:11 -0800 (PST) (envelope-from rizzo) Date: Sun, 10 Mar 2002 02:18:11 -0800 From: Luigi Rizzo To: Michael Smith Cc: smp@FreeBSD.org Subject: Re: Interrupt Context becomes a misnomer (was Re: Core recognizes SMPng tech lead ) Message-ID: <20020310021811.A30546@iguana.icir.org> References: <200203080211.g282BAt01492@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200203080211.g282BAt01492@mass.dis.org> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > We should stop doing (almost) anything in "interrupt context". An > interrupt handler should at most: > > - pacify the interrupting device > - make the driver's interrupt thread runnable definitely a good goal. For network device drivers, I suspect the least intrusive way to "pacify" the device would be to mask interrupts off on the device, and unmask them at the end of the interrupt thread. Does your suggestion require a separate device callback for the body of the interrupt thread, different from the actual interrupt handler ? cheers luigi > Now, before you all start screaming about "fast interrupts", yes, there > are a few devices that require special treatment. But there aren't many > of them, and they can be accomodated in this model (by doing slightly > more in the interrupt handler). > > In the case where a device can't be "pacified" without considerable work > (this is fairly rare), the handler can return status indicating that the > interrupt should be masked until the thread has run. > > You can turn the concept on it's head and view it as making every driver > have a "fast" interrupt handler. "Slow" handlers go away, making the > issue of handling things "in interrupt context" much less of a problem, > since almost nothing (clock code notwithstanding) is called from > interrupt context. > > This isn't a particularly novel approach; Apple use it, BSD/OS is likely > to go this way, and it's strongly encouraged by the IA64 interrupt model. > I'm sure that plenty of other systems do things this way as well; I just > don't have the research hours to track them down. > > Just food for thought at this stage, but something that anyone working on > interrupt handling should take to heart. > > Regards, > Mike > > - -- > To announce that there must be no criticism of the president, > or that we are to stand by the president, right or wrong, is not > only unpatriotic and servile, but is morally treasonable to > the American public. - Theodore Roosevelt > > > > ------- End of Blind-Carbon-Copy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Mar 10 2:38: 8 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id 2123937B400; Sun, 10 Mar 2002 02:38:05 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g2AAbRj03482; Sun, 10 Mar 2002 02:37:27 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200203101037.g2AAbRj03482@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Luigi Rizzo Cc: Michael Smith , smp@FreeBSD.org Subject: Re: Interrupt Context becomes a misnomer (was Re: Core recognizes SMPng tech lead ) In-reply-to: Your message of "Sun, 10 Mar 2002 02:18:11 PST." <20020310021811.A30546@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Mar 2002 02:37:27 -0800 From: Michael Smith Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > We should stop doing (almost) anything in "interrupt context". An > > interrupt handler should at most: > > > > - pacify the interrupting device > > - make the driver's interrupt thread runnable > > definitely a good goal. > > For network device drivers, I suspect the least intrusive way > to "pacify" the device would be to mask interrupts off on the > device, and unmask them at the end of the interrupt thread. This depends a lot on the architecture of the device; one development that would help a great deal would be a lockless, mp-safe queue primitive. > Does your suggestion require a separate device callback for > the body of the interrupt thread, different from the > actual interrupt handler ? The implementation I envisage has one thread per interrupt vector, invoking each interrupt handler registered for the vector. In the "default" case, no actual interrupt handler is installed; the default behaviour is to mask the interrupt and make the thread runnable (very similar to our current behaviour). Allowing a driver to register an actual interrupt-context-handler is an optimisation that provides the functionality of 'fast' handlers as well as potentially improved system responsiveness by not masking the interrupt for a length of time. The usual drawbacks with masked vectors, shared interrupts and fast handlers, of course still apply. = Mike -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Mar 10 16:11:58 2002 Delivered-To: freebsd-smp@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 4ACE737B404; Sun, 10 Mar 2002 16:11:31 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 2DFD2AE211; Sun, 10 Mar 2002 16:11:31 -0800 (PST) Date: Sun, 10 Mar 2002 16:11:31 -0800 From: Alfred Perlstein To: smp@freebsd.org Cc: davidc@freebsd.org, jhb@freebsd.org Subject: select fix and giant pushdown patch Message-ID: <20020311001131.GN26621@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Chad David and I have been working on fixing select(2) and poll(2)'s locking. I've been working on pushing pipe read/write ops down out from under Giant. The way it works is that there is a global select lock that is very close to a leaf lock, under select/poll you'll see this order of aquisition: filedesc -> objlock -> sellock where objlock is aquired in the fo_poll routine, from interrupt or writer POV you'll see: objlock -> sellock. Also, because pfind was broken by the proc locking such that it requires an sx lock we've fixed select such that the selinfo structure contains linkages back to the thread that is waiting on the resource, when leaving select all linkages not removed via selwakeup are removed. I've also been able to push down pipe reading/writing out from under Giant, so far the performance numbers don't look much better, hopefully they will improve as more code is pulled out from under Giant. It's starting to look like a lot of the system's requiring Giant just for MALLOC/FREE which is really dissappointing considering the work I put into fixing that months ago that was backed out. This code relies slightly on psignal being MPSAFE, if it's not a small amount of performance can be scrificed by grabbing Giant before calling it. Test, review please... bye, -Alfred Index: dev/bktr/bktr_core.c =================================================================== RCS file: /home/ncvs/src/sys/dev/bktr/bktr_core.c,v retrieving revision 1.117 diff -u -r1.117 bktr_core.c --- dev/bktr/bktr_core.c 12 Sep 2001 08:37:02 -0000 1.117 +++ dev/bktr/bktr_core.c 10 Mar 2002 08:08:36 -0000 @@ -809,7 +809,7 @@ } /* If someone has a select() on /dev/vbi, inform them */ - if (bktr->vbi_select.si_pid) { + if (SEL_WAITING(&bktr->vbi_select)) { selwakeup(&bktr->vbi_select); } Index: dev/kbd/kbd.c =================================================================== RCS file: /home/ncvs/src/sys/dev/kbd/kbd.c,v retrieving revision 1.27 diff -u -r1.27 kbd.c --- dev/kbd/kbd.c 12 Sep 2001 08:37:06 -0000 1.27 +++ dev/kbd/kbd.c 10 Mar 2002 08:08:36 -0000 @@ -524,7 +524,7 @@ #endif clist_alloc_cblocks(&sc->gkb_q, KB_QSIZE, KB_QSIZE/2); /* XXX */ sc->gkb_rsel.si_flags = 0; - sc->gkb_rsel.si_pid = 0; + SEL_INIT(&sc->gkb_rsel); splx(s); return 0; Index: dev/snp/snp.c =================================================================== RCS file: /home/ncvs/src/sys/dev/snp/snp.c,v retrieving revision 1.69 diff -u -r1.69 snp.c --- dev/snp/snp.c 24 Nov 2001 15:59:46 -0000 1.69 +++ dev/snp/snp.c 10 Mar 2002 08:08:36 -0000 @@ -373,7 +373,6 @@ wakeup((caddr_t)snp); } selwakeup(&snp->snp_sel); - snp->snp_sel.si_pid = 0; return (n); } @@ -447,7 +446,6 @@ detach_notty: selwakeup(&snp->snp_sel); - snp->snp_sel.si_pid = 0; if ((snp->snp_flags & SNOOP_OPEN) == 0) free(snp, M_SNP); Index: dev/sound/pcm/channel.c =================================================================== RCS file: /home/ncvs/src/sys/dev/sound/pcm/channel.c,v retrieving revision 1.81 diff -u -r1.81 channel.c --- dev/sound/pcm/channel.c 24 Feb 2002 00:49:43 -0000 1.81 +++ dev/sound/pcm/channel.c 10 Mar 2002 08:08:36 -0000 @@ -116,7 +116,7 @@ struct snd_dbuf *bs = c->bufsoft; CHN_LOCKASSERT(c); - if (sndbuf_getsel(bs)->si_pid && chn_polltrigger(c)) + if (SEL_WAITING(sndbuf_getsel(bs)) && chn_polltrigger(c)) selwakeup(sndbuf_getsel(bs)); wakeup(bs); } Index: dev/usb/ums.c =================================================================== RCS file: /home/ncvs/src/sys/dev/usb/ums.c,v retrieving revision 1.48 diff -u -r1.48 ums.c --- dev/usb/ums.c 15 Feb 2002 22:54:10 -0000 1.48 +++ dev/usb/ums.c 10 Mar 2002 08:08:36 -0000 @@ -345,7 +345,11 @@ sc->status.dx = sc->status.dy = sc->status.dz = 0; sc->rsel.si_flags = 0; +#ifdef __FreeBSD__ + SEL_INIT(&sc->rsel); +#else sc->rsel.si_pid = 0; +#endif sc->dev = make_dev(&ums_cdevsw, device_get_unit(self), UID_ROOT, GID_OPERATOR, Index: isa/psm.c =================================================================== RCS file: /home/ncvs/src/sys/isa/psm.c,v retrieving revision 1.43 diff -u -r1.43 psm.c --- isa/psm.c 19 Dec 2001 13:32:21 -0000 1.43 +++ isa/psm.c 10 Mar 2002 08:08:36 -0000 @@ -1314,8 +1314,7 @@ device_busy(devclass_get_device(psm_devclass, unit)); /* Initialize state */ - sc->rsel.si_flags = 0; - sc->rsel.si_pid = 0; + SEL_INIT(&sc->rsel); sc->mode.level = sc->dflt_mode.level; sc->mode.protocol = sc->dflt_mode.protocol; sc->watchdog = FALSE; Index: kern/kern_descrip.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_descrip.c,v retrieving revision 1.127 diff -u -r1.127 kern_descrip.c --- kern/kern_descrip.c 27 Feb 2002 18:32:12 -0000 1.127 +++ kern/kern_descrip.c 10 Mar 2002 08:09:25 -0000 @@ -1716,6 +1716,7 @@ FILE_UNLOCK(fp); return (0); } + mtx_lock(&Giant); if (fp->f_count < 0) panic("fdrop: count < 0"); if ((fp->f_flag & FHASLOCK) && fp->f_type == DTYPE_VNODE) { @@ -1733,6 +1734,7 @@ else error = 0; ffree(fp); + mtx_unlock(&Giant); return (error); } Index: kern/kern_ktrace.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_ktrace.c,v retrieving revision 1.60 diff -u -r1.60 kern_ktrace.c --- kern/kern_ktrace.c 27 Feb 2002 19:10:50 -0000 1.60 +++ kern/kern_ktrace.c 10 Mar 2002 08:08:36 -0000 @@ -181,6 +181,8 @@ if (error) return; + + mtx_lock(&Giant); /* * don't let p_tracep get ripped out from under us */ @@ -200,6 +202,7 @@ vrele(vp); FREE(kth, M_KTRACE); p->p_traceflag &= ~KTRFAC_ACTIVE; + mtx_unlock(&Giant); } void Index: kern/sys_generic.c =================================================================== RCS file: /home/ncvs/src/sys/kern/sys_generic.c,v retrieving revision 1.92 diff -u -r1.92 sys_generic.c --- kern/sys_generic.c 9 Mar 2002 22:44:37 -0000 1.92 +++ kern/sys_generic.c 10 Mar 2002 20:49:51 -0000 @@ -80,6 +80,7 @@ size_t, off_t, int); static int dofilewrite(struct thread *, struct file *, int, const void *, size_t, off_t, int); +static void clear_selinfo_list(struct thread *); /* * Read system call. @@ -102,13 +103,11 @@ struct file *fp; int error; - mtx_lock(&Giant); if ((error = fget_read(td, uap->fd, &fp)) == 0) { error = dofileread(td, fp, uap->fd, uap->buf, uap->nbyte, (off_t)-1, 0); fdrop(fp, td); } - mtx_unlock(&Giant); return(error); } @@ -137,7 +136,6 @@ if ((error = fget_read(td, uap->fd, &fp)) != 0) return (error); - mtx_lock(&Giant); if (fp->f_type != DTYPE_VNODE) { error = ESPIPE; } else { @@ -145,7 +143,6 @@ uap->offset, FOF_OFFSET); } fdrop(fp, td); - mtx_unlock(&Giant); return(error); } @@ -332,7 +329,6 @@ struct file *fp; int error; - mtx_lock(&Giant); if ((error = fget_write(td, uap->fd, &fp)) == 0) { error = dofilewrite(td, fp, uap->fd, uap->buf, uap->nbyte, (off_t)-1, 0); @@ -340,7 +336,6 @@ } else { error = EBADF; /* XXX this can't be right */ } - mtx_unlock(&Giant); return(error); } @@ -368,7 +363,6 @@ int error; if ((error = fget_write(td, uap->fd, &fp)) == 0) { - mtx_lock(&Giant); if (fp->f_type == DTYPE_VNODE) { error = dofilewrite(td, fp, uap->fd, uap->buf, uap->nbyte, uap->offset, FOF_OFFSET); @@ -376,7 +370,6 @@ error = ESPIPE; } fdrop(fp, td); - mtx_unlock(&Giant); } else { error = EBADF; /* this can't be right */ } @@ -423,8 +416,9 @@ } #endif cnt = nbyte; - if (fp->f_type == DTYPE_VNODE) + if (fp->f_type == DTYPE_VNODE) { bwillwrite(); + } if ((error = fo_write(fp, &auio, fp->f_cred, flags, td))) { if (auio.uio_resid != cnt && (error == ERESTART || error == EINTR || error == EWOULDBLOCK)) @@ -696,11 +690,40 @@ return (error); } +/* + * These are initialized in selectinit() via SYSINIT + */ +static struct mtx sellock; static int nselcoll; /* Select collisions since boot */ struct cv selwait; SYSCTL_INT(_kern, OID_AUTO, nselcoll, CTLFLAG_RD, &nselcoll, 0, ""); /* + * Remove the references to the thread from all of the objects + * we were polling. + * + * This code assumes that the underlying owner of the selinfo + * structure will hold sellock before it changes it, and that + * it will unlink itself from our list if it goes away. + */ +static void +clear_selinfo_list(td) + struct thread *td; +{ + struct selinfo *si, *nsi; + + mtx_assert(&sellock, MA_OWNED); + + si = TAILQ_FIRST(&td->td_selinfo); + while (si != NULL) { + nsi = TAILQ_NEXT(si, si_thrlist); + si->si_thread = NULL; + si = nsi; + } + TAILQ_INIT(&td->td_selinfo); +} + +/* * Select system call. */ #ifndef _SYS_SYSPROTO_H_ @@ -801,34 +824,37 @@ atv.tv_usec = 0; } timo = 0; - PROC_LOCK(td->td_proc); + mtx_lock(&sellock); retry: + ncoll = nselcoll; mtx_lock_spin(&sched_lock); td->td_flags |= TDF_SELECT; mtx_unlock_spin(&sched_lock); - PROC_UNLOCK(td->td_proc); + mtx_unlock(&sellock); + + /* XXX Is there a better place for this? */ + TAILQ_INIT(&td->td_selinfo); error = selscan(td, ibits, obits, uap->nd); - PROC_LOCK(td->td_proc); + mtx_lock(&sellock); if (error || td->td_retval[0]) goto done; if (atv.tv_sec || atv.tv_usec) { getmicrouptime(&rtv); if (timevalcmp(&rtv, &atv, >=)) { /* - * An event of our interest may occur during locking a process. - * In order to avoid missing the event that occured during locking - * the process, test TDF_SELECT and rescan file descriptors if - * necessary. + * An event of interest may occur while we do not hold + * sellock, so check TDF_SELECT and the number of collisions + * and rescan the file descriptors if necessary. */ mtx_lock_spin(&sched_lock); if ((td->td_flags & TDF_SELECT) == 0 || nselcoll != ncoll) { ncoll = nselcoll; td->td_flags |= TDF_SELECT; mtx_unlock_spin(&sched_lock); - PROC_UNLOCK(td->td_proc); + mtx_unlock(&sellock); error = selscan(td, ibits, obits, uap->nd); - PROC_LOCK(td->td_proc); + mtx_lock(&sellock); } else mtx_unlock_spin(&sched_lock); goto done; @@ -838,23 +864,28 @@ timo = ttv.tv_sec > 24 * 60 * 60 ? 24 * 60 * 60 * hz : tvtohz(&ttv); } + + /* XXX What is the point of this? */ mtx_lock_spin(&sched_lock); td->td_flags &= ~TDF_SELECT; mtx_unlock_spin(&sched_lock); if (timo > 0) - error = cv_timedwait_sig(&selwait, &td->td_proc->p_mtx, timo); + error = cv_timedwait_sig(&selwait, &sellock, timo); else - error = cv_wait_sig(&selwait, &td->td_proc->p_mtx); + error = cv_wait_sig(&selwait, &sellock); if (error == 0) goto retry; done: + clear_selinfo_list(td); + mtx_lock_spin(&sched_lock); td->td_flags &= ~TDF_SELECT; mtx_unlock_spin(&sched_lock); - PROC_UNLOCK(td->td_proc); + mtx_unlock(&sellock); + done_noproclock: /* select is not restarted after signals... */ if (error == ERESTART) @@ -982,36 +1013,39 @@ atv.tv_usec = 0; } timo = 0; - PROC_LOCK(td->td_proc); + mtx_lock(&sellock); retry: ncoll = nselcoll; mtx_lock_spin(&sched_lock); td->td_flags |= TDF_SELECT; mtx_unlock_spin(&sched_lock); - PROC_UNLOCK(td->td_proc); + mtx_unlock(&sellock); + + /* XXX Is there a better place for this? */ + TAILQ_INIT(&td->td_selinfo); error = pollscan(td, (struct pollfd *)bits, nfds); - PROC_LOCK(td->td_proc); + mtx_lock(&sellock); if (error || td->td_retval[0]) goto done; if (atv.tv_sec || atv.tv_usec) { getmicrouptime(&rtv); if (timevalcmp(&rtv, &atv, >=)) { /* - * An event of our interest may occur during locking a process. - * In order to avoid missing the event that occured during locking - * the process, test TDF_SELECT and rescan file descriptors if - * necessary. + * An event of interest may occur while we do not hold + * sellock, so check TDF_SELECT and the number of collisions + * and rescan the file descriptors if necessary. */ mtx_lock_spin(&sched_lock); if ((td->td_flags & TDF_SELECT) == 0 || nselcoll != ncoll) { ncoll = nselcoll; td->td_flags |= TDF_SELECT; mtx_unlock_spin(&sched_lock); - PROC_UNLOCK(td->td_proc); + mtx_unlock(&sellock); error = pollscan(td, (struct pollfd *)bits, nfds); - PROC_LOCK(td->td_proc); + mtx_lock(&sellock); } else mtx_unlock_spin(&sched_lock); + goto done; } ttv = atv; @@ -1019,21 +1053,28 @@ timo = ttv.tv_sec > 24 * 60 * 60 ? 24 * 60 * 60 * hz : tvtohz(&ttv); } + + /* XXX What is the point of this? */ mtx_lock_spin(&sched_lock); td->td_flags &= ~TDF_SELECT; mtx_unlock_spin(&sched_lock); + if (timo > 0) - error = cv_timedwait_sig(&selwait, &td->td_proc->p_mtx, timo); + error = cv_timedwait_sig(&selwait, &sellock, timo); else - error = cv_wait_sig(&selwait, &td->td_proc->p_mtx); + error = cv_wait_sig(&selwait, &sellock); + if (error == 0) goto retry; done: + clear_selinfo_list(td); + mtx_lock_spin(&sched_lock); td->td_flags &= ~TDF_SELECT; mtx_unlock_spin(&sched_lock); - PROC_UNLOCK(td->td_proc); + mtx_unlock(&sellock); + done_noproclock: /* poll is not restarted after signals... */ if (error == ERESTART) @@ -1126,18 +1167,6 @@ return (events & (POLLIN | POLLOUT | POLLRDNORM | POLLWRNORM)); } -static int -find_thread_in_proc(struct proc *p, struct thread *td) -{ - struct thread *td2; - FOREACH_THREAD_IN_PROC(p, td2) { - if (td2 == td) { - return (1); - } - } - return (0); -} - /* * Record a select request. */ @@ -1146,29 +1175,21 @@ struct thread *selector; struct selinfo *sip; { - struct proc *p; - pid_t mypid; - mypid = selector->td_proc->p_pid; - if ((sip->si_pid == mypid) && - (sip->si_thread == selector)) { /* XXXKSE should be an ID? */ - return; - } - if (sip->si_pid && - (p = pfind(sip->si_pid)) && - (find_thread_in_proc(p, sip->si_thread))) { - mtx_lock_spin(&sched_lock); - if (sip->si_thread->td_wchan == (caddr_t)&selwait) { - mtx_unlock_spin(&sched_lock); - PROC_UNLOCK(p); - sip->si_flags |= SI_COLL; - return; - } - mtx_unlock_spin(&sched_lock); - PROC_UNLOCK(p); + mtx_lock(&sellock); + /* + * If the thread is not NULL there is another thread + * interested in this object, and we need to flag the + * collision so selwakeup() can broadcast. + */ + if (sip->si_thread != NULL) { + sip->si_flags |= SI_COLL; + } else { + sip->si_thread = selector; + TAILQ_INSERT_TAIL(&selector->td_selinfo, sip, si_thrlist); } - sip->si_pid = mypid; - sip->si_thread = selector; + + mtx_unlock(&sellock); } /* @@ -1176,37 +1197,37 @@ */ void selwakeup(sip) - register struct selinfo *sip; + struct selinfo *sip; { struct thread *td; - register struct proc *p; - if (sip->si_pid == 0) - return; - if (sip->si_flags & SI_COLL) { + mtx_lock(&sellock); + td = sip->si_thread; + + if ((sip->si_flags & SI_COLL) != 0) { nselcoll++; sip->si_flags &= ~SI_COLL; cv_broadcast(&selwait); } - p = pfind(sip->si_pid); - sip->si_pid = 0; - td = sip->si_thread; - if (p != NULL) { - if (!find_thread_in_proc(p, td)) { - PROC_UNLOCK(p); /* lock is in pfind() */; - return; - } - mtx_lock_spin(&sched_lock); - if (td->td_wchan == (caddr_t)&selwait) { - if (td->td_proc->p_stat == SSLEEP) - setrunnable(td); - else - cv_waitq_remove(td); - } else - td->td_flags &= ~TDF_SELECT; - mtx_unlock_spin(&sched_lock); - PROC_UNLOCK(p); /* Lock is in pfind() */ + + if (td == NULL) { + mtx_unlock(&sellock); + return; } + + TAILQ_REMOVE(&td->td_selinfo, sip, si_thrlist); + mtx_lock_spin(&sched_lock); + if (td->td_wchan == (caddr_t)&selwait) { + if (td->td_proc->p_stat == SSLEEP) + setrunnable(td); + else + cv_waitq_remove(td); + } else + td->td_flags &= ~TDF_SELECT; + mtx_unlock_spin(&sched_lock); + + sip->si_thread = NULL; + mtx_unlock(&sellock); } static void selectinit __P((void *)); @@ -1218,4 +1239,5 @@ void *dummy; { cv_init(&selwait, "select"); + mtx_init(&sellock, "sellck", MTX_DEF); } Index: kern/sys_socket.c =================================================================== RCS file: /home/ncvs/src/sys/kern/sys_socket.c,v retrieving revision 1.37 diff -u -r1.37 sys_socket.c --- kern/sys_socket.c 13 Jan 2002 11:57:59 -0000 1.37 +++ kern/sys_socket.c 10 Mar 2002 08:08:37 -0000 @@ -65,7 +65,12 @@ int flags; { struct socket *so = (struct socket *)fp->f_data; - return so->so_proto->pr_usrreqs->pru_soreceive(so, 0, uio, 0, 0, 0); + int error; + + mtx_lock(&Giant); + error = so->so_proto->pr_usrreqs->pru_soreceive(so, 0, uio, 0, 0, 0); + mtx_unlock(&Giant); + return (error); } /* ARGSUSED */ @@ -78,8 +83,13 @@ int flags; { struct socket *so = (struct socket *)fp->f_data; - return so->so_proto->pr_usrreqs->pru_sosend(so, 0, uio, 0, 0, 0, + int error; + + mtx_lock(&Giant); + error = so->so_proto->pr_usrreqs->pru_sosend(so, 0, uio, 0, 0, 0, uio->uio_td); + mtx_unlock(&Giant); + return (error); } int Index: kern/tty.c =================================================================== RCS file: /home/ncvs/src/sys/kern/tty.c,v retrieving revision 1.165 diff -u -r1.165 tty.c --- kern/tty.c 2 Mar 2002 12:42:23 -0000 1.165 +++ kern/tty.c 10 Mar 2002 08:08:37 -0000 @@ -2273,7 +2273,7 @@ register struct tty *tp; { - if (tp->t_rsel.si_pid != 0) + if (SEL_WAITING(&tp->t_rsel)) selwakeup(&tp->t_rsel); if (ISSET(tp->t_state, TS_ASYNC) && tp->t_sigio != NULL) pgsigio(tp->t_sigio, SIGIO, (tp->t_session != NULL)); @@ -2289,7 +2289,7 @@ register struct tty *tp; { - if (tp->t_wsel.si_pid != 0 && tp->t_outq.c_cc <= tp->t_olowat) + if (SEL_WAITING(&tp->t_wsel) && tp->t_outq.c_cc <= tp->t_olowat) selwakeup(&tp->t_wsel); if (ISSET(tp->t_state, TS_ASYNC) && tp->t_sigio != NULL) pgsigio(tp->t_sigio, SIGIO, (tp->t_session != NULL)); Index: kern/vfs_bio.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v retrieving revision 1.302 diff -u -r1.302 vfs_bio.c --- kern/vfs_bio.c 5 Mar 2002 18:20:58 -0000 1.302 +++ kern/vfs_bio.c 10 Mar 2002 20:44:01 -0000 @@ -1079,6 +1079,7 @@ if (numdirtybuffers >= hidirtybuffers) { int s; + mtx_lock(&Giant); s = splbio(); while (numdirtybuffers >= hidirtybuffers) { bd_wakeup(1); @@ -1086,6 +1087,7 @@ tsleep(&needsbuffer, (PRIBIO + 4), "flswai", 0); } splx(s); + mtx_unlock(&Giant); } } Index: kern/vfs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_vnops.c,v retrieving revision 1.136 diff -u -r1.136 vfs_vnops.c --- kern/vfs_vnops.c 5 Mar 2002 15:38:49 -0000 1.136 +++ kern/vfs_vnops.c 10 Mar 2002 08:08:37 -0000 @@ -409,6 +409,7 @@ struct vnode *vp; int error, ioflag; + mtx_lock(&Giant); KASSERT(uio->uio_td == td, ("uio_td %p is not td %p", uio->uio_td, td)); vp = (struct vnode *)fp->f_data; @@ -429,6 +430,7 @@ fp->f_offset = uio->uio_offset; fp->f_nextoff = uio->uio_offset; VOP_UNLOCK(vp, 0, td); + mtx_unlock(&Giant); return (error); } @@ -447,6 +449,7 @@ struct mount *mp; int error, ioflag; + mtx_lock(&Giant); KASSERT(uio->uio_td == td, ("uio_td %p is not td %p", uio->uio_td, td)); vp = (struct vnode *)fp->f_data; @@ -464,8 +467,10 @@ ioflag |= IO_SYNC; mp = NULL; if (vp->v_type != VCHR && - (error = vn_start_write(vp, &mp, V_WAIT | PCATCH)) != 0) + (error = vn_start_write(vp, &mp, V_WAIT | PCATCH)) != 0) { + mtx_unlock(&Giant); return (error); + } VOP_LEASE(vp, td, cred, LEASE_WRITE); vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td); if ((flags & FOF_OFFSET) == 0) @@ -477,6 +482,7 @@ fp->f_nextoff = uio->uio_offset; VOP_UNLOCK(vp, 0, td); vn_finished_write(mp); + mtx_unlock(&Giant); return (error); } Index: net/bpf.c =================================================================== RCS file: /home/ncvs/src/sys/net/bpf.c,v retrieving revision 1.86 diff -u -r1.86 bpf.c --- net/bpf.c 14 Dec 2001 22:17:54 -0000 1.86 +++ net/bpf.c 10 Mar 2002 08:08:37 -0000 @@ -514,8 +514,6 @@ pgsigio(d->bd_sigio, d->bd_sig, 0); selwakeup(&d->bd_sel); - /* XXX */ - d->bd_sel.si_pid = 0; } static void Index: sys/proc.h =================================================================== RCS file: /home/ncvs/src/sys/sys/proc.h,v retrieving revision 1.206 diff -u -r1.206 proc.h --- sys/proc.h 23 Feb 2002 11:12:57 -0000 1.206 +++ sys/proc.h 10 Mar 2002 08:08:37 -0000 @@ -147,6 +147,7 @@ * m - Giant * n - not locked, lazy * o - locked by pgrpsess_lock sx + * p - select lock (sellock) * * If the locking key specifies two identifiers (for example, p_pptr) then * either lock is sufficient for read access, but both locks must be held @@ -259,6 +260,8 @@ TAILQ_ENTRY(thread) td_slpq; /* (j) Sleep queue. XXXKSE */ TAILQ_ENTRY(thread) td_blkq; /* (j) Mutex queue. XXXKSE */ TAILQ_ENTRY(thread) td_runq; /* (j) Run queue(s). XXXKSE */ + + TAILQ_HEAD(, selinfo) td_selinfo; /* (p) List of selinfos */ #define td_startzero td_flags int td_flags; /* (j) TDF_* flags. */ Index: sys/selinfo.h =================================================================== RCS file: /home/ncvs/src/sys/sys/selinfo.h,v retrieving revision 1.12 diff -u -r1.12 selinfo.h --- sys/selinfo.h 27 Sep 2001 20:33:15 -0000 1.12 +++ sys/selinfo.h 10 Mar 2002 08:08:37 -0000 @@ -45,12 +45,21 @@ * notified when I/O becomes possible. */ struct selinfo { - pid_t si_pid; /* process to be notified */ + TAILQ_ENTRY(selinfo) si_thrlist; /* list hung off of thread */ struct thread *si_thread; /* thread in that process XXXKSE */ struct klist si_note; /* kernel note list */ short si_flags; /* see below */ }; #define SI_COLL 0x0001 /* collision occurred */ + +#define SEL_WAITING(si) \ + ((si)->si_thread != NULL || ((si)->si_flags & SI_COLL) != 0) + +#define SEL_INIT(si) \ + do { \ + (si)->si_thread = NULL; \ + (si)->si_flags = 0; \ + } while (0) #ifdef _KERNEL struct thread; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 11 0:38:30 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 1F49C37B404; Mon, 11 Mar 2002 00:38:24 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA12921; Mon, 11 Mar 2002 19:38:17 +1100 Date: Mon, 11 Mar 2002 19:39:33 +1100 (EST) From: Bruce Evans X-X-Sender: To: Michael Smith Cc: "M. Warner Losh" , Subject: Re: Interrupt Context becomes a misnomer (was Re: Core recognizes SMPng tech lead ) In-Reply-To: <200203080211.g282BAt01489@mass.dis.org> Message-ID: <20020311190003.W5788-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 7 Mar 2002, Michael Smith wrote: > (moved to smp@) > > > This can be described as "newbus doesn't change often enough to do > > anything other than one big lock around it." However, I must admit > > that I've not thought through the implications of devices arriving and > > leaving at interrupt context. > > I've been talking about this with various people, but here's a good point > at which to bring up something that folks working on device drivers > should think long and hard about. > > We should stop doing (almost) anything in "interrupt context". An > interrupt handler should at most: > > - pacify the interrupting device > - make the driver's interrupt thread runnable This is insignificantly different from what happens for non-fast interrupts now in -current: - make the driver's interrupt thread runnable - [possibly do other higher-priority things] - run the driver's interrupt thread, which normally pacifys the interrupting device as one of the first things it does. We depend on icu/apic masking to keep the device quiet while we are running higher-priority things. icu/apic masking also prevents other devices that are sharing an interrupt from even interrupting, so we cannot in general support devices that need pacifying real soon in real-time. We would need immediate pacification to support such devices and/or hardware without an icu/apic, but this would require rewriting the interrupt system yet again and wouldn't significantly uncomplicate the new-bus-related locking: a single lock can lock out all the current hardware ithreads just as well as it can lock out all software ithreads, and would work equally poorly (if it is held for long) for both. > Now, before you all start screaming about "fast interrupts", yes, there > are a few devices that require special treatment. But there aren't many > of them, and they can be accomodated in this model (by doing slightly > more in the interrupt handler). Fast interrupt handlers are basically handlers that follow this model. I wouldn't want to use them for all interrupt handlers because they (or rather the code that shares data with them) is harder to write. But locking may require similar complications anyway (you can't just access your data but you have to lock it, and you must only lock it for short intervals to not defeat the point of having fast interrupt handlers/ immediate pacification. The whole driver must be aware of the real-time constraints of the hardware part of of interrupt handler). > In the case where a device can't be "pacified" without considerable work > (this is fairly rare), the handler can return status indicating that the > interrupt should be masked until the thread has run. > > You can turn the concept on it's head and view it as making every driver > have a "fast" interrupt handler. "Slow" handlers go away, making the > issue of handling things "in interrupt context" much less of a problem, > since almost nothing (clock code notwithstanding) is called from > interrupt context. This is sort of what we do now: every device without a fast interrupt handler has a near-null hardware interrupt handler that says that the interrupt should be masked. Eventually, we switch to a software interrupt handler that happens to access the hardware. (I think SWI handlers should be able to access hardware, at least if if they lock out there hardare interrupt handler -- this is not much different from hardware accesses in non-interrupt context to initiate i/o.) There is no data shared between the fast interrupt handler and the rest of the driver, so the locking for this is especially simple. However, the "software" part of the handler may need considerable locking to protect the data from non-interrupt accesses. > This isn't a particularly novel approach; Apple use it, BSD/OS is likely > to go this way, and it's strongly encouraged by the IA64 interrupt model. > I'm sure that plenty of other systems do things this way as well; I just > don't have the research hours to track them down. Two-bit micros probably used it since they couldn't afford the sophistication of the current model :-) Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 11 8: 2:26 2002 Delivered-To: freebsd-smp@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 4E89337B405; Mon, 11 Mar 2002 08:02:21 -0800 (PST) Received: from pool0620.cvx22-bradley.dialup.earthlink.net ([209.179.200.110] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16kSFe-0006XM-00; Mon, 11 Mar 2002 08:02:19 -0800 Message-ID: <3C8CD4F9.F55D4655@mindspring.com> Date: Mon, 11 Mar 2002 08:02:01 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: Michael Smith , "M. Warner Losh" , smp@FreeBSD.ORG Subject: Re: Interrupt Context becomes a misnomer (was Re: Core recognizesSMPng tech lead ) References: <20020311190003.W5788-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bruce Evans wrote: > > This isn't a particularly novel approach; Apple use it, BSD/OS is likely > > to go this way, and it's strongly encouraged by the IA64 interrupt model. > > I'm sure that plenty of other systems do things this way as well; I just > > don't have the research hours to track them down. > > Two-bit micros probably used it since they couldn't afford the > sophistication of the current model :-) FWIW, Windows uses this model. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 11 8:23:30 2002 Delivered-To: freebsd-smp@freebsd.org Received: from cn-sfo1-g7-2.cnet.com (nat-236-141.cnet.com [64.124.236.141]) by hub.freebsd.org (Postfix) with ESMTP id B4E6C37B417 for ; Mon, 11 Mar 2002 08:23:22 -0800 (PST) Received: from holsman.net (ianh2k2.cnet.com [10.16.90.220] (may be forged)) by cn-sfo1-g7-2.cnet.com (8.9.3/8.9.3) with ESMTP id IAA14451 for ; Mon, 11 Mar 2002 08:23:20 -0800 (PST) Message-ID: <3C8CD9F5.50507@holsman.net> Date: Mon, 11 Mar 2002 08:23:17 -0800 From: Ian Holsman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+) Gecko/20020220 X-Accept-Language: en-us MIME-Version: 1.0 To: freebsd-smp@freebsd.org Subject: feature request -- atomic add/dec return the old value Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org hi. I'm not sure if this is the right spot to ask, but I'd like to see freebsd return a value on it's add/subtract atomic functions. is this hard to implement? is there a reason not to ? TIA Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 11 9: 6:47 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id 2721C37B433 for ; Mon, 11 Mar 2002 09:05:30 -0800 (PST) Received: (qmail 20968 invoked from network); 11 Mar 2002 17:05:29 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 11 Mar 2002 17:05:29 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g2BH5lv22275; Mon, 11 Mar 2002 12:05:47 -0500 (EST) (envelope-from jhb@FreeBSD.org) 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: <20020311001131.GN26621@elvis.mu.org> Date: Mon, 11 Mar 2002 12:05:29 -0500 (EST) From: John Baldwin To: Alfred Perlstein Subject: RE: select fix and giant pushdown patch Cc: davidc@freebsd.org, smp@freebsd.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 11-Mar-02 Alfred Perlstein wrote: > Index: dev/kbd/kbd.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/kbd/kbd.c,v > retrieving revision 1.27 > diff -u -r1.27 kbd.c > --- dev/kbd/kbd.c 12 Sep 2001 08:37:06 -0000 1.27 > +++ dev/kbd/kbd.c 10 Mar 2002 08:08:36 -0000 > @@ -524,7 +524,7 @@ > #endif > clist_alloc_cblocks(&sc->gkb_q, KB_QSIZE, KB_QSIZE/2); /* XXX */ > sc->gkb_rsel.si_flags = 0; > - sc->gkb_rsel.si_pid = 0; > + SEL_INIT(&sc->gkb_rsel); > splx(s); > > return 0; softc's are already zero'd so you don't need this at all. > Index: dev/usb/ums.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/usb/ums.c,v > retrieving revision 1.48 > diff -u -r1.48 ums.c > --- dev/usb/ums.c 15 Feb 2002 22:54:10 -0000 1.48 > +++ dev/usb/ums.c 10 Mar 2002 08:08:36 -0000 > @@ -345,7 +345,11 @@ > sc->status.dx = sc->status.dy = sc->status.dz = 0; > > sc->rsel.si_flags = 0; > +#ifdef __FreeBSD__ > + SEL_INIT(&sc->rsel); > +#else > sc->rsel.si_pid = 0; > +#endif > > sc->dev = make_dev(&ums_cdevsw, device_get_unit(self), > UID_ROOT, GID_OPERATOR, Same here. > Index: isa/psm.c > =================================================================== > RCS file: /home/ncvs/src/sys/isa/psm.c,v > retrieving revision 1.43 > diff -u -r1.43 psm.c > --- isa/psm.c 19 Dec 2001 13:32:21 -0000 1.43 > +++ isa/psm.c 10 Mar 2002 08:08:36 -0000 > @@ -1314,8 +1314,7 @@ > device_busy(devclass_get_device(psm_devclass, unit)); > > /* Initialize state */ > - sc->rsel.si_flags = 0; > - sc->rsel.si_pid = 0; > + SEL_INIT(&sc->rsel); > sc->mode.level = sc->dflt_mode.level; > sc->mode.protocol = sc->dflt_mode.protocol; > sc->watchdog = FALSE; And here. > Index: kern/kern_ktrace.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/kern_ktrace.c,v > retrieving revision 1.60 > diff -u -r1.60 kern_ktrace.c > --- kern/kern_ktrace.c 27 Feb 2002 19:10:50 -0000 1.60 > +++ kern/kern_ktrace.c 10 Mar 2002 08:08:36 -0000 > @@ -181,6 +181,8 @@ > > if (error) > return; > + > + mtx_lock(&Giant); > /* > * don't let p_tracep get ripped out from under us > */ > @@ -200,6 +202,7 @@ > vrele(vp); > FREE(kth, M_KTRACE); > p->p_traceflag &= ~KTRFAC_ACTIVE; > + mtx_unlock(&Giant); > } This will probably result in lots of nice lock order reversals. That is why I'm working on getting things like this out from under Giant rather than bogusly pushing Giant down into them. Note that pushing Giant down into foo_drop routines or foo_free (we should pick a consistent name for those btw) is probably a good idea to handle things like fdrop() and crfree(). > + si = TAILQ_FIRST(&td->td_selinfo); > + while (si != NULL) { > + nsi = TAILQ_NEXT(si, si_thrlist); > + si->si_thread = NULL; > + si = nsi; > + } > + TAILQ_INIT(&td->td_selinfo); > +} > + > +/* Maybe: while(!TAILQ_EMPTY(&td->td_selinfo) { si = TAILQ_FIRST(...); nsi = TAILQ_NEXT(...); ... } w/o the TAILQ_INIT(). Also, calling the field td_selinfo makes it look like you have embedded a selinfo in the thread instead of a list of them. Maybe something like td_silist or something that makes it clear it's a head of a list and not a selinfo itself? > + mtx_lock(&sellock); > retry: > + > ncoll = nselcoll; > mtx_lock_spin(&sched_lock); > td->td_flags |= TDF_SELECT; > mtx_unlock_spin(&sched_lock); > - PROC_UNLOCK(td->td_proc); > + mtx_unlock(&sellock); > + > + /* XXX Is there a better place for this? */ > + TAILQ_INIT(&td->td_selinfo); Yes, init it when the thread is created at fork() for now (Julian will move it when needed). It only needs the INIT once. The PROC_LOCK's were oringally due to TDF_SELECT being a p_flag and can definitely go away now that it is a td_flag. > @@ -838,23 +864,28 @@ > timo = ttv.tv_sec > 24 * 60 * 60 ? > 24 * 60 * 60 * hz : tvtohz(&ttv); > } > + > + /* XXX What is the point of this? */ > mtx_lock_spin(&sched_lock); > td->td_flags &= ~TDF_SELECT; > mtx_unlock_spin(&sched_lock); You have to have the lock to make sure no one else is writing to td_flags and to make sure you don't have a stale value while performing the update. Thanks for fixing select() btw. I was also thinking about how to fix this as I mentioned to you earlier. The pfind() was definitely evil. I don't like having a global lock per-se, but I can't think of a better way to do this myself. > + TAILQ_REMOVE(&td->td_selinfo, sip, si_thrlist); > + mtx_lock_spin(&sched_lock); > + if (td->td_wchan == (caddr_t)&selwait) { > + if (td->td_proc->p_stat == SSLEEP) > + setrunnable(td); > + else > + cv_waitq_remove(td); > + } else > + td->td_flags &= ~TDF_SELECT; > + mtx_unlock_spin(&sched_lock); This can probably be simplified now to something like this: mtx_lock_spin(&sched_lock); if (td->td_proc->p_stat == SSLEEP) setrunnable(td); mtx_unlock_spin(&sched_lock); I would rather you commit the select stuff by itself and do the Giant pushdown's afterwards though I might like to review just that part of the diff once the select changes are in. Also, the XXXKSE comment in sys/select.h about si_thread can go away now. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 11 10:35:40 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id 3EFAB37B405 for ; Mon, 11 Mar 2002 10:35:07 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g2BIYQ301091; Mon, 11 Mar 2002 10:34:26 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200203111834.g2BIYQ301091@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Bruce Evans Cc: smp@FreeBSD.ORG Subject: Re: Interrupt Context becomes a misnomer (was Re: Core recognizes SMPng tech lead ) In-reply-to: Your message of "Mon, 11 Mar 2002 19:39:33 +1100." <20020311190003.W5788-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Mar 2002 10:34:26 -0800 From: Michael Smith Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > We should stop doing (almost) anything in "interrupt context". An > > interrupt handler should at most: > > > > - pacify the interrupting device > > - make the driver's interrupt thread runnable > > This is insignificantly different from what happens for non-fast interrupts > now in -current: Understood. The point I was trying to make is that "interrupt context" and the process of blocking interrupts should largely vanish. > We depend on icu/apic masking to keep the device quiet while we are > running higher-priority things. icu/apic masking also prevents other > devices that are sharing an interrupt from even interrupting, so we > cannot in general support devices that need pacifying real soon in > real-time. This is a platform constraint, and unlikely to go away soon. > We would need immediate pacification to support such > devices and/or hardware without an icu/apic, but this would require > rewriting the interrupt system yet again The scheme proposed will allow for closer to optimal behaviour in the APIC case where the vector is not shared (common) or the ICU case where the interrupt is not shared, by allowing the driver to establish a private 'fast' handler to provide this immediate pacification. > and wouldn't significantly > uncomplicate the new-bus-related locking: a single lock can lock out > all the current hardware ithreads just as well as it can lock out > all software ithreads, and would work equally poorly (if it is held > for long) for both. Newbus' lock would never be acquired in "interrupt context", and one would not acquire the lock to block interrupts. > Fast interrupt handlers are basically handlers that follow this model. > I wouldn't want to use them for all interrupt handlers because they > (or rather the code that shares data with them) is harder to write. > But locking may require similar complications anyway (you can't just > access your data but you have to lock it, and you must only lock it > for short intervals to not defeat the point of having fast interrupt > handlers/ immediate pacification. The whole driver must be aware of > the real-time constraints of the hardware part of of interrupt handler). Typically the data the fast handler needs to touch is invariant; the one item not fitting this description is the mechanism that the fast handler uses to feed tokens from the hardware to the soft handler. This is why I made such a deal a while back about lockless, mp-safe queue algorithms. If such an animal exists, it would serve us well to standardise on something that will let us pass even just a set of (void *) up a queue. Many peripherals want you to empty their output queue before they will stop interrupting; for a fast handler to be effective in this context, it needs to be able to put the tokens off this queue somewhere. > (I think SWI > handlers should be able to access hardware, at least if if they lock > out there hardare interrupt handler -- this is not much different from > hardware accesses in non-interrupt context to initiate i/o.) How would you best propose to implement this interlock? I'm guessing that for most hardware accesses, a well-placed spinlock would do, but then I can think of some peripherals where that wouldn't necessarily be adequate, due to spinning waiting for the hardware. -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 11 10:44:46 2002 Delivered-To: freebsd-smp@freebsd.org Received: from web11503.mail.yahoo.com (web11503.mail.yahoo.com [216.136.172.35]) by hub.freebsd.org (Postfix) with SMTP id 792BC37B400 for ; Mon, 11 Mar 2002 10:44:34 -0800 (PST) Message-ID: <20020311184434.31124.qmail@web11503.mail.yahoo.com> Received: from [129.7.251.251] by web11503.mail.yahoo.com via HTTP; Mon, 11 Mar 2002 10:44:34 PST Date: Mon, 11 Mar 2002 10:44:34 -0800 (PST) From: Raymond Mouton Subject: running a tyan thunder k7 dual 1.2GHZ MP's To: freebsd-smp@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1329753596-1015872274=:30607" Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --0-1329753596-1015872274=:30607 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline It runs sort of, I have the mptab output and my kernel config file attached. For some reason or other does a fatal page trap 12 every so often apparently at random, does some infinite loops off ping and a few other apps. The fatal page trap error message indicates boot() being called on one or the other cpu no matter what app I am currently running. I am willing to be the test rodent for you if I could get this thing stable by the time 4.6 is released. Sincerely, Raymond A. Mouton __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ --0-1329753596-1015872274=:30607 Content-Type: application/x-unknown; name=mptab Content-Transfer-Encoding: base64 Content-Description: mptab Content-Disposition: attachment; filename=mptab Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KCk1QVGFibGUs IHZlcnNpb24gMi4wLjE1CgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCgpNUCBGbG9hdGluZyBQb2ludGVyIFN0cnVjdHVyZToKCiAgbG9j YXRpb246CQkJQklPUwogIHBoeXNpY2FsIGFkZHJlc3M6CQkweDAwMGY3NGUw CiAgc2lnbmF0dXJlOgkJCSdfTVBfJwogIGxlbmd0aDoJCQkxNiBieXRlcwog IHZlcnNpb246CQkJMS40CiAgY2hlY2tzdW06CQkJMHgyYgogIG1vZGU6CQkJ CVZpcnR1YWwgV2lyZQoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQoKTVAgQ29uZmlnIFRhYmxlIEhlYWRlcjoKCiAgcGh5c2ljYWwgYWRk cmVzczoJCTB4MDAwOWZjNzAKICBzaWduYXR1cmU6CQkJJ1BDTVAnCiAgYmFz ZSB0YWJsZSBsZW5ndGg6CQkyNjAKICB2ZXJzaW9uOgkJCTEuNAogIGNoZWNr c3VtOgkJCTB4NGQKICBPRU0gSUQ6CQkJJ1RZQU4gICAgJwogIFByb2R1Y3Qg SUQ6CQkJJ0dVSU5ORVNTICAgICcKICBPRU0gdGFibGUgcG9pbnRlcjoJCTB4 MDAwMDAwMDAKICBPRU0gdGFibGUgc2l6ZToJCTAKICBlbnRyeSBjb3VudDoJ CQkyNAogIGxvY2FsIEFQSUMgYWRkcmVzczoJCTB4ZmVlMDAwMDAKICBleHRl bmRlZCB0YWJsZSBsZW5ndGg6CTM0NAogIGV4dGVuZGVkIHRhYmxlIGNoZWNr c3VtOgkxNgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoK TVAgQ29uZmlnIEJhc2UgVGFibGUgRW50cmllczoKCi0tClByb2Nlc3NvcnM6 CUFQSUMgSUQJVmVyc2lvbglTdGF0ZQkJRmFtaWx5CU1vZGVsCVN0ZXAJRmxh Z3MKCQkgMQkgMHgxMAkgQlNQLCB1c2FibGUJIDYJIDYJIDEJIDB4MzgzZmJm ZgoJCSAwCSAweDEwCSBBUCwgdXNhYmxlCSA2CSA2CSAxCSAweDM4M2ZiZmYK LS0KQnVzOgkJQnVzIElECVR5cGUKCQkgMAkgUENJICAgCgkJIDEJIFBDSSAg IAoJCSAyCSBJU0EgICAKLS0KSS9PIEFQSUNzOglBUElDIElECVZlcnNpb24J U3RhdGUJCUFkZHJlc3MKCQkgMgkgMHgxMQkgdXNhYmxlCQkgMHhmZWMwMDAw MAotLQpJL08gSW50czoJVHlwZQlQb2xhcml0eSAgICBUcmlnZ2VyCUJ1cyBJ RAkgSVJRCUFQSUMgSUQJUElOIwoJCUV4dElOVAlhY3RpdmUtaGkgICAgICAg IGVkZ2UJICAgICAyCSAgIDAJICAgICAgMgkgICAwCgkJSU5UCWFjdGl2ZS1o aSAgICAgICAgZWRnZQkgICAgIDIJICAgMQkgICAgICAyCSAgIDEKCQlJTlQJ YWN0aXZlLWhpICAgICAgICBlZGdlCSAgICAgMgkgICAwCSAgICAgIDIJICAg MgoJCUlOVAlhY3RpdmUtbG8gICAgICAgbGV2ZWwJICAgICAyCSAgIDMJICAg ICAgMgkgICAzCgkJSU5UCWFjdGl2ZS1oaSAgICAgICAgZWRnZQkgICAgIDIJ ICAgNAkgICAgICAyCSAgIDQKCQlJTlQJYWN0aXZlLWxvICAgICAgIGxldmVs CSAgICAgMgkgICA1CSAgICAgIDIJICAgNQoJCUlOVAlhY3RpdmUtaGkgICAg ICAgIGVkZ2UJICAgICAyCSAgIDYJICAgICAgMgkgICA2CgkJSU5UCWFjdGl2 ZS1oaSAgICAgICAgZWRnZQkgICAgIDIJICAgNwkgICAgICAyCSAgIDcKCQlJ TlQJYWN0aXZlLWhpICAgICAgICBlZGdlCSAgICAgMgkgICA4CSAgICAgIDIJ ICAgOAoJCUlOVAlhY3RpdmUtaGkgICAgICAgIGVkZ2UJICAgICAyCSAgIDkJ ICAgICAgMgkgICA5CgkJSU5UCWFjdGl2ZS1sbyAgICAgICBsZXZlbAkgICAg IDIJICAxMAkgICAgICAyCSAgMTAKCQlJTlQJYWN0aXZlLWxvICAgICAgIGxl dmVsCSAgICAgMgkgIDExCSAgICAgIDIJICAxMQoJCUlOVAlhY3RpdmUtaGkg ICAgICAgIGVkZ2UJICAgICAyCSAgMTIJICAgICAgMgkgIDEyCgkJSU5UCWFj dGl2ZS1oaSAgICAgICAgZWRnZQkgICAgIDIJICAxMwkgICAgICAyCSAgMTMK CQlJTlQJYWN0aXZlLWhpICAgICAgICBlZGdlCSAgICAgMgkgIDE0CSAgICAg IDIJICAxNAoJCUlOVAlhY3RpdmUtaGkgICAgICAgIGVkZ2UJICAgICAyCSAg MTUJICAgICAgMgkgIDE1Ci0tCkxvY2FsIEludHM6CVR5cGUJUG9sYXJpdHkg ICAgVHJpZ2dlcglCdXMgSUQJIElSUQlBUElDIElECVBJTiMKCQlFeHRJTlQJ YWN0aXZlLWhpICAgICAgICBlZGdlCSAgICAgMgkgICAwCSAgICAyNTUJICAg MAoJCU5NSQlhY3RpdmUtaGkgICAgICAgIGVkZ2UJICAgICAxCSAwOkEJICAg IDI1NQkgICAxCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t CgpNUCBDb25maWcgRXh0ZW5kZWQgVGFibGUgRW50cmllczoKCi0tClN5c3Rl bSBBZGRyZXNzIFNwYWNlCiBidXMgSUQ6IDAgYWRkcmVzcyB0eXBlOiBJL08g YWRkcmVzcwogYWRkcmVzcyBiYXNlOiAweDAKIGFkZHJlc3MgcmFuZ2U6IDB4 MTAwMDAKLS0KU3lzdGVtIEFkZHJlc3MgU3BhY2UKIGJ1cyBJRDogMCBhZGRy ZXNzIHR5cGU6IG1lbW9yeSBhZGRyZXNzCiBhZGRyZXNzIGJhc2U6IDB4MTAw MDAwMDAKIGFkZHJlc3MgcmFuZ2U6IDB4ZTQwMDAwMDAKLS0KU3lzdGVtIEFk ZHJlc3MgU3BhY2UKIGJ1cyBJRDogMCBhZGRyZXNzIHR5cGU6IHByZWZldGNo IGFkZHJlc3MKIGFkZHJlc3MgYmFzZTogMHhmNDAwMDAwMAogYWRkcmVzcyBy YW5nZTogMHg4MDAwMDAwCi0tClN5c3RlbSBBZGRyZXNzIFNwYWNlCiBidXMg SUQ6IDAgYWRkcmVzcyB0eXBlOiBtZW1vcnkgYWRkcmVzcwogYWRkcmVzcyBi YXNlOiAweGZjMDAwMDAwCiBhZGRyZXNzIHJhbmdlOiAweDJlMDAwMDAKLS0K U3lzdGVtIEFkZHJlc3MgU3BhY2UKIGJ1cyBJRDogMCBhZGRyZXNzIHR5cGU6 IG1lbW9yeSBhZGRyZXNzCiBhZGRyZXNzIGJhc2U6IDB4ZmVlMDEwMDAKIGFk ZHJlc3MgcmFuZ2U6IDB4MTFmZjAwMAotLQpTeXN0ZW0gQWRkcmVzcyBTcGFj ZQogYnVzIElEOiAwIGFkZHJlc3MgdHlwZTogbWVtb3J5IGFkZHJlc3MKIGFk ZHJlc3MgYmFzZTogMHhhMDAwMAogYWRkcmVzcyByYW5nZTogMHgyNDAwMAot LQpTeXN0ZW0gQWRkcmVzcyBTcGFjZQogYnVzIElEOiAwIGFkZHJlc3MgdHlw ZTogbWVtb3J5IGFkZHJlc3MKIGFkZHJlc3MgYmFzZTogMHhjODAwMAogYWRk cmVzcyByYW5nZTogMHgyMDAwCi0tClN5c3RlbSBBZGRyZXNzIFNwYWNlCiBi dXMgSUQ6IDAgYWRkcmVzcyB0eXBlOiBtZW1vcnkgYWRkcmVzcwogYWRkcmVz cyBiYXNlOiAweGNjMDAwCiBhZGRyZXNzIHJhbmdlOiAweDIwMDAKLS0KU3lz dGVtIEFkZHJlc3MgU3BhY2UKIGJ1cyBJRDogMCBhZGRyZXNzIHR5cGU6IG1l bW9yeSBhZGRyZXNzCiBhZGRyZXNzIGJhc2U6IDB4ZDAwMDAKIGFkZHJlc3Mg cmFuZ2U6IDB4MTAwMAotLQpTeXN0ZW0gQWRkcmVzcyBTcGFjZQogYnVzIElE OiAwIGFkZHJlc3MgdHlwZTogbWVtb3J5IGFkZHJlc3MKIGFkZHJlc3MgYmFz ZTogMHhkMjAwMAogYWRkcmVzcyByYW5nZTogMHgxMDAwCi0tClN5c3RlbSBB ZGRyZXNzIFNwYWNlCiBidXMgSUQ6IDAgYWRkcmVzcyB0eXBlOiBtZW1vcnkg YWRkcmVzcwogYWRkcmVzcyBiYXNlOiAweGQ0MDAwCiBhZGRyZXNzIHJhbmdl OiAweDEwMDAKLS0KU3lzdGVtIEFkZHJlc3MgU3BhY2UKIGJ1cyBJRDogMCBh ZGRyZXNzIHR5cGU6IG1lbW9yeSBhZGRyZXNzCiBhZGRyZXNzIGJhc2U6IDB4 ZDYwMDAKIGFkZHJlc3MgcmFuZ2U6IDB4MTAwMAotLQpTeXN0ZW0gQWRkcmVz cyBTcGFjZQogYnVzIElEOiAwIGFkZHJlc3MgdHlwZTogbWVtb3J5IGFkZHJl c3MKIGFkZHJlc3MgYmFzZTogMHhkODAwMAogYWRkcmVzcyByYW5nZTogMHgy MDAwCi0tClN5c3RlbSBBZGRyZXNzIFNwYWNlCiBidXMgSUQ6IDAgYWRkcmVz cyB0eXBlOiBtZW1vcnkgYWRkcmVzcwogYWRkcmVzcyBiYXNlOiAweGUwMDAw CiBhZGRyZXNzIHJhbmdlOiAweDEyMDAwCi0tClN5c3RlbSBBZGRyZXNzIFNw YWNlCiBidXMgSUQ6IDAgYWRkcmVzcyB0eXBlOiBtZW1vcnkgYWRkcmVzcwog YWRkcmVzcyBiYXNlOiAweGY0MDAwCiBhZGRyZXNzIHJhbmdlOiAweDIwMDAK LS0KU3lzdGVtIEFkZHJlc3MgU3BhY2UKIGJ1cyBJRDogMCBhZGRyZXNzIHR5 cGU6IG1lbW9yeSBhZGRyZXNzCiBhZGRyZXNzIGJhc2U6IDB4ZjgwMDAKIGFk ZHJlc3MgcmFuZ2U6IDB4NDAwMAotLQpCdXMgSGVpcmFyY2h5CiBidXMgSUQ6 IDIgYnVzIGluZm86IDB4MDEgcGFyZW50IGJ1cyBJRDogMAotLQpDb21wYXRp YmlsaXR5IEJ1cyBBZGRyZXNzCiBidXMgSUQ6IDAgYWRkcmVzcyBtb2RpZmll cjogYWRkCiBwcmVkZWZpbmVkIHJhbmdlOiAweDAwMDAwMDAwCi0tCkNvbXBh dGliaWxpdHkgQnVzIEFkZHJlc3MKIGJ1cyBJRDogMCBhZGRyZXNzIG1vZGlm aWVyOiBhZGQKIHByZWRlZmluZWQgcmFuZ2U6IDB4MDAwMDAwMDEKCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KCg== --0-1329753596-1015872274=:30607 Content-Type: application/x-unknown; name=SMPBASE Content-Transfer-Encoding: base64 Content-Description: SMPBASE Content-Disposition: attachment; filename=SMPBASE IwojIEdFTkVSSUMgLS0gR2VuZXJpYyBrZXJuZWwgY29uZmlndXJhdGlvbiBm aWxlIGZvciBGcmVlQlNEL2kzODYKIwojIEZvciBtb3JlIGluZm9ybWF0aW9u IG9uIHRoaXMgZmlsZSwgcGxlYXNlIHJlYWQgdGhlIGhhbmRib29rIHNlY3Rp b24gb24KIyBLZXJuZWwgQ29uZmlndXJhdGlvbiBGaWxlczoKIwojICAgIGh0 dHA6Ly93d3cuRnJlZUJTRC5vcmcvaGFuZGJvb2sva2VybmVsY29uZmlnLWNv bmZpZy5odG1sCiMKIyBUaGUgaGFuZGJvb2sgaXMgYWxzbyBhdmFpbGFibGUg bG9jYWxseSBpbiAvdXNyL3NoYXJlL2RvYy9oYW5kYm9vawojIGlmIHlvdSd2 ZSBpbnN0YWxsZWQgdGhlIGRvYyBkaXN0cmlidXRpb24sIG90aGVyd2lzZSBh bHdheXMgc2VlIHRoZQojIEZyZWVCU0QgV29ybGQgV2lkZSBXZWIgc2VydmVy IChodHRwOi8vd3d3LkZyZWVCU0Qub3JnLykgZm9yIHRoZQojIGxhdGVzdCBp bmZvcm1hdGlvbi4KIwojIEFuIGV4aGF1c3RpdmUgbGlzdCBvZiBvcHRpb25z IGFuZCBtb3JlIGRldGFpbGVkIGV4cGxhbmF0aW9ucyBvZiB0aGUKIyBkZXZp Y2UgbGluZXMgaXMgYWxzbyBwcmVzZW50IGluIHRoZSAuL0xJTlQgY29uZmln dXJhdGlvbiBmaWxlLiBJZiB5b3UgYXJlCiMgaW4gZG91YnQgYXMgdG8gdGhl IHB1cnBvc2Ugb3IgbmVjZXNzaXR5IG9mIGEgbGluZSwgY2hlY2sgZmlyc3Qg aW4gTElOVC4KIwojICRGcmVlQlNEOiBzcmMvc3lzL2kzODYvY29uZi9HRU5F UklDLHYgMS4yNDYuMi4zOCAyMDAyLzAxLzI1IDE3OjQxOjQwIG11cnJheSBF eHAgJAoKbWFjaGluZQkJaTM4NgojY3B1CQlJMzg2X0NQVQojY3B1CQlJNDg2 X0NQVQojY3B1CQlJNTg2X0NQVQpjcHUJCUk2ODZfQ1BVCmlkZW50CQlTTVBC QVNFCm1heHVzZXJzCTAKCiNtYWtlb3B0aW9ucwlERUJVRz0tZwkJI0J1aWxk IGtlcm5lbCB3aXRoIGdkYigxKSBkZWJ1ZyBzeW1ib2xzCgpvcHRpb25zIAlN QVRIX0VNVUxBVEUJCSNTdXBwb3J0IGZvciB4ODcgZW11bGF0aW9uCm9wdGlv bnMgCUlORVQJCQkjSW50ZXJORVR3b3JraW5nCm9wdGlvbnMgCUlORVQ2CQkJ I0lQdjYgY29tbXVuaWNhdGlvbnMgcHJvdG9jb2xzCm9wdGlvbnMgCUZGUwkJ CSNCZXJrZWxleSBGYXN0IEZpbGVzeXN0ZW0Kb3B0aW9ucyAJRkZTX1JPT1QJ CSNGRlMgdXNhYmxlIGFzIHJvb3QgZGV2aWNlIFtrZWVwIHRoaXMhXQpvcHRp b25zIAlTT0ZUVVBEQVRFUwkJI0VuYWJsZSBGRlMgc29mdCB1cGRhdGVzIHN1 cHBvcnQKb3B0aW9ucyAJVUZTX0RJUkhBU0gJCSNJbXByb3ZlIHBlcmZvcm1h bmNlIG9uIGJpZyBkaXJlY3RvcmllcwpvcHRpb25zIAlNRlMJCQkjTWVtb3J5 IEZpbGVzeXN0ZW0Kb3B0aW9ucyAJTURfUk9PVAkJCSNNRCBpcyBhIHBvdGVu dGlhbCByb290IGRldmljZQpvcHRpb25zIAlORlMJCQkjTmV0d29yayBGaWxl c3lzdGVtCm9wdGlvbnMgCU5GU19ST09UCQkjTkZTIHVzYWJsZSBhcyByb290 IGRldmljZSwgTkZTIHJlcXVpcmVkCm9wdGlvbnMgCU1TRE9TRlMJCQkjTVNE T1MgRmlsZXN5c3RlbQpvcHRpb25zIAlDRDk2NjAJCQkjSVNPIDk2NjAgRmls ZXN5c3RlbQpvcHRpb25zIAlDRDk2NjBfUk9PVAkJI0NELVJPTSB1c2FibGUg YXMgcm9vdCwgQ0Q5NjYwIHJlcXVpcmVkCm9wdGlvbnMgCVBST0NGUwkJCSNQ cm9jZXNzIGZpbGVzeXN0ZW0Kb3B0aW9ucyAJQ09NUEFUXzQzCQkjQ29tcGF0 aWJsZSB3aXRoIEJTRCA0LjMgW0tFRVAgVEhJUyFdCm9wdGlvbnMgCVNDU0lf REVMQVk9MTUwMDAJI0RlbGF5IChpbiBtcykgYmVmb3JlIHByb2JpbmcgU0NT SQpvcHRpb25zIAlVQ09OU09MRQkJI0FsbG93IHVzZXJzIHRvIGdyYWIgdGhl IGNvbnNvbGUKb3B0aW9ucyAJVVNFUkNPTkZJRwkJI2Jvb3QgLWMgZWRpdG9y Cm9wdGlvbnMgCVZJU1VBTF9VU0VSQ09ORklHCSN2aXN1YWwgYm9vdCAtYyBl ZGl0b3IKb3B0aW9ucyAJS1RSQUNFCQkJI2t0cmFjZSgxKSBzdXBwb3J0Cm9w dGlvbnMgCVNZU1ZTSE0JCQkjU1lTVi1zdHlsZSBzaGFyZWQgbWVtb3J5Cm9w dGlvbnMgCVNZU1ZNU0cJCQkjU1lTVi1zdHlsZSBtZXNzYWdlIHF1ZXVlcwpv cHRpb25zIAlTWVNWU0VNCQkJI1NZU1Ytc3R5bGUgc2VtYXBob3JlcwpvcHRp b25zIAlQMTAwM18xQgkJI1Bvc2l4IFAxMDAzXzFCIHJlYWwtdGltZSBleHRl bnNpb25zCm9wdGlvbnMgCV9LUE9TSVhfUFJJT1JJVFlfU0NIRURVTElORwpv cHRpb25zCQlJQ01QX0JBTkRMSU0JCSNSYXRlIGxpbWl0IGJhZCByZXBsaWVz Cm9wdGlvbnMgCUtCRF9JTlNUQUxMX0NERVYJIyBpbnN0YWxsIGEgQ0RFViBl bnRyeSBpbiAvZGV2CgojIFRvIG1ha2UgYW4gU01QIGtlcm5lbCwgdGhlIG5l eHQgdHdvIGFyZSBuZWVkZWQKb3B0aW9ucyAJU01QCQkJIyBTeW1tZXRyaWMg TXVsdGlQcm9jZXNzb3IgS2VybmVsCm9wdGlvbnMgCUFQSUNfSU8JCQkjIFN5 bW1ldHJpYyAoQVBJQykgSS9PCgpkZXZpY2UJCWlzYQpkZXZpY2UJCWVpc2EK ZGV2aWNlCQlwY2kKCiMgRmxvcHB5IGRyaXZlcwpkZXZpY2UJCWZkYzAJYXQg aXNhPyBwb3J0IElPX0ZEMSBpcnEgNiBkcnEgMgpkZXZpY2UJCWZkMAlhdCBm ZGMwIGRyaXZlIDAKZGV2aWNlCQlmZDEJYXQgZmRjMCBkcml2ZSAxCiMKIyBJ ZiB5b3UgaGF2ZSBhIFRvc2hpYmEgTGlicmV0dG8gd2l0aCBpdHMgWS1FIERh dGEgUENNQ0lBIGZsb3BweSwKIyBkb24ndCB1c2UgdGhlIGFib3ZlIGxpbmUg Zm9yIGZkYzAgYnV0IHRoZSBmb2xsb3dpbmcgb25lOgojZGV2aWNlCQlmZGMw CgojIEFUQSBhbmQgQVRBUEkgZGV2aWNlcwpkZXZpY2UJCWF0YTAJYXQgaXNh PyBwb3J0IElPX1dEMSBpcnEgMTQKZGV2aWNlCQlhdGExCWF0IGlzYT8gcG9y dCBJT19XRDIgaXJxIDE1CmRldmljZQkJYXRhCmRldmljZQkJYXRhZGlzawkJ CSMgQVRBIGRpc2sgZHJpdmVzCmRldmljZQkJYXRhcGljZAkJCSMgQVRBUEkg Q0RST00gZHJpdmVzCmRldmljZQkJYXRhcGlmZAkJCSMgQVRBUEkgZmxvcHB5 IGRyaXZlcwojZGV2aWNlCQlhdGFwaXN0CQkJIyBBVEFQSSB0YXBlIGRyaXZl cwpvcHRpb25zIAlBVEFfU1RBVElDX0lECQkjU3RhdGljIGRldmljZSBudW1i ZXJpbmcKCiMgU0NTSSBDb250cm9sbGVycwojZGV2aWNlCQlhaGIJCSMgRUlT QSBBSEExNzQyIGZhbWlseQpkZXZpY2UJCWFoYwkJIyBBSEEyOTQwIGFuZCBv bmJvYXJkIEFJQzd4eHggZGV2aWNlcwojZGV2aWNlCQlhbWQJCSMgQU1EIDUz Qzk3NCAoVGVrcmFtIERDLTM5MChUKSkKI2RldmljZQkJaXNwCQkjIFFsb2dp YyBmYW1pbHkKI2RldmljZQkJbmNyCQkjIE5DUi9TeW1iaW9zIExvZ2ljCiNk ZXZpY2UJCXN5bQkJIyBOQ1IvU3ltYmlvcyBMb2dpYyAobmV3ZXIgY2hpcHNl dHMpCiNvcHRpb25zCQlTWU1fU0VUVVBfTFBfUFJPQkVfTUFQPTB4NDAKCQkJ CSMgQWxsb3cgbmNyIHRvIGF0dGFjaCBsZWdhY3kgTkNSIGRldmljZXMgd2hl biAKCQkJCSMgYm90aCBzeW0gYW5kIG5jciBhcmUgY29uZmlndXJlZAoKI2Rl dmljZQkJYWR2MAlhdCBpc2E/CiNkZXZpY2UJCWFkdwojZGV2aWNlCQlidDAJ YXQgaXNhPwojZGV2aWNlCQlhaGEwCWF0IGlzYT8KI2RldmljZQkJYWljMAlh dCBpc2E/CgojZGV2aWNlCQluY3YJCSMgTkNSIDUzQzUwMAojZGV2aWNlCQlu c3AJCSMgV29ya2JpdCBOaW5qYSBTQ1NJLTMKI2RldmljZQkJc3RnCQkjIFRN QyAxOEMzMC8xOEM1MAoKIyBTQ1NJIHBlcmlwaGVyYWxzCmRldmljZQkJc2Ni dXMJCSMgU0NTSSBidXMgKHJlcXVpcmVkKQpkZXZpY2UJCWRhCQkjIERpcmVj dCBBY2Nlc3MgKGRpc2tzKQpkZXZpY2UJCXNhCQkjIFNlcXVlbnRpYWwgQWNj ZXNzICh0YXBlIGV0YykKZGV2aWNlCQljZAkJIyBDRApkZXZpY2UJCXBhc3MJ CSMgUGFzc3Rocm91Z2ggZGV2aWNlIChkaXJlY3QgU0NTSSBhY2Nlc3MpCgoj IFJBSUQgY29udHJvbGxlcnMgaW50ZXJmYWNlZCB0byB0aGUgU0NTSSBzdWJz eXN0ZW0KI2RldmljZQkJYXNyCQkjIERQVCBTbWFydFJBSUQgViwgVkkgYW5k IEFkYXB0ZWMgU0NTSSBSQUlECiNkZXZpY2UJCWRwdAkJIyBEUFQgU21hcnRj YWNoZSAtIFNlZSBMSU5UIGZvciBvcHRpb25zIQojZGV2aWNlCQltbHkJCSMg TXlsZXggQWNjZWxlUkFJRC9lWHRyZW1lUkFJRAoKIyBSQUlEIGNvbnRyb2xs ZXJzCiNkZXZpY2UJCWFhYwkJIyBBZGFwdGVjIEZTQSBSQUlELCBEZWxsIFBF UkMyL1BFUkMzCiNkZXZpY2UJCWlkYQkJIyBDb21wYXEgU21hcnQgUkFJRAoj ZGV2aWNlCQlhbXIJCSMgQU1JIE1lZ2FSQUlECiNkZXZpY2UJCW1seAkJIyBN eWxleCBEQUM5NjAgZmFtaWx5CiNkZXZpY2UJCXR3ZQkJIyAzd2FyZSBFc2Nh bGFkZQoKIyBhdGtiZGMwIGNvbnRyb2xzIGJvdGggdGhlIGtleWJvYXJkIGFu ZCB0aGUgUFMvMiBtb3VzZQpkZXZpY2UJCWF0a2JkYzAJYXQgaXNhPyBwb3J0 IElPX0tCRApkZXZpY2UJCWF0a2JkMAlhdCBhdGtiZGM/IGlycSAxIGZsYWdz IDB4MQpkZXZpY2UJCXBzbTAJYXQgYXRrYmRjPyBpcnEgMTIKCmRldmljZQkJ dmdhMAlhdCBpc2E/CgojIHNwbGFzaCBzY3JlZW4vc2NyZWVuIHNhdmVyCnBz ZXVkby1kZXZpY2UJc3BsYXNoCgojIHN5c2NvbnMgaXMgdGhlIGRlZmF1bHQg Y29uc29sZSBkcml2ZXIsIHJlc2VtYmxpbmcgYW4gU0NPIGNvbnNvbGUKZGV2 aWNlCQlzYzAJYXQgaXNhPyBmbGFncyAweDEwMAoKIyBFbmFibGUgdGhpcyBh bmQgUENWVF9GUkVFQlNEIGZvciBwY3Z0IHZ0MjIwIGNvbXBhdGlibGUgY29u c29sZSBkcml2ZXIKI2RldmljZQkJdnQwCWF0IGlzYT8KI29wdGlvbnMgCVhT RVJWRVIJCQkjIHN1cHBvcnQgZm9yIFggc2VydmVyIG9uIGEgdnQgY29uc29s ZQojb3B0aW9ucyAJRkFUX0NVUlNPUgkJIyBzdGFydCB3aXRoIGJsb2NrIGN1 cnNvcgojIElmIHlvdSBoYXZlIGEgVGhpbmtQQUQsIHVuY29tbWVudCB0aGlz IGFsb25nIHdpdGggdGhlIHJlc3Qgb2YgdGhlIFBDVlQgbGluZXMKI29wdGlv bnMgCVBDVlRfU0NBTlNFVD0yCQkjIElCTSBrZXlib2FyZHMgYXJlIG5vbi1z dGQKCiMgRmxvYXRpbmcgcG9pbnQgc3VwcG9ydCAtIGRvIG5vdCBkaXNhYmxl LgpkZXZpY2UJCW5weDAJYXQgbmV4dXM/IHBvcnQgSU9fTlBYIGlycSAxMwoK IyBQb3dlciBtYW5hZ2VtZW50IHN1cHBvcnQgKHNlZSBMSU5UIGZvciBtb3Jl IG9wdGlvbnMpCmRldmljZQkJYXBtMCAgICBhdCBuZXh1cz8gZGlzYWJsZSBm bGFncyAweDIwICMgQWR2YW5jZWQgUG93ZXIgTWFuYWdlbWVudAoKIyBQQ0NB UkQgKFBDTUNJQSkgc3VwcG9ydAojZGV2aWNlCQljYXJkCiNkZXZpY2UJCXBj aWMwCWF0IGlzYT8gaXJxIDAgcG9ydCAweDNlMCBpb21lbSAweGQwMDAwCiNk ZXZpY2UJCXBjaWMxCWF0IGlzYT8gaXJxIDAgcG9ydCAweDNlMiBpb21lbSAw eGQ0MDAwIGRpc2FibGUKCiMgU2VyaWFsIChDT00pIHBvcnRzCmRldmljZQkJ c2lvMAlhdCBpc2E/IHBvcnQgSU9fQ09NMSBmbGFncyAweDEwIGlycSA0CmRl dmljZQkJc2lvMQlhdCBpc2E/IHBvcnQgSU9fQ09NMiBpcnEgMwpkZXZpY2UJ CXNpbzIJYXQgaXNhPyBkaXNhYmxlIHBvcnQgSU9fQ09NMyBpcnEgNQpkZXZp Y2UJCXNpbzMJYXQgaXNhPyBkaXNhYmxlIHBvcnQgSU9fQ09NNCBpcnEgOQoK IyBQYXJhbGxlbCBwb3J0CmRldmljZQkJcHBjMAlhdCBpc2E/IGlycSA3CmRl dmljZQkJcHBidXMJCSMgUGFyYWxsZWwgcG9ydCBidXMgKHJlcXVpcmVkKQpk ZXZpY2UJCWxwdAkJIyBQcmludGVyCmRldmljZQkJcGxpcAkJIyBUQ1AvSVAg b3ZlciBwYXJhbGxlbApkZXZpY2UJCXBwaQkJIyBQYXJhbGxlbCBwb3J0IGlu dGVyZmFjZSBkZXZpY2UKI2RldmljZQkJdnBvCQkjIFJlcXVpcmVzIHNjYnVz IGFuZCBkYQoKCiMgUENJIEV0aGVybmV0IE5JQ3MuCiNkZXZpY2UJCWRlCQkj IERFQy9JbnRlbCBEQzIxeDR4IChgYFR1bGlwJycpCiNkZXZpY2UJCXR4cAkJ IyAzQ29tIDNjUjk5MCAoYGBUeXBob29uJycpCiNkZXZpY2UJCXZ4CQkjIDND b20gM2M1OTAsIDNjNTk1IChgYFZvcnRleCcnKQoKIyBQQ0kgRXRoZXJuZXQg TklDcyB0aGF0IHVzZSB0aGUgY29tbW9uIE1JSSBidXMgY29udHJvbGxlciBj b2RlLgojIE5PVEU6IEJlIHN1cmUgdG8ga2VlcCB0aGUgJ2RldmljZSBtaWli dXMnIGxpbmUgaW4gb3JkZXIgdG8gdXNlIHRoZXNlIE5JQ3MhCmRldmljZQkJ bWlpYnVzCQkjIE1JSSBidXMgc3VwcG9ydAojZGV2aWNlCQlkYwkJIyBERUMv SW50ZWwgMjExNDMgYW5kIHZhcmlvdXMgd29ya2FsaWtlcwojZGV2aWNlCQlm eHAJCSMgSW50ZWwgRXRoZXJFeHByZXNzIFBSTy8xMDBCICg4MjU1NywgODI1 NTgpCiNkZXZpY2UJCXBjbgkJIyBBTUQgQW03OUM5N3ggUENJIDEwLzEwMCBO SUNzCiNkZXZpY2UJCXJsCQkjIFJlYWxUZWsgODEyOS84MTM5CiNkZXZpY2UJ CXNmCQkjIEFkYXB0ZWMgQUlDLTY5MTUgKGBgU3RhcmZpcmUnJykKI2Rldmlj ZQkJc2lzCQkjIFNpbGljb24gSW50ZWdyYXRlZCBTeXN0ZW1zIFNpUyA5MDAv U2lTIDcwMTYKI2RldmljZQkJc3RlCQkjIFN1bmRhbmNlIFNUMjAxIChELUxp bmsgREZFLTU1MFRYKQojZGV2aWNlCQl0bAkJIyBUZXhhcyBJbnN0cnVtZW50 cyBUaHVuZGVyTEFOCiNkZXZpY2UJCXR4CQkjIFNNQyBFdGhlclBvd2VyIElJ ICg4M2MxNzAgYGBFUElDJycpCiNkZXZpY2UJCXZyCQkjIFZJQSBSaGluZSwg UmhpbmUgSUkKI2RldmljZQkJd2IJCSMgV2luYm9uZCBXODlDODQwRgojZGV2 aWNlCQl3eAkJIyBJbnRlbCBHaWdhYml0IEV0aGVybmV0IENhcmQgKGBgV2lz ZW1hbicnKQpkZXZpY2UJCXhsCQkjIDNDb20gM2M5MHggKGBgQm9vbWVyYW5n JycsIGBgQ3ljbG9uZScnKQojZGV2aWNlCQliZ2UJCSMgQnJvYWRjb20gQkNN NTcweCAoYGBUaWdvbiBJSUknJykKCiMgSVNBIEV0aGVybmV0IE5JQ3MuCiMg J2RldmljZSBlZCcgcmVxdWlyZXMgJ2RldmljZSBtaWlidXMnCiNkZXZpY2UJ CWVkMAlhdCBpc2E/IHBvcnQgMHgyODAgaXJxIDEwIGlvbWVtIDB4ZDgwMDAK I2RldmljZQkJZXgKI2RldmljZQkJZXAKI2RldmljZQkJZmUwCWF0IGlzYT8g cG9ydCAweDMwMAojIFhpcmNvbSBFdGhlcm5ldAojZGV2aWNlCQl4ZQojIFBS SVNNIEkgSUVFRSA4MDIuMTFiIHdpcmVsZXNzIE5JQy4KI2RldmljZQkJYXdp CiMgV2F2ZUxBTi9JRUVFIDgwMi4xMSB3aXJlbGVzcyBOSUNzLiBOb3RlOiB0 aGUgV2F2ZUxBTi9JRUVFIHJlYWxseQojIGV4aXN0cyBvbmx5IGFzIGEgUENN Q0lBIGRldmljZSwgc28gdGhlcmUgaXMgbm8gSVNBIGF0dGFjaG1lbnQgbmVl ZGVkCiMgYW5kIHJlc291cmNlcyB3aWxsIGFsd2F5cyBiZSBkeW5hbWljYWxs eSBhc3NpZ25lZCBieSB0aGUgcGNjYXJkIGNvZGUuCiNkZXZpY2UJCXdpCiMg QWlyb25ldCA0NTAwLzQ4MDAgODAyLjExIHdpcmVsZXNzIE5JQ3MuIE5vdGU6 IHRoZSBkZWNsYXJhdGlvbiBiZWxvdyB3aWxsCiMgd29yayBmb3IgUENNQ0lB IGFuZCBQQ0kgY2FyZHMsIGFzIHdlbGwgYXMgSVNBIGNhcmRzIHNldCB0byBJ U0EgUG5QCiMgbW9kZSAodGhlIGZhY3RvcnkgZGVmYXVsdCkuIElmIHlvdSBz ZXQgdGhlIHN3aXRjaGVzIG9uIHlvdXIgSVNBCiMgY2FyZCBmb3IgYSBtYW51 YWxseSBjaG9zZW4gSS9PIGFkZHJlc3MgYW5kIElSUSwgeW91IG11c3Qgc3Bl Y2lmeQojIHRob3NlIHBhcmFtZXRlcnMgaGVyZS4KI2RldmljZQkJYW4KIyBU aGUgcHJvYmUgb3JkZXIgb2YgdGhlc2UgaXMgcHJlc2VudGx5IGRldGVybWlu ZWQgYnkgaTM4Ni9pc2EvaXNhX2NvbXBhdC5jLgojZGV2aWNlCQlpZTAJYXQg aXNhPyBwb3J0IDB4MzAwIGlycSAxMCBpb21lbSAweGQwMDAwCiNkZXZpY2UJ CWxlMAlhdCBpc2E/IHBvcnQgMHgzMDAgaXJxIDUgaW9tZW0gMHhkMDAwMAoj ZGV2aWNlCQlsbmMwCWF0IGlzYT8gcG9ydCAweDI4MCBpcnEgMTAgZHJxIDAK I2RldmljZQkJY3MwCWF0IGlzYT8gcG9ydCAweDMwMAojZGV2aWNlCQlzbjAJ YXQgaXNhPyBwb3J0IDB4MzAwIGlycSAxMAoKIyBQc2V1ZG8gZGV2aWNlcyAt IHRoZSBudW1iZXIgaW5kaWNhdGVzIGhvdyBtYW55IHVuaXRzIHRvIGFsbG9j YXRlLgpwc2V1ZG8tZGV2aWNlCWxvb3AJCSMgTmV0d29yayBsb29wYmFjawpw c2V1ZG8tZGV2aWNlCWV0aGVyCQkjIEV0aGVybmV0IHN1cHBvcnQKcHNldWRv LWRldmljZQlzbAkxCSMgS2VybmVsIFNMSVAKcHNldWRvLWRldmljZQlwcHAJ MQkjIEtlcm5lbCBQUFAKcHNldWRvLWRldmljZQl0dW4JCSMgUGFja2V0IHR1 bm5lbC4KcHNldWRvLWRldmljZQlwdHkJCSMgUHNldWRvLXR0eXMgKHRlbG5l dCBldGMpCnBzZXVkby1kZXZpY2UJbWQJCSMgTWVtb3J5ICJkaXNrcyIKcHNl dWRvLWRldmljZQlnaWYJCSMgSVB2NiBhbmQgSVB2NCB0dW5uZWxpbmcKcHNl dWRvLWRldmljZQlmYWl0aAkxCSMgSVB2Ni10by1JUHY0IHJlbGF5aW5nICh0 cmFuc2xhdGlvbikKCiMgVGhlIGBicGYnIHBzZXVkby1kZXZpY2UgZW5hYmxl cyB0aGUgQmVya2VsZXkgUGFja2V0IEZpbHRlci4KIyBCZSBhd2FyZSBvZiB0 aGUgYWRtaW5pc3RyYXRpdmUgY29uc2VxdWVuY2VzIG9mIGVuYWJsaW5nIHRo aXMhCnBzZXVkby1kZXZpY2UJYnBmCQkjQmVya2VsZXkgcGFja2V0IGZpbHRl cgoKIyBVU0Igc3VwcG9ydAojZGV2aWNlCQl1aGNpCQkjIFVIQ0kgUENJLT5V U0IgaW50ZXJmYWNlCiNkZXZpY2UJCW9oY2kJCSMgT0hDSSBQQ0ktPlVTQiBp bnRlcmZhY2UKI2RldmljZQkJdXNiCQkjIFVTQiBCdXMgKHJlcXVpcmVkKQoj ZGV2aWNlCQl1Z2VuCQkjIEdlbmVyaWMKI2RldmljZQkJdWhpZAkJIyAiSHVt YW4gSW50ZXJmYWNlIERldmljZXMiCiNkZXZpY2UJCXVrYmQJCSMgS2V5Ym9h cmQKI2RldmljZQkJdWxwdAkJIyBQcmludGVyCiNkZXZpY2UJCXVtYXNzCQkj IERpc2tzL01hc3Mgc3RvcmFnZSAtIFJlcXVpcmVzIHNjYnVzIGFuZCBkYQoj ZGV2aWNlCQl1bXMJCSMgTW91c2UKI2RldmljZQkJdXNjYW5uZXIJIyBTY2Fu bmVycwojZGV2aWNlCQl1cmlvCQkjIERpYW1vbmQgUmlvIE1QMyBQbGF5ZXIK IyBVU0IgRXRoZXJuZXQsIHJlcXVpcmVzIG1paQojZGV2aWNlCQlhdWUJCSMg QURNdGVrIFVTQiBldGhlcm5ldAojZGV2aWNlCQljdWUJCSMgQ0FUQyBVU0Ig ZXRoZXJuZXQKI2RldmljZQkJa3VlCQkjIEthd2FzYWtpIExTSSBVU0IgZXRo ZXJuZXQKCmRldmljZQkJdGkJCSNUSSBHQTYyMFQgYmFzZSBHaWdhTmV0CmRl dmljZQkJcGNtCQkjU09VTkQK --0-1329753596-1015872274=:30607-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 11 11:45:24 2002 Delivered-To: freebsd-smp@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 1F8E537B404 for ; Mon, 11 Mar 2002 11:45:18 -0800 (PST) Received: from pool0355.cvx21-bradley.dialup.earthlink.net ([209.179.193.100] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16kVjP-0003cw-00; Mon, 11 Mar 2002 11:45:16 -0800 Message-ID: <3C8D093B.ED01C798@mindspring.com> Date: Mon, 11 Mar 2002 11:44:59 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Raymond Mouton Cc: freebsd-smp@freebsd.org Subject: Re: running a tyan thunder k7 dual 1.2GHZ MP's References: <20020311184434.31124.qmail@web11503.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Raymond Mouton wrote: > It runs sort of, I have the mptab output and my kernel config file > attached. > For some reason or other does a fatal page trap 12 every so often > apparently at random, does some infinite loops off ping and a few other > apps. The fatal page trap error message indicates boot() being called > on one or the other cpu no matter what app I am currently running. I am > willing to be the test rodent for you if I could get this thing stable > by the time 4.6 is released. Set DISABLE_PSE in your config, and let us know if that makes it happy for you. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 11 12:47:26 2002 Delivered-To: freebsd-smp@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id BCD6F37B417 for ; Mon, 11 Mar 2002 12:47:24 -0800 (PST) Received: from gateway.posi.net ([12.236.90.177]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020311204719.CTWU1214.rwcrmhc54.attbi.com@gateway.posi.net>; Mon, 11 Mar 2002 20:47:19 +0000 Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.11.6/8.11.6) with ESMTP id g2BKlE847147; Mon, 11 Mar 2002 12:47:18 -0800 (PST) (envelope-from kbyanc@posi.net) X-Authentication-Warning: gateway.posi.net: kbyanc owned process doing -bs Date: Mon, 11 Mar 2002 12:47:13 -0800 (PST) From: Kelly Yancey To: Ian Holsman Cc: freebsd-smp@FreeBSD.ORG Subject: Re: feature request -- atomic add/dec return the old value In-Reply-To: <3C8CD9F5.50507@holsman.net> Message-ID: <20020311122542.J47075-100000@gateway.posi.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 11 Mar 2002, Ian Holsman wrote: > hi. > I'm not sure if this is the right spot to ask, > but I'd like to see freebsd return a value on it's > add/subtract atomic functions. > > is this hard to implement? > > is there a reason not to ? > Because many platforms (including the x86) implement addition and subtraction instructions which modify the value in-place (whether in memory or in a register). To get the behaviour you desire, you can build your own routine using the existing atomic operations like so (not actually tested): static inline int atomic_readandadd_int(int *P, int V) { register int orig; register int new; do { orig = *P; new = orig + V; } while (!atomic_cmpset_int(P, orig, new); return (orig); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 11 14:21:28 2002 Delivered-To: freebsd-smp@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id DB2F137B416; Mon, 11 Mar 2002 14:21:02 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 8FFDAAE272; Mon, 11 Mar 2002 14:21:02 -0800 (PST) Date: Mon, 11 Mar 2002 14:21:02 -0800 From: Alfred Perlstein To: John Baldwin Cc: davidc@freebsd.org, smp@freebsd.org Subject: Re: select fix and giant pushdown patch Message-ID: <20020311222102.GA92565@elvis.mu.org> References: <20020311001131.GN26621@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * John Baldwin [020311 09:05] wrote: > > > Index: dev/kbd/kbd.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/dev/kbd/kbd.c,v > > retrieving revision 1.27 > > diff -u -r1.27 kbd.c > > --- dev/kbd/kbd.c 12 Sep 2001 08:37:06 -0000 1.27 > > +++ dev/kbd/kbd.c 10 Mar 2002 08:08:36 -0000 > > @@ -524,7 +524,7 @@ > > #endif > > clist_alloc_cblocks(&sc->gkb_q, KB_QSIZE, KB_QSIZE/2); /* XXX */ > > sc->gkb_rsel.si_flags = 0; > > - sc->gkb_rsel.si_pid = 0; > > + SEL_INIT(&sc->gkb_rsel); > > splx(s); > > > > return 0; > > softc's are already zero'd so you don't need this at all. ok. fixed in the other places you mentioned as well. > > > Index: kern/kern_ktrace.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/kern/kern_ktrace.c,v > > retrieving revision 1.60 > > diff -u -r1.60 kern_ktrace.c > > --- kern/kern_ktrace.c 27 Feb 2002 19:10:50 -0000 1.60 > > +++ kern/kern_ktrace.c 10 Mar 2002 08:08:36 -0000 > > @@ -181,6 +181,8 @@ > > > > if (error) > > return; > > + > > + mtx_lock(&Giant); > > /* > > * don't let p_tracep get ripped out from under us > > */ > > @@ -200,6 +202,7 @@ > > vrele(vp); > > FREE(kth, M_KTRACE); > > p->p_traceflag &= ~KTRFAC_ACTIVE; > > + mtx_unlock(&Giant); > > } > > This will probably result in lots of nice lock order reversals. That is why > I'm working on getting things like this out from under Giant rather than > bogusly pushing Giant down into them. How exactly? Every other place is covered by Giant, calling into Ktrace while holding any lock other than Giant should kill you because Ktrace may block. I wouldn't worry about it. > > Note that pushing Giant down into foo_drop routines or foo_free (we should pick > a consistent name for those btw) is probably a good idea to handle things like > fdrop() and crfree(). > > > + si = TAILQ_FIRST(&td->td_selinfo); > > + while (si != NULL) { > > + nsi = TAILQ_NEXT(si, si_thrlist); > > + si->si_thread = NULL; > > + si = nsi; > > + } > > + TAILQ_INIT(&td->td_selinfo); > > +} > > + > > +/* > > Maybe: > > while(!TAILQ_EMPTY(&td->td_selinfo) { > si = TAILQ_FIRST(...); > nsi = TAILQ_NEXT(...); > ... > } > > w/o the TAILQ_INIT(). No, actually this code needs to be fixed up. :) *slaps chad* It should be a TAILQ_FOREACH followed by a TAILQ_INIT. :) TAILQ_FOREACH(&td->td_selq, si, si_thrlist) si->si_thread = NULL; TAILQ_INIT(&td->td_selq); The idea is that you really don't need to dequeue the selinfos, just null out the thread pointer and clear the thread's list of selinfos. :) > Also, calling the field td_selinfo makes it look like you have embedded a > selinfo in the thread instead of a list of them. Maybe something like > td_silist or something that makes it clear it's a head of a list and not a > selinfo itself? Can do. > > > + mtx_lock(&sellock); > > retry: > > + > > ncoll = nselcoll; > > mtx_lock_spin(&sched_lock); > > td->td_flags |= TDF_SELECT; > > mtx_unlock_spin(&sched_lock); > > - PROC_UNLOCK(td->td_proc); > > + mtx_unlock(&sellock); > > + > > + /* XXX Is there a better place for this? */ > > + TAILQ_INIT(&td->td_selinfo); > > Yes, init it when the thread is created at fork() for now (Julian will move it > when needed). It only needs the INIT once. > > The PROC_LOCK's were oringally due to TDF_SELECT being a p_flag and can > definitely go away now that it is a td_flag. I think we need an assertion that a cv can only be used with a single mutex. > > > @@ -838,23 +864,28 @@ > > timo = ttv.tv_sec > 24 * 60 * 60 ? > > 24 * 60 * 60 * hz : tvtohz(&ttv); > > } > > + > > + /* XXX What is the point of this? */ > > mtx_lock_spin(&sched_lock); > > td->td_flags &= ~TDF_SELECT; > > mtx_unlock_spin(&sched_lock); > > You have to have the lock to make sure no one else is writing to td_flags and > to make sure you don't have a stale value while performing the update. This is Chad's XXX, what he's talking about is why do we need to clear the TDF_SELECT flag at all, not that it's done while holding sched lock (which makes sense). I think there's actually a race here, we seem to only recheck the TDF_SELECT flag if there was a timeout specified in the select call. So if there wasn't a timeout it looks like we could loose a race where an fd being waited on but we don't recheck if a selwakeup occured on it. Am I missing something? Basically, I think this code should be something like: mtx_lock_spin(&sched_lock); if ((td->td_flags & TDF_SELECT) == 0) { mtx_unlock_spin(&sched_lock); goto restart; } td->td_flags &= ~TDF_SELECT; mtx_unlock_spin(&sched_lock); ?? Why was there extra hysterics put into the timeout code? > > Thanks for fixing select() btw. I was also thinking about how to fix this as I > mentioned to you earlier. The pfind() was definitely evil. I don't like > having a global lock per-se, but I can't think of a better way to do this > myself. You can look at the linux mechanism, but there it seems to pound heavily on the schedlock by leaving multiple equivelants to "asleep" entries on the wait channels. I think Linux allows one to basically sleep on multiple addresses asyncronously. I'm not sure this is better because it requires a LOT of overhead imo. a) the filedesc lock isn't held so each file must be "fhold()'d" and a pointer to it retained in a private store. because of this, when select exits instead of just having to walk a linked list NULL'ing out a pointer, they must walk the list of objects, fput()'ing them, and removing the async sleep structures (unless that's done via linking all the async sleep objects together.:) b) each file may require an async sleep event to be queued, this can pound on schedlock (that is unless they have some magical way of avoiding that). > > > + TAILQ_REMOVE(&td->td_selinfo, sip, si_thrlist); > > + mtx_lock_spin(&sched_lock); > > + if (td->td_wchan == (caddr_t)&selwait) { > > + if (td->td_proc->p_stat == SSLEEP) > > + setrunnable(td); > > + else > > + cv_waitq_remove(td); > > + } else > > + td->td_flags &= ~TDF_SELECT; > > + mtx_unlock_spin(&sched_lock); > > This can probably be simplified now to something like this: > > mtx_lock_spin(&sched_lock); > if (td->td_proc->p_stat == SSLEEP) > setrunnable(td); > mtx_unlock_spin(&sched_lock); Huh, why? > > I would rather you commit the select stuff by itself and do the Giant > pushdown's afterwards though I might like to review just that part of the diff > once the select changes are in. Ok. I'll post two seperate diffs tonight. > > Also, the XXXKSE comment in sys/select.h about si_thread can go away now. Ok. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 11 14:40:57 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail.acns.ab.ca (mail.acns.ab.ca [142.179.151.95]) by hub.freebsd.org (Postfix) with ESMTP id 892FC37B416; Mon, 11 Mar 2002 14:40:48 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g2BMehu25385; Mon, 11 Mar 2002 15:40:43 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g2BMegC89163; Mon, 11 Mar 2002 15:40:42 -0700 (MST) (envelope-from davidc) Date: Mon, 11 Mar 2002 15:40:42 -0700 From: Chad David To: Alfred Perlstein Cc: John Baldwin , smp@FreeBSD.org Subject: Re: select fix and giant pushdown patch Message-ID: <20020311154042.A89113@colnta.acns.ab.ca> References: <20020311001131.GN26621@elvis.mu.org> <20020311222102.GA92565@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020311222102.GA92565@elvis.mu.org>; from bright@mu.org on Mon, Mar 11, 2002 at 02:21:02PM -0800 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Mar 11, 2002 at 02:21:02PM -0800, Alfred Perlstein wrote: > * John Baldwin [020311 09:05] wrote: > > > > > + si = TAILQ_FIRST(&td->td_selinfo); > > > + while (si != NULL) { > > > + nsi = TAILQ_NEXT(si, si_thrlist); > > > + si->si_thread = NULL; > > > + si = nsi; > > > + } > > > + TAILQ_INIT(&td->td_selinfo); > > > +} > > > + > > > +/* > > > > Maybe: > > > > while(!TAILQ_EMPTY(&td->td_selinfo) { > > si = TAILQ_FIRST(...); > > nsi = TAILQ_NEXT(...); > > ... > > } > > > > w/o the TAILQ_INIT(). > > No, actually this code needs to be fixed up. :) *slaps chad* > It should be a TAILQ_FOREACH followed by a TAILQ_INIT. :) man 9 queue Note: Faster TailQ Deletion. If you cannot trust the man page what can you trust ;-). > > > Also, calling the field td_selinfo makes it look like you have embedded a > > selinfo in the thread instead of a list of them. Maybe something like > > td_silist or something that makes it clear it's a head of a list and not a > > selinfo itself? > > Can do. I was waiting for Alfred to tell me to fix this but he never did, and then I forgot. > > > > > > + mtx_lock(&sellock); > > > retry: > > > + > > > ncoll = nselcoll; > > > mtx_lock_spin(&sched_lock); > > > td->td_flags |= TDF_SELECT; > > > mtx_unlock_spin(&sched_lock); > > > - PROC_UNLOCK(td->td_proc); > > > + mtx_unlock(&sellock); > > > + > > > + /* XXX Is there a better place for this? */ > > > + TAILQ_INIT(&td->td_selinfo); > > > > Yes, init it when the thread is created at fork() for now (Julian will move it > > when needed). It only needs the INIT once. > > > > The PROC_LOCK's were oringally due to TDF_SELECT being a p_flag and can > > definitely go away now that it is a td_flag. > > I think we need an assertion that a cv can only be used with a single > mutex. And that the mutex is held? > > > > > > @@ -838,23 +864,28 @@ > > > timo = ttv.tv_sec > 24 * 60 * 60 ? > > > 24 * 60 * 60 * hz : tvtohz(&ttv); > > > } > > > + > > > + /* XXX What is the point of this? */ > > > mtx_lock_spin(&sched_lock); > > > td->td_flags &= ~TDF_SELECT; > > > mtx_unlock_spin(&sched_lock); > > > > You have to have the lock to make sure no one else is writing to td_flags and > > to make sure you don't have a stale value while performing the update. > > This is Chad's XXX, what he's talking about is why do we need to clear > the TDF_SELECT flag at all, not that it's done while holding sched lock > (which makes sense). > > I think there's actually a race here, we seem to only recheck the > TDF_SELECT flag if there was a timeout specified in the select call. > So if there wasn't a timeout it looks like we could loose a race > where an fd being waited on but we don't recheck if a selwakeup occured > on it. Am I missing something? Basically, I think this code should be > something like: > > mtx_lock_spin(&sched_lock); > if ((td->td_flags & TDF_SELECT) == 0) { > mtx_unlock_spin(&sched_lock); > goto restart; > } > td->td_flags &= ~TDF_SELECT; > mtx_unlock_spin(&sched_lock); I think you also need to check nselcoll. > > ?? > > Why was there extra hysterics put into the timeout code? > -- Chad David davidc@acns.ab.ca www.FreeBSD.org davidc@freebsd.org ACNS Inc. Calgary, Alberta Canada Fourthly, The constant breeders, beside the gain of eight shillings sterling per annum by the sale of their children, will be rid of the charge of maintaining them after the first year. - Johnathan Swift To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 11 14:44:10 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id E34F537B435 for ; Mon, 11 Mar 2002 14:43:47 -0800 (PST) Received: (qmail 12671 invoked from network); 11 Mar 2002 22:43:47 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 11 Mar 2002 22:43:47 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g2BMi3v23746; Mon, 11 Mar 2002 17:44:04 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020311222102.GA92565@elvis.mu.org> Date: Mon, 11 Mar 2002 17:43:41 -0500 (EST) From: John Baldwin To: Alfred Perlstein Subject: Re: select fix and giant pushdown patch Cc: smp@freebsd.org, davidc@freebsd.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 11-Mar-2002 Alfred Perlstein wrote: >> Note that pushing Giant down into foo_drop routines or foo_free (we should >> pick >> a consistent name for those btw) is probably a good idea to handle things >> like >> fdrop() and crfree(). >> >> > + si = TAILQ_FIRST(&td->td_selinfo); >> > + while (si != NULL) { >> > + nsi = TAILQ_NEXT(si, si_thrlist); >> > + si->si_thread = NULL; >> > + si = nsi; >> > + } >> > + TAILQ_INIT(&td->td_selinfo); >> > +} >> > + >> > +/* >> >> Maybe: >> >> while(!TAILQ_EMPTY(&td->td_selinfo) { >> si = TAILQ_FIRST(...); >> nsi = TAILQ_NEXT(...); >> ... >> } >> >> w/o the TAILQ_INIT(). > > No, actually this code needs to be fixed up. :) *slaps chad* > It should be a TAILQ_FOREACH followed by a TAILQ_INIT. :) > > TAILQ_FOREACH(&td->td_selq, si, si_thrlist) > si->si_thread = NULL; > TAILQ_INIT(&td->td_selq); > > The idea is that you really don't need to dequeue the selinfos, just > null out the thread pointer and clear the thread's list of selinfos. > >:) Ah, sure. Looks good then. >> > @@ -838,23 +864,28 @@ >> > timo = ttv.tv_sec > 24 * 60 * 60 ? >> > 24 * 60 * 60 * hz : tvtohz(&ttv); >> > } >> > + >> > + /* XXX What is the point of this? */ >> > mtx_lock_spin(&sched_lock); >> > td->td_flags &= ~TDF_SELECT; >> > mtx_unlock_spin(&sched_lock); >> >> You have to have the lock to make sure no one else is writing to td_flags >> and >> to make sure you don't have a stale value while performing the update. > > This is Chad's XXX, what he's talking about is why do we need to clear > the TDF_SELECT flag at all, not that it's done while holding sched lock > (which makes sense). In case we didn't block we don't want to leave TDF_SELECT set? I.e. if during the original scan one of the fd's said it was ready. > I think there's actually a race here, we seem to only recheck the > TDF_SELECT flag if there was a timeout specified in the select call. > So if there wasn't a timeout it looks like we could loose a race > where an fd being waited on but we don't recheck if a selwakeup occured > on it. Am I missing something? Basically, I think this code should be > something like: > > mtx_lock_spin(&sched_lock); > if ((td->td_flags & TDF_SELECT) == 0) { > mtx_unlock_spin(&sched_lock); > goto restart; > } > td->td_flags &= ~TDF_SELECT; > mtx_unlock_spin(&sched_lock); > > ?? This is an old race so I'm not sure we need to worry about it. If we don't mark the fd as ready now and we are returning, then we will mark it the next time the user calls select. We just need to not be blocked while there is data ready or a writer ready. > Why was there extra hysterics put into the timeout code? Not sure a) why or b) what exactly you are talking about. >> > + TAILQ_REMOVE(&td->td_selinfo, sip, si_thrlist); >> > + mtx_lock_spin(&sched_lock); >> > + if (td->td_wchan == (caddr_t)&selwait) { >> > + if (td->td_proc->p_stat == SSLEEP) >> > + setrunnable(td); >> > + else >> > + cv_waitq_remove(td); >> > + } else >> > + td->td_flags &= ~TDF_SELECT; >> > + mtx_unlock_spin(&sched_lock); >> >> This can probably be simplified now to something like this: >> >> mtx_lock_spin(&sched_lock); >> if (td->td_proc->p_stat == SSLEEP) >> setrunnable(td); >> mtx_unlock_spin(&sched_lock); > > Huh, why? Because we don't have stale selinfo references to threads now that we clear them all when we exit. The td_wchan compare was to handle the stale references. I don't think we can now be on the cv waitq and be runnable now at the same time anymore either. >> I would rather you commit the select stuff by itself and do the Giant >> pushdown's afterwards though I might like to review just that part of the >> diff >> once the select changes are in. > > Ok. I'll post two seperate diffs tonight. Thanks! -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 11 15:29: 7 2002 Delivered-To: freebsd-smp@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id D247437B405; Mon, 11 Mar 2002 15:29:03 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 8F39FAE1FE; Mon, 11 Mar 2002 15:29:03 -0800 (PST) Date: Mon, 11 Mar 2002 15:29:03 -0800 From: Alfred Perlstein To: Chad David Cc: John Baldwin , smp@FreeBSD.org Subject: Re: select fix and giant pushdown patch Message-ID: <20020311232903.GB92565@elvis.mu.org> References: <20020311001131.GN26621@elvis.mu.org> <20020311222102.GA92565@elvis.mu.org> <20020311154042.A89113@colnta.acns.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020311154042.A89113@colnta.acns.ab.ca> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Chad David [020311 14:40] wrote: > On Mon, Mar 11, 2002 at 02:21:02PM -0800, Alfred Perlstein wrote: > > > > No, actually this code needs to be fixed up. :) *slaps chad* > > It should be a TAILQ_FOREACH followed by a TAILQ_INIT. :) > > man 9 queue > Note: Faster TailQ Deletion. If you cannot trust the man page what > can you trust ;-). That only applies when removing the nodes from the list. :) UTSL sys/queue.h to see what TAILQ_FOREACH expands to. :) > > > Also, calling the field td_selinfo makes it look like you have embedded a > > > selinfo in the thread instead of a list of them. Maybe something like > > > td_silist or something that makes it clear it's a head of a list and not a > > > selinfo itself? > > > > Can do. > > I was waiting for Alfred to tell me to fix this but he never did, and then > I forgot. I've got it, it's td_selq. > > I think we need an assertion that a cv can only be used with a single > > mutex. > > And that the mutex is held? Yes. :) John is all about infrastructure, and we need such assertions in the code. :) > > This is Chad's XXX, what he's talking about is why do we need to clear > > the TDF_SELECT flag at all, not that it's done while holding sched lock > > (which makes sense). > > > > I think there's actually a race here, we seem to only recheck the > > TDF_SELECT flag if there was a timeout specified in the select call. > > So if there wasn't a timeout it looks like we could loose a race > > where an fd being waited on but we don't recheck if a selwakeup occured > > on it. Am I missing something? Basically, I think this code should be > > something like: > > > > mtx_lock_spin(&sched_lock); > > if ((td->td_flags & TDF_SELECT) == 0) { > > mtx_unlock_spin(&sched_lock); > > goto restart; > > } > > td->td_flags &= ~TDF_SELECT; > > mtx_unlock_spin(&sched_lock); > > I think you also need to check nselcoll. Good call. Are you sure about this? It's just odd that there's so much hysterics when a timeout is involved... should we just nuke that code and add the 'goto restart' here if the flag is unset OR we've had more collisions? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 11 15:37:34 2002 Delivered-To: freebsd-smp@freebsd.org Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by hub.freebsd.org (Postfix) with ESMTP id 4556337B402; Mon, 11 Mar 2002 15:37:30 -0800 (PST) Received: (from jake@localhost) by k6.locore.ca (8.11.6/8.11.6) id g2BNh0F38647; Mon, 11 Mar 2002 18:43:00 -0500 (EST) (envelope-from jake) Date: Mon, 11 Mar 2002 18:42:59 -0500 From: Jake Burkholder To: Alfred Perlstein Cc: Chad David , John Baldwin , smp@FreeBSD.ORG Subject: Re: select fix and giant pushdown patch Message-ID: <20020311184259.J20687@locore.ca> References: <20020311001131.GN26621@elvis.mu.org> <20020311222102.GA92565@elvis.mu.org> <20020311154042.A89113@colnta.acns.ab.ca> <20020311232903.GB92565@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020311232903.GB92565@elvis.mu.org>; from bright@mu.org on Mon, Mar 11, 2002 at 03:29:03PM -0800 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Apparently, On Mon, Mar 11, 2002 at 03:29:03PM -0800, Alfred Perlstein said words to the effect of; > > > I think we need an assertion that a cv can only be used with a single > > > mutex. > > > > And that the mutex is held? > > Yes. :) John is all about infrastructure, and we need such assertions > in the code. :) > If you actually look at the CV code, Jason added code which does this but its not normally enabled. Its under a CV_DEBUG option which should probably be turned on if INVARIANTS is set. Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 11 15:41: 1 2002 Delivered-To: freebsd-smp@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 190E837B43E; Mon, 11 Mar 2002 15:40:11 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id DB40EAE1D0; Mon, 11 Mar 2002 15:40:10 -0800 (PST) Date: Mon, 11 Mar 2002 15:40:10 -0800 From: Alfred Perlstein To: Jake Burkholder Cc: Chad David , John Baldwin , smp@FreeBSD.ORG Subject: Re: select fix and giant pushdown patch Message-ID: <20020311234010.GC92565@elvis.mu.org> References: <20020311001131.GN26621@elvis.mu.org> <20020311222102.GA92565@elvis.mu.org> <20020311154042.A89113@colnta.acns.ab.ca> <20020311232903.GB92565@elvis.mu.org> <20020311184259.J20687@locore.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020311184259.J20687@locore.ca> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Jake Burkholder [020311 15:37] wrote: > Apparently, On Mon, Mar 11, 2002 at 03:29:03PM -0800, > Alfred Perlstein said words to the effect of; > > > > > I think we need an assertion that a cv can only be used with a single > > > > mutex. > > > > > > And that the mutex is held? > > > > Yes. :) John is all about infrastructure, and we need such assertions > > in the code. :) > > > > If you actually look at the CV code, Jason added code which does this > but its not normally enabled. Its under a CV_DEBUG option which should > probably be turned on if INVARIANTS is set. Well don't do it until my patch is committed if you want a bootable system :) -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 11 15:48:52 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail.acns.ab.ca (mail.acns.ab.ca [142.179.151.95]) by hub.freebsd.org (Postfix) with ESMTP id 8F2C037B405; Mon, 11 Mar 2002 15:48:46 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g2BNmeu25683; Mon, 11 Mar 2002 16:48:40 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g2BNmeI89310; Mon, 11 Mar 2002 16:48:40 -0700 (MST) (envelope-from davidc) Date: Mon, 11 Mar 2002 16:48:40 -0700 From: Chad David To: Alfred Perlstein Cc: John Baldwin , smp@FreeBSD.org Subject: Re: select fix and giant pushdown patch Message-ID: <20020311164840.A89277@colnta.acns.ab.ca> References: <20020311001131.GN26621@elvis.mu.org> <20020311222102.GA92565@elvis.mu.org> <20020311154042.A89113@colnta.acns.ab.ca> <20020311232903.GB92565@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020311232903.GB92565@elvis.mu.org>; from bright@mu.org on Mon, Mar 11, 2002 at 03:29:03PM -0800 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Mar 11, 2002 at 03:29:03PM -0800, Alfred Perlstein wrote: > * Chad David [020311 14:40] wrote: > > On Mon, Mar 11, 2002 at 02:21:02PM -0800, Alfred Perlstein wrote: > > > > > > No, actually this code needs to be fixed up. :) *slaps chad* > > > It should be a TAILQ_FOREACH followed by a TAILQ_INIT. :) > > > > man 9 queue > > Note: Faster TailQ Deletion. If you cannot trust the man page what > > can you trust ;-). > > That only applies when removing the nodes from the list. :) > UTSL sys/queue.h to see what TAILQ_FOREACH expands to. :) I know, I know. I wrote some of this at 4am, and I'm still feeling stupid about all of the other dump things I did, so don't rub it in :(. > > > > This is Chad's XXX, what he's talking about is why do we need to clear > > > the TDF_SELECT flag at all, not that it's done while holding sched lock > > > (which makes sense). > > > > > > I think there's actually a race here, we seem to only recheck the > > > TDF_SELECT flag if there was a timeout specified in the select call. > > > So if there wasn't a timeout it looks like we could loose a race > > > where an fd being waited on but we don't recheck if a selwakeup occured > > > on it. Am I missing something? Basically, I think this code should be > > > something like: > > > > > > mtx_lock_spin(&sched_lock); > > > if ((td->td_flags & TDF_SELECT) == 0) { > > > mtx_unlock_spin(&sched_lock); > > > goto restart; > > > } > > > td->td_flags &= ~TDF_SELECT; > > > mtx_unlock_spin(&sched_lock); > > > > I think you also need to check nselcoll. > > Good call. Are you sure about this? It's just odd that there's so > much hysterics when a timeout is involved... should we just nuke > that code and add the 'goto restart' here if the flag is unset OR > we've had more collisions? I think you need the extra call to selscan() in the timedout case so that you will return with the most up to date bits set. You could put a check right after we lock sellock and remove the timeout check, but if we are timedout you probably do not want to loop there, but instead just update the bits and return? I would remove the td->td_flags &= ~TDF_SELECT part all together after the timeout check as is gets cleared right after done: anyway. -- Chad David davidc@acns.ab.ca www.FreeBSD.org davidc@freebsd.org ACNS Inc. Calgary, Alberta Canada Fourthly, The constant breeders, beside the gain of eight shillings sterling per annum by the sale of their children, will be rid of the charge of maintaining them after the first year. - Johnathan Swift To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 11 22:14:12 2002 Delivered-To: freebsd-smp@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id E7FE137B400; Mon, 11 Mar 2002 22:13:51 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 86E07AE22C; Mon, 11 Mar 2002 22:13:51 -0800 (PST) Date: Mon, 11 Mar 2002 22:13:51 -0800 From: Alfred Perlstein To: smp@freebsd.org Cc: jhb@FreeBSD.org, davidc@freebsd.org, jake@locore.ca Subject: select fix take II. Message-ID: <20020312061351.GF92565@elvis.mu.org> References: <20020311001131.GN26621@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020311001131.GN26621@elvis.mu.org> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Alfred Perlstein [020310 16:12] wrote: > Chad David and I have been working on fixing select(2) and poll(2)'s > locking. I've been working on pushing pipe read/write ops down > out from under Giant. Ok, after further investigation revision 1.79 of sys_generic.c seems to have been wrong. I had to pretty much lay the 4.x version of sys_generic.c next to the 5.x one to get this right. If you review the patch after it's applied the code is a LOT cleaner and makes a hell of a lot more sense now. The XXX near the TDF_SELECT check is gone because it's obvious what it's for. So do we brave this delta for the developer preview? :) Index: dev/bktr/bktr_core.c =================================================================== RCS file: /home/ncvs/src/sys/dev/bktr/bktr_core.c,v retrieving revision 1.117 diff -u -r1.117 bktr_core.c --- dev/bktr/bktr_core.c 12 Sep 2001 08:37:02 -0000 1.117 +++ dev/bktr/bktr_core.c 11 Mar 2002 02:44:14 -0000 @@ -809,7 +809,7 @@ } /* If someone has a select() on /dev/vbi, inform them */ - if (bktr->vbi_select.si_pid) { + if (SEL_WAITING(&bktr->vbi_select)) { selwakeup(&bktr->vbi_select); } Index: dev/kbd/kbd.c =================================================================== RCS file: /home/ncvs/src/sys/dev/kbd/kbd.c,v retrieving revision 1.27 diff -u -r1.27 kbd.c --- dev/kbd/kbd.c 12 Sep 2001 08:37:06 -0000 1.27 +++ dev/kbd/kbd.c 11 Mar 2002 22:08:08 -0000 @@ -523,8 +523,6 @@ bzero(&sc->gkb_q, sizeof(sc->gkb_q)); #endif clist_alloc_cblocks(&sc->gkb_q, KB_QSIZE, KB_QSIZE/2); /* XXX */ - sc->gkb_rsel.si_flags = 0; - sc->gkb_rsel.si_pid = 0; splx(s); return 0; Index: dev/snp/snp.c =================================================================== RCS file: /home/ncvs/src/sys/dev/snp/snp.c,v retrieving revision 1.69 diff -u -r1.69 snp.c --- dev/snp/snp.c 24 Nov 2001 15:59:46 -0000 1.69 +++ dev/snp/snp.c 11 Mar 2002 02:44:14 -0000 @@ -373,7 +373,6 @@ wakeup((caddr_t)snp); } selwakeup(&snp->snp_sel); - snp->snp_sel.si_pid = 0; return (n); } @@ -447,7 +446,6 @@ detach_notty: selwakeup(&snp->snp_sel); - snp->snp_sel.si_pid = 0; if ((snp->snp_flags & SNOOP_OPEN) == 0) free(snp, M_SNP); Index: dev/sound/pcm/channel.c =================================================================== RCS file: /home/ncvs/src/sys/dev/sound/pcm/channel.c,v retrieving revision 1.81 diff -u -r1.81 channel.c --- dev/sound/pcm/channel.c 24 Feb 2002 00:49:43 -0000 1.81 +++ dev/sound/pcm/channel.c 11 Mar 2002 02:44:14 -0000 @@ -116,7 +116,7 @@ struct snd_dbuf *bs = c->bufsoft; CHN_LOCKASSERT(c); - if (sndbuf_getsel(bs)->si_pid && chn_polltrigger(c)) + if (SEL_WAITING(sndbuf_getsel(bs)) && chn_polltrigger(c)) selwakeup(sndbuf_getsel(bs)); wakeup(bs); } Index: dev/usb/ums.c =================================================================== RCS file: /home/ncvs/src/sys/dev/usb/ums.c,v retrieving revision 1.48 diff -u -r1.48 ums.c --- dev/usb/ums.c 15 Feb 2002 22:54:10 -0000 1.48 +++ dev/usb/ums.c 11 Mar 2002 22:38:21 -0000 @@ -344,8 +344,10 @@ sc->status.button = sc->status.obutton = 0; sc->status.dx = sc->status.dy = sc->status.dz = 0; +#ifndef __FreeBSD__ sc->rsel.si_flags = 0; sc->rsel.si_pid = 0; +#endif sc->dev = make_dev(&ums_cdevsw, device_get_unit(self), UID_ROOT, GID_OPERATOR, Index: isa/psm.c =================================================================== RCS file: /home/ncvs/src/sys/isa/psm.c,v retrieving revision 1.43 diff -u -r1.43 psm.c --- isa/psm.c 19 Dec 2001 13:32:21 -0000 1.43 +++ isa/psm.c 11 Mar 2002 22:08:51 -0000 @@ -1314,8 +1314,6 @@ device_busy(devclass_get_device(psm_devclass, unit)); /* Initialize state */ - sc->rsel.si_flags = 0; - sc->rsel.si_pid = 0; sc->mode.level = sc->dflt_mode.level; sc->mode.protocol = sc->dflt_mode.protocol; sc->watchdog = FALSE; Index: kern/sys_generic.c =================================================================== RCS file: /home/ncvs/src/sys/kern/sys_generic.c,v retrieving revision 1.92 diff -u -r1.92 sys_generic.c --- kern/sys_generic.c 9 Mar 2002 22:44:37 -0000 1.92 +++ kern/sys_generic.c 12 Mar 2002 05:46:13 -0000 @@ -80,6 +80,7 @@ size_t, off_t, int); static int dofilewrite(struct thread *, struct file *, int, const void *, size_t, off_t, int); +static void clear_selinfo_list(struct thread *); /* * Read system call. @@ -696,11 +697,36 @@ return (error); } +/* + * These are initialized in selectinit() via SYSINIT + */ +static struct mtx sellock; +static struct cv selwait; static int nselcoll; /* Select collisions since boot */ -struct cv selwait; SYSCTL_INT(_kern, OID_AUTO, nselcoll, CTLFLAG_RD, &nselcoll, 0, ""); /* + * Remove the references to the thread from all of the objects + * we were polling. + * + * This code assumes that the underlying owner of the selinfo + * structure will hold sellock before it changes it, and that + * it will unlink itself from our list if it goes away. + */ +static void +clear_selinfo_list(td) + struct thread *td; +{ + struct selinfo *si; + + mtx_assert(&sellock, MA_OWNED); + + TAILQ_FOREACH(si, &td->td_selq, si_thrlist) + si->si_thread = NULL; + TAILQ_INIT(&td->td_selq); +} + +/* * Select system call. */ #ifndef _SYS_SYSPROTO_H_ @@ -775,7 +801,7 @@ sbp += ncpbytes / sizeof *sbp; \ error = copyin(uap->name, ibits[x], ncpbytes); \ if (error != 0) \ - goto done_noproclock; \ + goto done_nosellock; \ } \ } while (0) getbits(in, 0); @@ -789,10 +815,10 @@ error = copyin((caddr_t)uap->tv, (caddr_t)&atv, sizeof (atv)); if (error) - goto done_noproclock; + goto done_nosellock; if (itimerfix(&atv)) { error = EINVAL; - goto done_noproclock; + goto done_nosellock; } getmicrouptime(&rtv); timevaladd(&atv, &rtv); @@ -801,61 +827,62 @@ atv.tv_usec = 0; } timo = 0; - PROC_LOCK(td->td_proc); + mtx_lock(&sellock); retry: + ncoll = nselcoll; mtx_lock_spin(&sched_lock); td->td_flags |= TDF_SELECT; mtx_unlock_spin(&sched_lock); - PROC_UNLOCK(td->td_proc); + mtx_unlock(&sellock); + + /* XXX Is there a better place for this? */ + TAILQ_INIT(&td->td_selq); error = selscan(td, ibits, obits, uap->nd); - PROC_LOCK(td->td_proc); + mtx_lock(&sellock); if (error || td->td_retval[0]) goto done; if (atv.tv_sec || atv.tv_usec) { getmicrouptime(&rtv); - if (timevalcmp(&rtv, &atv, >=)) { - /* - * An event of our interest may occur during locking a process. - * In order to avoid missing the event that occured during locking - * the process, test TDF_SELECT and rescan file descriptors if - * necessary. - */ - mtx_lock_spin(&sched_lock); - if ((td->td_flags & TDF_SELECT) == 0 || nselcoll != ncoll) { - ncoll = nselcoll; - td->td_flags |= TDF_SELECT; - mtx_unlock_spin(&sched_lock); - PROC_UNLOCK(td->td_proc); - error = selscan(td, ibits, obits, uap->nd); - PROC_LOCK(td->td_proc); - } else - mtx_unlock_spin(&sched_lock); + if (timevalcmp(&rtv, &atv, >=)) goto done; - } ttv = atv; timevalsub(&ttv, &rtv); timo = ttv.tv_sec > 24 * 60 * 60 ? 24 * 60 * 60 * hz : tvtohz(&ttv); } + + /* + * An event of interest may occur while we do not hold + * sellock, so check TDF_SELECT and the number of + * collisions and rescan the file descriptors if + * necessary. + */ mtx_lock_spin(&sched_lock); + if ((td->td_flags & TDF_SELECT) == 0 || nselcoll != ncoll) { + mtx_unlock_spin(&sched_lock); + goto retry; + } td->td_flags &= ~TDF_SELECT; mtx_unlock_spin(&sched_lock); if (timo > 0) - error = cv_timedwait_sig(&selwait, &td->td_proc->p_mtx, timo); + error = cv_timedwait_sig(&selwait, &sellock, timo); else - error = cv_wait_sig(&selwait, &td->td_proc->p_mtx); + error = cv_wait_sig(&selwait, &sellock); if (error == 0) goto retry; done: + clear_selinfo_list(td); + mtx_lock_spin(&sched_lock); td->td_flags &= ~TDF_SELECT; mtx_unlock_spin(&sched_lock); - PROC_UNLOCK(td->td_proc); -done_noproclock: + mtx_unlock(&sellock); + +done_nosellock: /* select is not restarted after signals... */ if (error == ERESTART) error = EINTR; @@ -967,13 +994,13 @@ bits = smallbits; error = copyin(SCARG(uap, fds), bits, ni); if (error) - goto done_noproclock; + goto done_nosellock; if (SCARG(uap, timeout) != INFTIM) { atv.tv_sec = SCARG(uap, timeout) / 1000; atv.tv_usec = (SCARG(uap, timeout) % 1000) * 1000; if (itimerfix(&atv)) { error = EINVAL; - goto done_noproclock; + goto done_nosellock; } getmicrouptime(&rtv); timevaladd(&atv, &rtv); @@ -982,59 +1009,59 @@ atv.tv_usec = 0; } timo = 0; - PROC_LOCK(td->td_proc); + mtx_lock(&sellock); retry: ncoll = nselcoll; mtx_lock_spin(&sched_lock); td->td_flags |= TDF_SELECT; mtx_unlock_spin(&sched_lock); - PROC_UNLOCK(td->td_proc); + mtx_unlock(&sellock); + + /* XXX Is there a better place for this? */ + TAILQ_INIT(&td->td_selq); error = pollscan(td, (struct pollfd *)bits, nfds); - PROC_LOCK(td->td_proc); + mtx_lock(&sellock); if (error || td->td_retval[0]) goto done; if (atv.tv_sec || atv.tv_usec) { getmicrouptime(&rtv); - if (timevalcmp(&rtv, &atv, >=)) { - /* - * An event of our interest may occur during locking a process. - * In order to avoid missing the event that occured during locking - * the process, test TDF_SELECT and rescan file descriptors if - * necessary. - */ - mtx_lock_spin(&sched_lock); - if ((td->td_flags & TDF_SELECT) == 0 || nselcoll != ncoll) { - ncoll = nselcoll; - td->td_flags |= TDF_SELECT; - mtx_unlock_spin(&sched_lock); - PROC_UNLOCK(td->td_proc); - error = pollscan(td, (struct pollfd *)bits, nfds); - PROC_LOCK(td->td_proc); - } else - mtx_unlock_spin(&sched_lock); + if (timevalcmp(&rtv, &atv, >=)) goto done; - } ttv = atv; timevalsub(&ttv, &rtv); timo = ttv.tv_sec > 24 * 60 * 60 ? 24 * 60 * 60 * hz : tvtohz(&ttv); } + /* + * An event of interest may occur while we do not hold + * sellock, so check TDF_SELECT and the number of collisions + * and rescan the file descriptors if necessary. + */ mtx_lock_spin(&sched_lock); + if ((td->td_flags & TDF_SELECT) == 0 || nselcoll != ncoll) { + mtx_unlock_spin(&sched_lock); + goto retry; + } td->td_flags &= ~TDF_SELECT; mtx_unlock_spin(&sched_lock); + if (timo > 0) - error = cv_timedwait_sig(&selwait, &td->td_proc->p_mtx, timo); + error = cv_timedwait_sig(&selwait, &sellock, timo); else - error = cv_wait_sig(&selwait, &td->td_proc->p_mtx); + error = cv_wait_sig(&selwait, &sellock); + if (error == 0) goto retry; done: + clear_selinfo_list(td); + mtx_lock_spin(&sched_lock); td->td_flags &= ~TDF_SELECT; mtx_unlock_spin(&sched_lock); - PROC_UNLOCK(td->td_proc); -done_noproclock: + mtx_unlock(&sellock); + +done_nosellock: /* poll is not restarted after signals... */ if (error == ERESTART) error = EINTR; @@ -1126,18 +1153,6 @@ return (events & (POLLIN | POLLOUT | POLLRDNORM | POLLWRNORM)); } -static int -find_thread_in_proc(struct proc *p, struct thread *td) -{ - struct thread *td2; - FOREACH_THREAD_IN_PROC(p, td2) { - if (td2 == td) { - return (1); - } - } - return (0); -} - /* * Record a select request. */ @@ -1146,29 +1161,21 @@ struct thread *selector; struct selinfo *sip; { - struct proc *p; - pid_t mypid; - mypid = selector->td_proc->p_pid; - if ((sip->si_pid == mypid) && - (sip->si_thread == selector)) { /* XXXKSE should be an ID? */ - return; - } - if (sip->si_pid && - (p = pfind(sip->si_pid)) && - (find_thread_in_proc(p, sip->si_thread))) { - mtx_lock_spin(&sched_lock); - if (sip->si_thread->td_wchan == (caddr_t)&selwait) { - mtx_unlock_spin(&sched_lock); - PROC_UNLOCK(p); - sip->si_flags |= SI_COLL; - return; - } - mtx_unlock_spin(&sched_lock); - PROC_UNLOCK(p); + mtx_lock(&sellock); + /* + * If the thread is not NULL there is another thread + * interested in this object, and we need to flag the + * collision so selwakeup() can broadcast. + */ + if (sip->si_thread != NULL) { + sip->si_flags |= SI_COLL; + } else { + sip->si_thread = selector; + TAILQ_INSERT_TAIL(&selector->td_selq, sip, si_thrlist); } - sip->si_pid = mypid; - sip->si_thread = selector; + + mtx_unlock(&sellock); } /* @@ -1176,37 +1183,37 @@ */ void selwakeup(sip) - register struct selinfo *sip; + struct selinfo *sip; { struct thread *td; - register struct proc *p; - if (sip->si_pid == 0) - return; - if (sip->si_flags & SI_COLL) { + mtx_lock(&sellock); + td = sip->si_thread; + + if ((sip->si_flags & SI_COLL) != 0) { nselcoll++; sip->si_flags &= ~SI_COLL; cv_broadcast(&selwait); } - p = pfind(sip->si_pid); - sip->si_pid = 0; - td = sip->si_thread; - if (p != NULL) { - if (!find_thread_in_proc(p, td)) { - PROC_UNLOCK(p); /* lock is in pfind() */; - return; - } - mtx_lock_spin(&sched_lock); - if (td->td_wchan == (caddr_t)&selwait) { - if (td->td_proc->p_stat == SSLEEP) - setrunnable(td); - else - cv_waitq_remove(td); - } else - td->td_flags &= ~TDF_SELECT; - mtx_unlock_spin(&sched_lock); - PROC_UNLOCK(p); /* Lock is in pfind() */ + + if (td == NULL) { + mtx_unlock(&sellock); + return; } + + TAILQ_REMOVE(&td->td_selq, sip, si_thrlist); + mtx_lock_spin(&sched_lock); + if (td->td_wchan == (caddr_t)&selwait) { + if (td->td_proc->p_stat == SSLEEP) + setrunnable(td); + else + cv_waitq_remove(td); + } else + td->td_flags &= ~TDF_SELECT; + mtx_unlock_spin(&sched_lock); + + sip->si_thread = NULL; + mtx_unlock(&sellock); } static void selectinit __P((void *)); @@ -1218,4 +1225,5 @@ void *dummy; { cv_init(&selwait, "select"); + mtx_init(&sellock, "sellck", MTX_DEF); } Index: kern/tty.c =================================================================== RCS file: /home/ncvs/src/sys/kern/tty.c,v retrieving revision 1.165 diff -u -r1.165 tty.c --- kern/tty.c 2 Mar 2002 12:42:23 -0000 1.165 +++ kern/tty.c 11 Mar 2002 02:44:14 -0000 @@ -2273,7 +2273,7 @@ register struct tty *tp; { - if (tp->t_rsel.si_pid != 0) + if (SEL_WAITING(&tp->t_rsel)) selwakeup(&tp->t_rsel); if (ISSET(tp->t_state, TS_ASYNC) && tp->t_sigio != NULL) pgsigio(tp->t_sigio, SIGIO, (tp->t_session != NULL)); @@ -2289,7 +2289,7 @@ register struct tty *tp; { - if (tp->t_wsel.si_pid != 0 && tp->t_outq.c_cc <= tp->t_olowat) + if (SEL_WAITING(&tp->t_wsel) && tp->t_outq.c_cc <= tp->t_olowat) selwakeup(&tp->t_wsel); if (ISSET(tp->t_state, TS_ASYNC) && tp->t_sigio != NULL) pgsigio(tp->t_sigio, SIGIO, (tp->t_session != NULL)); Index: net/bpf.c =================================================================== RCS file: /home/ncvs/src/sys/net/bpf.c,v retrieving revision 1.86 diff -u -r1.86 bpf.c --- net/bpf.c 14 Dec 2001 22:17:54 -0000 1.86 +++ net/bpf.c 11 Mar 2002 02:44:14 -0000 @@ -514,8 +514,6 @@ pgsigio(d->bd_sigio, d->bd_sig, 0); selwakeup(&d->bd_sel); - /* XXX */ - d->bd_sel.si_pid = 0; } static void Index: sys/proc.h =================================================================== RCS file: /home/ncvs/src/sys/sys/proc.h,v retrieving revision 1.206 diff -u -r1.206 proc.h --- sys/proc.h 23 Feb 2002 11:12:57 -0000 1.206 +++ sys/proc.h 11 Mar 2002 22:20:23 -0000 @@ -147,6 +147,7 @@ * m - Giant * n - not locked, lazy * o - locked by pgrpsess_lock sx + * p - select lock (sellock) * * If the locking key specifies two identifiers (for example, p_pptr) then * either lock is sufficient for read access, but both locks must be held @@ -259,6 +260,8 @@ TAILQ_ENTRY(thread) td_slpq; /* (j) Sleep queue. XXXKSE */ TAILQ_ENTRY(thread) td_blkq; /* (j) Mutex queue. XXXKSE */ TAILQ_ENTRY(thread) td_runq; /* (j) Run queue(s). XXXKSE */ + + TAILQ_HEAD(, selinfo) td_selq; /* (p) List of selinfos */ #define td_startzero td_flags int td_flags; /* (j) TDF_* flags. */ Index: sys/selinfo.h =================================================================== RCS file: /home/ncvs/src/sys/sys/selinfo.h,v retrieving revision 1.12 diff -u -r1.12 selinfo.h --- sys/selinfo.h 27 Sep 2001 20:33:15 -0000 1.12 +++ sys/selinfo.h 11 Mar 2002 22:27:05 -0000 @@ -45,12 +45,21 @@ * notified when I/O becomes possible. */ struct selinfo { - pid_t si_pid; /* process to be notified */ - struct thread *si_thread; /* thread in that process XXXKSE */ + TAILQ_ENTRY(selinfo) si_thrlist; /* list hung off of thread */ + struct thread *si_thread; /* thread waiting */ struct klist si_note; /* kernel note list */ short si_flags; /* see below */ }; #define SI_COLL 0x0001 /* collision occurred */ + +#define SEL_WAITING(si) \ + ((si)->si_thread != NULL || ((si)->si_flags & SI_COLL) != 0) + +#define SEL_INIT(si) \ + do { \ + (si)->si_thread = NULL; \ + (si)->si_flags = 0; \ + } while (0) #ifdef _KERNEL struct thread; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Mar 12 4:20: 5 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id DA3A937B400; Tue, 12 Mar 2002 04:19:55 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id XAA23413; Tue, 12 Mar 2002 23:19:52 +1100 Date: Tue, 12 Mar 2002 23:21:13 +1100 (EST) From: Bruce Evans X-X-Sender: To: John Baldwin Cc: Alfred Perlstein , , Subject: RE: select fix and giant pushdown patch In-Reply-To: Message-ID: <20020312231256.V11516-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 11 Mar 2002, John Baldwin wrote: > On 11-Mar-02 Alfred Perlstein wrote: > > Index: dev/kbd/kbd.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/dev/kbd/kbd.c,v > > retrieving revision 1.27 > > diff -u -r1.27 kbd.c > > --- dev/kbd/kbd.c 12 Sep 2001 08:37:06 -0000 1.27 > > +++ dev/kbd/kbd.c 10 Mar 2002 08:08:36 -0000 > > @@ -524,7 +524,7 @@ > > #endif > > clist_alloc_cblocks(&sc->gkb_q, KB_QSIZE, KB_QSIZE/2); /* XXX */ > > sc->gkb_rsel.si_flags = 0; > > - sc->gkb_rsel.si_pid = 0; > > + SEL_INIT(&sc->gkb_rsel); > > splx(s); > > > > return 0; > > softc's are already zero'd so you don't need this at all. SEL_INIT() might be magic though. In practice, it only initializes to 0 and NULL, so it is only needed if the memory is already zero'd on machines where NULL is not all zeros. I dislike macros that do trivial initializations anyway. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Mar 14 9:15:29 2002 Delivered-To: freebsd-smp@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 5CFD037B400 for ; Thu, 14 Mar 2002 09:15:23 -0800 (PST) Received: from localhost (arr@localhost) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g2EHFL897960 for ; Thu, 14 Mar 2002 12:15:21 -0500 (EST) (envelope-from arr@FreeBSD.org) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Thu, 14 Mar 2002 12:15:21 -0500 (EST) From: "Andrew R. Reiter" X-Sender: arr@fledge.watson.org To: freebsd-smp@FreeBSD.org Subject: Patch to lock down modules Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all, I'd like to commit this patch soon, but I figure I should get a feeling from this list as to whether or not this is should be changed or if it's OK. The patch is located at: http://people.freebsd.org/~arr/modlock.diff Testing and review are encouraged. Thanks, Andrew -- Andrew R. Reiter arr@watson.org arr@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Mar 14 10: 2:27 2002 Delivered-To: freebsd-smp@freebsd.org Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by hub.freebsd.org (Postfix) with ESMTP id 0FD0037B41B; Thu, 14 Mar 2002 10:02:13 -0800 (PST) Received: (from jake@localhost) by k6.locore.ca (8.11.6/8.11.6) id g2EI8hE57359; Thu, 14 Mar 2002 13:08:43 -0500 (EST) (envelope-from jake) Date: Thu, 14 Mar 2002 13:08:43 -0500 From: Jake Burkholder To: "Andrew R. Reiter" Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Patch to lock down modules Message-ID: <20020314130843.B52298@locore.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from arr@FreeBSD.ORG on Thu, Mar 14, 2002 at 12:15:21PM -0500 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Apparently, On Thu, Mar 14, 2002 at 12:15:21PM -0500, Andrew R. Reiter said words to the effect of; > Hi all, > > I'd like to commit this patch soon, but I figure I should get > a feeling from this list as to whether or not this is should be > changed or if it's OK. The patch is located at: > > http://people.freebsd.org/~arr/modlock.diff > > Testing and review are encouraged. Couple problems: I think that you missed a MOD_SLOCK before the newmod = module_lookupbyname(data->name); in module_register. Also in that function the MOD_XLOCK isn't needed until just before the TAILQ_INSERT_TAIL. The increment of nextid needs something, I would probably move it to just before the TAILQ_INSERT, under the XLOCK. An atomic_add_and_return_old_value would be useful here. Also, I think that you should do another module_lookupbyname after acquiring the XLOCK and before the TAILQ_INSERT, because conceivably another module with the same name could show up when you release the SLOCK. Can you explain the wierd logic that was added to linker_file_unload? Thanks, Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Mar 14 10:26:12 2002 Delivered-To: freebsd-smp@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id A811537B402; Thu, 14 Mar 2002 10:25:50 -0800 (PST) Received: from localhost (arr@localhost) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g2EIPPm98698; Thu, 14 Mar 2002 13:25:25 -0500 (EST) (envelope-from arr@FreeBSD.org) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Thu, 14 Mar 2002 13:25:24 -0500 (EST) From: "Andrew R. Reiter" X-Sender: arr@fledge.watson.org To: Jake Burkholder Cc: "Andrew R. Reiter" , freebsd-smp@FreeBSD.org Subject: Re: Patch to lock down modules In-Reply-To: <20020314130843.B52298@locore.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 14 Mar 2002, Jake Burkholder wrote: : :Couple problems: : :I think that you missed a MOD_SLOCK before the : newmod = module_lookupbyname(data->name); :in module_register. Actually, iirc, module_register only got called from one spot, and in that spot, keeping SLOCK held seemed better than dropping it and reaquiring a SLOCK in module_register. If we'd like to keep this more consisten with some of the other funcitons, then I can change this no problem. : :Also in that function the MOD_XLOCK isn't needed until just before the :TAILQ_INSERT_TAIL. The increment of nextid needs something, I would :probably move it to just before the TAILQ_INSERT, under the XLOCK. An :atomic_add_and_return_old_value would be useful here. Also, I think :that you should do another module_lookupbyname after acquiring the :XLOCK and before the TAILQ_INSERT, because conceivably another module :with the same name could show up when you release the SLOCK. Seems reasonable... :Can you explain the wierd logic that was added to linker_file_unload? Ugh, yes, this is kinda ugly. Essentially this is a result of hacking this back and forth between where we should be holding SLOCK over. This is exactly what I wanted to discuss this b/c prior to making this change, I had a much more simple strategy here (but was dropped due to changes to a better strategy for kern_module). We discussed before about possibly having two sets of lookup functions -- internal and external -- perhaps this is a better solution? :Thanks, :Jake : -- Andrew R. Reiter arr@watson.org arr@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Mar 14 10:37:50 2002 Delivered-To: freebsd-smp@freebsd.org Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by hub.freebsd.org (Postfix) with ESMTP id 25F3A37B419; Thu, 14 Mar 2002 10:37:36 -0800 (PST) Received: (from jake@localhost) by k6.locore.ca (8.11.6/8.11.6) id g2EIi2v57632; Thu, 14 Mar 2002 13:44:02 -0500 (EST) (envelope-from jake) Date: Thu, 14 Mar 2002 13:43:59 -0500 From: Jake Burkholder To: "Andrew R. Reiter" Cc: freebsd-smp@FreeBSD.org Subject: Re: Patch to lock down modules Message-ID: <20020314134359.C52298@locore.ca> References: <20020314130843.B52298@locore.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from arr@FreeBSD.org on Thu, Mar 14, 2002 at 01:25:24PM -0500 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Apparently, On Thu, Mar 14, 2002 at 01:25:24PM -0500, Andrew R. Reiter said words to the effect of; > On Thu, 14 Mar 2002, Jake Burkholder wrote: > > : > :Couple problems: > : > :I think that you missed a MOD_SLOCK before the > : newmod = module_lookupbyname(data->name); > :in module_register. > > Actually, iirc, module_register only got called from one spot, and in that > spot, keeping SLOCK held seemed better than dropping it and reaquiring a > SLOCK in module_register. If we'd like to keep this more consisten with > some of the other funcitons, then I can change this no problem. Hum. Well, I don't like its side effect of releasing the lock. I think that the place where its called in kern_linker.c should not do a lookup by name itself, but leave it to module_register, it will return an error anyway. That way it doesn't need to acquire the lock before hand, and can leave it up to module_register. > > : > :Also in that function the MOD_XLOCK isn't needed until just before the > :TAILQ_INSERT_TAIL. The increment of nextid needs something, I would > :probably move it to just before the TAILQ_INSERT, under the XLOCK. An > :atomic_add_and_return_old_value would be useful here. Also, I think > :that you should do another module_lookupbyname after acquiring the > :XLOCK and before the TAILQ_INSERT, because conceivably another module > :with the same name could show up when you release the SLOCK. > > Seems reasonable... > > :Can you explain the wierd logic that was added to linker_file_unload? > > Ugh, yes, this is kinda ugly. Essentially this is a result of hacking > this back and forth between where we should be holding SLOCK over. This > is exactly what I wanted to discuss this b/c prior to making this change, > I had a much more simple strategy here (but was dropped due to changes to > a better strategy for kern_module). We discussed before about possibly > having two sets of lookup functions -- internal and external -- perhaps > this is a better solution? Hmm, I'll have to look at it more closely. > > :Thanks, > :Jake > : > > -- > Andrew R. Reiter > arr@watson.org > arr@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Mar 14 11:58:38 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail.velosystems.net (wsip68-15-85-238.oc.oc.cox.net [68.15.85.238]) by hub.freebsd.org (Postfix) with ESMTP id C679B37B41A for ; Thu, 14 Mar 2002 11:58:34 -0800 (PST) Received: from win2kads (win2kads [192.168.1.5]) by mail.velosystems.net (Postfix) with SMTP id B2CCD12729 for ; Thu, 14 Mar 2002 11:58:29 -0800 (PST) Message-ID: <008c01c1cb92$c62a28c0$0501a8c0@VELOSYSTEMS.NET> From: "Steve Wingate" To: Subject: Intel Xeon hyperthreading Date: Thu, 14 Mar 2002 11:59:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Has anyone testing Intel Xeon hyperthreading on FreeBSD? I'm building a Dual Xeon box and I was curious if FreeBSD would see that as two processors or four. TIA. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Mar 14 12: 1:27 2002 Delivered-To: freebsd-smp@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id BAB0337B417; Thu, 14 Mar 2002 12:01:22 -0800 (PST) Received: from localhost (arr@localhost) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g2EK1HN00341; Thu, 14 Mar 2002 15:01:17 -0500 (EST) (envelope-from arr@FreeBSD.org) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Thu, 14 Mar 2002 15:01:16 -0500 (EST) From: "Andrew R. Reiter" X-Sender: arr@fledge.watson.org To: Jake Burkholder Cc: "Andrew R. Reiter" , freebsd-smp@FreeBSD.org Subject: Re: Patch to lock down modules In-Reply-To: <20020314134359.C52298@locore.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 14 Mar 2002, Jake Burkholder wrote: :> :Can you explain the wierd logic that was added to linker_file_unload? :> :> Ugh, yes, this is kinda ugly. Essentially this is a result of hacking :> this back and forth between where we should be holding SLOCK over. This :> is exactly what I wanted to discuss this b/c prior to making this change, :> I had a much more simple strategy here (but was dropped due to changes to :> a better strategy for kern_module). We discussed before about possibly :> having two sets of lookup functions -- internal and external -- perhaps :> this is a better solution? : :Hmm, I'll have to look at it more closely. : :> :> :Thanks, :> :Jake I uploaded a new patch (tested somewhat) to: http://people.freebsd.org/~arr/modlock.diff this takes care of 2 of the 3 issues you brought up -- but, I'd enjoy inspection of the atomic set and addcalls I used. I'll relook at the 3rd issue (ugliness in kern_linker) and see what I can figure out if I don't hear from you. Thanks, Andrew -- Andrew R. Reiter arr@watson.org arr@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Mar 14 12:24:17 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mailhub.yumyumyum.org (dsl092-171-091.wdc1.dsl.speakeasy.net [66.92.171.91]) by hub.freebsd.org (Postfix) with SMTP id B6FFB37B416 for ; Thu, 14 Mar 2002 12:24:13 -0800 (PST) Received: (qmail 20172 invoked from network); 14 Mar 2002 20:24:00 -0000 Received: from dsl092-171-091.wdc1.dsl.speakeasy.net (66.92.171.91) by dsl092-171-091.wdc1.dsl.speakeasy.net with SMTP; 14 Mar 2002 20:24:00 -0000 Date: Thu, 14 Mar 2002 15:24:00 -0500 (EST) From: Kenneth Culver To: Steve Wingate Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Intel Xeon hyperthreading In-Reply-To: <008c01c1cb92$c62a28c0$0501a8c0@VELOSYSTEMS.NET> Message-ID: <20020314152326.H20147-100000@alpha.yumyumyum.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I don't know if anyone is working on that, but from what I could tell, in a lot of cases, enabling the hyperthreading actually *decreased* performance of a lot of multithreaded and single threaded apps. Ken On Thu, 14 Mar 2002, Steve Wingate wrote: > Has anyone testing Intel Xeon hyperthreading on FreeBSD? I'm building a Dual > Xeon box and I was curious if FreeBSD would see that as two processors or > four. TIA. > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Mar 14 12:32:27 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id EA80E37B428 for ; Thu, 14 Mar 2002 12:32:11 -0800 (PST) Received: (qmail 26167 invoked from network); 14 Mar 2002 20:32:11 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 14 Mar 2002 20:32:11 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g2EKWav36631; Thu, 14 Mar 2002 15:32:37 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <008c01c1cb92$c62a28c0$0501a8c0@VELOSYSTEMS.NET> Date: Thu, 14 Mar 2002 15:32:12 -0500 (EST) From: John Baldwin To: Steve Wingate Subject: RE: Intel Xeon hyperthreading Cc: freebsd-smp@freebsd.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 14-Mar-2002 Steve Wingate wrote: > Has anyone testing Intel Xeon hyperthreading on FreeBSD? I'm building a Dual > Xeon box and I was curious if FreeBSD would see that as two processors or > four. TIA. We currently don't support hyperthreading in FreeBSD. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Mar 14 13: 5: 8 2002 Delivered-To: freebsd-smp@freebsd.org Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by hub.freebsd.org (Postfix) with ESMTP id E6A9537B416; Thu, 14 Mar 2002 13:05:02 -0800 (PST) Received: (from jake@localhost) by k6.locore.ca (8.11.6/8.11.6) id g2ELBYG58399; Thu, 14 Mar 2002 16:11:34 -0500 (EST) (envelope-from jake) Date: Thu, 14 Mar 2002 16:11:33 -0500 From: Jake Burkholder To: "Andrew R. Reiter" Cc: freebsd-smp@FreeBSD.org Subject: Re: Patch to lock down modules Message-ID: <20020314161133.E52298@locore.ca> References: <20020314134359.C52298@locore.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from arr@FreeBSD.org on Thu, Mar 14, 2002 at 03:01:16PM -0500 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Apparently, On Thu, Mar 14, 2002 at 03:01:16PM -0500, Andrew R. Reiter said words to the effect of; > On Thu, 14 Mar 2002, Jake Burkholder wrote: > > :> :Can you explain the wierd logic that was added to linker_file_unload? > :> > :> Ugh, yes, this is kinda ugly. Essentially this is a result of hacking > :> this back and forth between where we should be holding SLOCK over. This > :> is exactly what I wanted to discuss this b/c prior to making this change, > :> I had a much more simple strategy here (but was dropped due to changes to > :> a better strategy for kern_module). We discussed before about possibly > :> having two sets of lookup functions -- internal and external -- perhaps > :> this is a better solution? > : > :Hmm, I'll have to look at it more closely. > : > :> > :> :Thanks, > :> :Jake > > I uploaded a new patch (tested somewhat) to: > http://people.freebsd.org/~arr/modlock.diff > > this takes care of 2 of the 3 issues you brought up -- but, I'd enjoy > inspection of the atomic set and addcalls I used. Sorry, I should have been clearer. module_lookupbyname should assert that the lock is locked either shared or exclusive, sx_assert(SX_LOCKED) does this, so it can be called with either. Don't bother with the shared lock - upgrade - release exclusive, or with the atomic ops, just get an exclusive lock over the whole thing. like: MOD_XLOCK; mp = module_lookupbyname(newmod->name); if (mp != NULL) { MOD_XUNLOCK; ... return (EEXIST); } newmod->id = nextid++; TAILQ_INSERT_TAIL(&modules, newmod, link); ... MOD_XUNLOCK; return (0); > > I'll relook at the 3rd issue (ugliness in kern_linker) and see what I can > figure out if I don't hear from you. Ok. Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Mar 14 13:16:43 2002 Delivered-To: freebsd-smp@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 7EBBC37B405; Thu, 14 Mar 2002 13:16:19 -0800 (PST) Received: from pool0226.cvx22-bradley.dialup.earthlink.net ([209.179.198.226] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16lcaA-00042I-00; Thu, 14 Mar 2002 13:16:19 -0800 Message-ID: <3C911311.507648B@mindspring.com> Date: Thu, 14 Mar 2002 13:16:01 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Andrew R. Reiter" Cc: freebsd-smp@FreeBSD.org Subject: Re: Patch to lock down modules References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "Andrew R. Reiter" wrote: > Hi all, > > I'd like to commit this patch soon, but I figure I should get > a feeling from this list as to whether or not this is should be > changed or if it's OK. The patch is located at: > > http://people.freebsd.org/~arr/modlock.diff > > Testing and review are encouraged. Why is the first module_lookupbyname() not permitted to stay, but the others are? A casual perusal seems like you could lock around it? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Mar 14 13:41:22 2002 Delivered-To: freebsd-smp@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 61E8437B425 for ; Thu, 14 Mar 2002 13:40:59 -0800 (PST) Received: from pool0226.cvx22-bradley.dialup.earthlink.net ([209.179.198.226] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16lcxz-0004bK-00; Thu, 14 Mar 2002 13:40:56 -0800 Message-ID: <3C9118D6.81B9FD62@mindspring.com> Date: Thu, 14 Mar 2002 13:40:38 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kenneth Culver Cc: Steve Wingate , freebsd-smp@FreeBSD.ORG Subject: Re: Intel Xeon hyperthreading References: <20020314152326.H20147-100000@alpha.yumyumyum.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Kenneth Culver wrote: > I don't know if anyone is working on that, but from what I could tell, in > a lot of cases, enabling the hyperthreading actually *decreased* > performance of a lot of multithreaded and single threaded apps. It requires extensive compiler support. If you read the Intel documentation on how to write a compiler that does the right things, it reads like a list of sixteen "don't do this thing GCC did, do this instead". So the answer is really a question... does the original poster have their patches to GCC ready so that we can compile code that tests hyperthreading? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Mar 14 14: 1:37 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mailhub.yumyumyum.org (dsl092-171-091.wdc1.dsl.speakeasy.net [66.92.171.91]) by hub.freebsd.org (Postfix) with SMTP id E410137B404 for ; Thu, 14 Mar 2002 14:01:32 -0800 (PST) Received: (qmail 22096 invoked from network); 14 Mar 2002 22:01:18 -0000 Received: from dsl092-171-091.wdc1.dsl.speakeasy.net (66.92.171.91) by dsl092-171-091.wdc1.dsl.speakeasy.net with SMTP; 14 Mar 2002 22:01:18 -0000 Date: Thu, 14 Mar 2002 17:01:18 -0500 (EST) From: Kenneth Culver To: Terry Lambert Cc: Steve Wingate , Subject: Re: Intel Xeon hyperthreading In-Reply-To: <3C9118D6.81B9FD62@mindspring.com> Message-ID: <20020314170017.I22063-100000@alpha.yumyumyum.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Kenneth Culver wrote: > > I don't know if anyone is working on that, but from what I could tell, in > > a lot of cases, enabling the hyperthreading actually *decreased* > > performance of a lot of multithreaded and single threaded apps. > > It requires extensive compiler support. > > If you read the Intel documentation on how to write a compiler > that does the right things, it reads like a list of sixteen > "don't do this thing GCC did, do this instead". > > So the answer is really a question... does the original poster > have their patches to GCC ready so that we can compile code > that tests hyperthreading? > Yeah, I know, but from what I hear a lot of people are misunderstanding what hyperthreading is, and they think it basically doubles performance. I posted with that in mind. :-) Ken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Mar 14 18:39: 4 2002 Delivered-To: freebsd-smp@freebsd.org Received: from eudoramail.com (netturbo3.cscoms.com [202.183.214.4]) by hub.freebsd.org (Postfix) with SMTP id 6EF1437B43B for ; Thu, 14 Mar 2002 18:35:12 -0800 (PST) From: "Moissanite" To: Subject: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 15 Mar 2002 09:39:03 +0700 Reply-To: "Moissanite" Content-Transfer-Encoding: 8bit Message-Id: <20020315023513.6EF1437B43B@hub.freebsd.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Moissanite: More Fire and Brilliance
The Truth About Moissanite
 
Fact - Moissanite delivers more fire, brilliance and luster than any other hard jewel on Earth.
This unretouched photograph supports the adage that "a picture is worth a thousand words". Here, a light source over a similar sized moissanite and diamond placed in shallow water clearly shows the superior fire and brilliance of this unique new jewel. And the picture is supported by measurable facts: the GIA publishes the dispersion (fire) of created moissanite at 0.104, refractive index (brilliance) at 2.65 to 2.69, and luster at 20.4%. No other hard jewel measures up, not even a fine diamond. And only moissanite and diamond are over 9 on the Mohs hardness scale. Moissanite jewels created by Charles & Colvard are available in all popular shapes and sizes. 

www.moissanitesource.com is the place to buy moissanite jewelry on the internet. Buy with confidence at the best prices in the world. 
 
Moissanite Created By Charles & Colvard
 

Moissanite created by Charles & Colvard is a unique jewel, not a synthetic diamond.

Moissanite Source is an authorized distributor of Moissanite.

 

If you wish to stop receiving these occasional mailings, simply reply to this email with the word "REMOVE" in
the subject line and we will remove your name and email address from our database.
To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Mar 14 18:41: 0 2002 Delivered-To: freebsd-smp@freebsd.org Received: from eudoramail.com (netturbo3.cscoms.com [202.183.214.4]) by hub.freebsd.org (Postfix) with SMTP id 751E437B4A5 for ; Thu, 14 Mar 2002 18:36:09 -0800 (PST) From: "Moissanite" To: Subject: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 15 Mar 2002 09:40:02 +0700 Reply-To: "Moissanite" Content-Transfer-Encoding: 8bit Message-Id: <20020315023609.751E437B4A5@hub.freebsd.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Moissanite: More Fire and Brilliance
The Truth About Moissanite
 
Fact - Moissanite delivers more fire, brilliance and luster than any other hard jewel on Earth.
This unretouched photograph supports the adage that "a picture is worth a thousand words". Here, a light source over a similar sized moissanite and diamond placed in shallow water clearly shows the superior fire and brilliance of this unique new jewel. And the picture is supported by measurable facts: the GIA publishes the dispersion (fire) of created moissanite at 0.104, refractive index (brilliance) at 2.65 to 2.69, and luster at 20.4%. No other hard jewel measures up, not even a fine diamond. And only moissanite and diamond are over 9 on the Mohs hardness scale. Moissanite jewels created by Charles & Colvard are available in all popular shapes and sizes. 

www.moissanitesource.com is the place to buy moissanite jewelry on the internet. Buy with confidence at the best prices in the world. 
 
Moissanite Created By Charles & Colvard
 

Moissanite created by Charles & Colvard is a unique jewel, not a synthetic diamond.

Moissanite Source is an authorized distributor of Moissanite.

 

If you wish to stop receiving these occasional mailings, simply reply to this email with the word "REMOVE" in
the subject line and we will remove your name and email address from our database.
To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Mar 15 14:54: 2 2002 Delivered-To: freebsd-smp@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 633A237B422; Fri, 15 Mar 2002 14:53:45 -0800 (PST) Received: from localhost (arr@localhost) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g2FMrhA19845; Fri, 15 Mar 2002 17:53:43 -0500 (EST) (envelope-from arr@FreeBSD.org) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Fri, 15 Mar 2002 17:53:42 -0500 (EST) From: "Andrew R. Reiter" X-Sender: arr@fledge.watson.org To: jake@FreeBSD.org Cc: smp@FreeBSD.org Subject: RFR: modlock.diff -- updated Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Jake, I've updated the patch with regards to cleaning up kern_linker a bit and some of your other recommendations. Could you review this again? http://people.freebsd.org/~arr/modlock.diff Cheers, Andrew -- Andrew R. Reiter arr@watson.org arr@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Mar 16 1:22:30 2002 Delivered-To: freebsd-smp@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id CFC7737B402; Sat, 16 Mar 2002 01:22:26 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2G9MMUD035759; Sat, 16 Mar 2002 10:22:22 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org, smp@freebsd.org Subject: -current lock warning... From: Poul-Henning Kamp Date: Sat, 16 Mar 2002 10:22:22 +0100 Message-ID: <35758.1016270542@critter.freebsd.dk> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I get this one on every single boot. We're not shipping the snapshot with that in place, right ? real memory = 268423168 (262132K bytes) avail memory = 257003520 (250980K bytes) acquiring duplicate lock of same type: "thrd_sleep" 1st @ ../../../vm/vm_map.c:2288 2nd @ ../../../vm/vm_kern.c:172 Debugger("witness_lock") Stopped at Debugger+0x40: xorl %eax,%eax db> trace Debugger(c02e9ace) at Debugger+0x40 witness_lock(c038afe4,8,c02f8440,ac,c038afb4) at witness_lock+0x546 _sx_xlock(c038afe4,c02f8440,ac,bfc00000,c0435c5c) at _sx_xlock+0xa1 _vm_map_lock(c038afb4,c02f8440,ac,c034a840,1) at _vm_map_lock+0x16 kmem_alloc(c038afb4,3000,c0e41a00,0,c02fa434) at kmem_alloc+0x41 _zget(c0e41a00,bfc00000,0,c0435cd0,c0281769) at _zget+0xfa zalloc(c0e41a00,c034a840,1,c02f8630,a7) at zalloc+0x3b vmspace_alloc(0,bfc00000,c035c940,c02f8630,8f0) at vmspace_alloc+0x2d vmspace_fork(c035c940,cbb9ad24,c0331f84,cbb9ab00,c0331d60) at vmspace_fork+0x4d vm_forkproc(c0332080,cbb9ab00,cbb9ac00,20014) at vm_forkproc+0xc6 fork1(c0332080,20014,c0332130) at fork1+0xd58 create_init(0,432c00,432000,0,c012368c) at create_init+0x17 mi_startup() at mi_startup+0x90 begin() at begin+0x43 db> -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Mar 16 5:20:38 2002 Delivered-To: freebsd-smp@freebsd.org Received: from web21107.mail.yahoo.com (web21107.mail.yahoo.com [216.136.227.109]) by hub.freebsd.org (Postfix) with SMTP id 52B6137B405 for ; Sat, 16 Mar 2002 05:20:31 -0800 (PST) Message-ID: <20020316132031.97750.qmail@web21107.mail.yahoo.com> Received: from [62.254.0.5] by web21107.mail.yahoo.com via HTTP; Sat, 16 Mar 2002 05:20:31 PST Date: Sat, 16 Mar 2002 05:20:31 -0800 (PST) From: Hiten Pandya Reply-To: hiten@uk.FreeBSD.org Subject: Re: -current lock warning... To: Poul-Henning Kamp , current@freebsd.org, smp@freebsd.org In-Reply-To: <35758.1016270542@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --- Poul-Henning Kamp wrote: > I get this one on every single boot. We're not shipping the snapshot > with that in place, right ? > > real memory = 268423168 (262132K bytes) > avail memory = 257003520 (250980K bytes) > acquiring duplicate lock of same type: "thrd_sleep" > 1st @ ../../../vm/vm_map.c:2288 > 2nd @ ../../../vm/vm_kern.c:172 > Debugger("witness_lock") > Stopped at Debugger+0x40: xorl %eax,%eax > db> trace > Debugger(c02e9ace) at Debugger+0x40 > witness_lock(c038afe4,8,c02f8440,ac,c038afb4) at witness_lock+0x546 > _sx_xlock(c038afe4,c02f8440,ac,bfc00000,c0435c5c) at _sx_xlock+0xa1 > _vm_map_lock(c038afb4,c02f8440,ac,c034a840,1) at _vm_map_lock+0x16 > kmem_alloc(c038afb4,3000,c0e41a00,0,c02fa434) at kmem_alloc+0x41 > _zget(c0e41a00,bfc00000,0,c0435cd0,c0281769) at _zget+0xfa > zalloc(c0e41a00,c034a840,1,c02f8630,a7) at zalloc+0x3b > vmspace_alloc(0,bfc00000,c035c940,c02f8630,8f0) at vmspace_alloc+0x2d > vmspace_fork(c035c940,cbb9ad24,c0331f84,cbb9ab00,c0331d60) at > vmspace_fork+0x4d > vm_forkproc(c0332080,cbb9ab00,cbb9ac00,20014) at vm_forkproc+0xc6 > fork1(c0332080,20014,c0332130) at fork1+0xd58 > create_init(0,432c00,432000,0,c012368c) at create_init+0x17 > mi_startup() at mi_startup+0x90 > begin() at begin+0x43 > db> I haven't seen this. I built a kernel today, and I have a dual processor machine. Are you using any special kernel options, such as VFS_BIO_DEBUG or something, or am I talking nuts? :) Regards, -- Hiten __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Mar 16 5:33:52 2002 Delivered-To: freebsd-smp@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 44B3037B404; Sat, 16 Mar 2002 05:33:48 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2GDXSUD038197; Sat, 16 Mar 2002 14:33:39 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: hiten@uk.FreeBSD.org Cc: current@freebsd.org, smp@freebsd.org Subject: Re: -current lock warning... In-Reply-To: Your message of "Sat, 16 Mar 2002 05:20:31 PST." <20020316132031.97750.qmail@web21107.mail.yahoo.com> Date: Sat, 16 Mar 2002 14:33:28 +0100 Message-ID: <38196.1016285608@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message <20020316132031.97750.qmail@web21107.mail.yahoo.com>, Hiten Pandya w rites: >I haven't seen this. I built a kernel today, and I have a dual processor >machine. Are you using any special kernel options, such as VFS_BIO_DEBUG >or something, or am I talking nuts? :) Well, I have. On a single CPU net-booting -current. No. Yes :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Mar 16 5:37:14 2002 Delivered-To: freebsd-smp@freebsd.org Received: from web21104.mail.yahoo.com (web21104.mail.yahoo.com [216.136.227.106]) by hub.freebsd.org (Postfix) with SMTP id 3657137B400 for ; Sat, 16 Mar 2002 05:37:10 -0800 (PST) Message-ID: <20020316133709.23309.qmail@web21104.mail.yahoo.com> Received: from [62.254.0.5] by web21104.mail.yahoo.com via HTTP; Sat, 16 Mar 2002 05:37:09 PST Date: Sat, 16 Mar 2002 05:37:09 -0800 (PST) From: Hiten Pandya Reply-To: hiten@uk.FreeBSD.org Subject: Re: -current lock warning... To: Poul-Henning Kamp Cc: current@freebsd.org, smp@freebsd.org In-Reply-To: <38196.1016285608@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --- Poul-Henning Kamp wrote: > >I haven't seen this. I built a kernel today, and I have a dual processor > >machine. Are you using any special kernel options, such as VFS_BIO_DEBUG > >or something, or am I talking nuts? :) > > Well, I have. On a single CPU net-booting -current. No. Yes :-) Although I am still getting the following lock problems when I shut the system down: lock order reversal 1st 0xc036afc0 allproc @ ../../../kern/vfs_syscalls.c:452 2nd 0xc7ecce34 filedesc structure @ ../../../kern/vfs_syscalls.c:457 I think I will have to check out lock problems you are getting today, once I finish my breakfast. :-) __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Mar 16 5:57:22 2002 Delivered-To: freebsd-smp@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (cvsup2.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id C700637B417; Sat, 16 Mar 2002 05:57:16 -0800 (PST) Received: from silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp [IPv6:3ffe:b80:5b0:3:280:c8ff:fe6b:6d73]) by rina.r.dl.itc.u-tokyo.ac.jp (8.12.2/3.7W-rina.r-Nankai-Koya) with ESMTP id g2GDvESp060887 ; Sat, 16 Mar 2002 22:57:14 +0900 (JST) Received: from silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (8.12.2/3.7W-carrots-Keikyu-Kurihama) with ESMTP id g2GDuwA5043113 ; Sat, 16 Mar 2002 22:57:13 +0900 (JST) Message-Id: <200203161357.g2GDuwA5043113@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> Date: Sat, 16 Mar 2002 22:56:58 +0900 From: Seigo Tanimura To: Poul-Henning Kamp Cc: current@freebsd.org, smp@freebsd.org, Seigo Tanimura Subject: Re: -current lock warning... In-Reply-To: <35758.1016270542@critter.freebsd.dk> References: <35758.1016270542@critter.freebsd.dk> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 16 Mar 2002 10:22:22 +0100, Poul-Henning Kamp said: Poul-Henning> acquiring duplicate lock of same type: "thrd_sleep" Poul-Henning> 1st @ ../../../vm/vm_map.c:2288 Poul-Henning> 2nd @ ../../../vm/vm_kern.c:172 (snip) Poul-Henning> _vm_map_lock(c038afb4,c02f8440,ac,c034a840,1) at _vm_map_lock+0x16 Poul-Henning> kmem_alloc(c038afb4,3000,c0e41a00,0,c02fa434) at kmem_alloc+0x41 Poul-Henning> _zget(c0e41a00,bfc00000,0,c0435cd0,c0281769) at _zget+0xfa Poul-Henning> zalloc(c0e41a00,c034a840,1,c02f8630,a7) at zalloc+0x3b Poul-Henning> vmspace_alloc(0,bfc00000,c035c940,c02f8630,8f0) at vmspace_alloc+0x2d Poul-Henning> vmspace_fork(c035c940,cbb9ad24,c0331f84,cbb9ab00,c0331d60) at vmspace_fork+0x4d Poul-Henning> vm_forkproc(c0332080,cbb9ab00,cbb9ac00,20014) at vm_forkproc+0xc6 This seems due to naming all of the vm map locks as "thrd_sleep." The locks of vm maps should have their own hierarachy. For instance, lock the map of a process vm space first, then lock the kernel_map. -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Mar 16 7:16:25 2002 Delivered-To: freebsd-smp@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 5DEC237B400; Sat, 16 Mar 2002 07:16:21 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g2GFGJF29877; Sat, 16 Mar 2002 10:16:19 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 16 Mar 2002 10:16:19 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp Cc: current@freebsd.org, smp@freebsd.org Subject: Re: -current lock warning... In-Reply-To: <35758.1016270542@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 16 Mar 2002, Poul-Henning Kamp wrote: > I get this one on every single boot. We're not shipping the snapshot > with that in place, right ? I assume this is from Brian's recent VM locking commit. Currently, it's on the list of commits to back out of the DP1 branch, assuming the issues aren't resolved in the next day or two. If they get resolved, all the better, we'll leave it in and pick up the fix. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Mar 16 8:25:29 2002 Delivered-To: freebsd-smp@freebsd.org Received: from web21110.mail.yahoo.com (web21110.mail.yahoo.com [216.136.227.112]) by hub.freebsd.org (Postfix) with SMTP id 2069C37B41A for ; Sat, 16 Mar 2002 08:21:24 -0800 (PST) Message-ID: <20020316162123.61127.qmail@web21110.mail.yahoo.com> Received: from [62.254.0.5] by web21110.mail.yahoo.com via HTTP; Sat, 16 Mar 2002 08:21:23 PST Date: Sat, 16 Mar 2002 08:21:23 -0800 (PST) From: Hiten Pandya Reply-To: hiten@uk.FreeBSD.org Subject: Re: -current lock warning... To: Seigo Tanimura , Poul-Henning Kamp Cc: Hiten Pandya , Munehiro Matsuda , Robert Watson , current@freebsd.org, smp@freebsd.org, Seigo Tanimura In-Reply-To: <200203161618.g2GGHMA5085135@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > The patch attached below renames the lock of the kernel_map to > "kernel_map" once witness gets ready to run. This eliminated all of > the lock order reversals on my PC. I will check it out. I will check this out on my dual-processor machine. Thanks for the patch. :-) __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Mar 16 8:52:11 2002 Delivered-To: freebsd-smp@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (rina.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id 5A1F737B400; Sat, 16 Mar 2002 08:51:51 -0800 (PST) Received: from silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp [IPv6:3ffe:b80:5b0:3:280:c8ff:fe6b:6d73]) by rina.r.dl.itc.u-tokyo.ac.jp (8.12.2/3.7W-rina.r-Nankai-Koya) with ESMTP id g2GGIgSp063452 ; Sun, 17 Mar 2002 01:18:42 +0900 (JST) Received: from silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (8.12.2/3.7W-carrots-Keikyu-Kurihama) with ESMTP id g2GGHMA5085135 ; Sun, 17 Mar 2002 01:18:42 +0900 (JST) Message-Id: <200203161618.g2GGHMA5085135@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> Date: Sun, 17 Mar 2002 01:17:21 +0900 From: Seigo Tanimura To: Poul-Henning Kamp Cc: Hiten Pandya , Munehiro Matsuda , Robert Watson , current@freebsd.org, smp@freebsd.org, Seigo Tanimura Subject: Re: -current lock warning... In-Reply-To: <200203161357.g2GDuwA5043113@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> References: <35758.1016270542@critter.freebsd.dk> <200203161357.g2GDuwA5043113@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: multipart/mixed; boundary="Multipart_Sun_Mar_17_01:17:21_2002-1" Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --Multipart_Sun_Mar_17_01:17:21_2002-1 Content-Type: text/plain; charset=US-ASCII On Sat, 16 Mar 2002 22:56:58 +0900, Seigo Tanimura said: Seigo> On Sat, 16 Mar 2002 10:22:22 +0100, Seigo> Poul-Henning Kamp said: Seigo> Poul-Henning> acquiring duplicate lock of same type: "thrd_sleep" Seigo> Poul-Henning> 1st @ ../../../vm/vm_map.c:2288 Seigo> Poul-Henning> 2nd @ ../../../vm/vm_kern.c:172 Seigo> (snip) Seigo> Poul-Henning> _vm_map_lock(c038afb4,c02f8440,ac,c034a840,1) at _vm_map_lock+0x16 Seigo> Poul-Henning> kmem_alloc(c038afb4,3000,c0e41a00,0,c02fa434) at kmem_alloc+0x41 Seigo> Poul-Henning> _zget(c0e41a00,bfc00000,0,c0435cd0,c0281769) at _zget+0xfa Seigo> Poul-Henning> zalloc(c0e41a00,c034a840,1,c02f8630,a7) at zalloc+0x3b Seigo> Poul-Henning> vmspace_alloc(0,bfc00000,c035c940,c02f8630,8f0) at vmspace_alloc+0x2d Seigo> Poul-Henning> vmspace_fork(c035c940,cbb9ad24,c0331f84,cbb9ab00,c0331d60) at vmspace_fork+0x4d Seigo> Poul-Henning> vm_forkproc(c0332080,cbb9ab00,cbb9ac00,20014) at vm_forkproc+0xc6 Seigo> This seems due to naming all of the vm map locks as "thrd_sleep." The Seigo> locks of vm maps should have their own hierarachy. For instance, lock Seigo> the map of a process vm space first, then lock the kernel_map. The patch attached below renames the lock of the kernel_map to "kernel_map" once witness gets ready to run. This eliminated all of the lock order reversals on my PC. --Multipart_Sun_Mar_17_01:17:21_2002-1 Content-Type: application/octet-stream; type=patch Content-Disposition: attachment; filename="vm_map_renamelock.diff" Content-Transfer-Encoding: 7bit ? i386/conf/BUNKO ? i386/conf/BUNKO.hints ? i386/conf/LINT ? modules/3dfx/pci.h ? modules/aha/aha.h ? modules/kernfs/kernfs.kld ? modules/kernfs/kernfs.ko ? modules/kernfs/setdef0.c ? modules/kernfs/setdef1.c ? modules/kernfs/setdefs.h ? modules/kernfs/vnode_if.h ? modules/lnc/lnc.kld ? modules/lnc/lnc.ko ? modules/random/opt_noblockrandom.h ? modules/svr4/opt_compat.h ? modules/svr4/opt_svr4.h ? modules/svr4/opt_vmpage.h ? modules/svr4/setdef0.c ? modules/svr4/setdef1.c ? modules/svr4/setdefs.h ? modules/svr4/svr4.kld ? modules/svr4/svr4.ko ? modules/svr4/svr4_assym.h ? modules/svr4/vnode_if.h Index: vm/vm_kern.c =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_kern.c,v retrieving revision 1.76 diff -u -r1.76 vm_kern.c --- vm/vm_kern.c 10 Mar 2002 21:52:46 -0000 1.76 +++ vm/vm_kern.c 16 Mar 2002 15:48:29 -0000 @@ -515,3 +515,17 @@ /* ... and ending with the completion of the above `insert' */ vm_map_unlock(m); } + +/* + * kernel_map_initialize: + * + * Rename the lock of kernel_map. We cannot do this in kmem_init + * because Witness is cold. + */ +static void +kernel_map_initialize(void *dummy __unused) +{ + vm_map_renamelock(kernel_map, "kernel_map"); +} + +SYSINIT(kernel_map_init, SI_SUB_WITNESS, SI_ORDER_SECOND, kernel_map_initialize, NULL) Index: vm/vm_map.c =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_map.c,v retrieving revision 1.215 diff -u -r1.215 vm_map.c --- vm/vm_map.c 13 Mar 2002 23:48:08 -0000 1.215 +++ vm/vm_map.c 16 Mar 2002 15:48:40 -0000 @@ -91,6 +91,9 @@ #include #include +/* The default name of a map lock. */ +#define MAPLOCK_NAME "vm map" + /* * Virtual memory maps provide for the mapping, protection, * and sharing of virtual memory objects. In addition, @@ -405,7 +408,21 @@ map->first_free = &map->header; map->hint = &map->header; map->timestamp = 0; - sx_init(&map->lock, "thrd_sleep"); + sx_init(&map->lock, MAPLOCK_NAME); +} + +/* + * vm_map_renamelock: + * + * Renames the lock of a VM map. This + * lets us check the lock order of VM + * maps. + */ +void +vm_map_renamelock(vm_map_t map, const char *name) +{ + sx_destroy(&map->lock); + sx_init(&map->lock, name); } void Index: vm/vm_map.h =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_map.h,v retrieving revision 1.71 diff -u -r1.71 vm_map.h --- vm/vm_map.h 13 Mar 2002 23:48:08 -0000 1.71 +++ vm/vm_map.h 16 Mar 2002 15:48:41 -0000 @@ -277,6 +277,7 @@ int vm_map_findspace (vm_map_t, vm_offset_t, vm_size_t, vm_offset_t *); int vm_map_inherit (vm_map_t, vm_offset_t, vm_offset_t, vm_inherit_t); void vm_map_init (struct vm_map *, vm_offset_t, vm_offset_t); +void vm_map_renamelock (struct vm_map *, const char *); void vm_map_destroy (struct vm_map *); int vm_map_insert (vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t, vm_offset_t, vm_prot_t, vm_prot_t, int); int vm_map_lookup (vm_map_t *, vm_offset_t, vm_prot_t, vm_map_entry_t *, vm_object_t *, --Multipart_Sun_Mar_17_01:17:21_2002-1 Content-Type: text/plain; charset=US-ASCII -- Seigo Tanimura --Multipart_Sun_Mar_17_01:17:21_2002-1-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Mar 16 9:32:53 2002 Delivered-To: freebsd-smp@freebsd.org Received: from warez.scriptkiddie.org (uswest-dsl-142-38.cortland.com [209.162.142.38]) by hub.freebsd.org (Postfix) with ESMTP id 8603D37B402; Sat, 16 Mar 2002 09:32:49 -0800 (PST) Received: from [192.168.69.11] (unknown [192.168.69.11]) by warez.scriptkiddie.org (Postfix) with ESMTP id C286762D01; Sat, 16 Mar 2002 09:32:48 -0800 (PST) Date: Sat, 16 Mar 2002 09:33:02 -0800 (PST) From: Lamont Granquist To: Cc: Poul-Henning Kamp , , Subject: Re: -current lock warning... In-Reply-To: <20020316133709.23309.qmail@web21104.mail.yahoo.com> Message-ID: <20020316093042.R5356-100000@coredump.scriptkiddie.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've seen this as well, -current from about 5 days ago, dual proc 1.4GHz K7 A7M266D with a 13GB IBM UDMA66 drive, GENERIC kernel + hints. On Sat, 16 Mar 2002, Hiten Pandya wrote: > --- Poul-Henning Kamp wrote: > > >I haven't seen this. I built a kernel today, and I have a dual processor > > >machine. Are you using any special kernel options, such as VFS_BIO_DEBUG > > >or something, or am I talking nuts? :) > > > > Well, I have. On a single CPU net-booting -current. No. Yes :-) > > Although I am still getting the following lock problems when I shut > the system down: > > lock order reversal > 1st 0xc036afc0 allproc @ ../../../kern/vfs_syscalls.c:452 > 2nd 0xc7ecce34 filedesc structure @ ../../../kern/vfs_syscalls.c:457 > > I think I will have to check out lock problems you are getting today, > once I finish my breakfast. :-) > > __________________________________________________ > Do You Yahoo!? > Yahoo! Sports - live college hoops coverage > http://sports.yahoo.com/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Mar 16 10:21:24 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by hub.freebsd.org (Postfix) with ESMTP id 7F04037B400; Sat, 16 Mar 2002 10:21:12 -0800 (PST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 14DF24CFAE; Sat, 16 Mar 2002 13:21:12 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id NAA01950; Sat, 16 Mar 2002 13:21:11 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id KAA18256; Sat, 16 Mar 2002 10:21:11 -0800 (PST) Message-Id: <200203161821.KAA18256@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: current@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: -current lock warning... Date: Sat, 16 Mar 2002 10:21:11 -0800 Versions: dmail (solaris) 2.4/makemail 2.9b Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Although I am still getting the following lock problems when I shut > the system down: > > lock order reversal > 1st 0xc036afc0 allproc @ ../../../kern/vfs_syscalls.c:452 > 2nd 0xc7ecce34 filedesc structure @ ../../../kern/vfs_syscalls.c:457 I've been seeing this since Feb 4. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message