From owner-freebsd-smp Sun Nov 26 9: 7:27 2000 Delivered-To: freebsd-smp@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 0887B37B4C5 for ; Sun, 26 Nov 2000 09:07:12 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id eAQH5sb95721 for smp@freebsd.org; Sun, 26 Nov 2000 11:05:54 -0600 (CST) (envelope-from jlemon) Date: Sun, 26 Nov 2000 11:05:54 -0600 From: Jonathan Lemon To: smp@freebsd.org Subject: patch to make bpf mpsafe Message-ID: <20001126110554.H69183@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Attached is a patch to make bpf mpsafe (and also cleans up some cruft). BPF happened to be the first subsystem called by ether_input, so was the first thing that I looked at. 3 levels of mutexes are added: bpf_mtx - global to BPF, protects BPF interface list, device open (bif_next, bif_ifp) bpf interface mtx - protects per-interface descriptor list (bd_next, bd_bif, ifp->if_bpf) bpf descriptor mtx - protects fields in the individual descriptor. Locking order is top to bottom, but the hierarchy can be entered at any point. Network drivers start by locking the interface mutex, then walking the list, locking each descriptor as it is manipulated. User level code reading from the bpf descriptor sleeps on the descriptor mutex. This has been lightly tested with an mpsafe network driver. Comments welcome. -- Jonathan Index: bpf.c =================================================================== RCS file: /ncvs/src/sys/net/bpf.c,v retrieving revision 1.69 diff -u -r1.69 bpf.c --- bpf.c 2000/11/03 00:51:41 1.69 +++ bpf.c 2000/11/25 17:42:30 @@ -82,20 +82,8 @@ #if NBPF > 0 -/* - * Older BSDs don't have kernel malloc. - */ -#if BSD < 199103 -extern bcopy(); -static caddr_t bpf_alloc(); -#include -#define BPF_BUFSIZE (MCLBYTES-8) -#define UIOMOVE(cp, len, code, uio) uiomove(cp, len, code, uio) -#else #define BPF_BUFSIZE 4096 #define UIOMOVE(cp, len, code, uio) uiomove(cp, len, uio) -#endif - #define PRINET 26 /* interruptible */ /* @@ -112,6 +100,10 @@ * bpf_iflist is the list of interfaces; each corresponds to an ifnet */ static struct bpf_if *bpf_iflist; +static struct mtx bpf_mtx; /* bpf global lock */ + +#define BPF_LOCK mtx_enter(&bpf_mtx, MTX_DEF) +#define BPF_UNLOCK mtx_exit(&bpf_mtx, MTX_DEF) static int bpf_allocbufs __P((struct bpf_d *)); static void bpf_attachd __P((struct bpf_d *d, struct bpf_if *bp)); @@ -235,13 +228,8 @@ if (m == 0) return (ENOBUFS); if (len > MHLEN) { -#if BSD >= 199103 MCLGET(m, M_WAIT); if ((m->m_flags & M_EXT) == 0) { -#else - MCLGET(m); - if (m->m_len != MCLBYTES) { -#endif error = ENOBUFS; goto bad; } @@ -286,11 +274,13 @@ * Finally, point the driver's bpf cookie at the interface so * it will divert packets to bpf. */ + BPFIF_LOCK(bp); d->bd_bif = bp; d->bd_next = bp->bif_dlist; bp->bif_dlist = d; bp->bif_ifp->if_bpf = bp; + BPFIF_UNLOCK(bp); } /* @@ -324,6 +314,7 @@ } } /* Remove d from the interface's descriptor list. */ + BPFIF_LOCK(bp); p = &bp->bif_dlist; while (*p != d) { p = &(*p)->bd_next; @@ -336,6 +327,7 @@ * Let the driver know that there are no more listeners. */ d->bd_bif->bif_ifp->if_bpf = 0; + BPFIF_UNLOCK(bp); d->bd_bif = 0; } @@ -356,13 +348,16 @@ if (p->p_prison) return (EPERM); + BPF_LOCK; d = dev->si_drv1; /* * Each minor can be opened by only one process. If the requested * minor is in use, return EBUSY. */ - if (d) + if (d) { + BPF_UNLOCK; return (EBUSY); + } if ((dev->si_flags & SI_NAMED) == 0) make_dev(&bpf_cdevsw, minor(dev), UID_ROOT, GID_WHEEL, 0600, "bpf%d", dev2unit(dev)); @@ -372,6 +367,8 @@ d->bd_bufsize = bpf_bufsize; d->bd_sig = SIGIO; d->bd_seesent = 1; + mtx_init(&d->bd_mtx, devtoname(dev), MTX_DEF); + BPF_UNLOCK; return (0); } @@ -393,8 +390,10 @@ funsetown(d->bd_sigio); s = splimp(); + BPF_LOCK; if (d->bd_bif) bpf_detachd(d); + BPF_UNLOCK; splx(s); bpf_freed(d); dev->si_drv1 = 0; @@ -403,45 +402,7 @@ return (0); } -/* - * Support for SunOS, which does not have tsleep. - */ -#if BSD < 199103 -static -bpf_timeout(arg) - caddr_t arg; -{ - struct bpf_d *d = (struct bpf_d *)arg; - d->bd_timedout = 1; - wakeup(arg); -} -#define BPF_SLEEP(chan, pri, s, t) bpf_sleep((struct bpf_d *)chan) - -int -bpf_sleep(d) - register struct bpf_d *d; -{ - register int rto = d->bd_rtout; - register int st; - - if (rto != 0) { - d->bd_timedout = 0; - timeout(bpf_timeout, (caddr_t)d, rto); - } - st = sleep((caddr_t)d, PRINET|PCATCH); - if (rto != 0) { - if (d->bd_timedout == 0) - untimeout(bpf_timeout, (caddr_t)d); - else if (st == 0) - return EWOULDBLOCK; - } - return (st != 0) ? EINTR : 0; -} -#else -#define BPF_SLEEP tsleep -#endif - /* * Rotate the packet buffers in descriptor d. Move the store buffer * into the hold slot, and the free buffer into the store slot. @@ -474,6 +435,7 @@ return (EINVAL); s = splimp(); + BPFD_LOCK(d); /* * If the hold buffer is empty, then do a timed sleep, which * ends when the timeout expires or when enough packets @@ -497,6 +459,7 @@ * it before using it again. */ if (d->bd_bif == NULL) { + BPFD_UNLOCK(d); splx(s); return (ENXIO); } @@ -504,9 +467,10 @@ if (ioflag & IO_NDELAY) error = EWOULDBLOCK; else - error = BPF_SLEEP((caddr_t)d, PRINET|PCATCH, "bpf", - d->bd_rtout); + error = msleep((caddr_t)d, &d->bd_mtx, PRINET|PCATCH, + "bpf", d->bd_rtout); if (error == EINTR || error == ERESTART) { + BPFD_UNLOCK(d); splx(s); return (error); } @@ -525,6 +489,7 @@ break; if (d->bd_slen == 0) { + BPFD_UNLOCK(d); splx(s); return (0); } @@ -535,6 +500,7 @@ /* * At this point, we know we have something in the hold slot. */ + BPFD_UNLOCK(d); splx(s); /* @@ -545,9 +511,11 @@ error = UIOMOVE(d->bd_hbuf, d->bd_hlen, UIO_READ, uio); s = splimp(); + BPFD_LOCK(d); d->bd_fbuf = d->bd_hbuf; d->bd_hbuf = 0; d->bd_hlen = 0; + BPFD_UNLOCK(d); splx(s); return (error); @@ -565,17 +533,9 @@ if (d->bd_async && d->bd_sig && d->bd_sigio) pgsigio(d->bd_sigio, d->bd_sig, 0); -#if BSD >= 199103 selwakeup(&d->bd_sel); /* XXX */ d->bd_sel.si_pid = 0; -#else - if (d->bd_selproc) { - selwakeup(d->bd_selproc, (int)d->bd_selcoll); - d->bd_selcoll = 0; - d->bd_selproc = 0; - } -#endif } static int @@ -610,11 +570,9 @@ dst.sa_family = pseudo_AF_HDRCMPLT; s = splnet(); -#if BSD >= 199103 + mtx_enter(&Giant, MTX_DEF); error = (*ifp->if_output)(ifp, m, &dst, (struct rtentry *)0); -#else - error = (*ifp->if_output)(ifp, m, &dst); -#endif + mtx_exit(&Giant, MTX_DEF); splx(s); /* * The driver frees the mbuf. @@ -624,12 +582,15 @@ /* * Reset a descriptor by flushing its packet buffer and clearing the - * receive and drop counts. Should be called at splimp. + * receive and drop counts. Should be called with the descriptor mutex + * held. */ static void reset_d(d) struct bpf_d *d; { + + mtx_assert(&d->bd_mtx, MA_OWNED); if (d->bd_hbuf) { /* Free the hold buffer. */ d->bd_fbuf = d->bd_hbuf; @@ -670,7 +631,7 @@ int flags; struct proc *p; { - register struct bpf_d *d = dev->si_drv1; + struct bpf_d *d = dev->si_drv1; int s, error = 0; switch (cmd) { @@ -687,9 +648,11 @@ int n; s = splimp(); + BPFD_LOCK(d); n = d->bd_slen; if (d->bd_hbuf) n += d->bd_hlen; + BPFD_UNLOCK(d); splx(s); *(int *)addr = n; @@ -720,9 +683,6 @@ * Set buffer length. */ case BIOCSBLEN: -#if BSD < 199103 - error = EINVAL; -#else if (d->bd_bif != 0) error = EINVAL; else { @@ -734,7 +694,6 @@ *(u_int *)addr = size = BPF_MINBUFSIZE; d->bd_bufsize = size; } -#endif break; /* @@ -749,7 +708,9 @@ */ case BIOCFLUSH: s = splimp(); + BPFD_LOCK(d); reset_d(d); + BPFD_UNLOCK(d); splx(s); break; @@ -951,8 +912,10 @@ if (fp->bf_len != 0) return (EINVAL); s = splimp(); + BPFD_LOCK(d); d->bd_filter = 0; reset_d(d); + BPFD_UNLOCK(d); splx(s); if (old != 0) free((caddr_t)old, M_BPF); @@ -967,8 +930,10 @@ if (copyin((caddr_t)fp->bf_insns, (caddr_t)fcode, size) == 0 && bpf_validate(fcode, (int)flen)) { s = splimp(); + BPFD_LOCK(d); d->bd_filter = fcode; reset_d(d); + BPFD_UNLOCK(d); splx(s); if (old != 0) free((caddr_t)old, M_BPF); @@ -990,7 +955,7 @@ struct ifreq *ifr; { struct bpf_if *bp; - int s, error; + int error; struct ifnet *theywant; theywant = ifunit(ifr->ifr_name); @@ -1000,11 +965,14 @@ /* * Look through attached interfaces for the named one. */ + BPF_LOCK; for (bp = bpf_iflist; bp != 0; bp = bp->bif_next) { struct ifnet *ifp = bp->bif_ifp; if (ifp == 0 || ifp != theywant) continue; + + BPF_UNLOCK; /* * We found the requested interface. * If it's not up, return an error. @@ -1020,7 +988,6 @@ if (error != 0) return (error); } - s = splimp(); if (bp != d->bd_bif) { if (d->bd_bif) /* @@ -1030,10 +997,12 @@ bpf_attachd(d, bp); } + BPFD_LOCK(d); reset_d(d); - splx(s); + BPFD_UNLOCK(d); return (0); } + BPF_UNLOCK; /* Not found. */ return (ENXIO); } @@ -1063,12 +1032,14 @@ return (ENXIO); s = splimp(); + BPFD_LOCK(d); if (events & (POLLIN | POLLRDNORM)) { if (d->bd_hlen != 0 || (d->bd_immediate && d->bd_slen != 0)) revents |= events & (POLLIN | POLLRDNORM); else selrecord(p, &d->bd_sel); } + BPFD_UNLOCK(d); splx(s); return (revents); } @@ -1088,18 +1059,18 @@ struct bpf_if *bp; register struct bpf_d *d; register u_int slen; - /* - * Note that the ipl does not have to be raised at this point. - * The only problem that could arise here is that if two different - * interfaces shared any data. This is not the case. - */ + bp = ifp->if_bpf; + BPFIF_LOCK(bp); for (d = bp->bif_dlist; d != 0; d = d->bd_next) { + BPFD_LOCK(d); ++d->bd_rcount; slen = bpf_filter(d->bd_filter, pkt, pktlen, pktlen); if (slen != 0) catchpacket(d, pkt, pktlen, slen, bcopy); + BPFD_UNLOCK(d); } + BPFIF_UNLOCK(bp); } /* @@ -1146,14 +1117,18 @@ for (m0 = m; m0 != 0; m0 = m0->m_next) pktlen += m0->m_len; + BPFIF_LOCK(bp); for (d = bp->bif_dlist; d != 0; d = d->bd_next) { if (!d->bd_seesent && (m->m_pkthdr.rcvif == NULL)) continue; + BPFD_LOCK(d); ++d->bd_rcount; slen = bpf_filter(d->bd_filter, (u_char *)m, pktlen, 0); if (slen != 0) catchpacket(d, (u_char *)m, pktlen, slen, bpf_mcopy); + BPFD_UNLOCK(d); } + BPFIF_UNLOCK(bp); } /* @@ -1276,6 +1251,7 @@ } if (d->bd_filter) free((caddr_t)d->bd_filter, M_BPF); + mtx_destroy(&d->bd_mtx); } /* @@ -1296,9 +1272,12 @@ bp->bif_dlist = 0; bp->bif_ifp = ifp; bp->bif_dlt = dlt; + mtx_init(&bp->bif_mtx, "bpf interface lock", MTX_DEF); + BPF_LOCK; bp->bif_next = bpf_iflist; bpf_iflist = bp; + BPF_UNLOCK; bp->bif_ifp->if_bpf = 0; @@ -1329,6 +1308,7 @@ int s; s = splimp(); + BPF_LOCK; /* Locate BPF interface information */ bp_prev = NULL; @@ -1340,25 +1320,30 @@ /* Interface wasn't attached */ if (bp->bif_ifp == NULL) { + BPF_UNLOCK; splx(s); printf("bpfdetach: %s%d was not attached\n", ifp->if_name, ifp->if_unit); return; } - while ((d = bp->bif_dlist) != NULL) { - bpf_detachd(d); - bpf_wakeup(d); - } - if (bp_prev) { bp_prev->bif_next = bp->bif_next; } else { bpf_iflist = bp->bif_next; } + while ((d = bp->bif_dlist) != NULL) { + bpf_detachd(d); + BPFD_LOCK(d); + bpf_wakeup(d); + BPFD_UNLOCK(d); + } + + mtx_destroy(&bp->bif_mtx); free(bp, M_BPF); + BPF_UNLOCK; splx(s); } @@ -1390,6 +1375,7 @@ void *unused; { + mtx_init(&bpf_mtx, "bpf global lock", MTX_DEF); EVENTHANDLER_REGISTER(dev_clone, bpf_clone, 0, 1000); cdevsw_add(&bpf_cdevsw); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Nov 26 10:30:59 2000 Delivered-To: freebsd-smp@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 5DF8537B479; Sun, 26 Nov 2000 10:30:57 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eAQIUvb01899; Sun, 26 Nov 2000 10:30:57 -0800 (PST) Date: Sun, 26 Nov 2000 10:30:57 -0800 From: Alfred Perlstein To: smp@freebsd.org Cc: jhb@freebsd.org Subject: sysctl for DEBUG_MUTEX? Message-ID: <20001126103056.T8051@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I was wondering if it was possible to change DEBUG_MUTEX such that it sets up a sysctl that one could flip on and off so that those of us using it only have to pay the penalty when we're interested in the debugging. Tor Egge explained that he doesn't have the painfully slow disk access when he removes the DEBUG_MUTEX option. I'm going to take a quick look at it, the idea would be to hook a sysctl proc (sysctl handler) that would setup/teardown the DEBUG_MUTEX state. We'd still need a global lock for the linked list of mutexes, however all the expensive validation stuff would be done only when the sysctl was on, otherwise they'd just be linked together. John has been working on the mutex stuff for quite a while and if he wanted to do this it would probably go a lot smoother that if I tried. *nudge* :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Nov 26 13: 0:34 2000 Delivered-To: freebsd-smp@freebsd.org Received: from io.yi.org (unknown [24.70.218.157]) by hub.freebsd.org (Postfix) with ESMTP id 535DE37B479; Sun, 26 Nov 2000 13:00:15 -0800 (PST) Received: from io.yi.org (localhost.gvcl1.bc.wave.home.com [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id D824BBA7A; Sun, 26 Nov 2000 13:00:14 -0800 (PST) X-Mailer: exmh version 2.1.1 10/15/1999 To: arch@freebsd.org Cc: smp@freebsd.org Subject: review: callout patch Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 26 Nov 2000 13:00:14 -0800 From: Jake Burkholder Message-Id: <20001126210014.D824BBA7A@io.yi.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This patch makes most of sys/kern/* sources use callout_reset for registering callouts rather than timeout(9). This should greatly reduce the use of the fixed size callfree allocator pool. Currently we panic when it runs out. This was motivated by NetBSD, who have completely removed timeout(9) from their kernel. Please review it. Index: compat/linux/linux_misc.c =================================================================== RCS file: /home/ncvs/src/sys/compat/linux/linux_misc.c,v retrieving revision 1.88 diff -u -r1.88 linux_misc.c --- compat/linux/linux_misc.c 2000/11/10 21:30:18 1.88 +++ compat/linux/linux_misc.c 2000/11/26 00:55:05 @@ -115,9 +115,9 @@ old_it = p->p_realtimer; getmicrouptime(&tv); if (timevalisset(&old_it.it_value)) - untimeout(realitexpire, (caddr_t)p, p->p_ithandle); + callout_stop(&p->p_itcallout); if (it.it_value.tv_sec != 0) { - p->p_ithandle = timeout(realitexpire, (caddr_t)p, tvtohz(&it.it_value)); + callout_reset(&p->p_itcallout, tvtohz(&it.it_value), realitexpire, p); timevaladd(&it.it_value, &tv); } p->p_realtimer = it; Index: kern/init_main.c =================================================================== RCS file: /home/ncvs/src/sys/kern/init_main.c,v retrieving revision 1.147 diff -u -r1.147 init_main.c --- kern/init_main.c 2000/11/22 07:41:57 1.147 +++ kern/init_main.c 2000/11/26 00:21:00 @@ -312,6 +312,9 @@ bcopy("swapper", p->p_comm, sizeof ("swapper")); + callout_init(&p->p_itcallout, 0); + callout_init(&p->p_slpcallout, 0); + /* Create credentials. */ cred0.p_refcnt = 1; cred0.p_uidinfo = uifind(0); Index: kern/kern_acct.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_acct.c,v retrieving revision 1.26 diff -u -r1.26 kern_acct.c --- kern/kern_acct.c 2000/07/04 03:34:06 1.26 +++ kern/kern_acct.c 2000/11/26 07:30:52 @@ -77,11 +77,9 @@ static void acctwatch __P((void *)); /* - * Accounting callout handle used for periodic scheduling of - * acctwatch. + * Accounting callout used for periodic scheduling of acctwatch. */ -static struct callout_handle acctwatch_handle - = CALLOUT_HANDLE_INITIALIZER(&acctwatch_handle); +static struct callout acctwatch_callout; /* * Accounting vnode pointer, and saved vnode pointer. @@ -148,7 +146,7 @@ * close the file, and (if no new file was specified, leave). */ if (acctp != NULLVP || savacctp != NULLVP) { - untimeout(acctwatch, NULL, acctwatch_handle); + callout_stop(&acctwatch_callout); error = vn_close((acctp != NULLVP ? acctp : savacctp), FWRITE, p->p_ucred, p); acctp = savacctp = NULLVP; @@ -161,6 +159,7 @@ * free space watcher. */ acctp = nd.ni_vp; + callout_init(&acctwatch_callout, 0); acctwatch(NULL); return (error); } @@ -329,5 +328,5 @@ log(LOG_NOTICE, "Accounting suspended\n"); } } - acctwatch_handle = timeout(acctwatch, NULL, acctchkfreq * hz); + callout_reset(&acctwatch_callout, acctchkfreq * hz, acctwatch, NULL); } Index: kern/kern_exit.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_exit.c,v retrieving revision 1.104 diff -u -r1.104 kern_exit.c --- kern/kern_exit.c 2000/11/22 07:41:58 1.104 +++ kern/kern_exit.c 2000/11/26 00:05:38 @@ -172,7 +172,7 @@ p->p_flag |= P_WEXIT; SIGEMPTYSET(p->p_siglist); if (timevalisset(&p->p_realtimer.it_value)) - untimeout(realitexpire, (caddr_t)p, p->p_ithandle); + callout_stop(&p->p_itcallout); /* * Reset any sigio structures pointing to us as a result of Index: kern/kern_fork.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_fork.c,v retrieving revision 1.84 diff -u -r1.84 kern_fork.c --- kern/kern_fork.c 2000/11/22 07:41:58 1.84 +++ kern/kern_fork.c 2000/11/26 00:20:48 @@ -483,6 +483,9 @@ LIST_INIT(&p2->p_heldmtx); LIST_INIT(&p2->p_contested); + callout_init(&p2->p_itcallout, 0); + callout_init(&p2->p_slpcallout, 0); + #ifdef KTRACE /* * Copy traceflag and tracefile if enabled. Index: kern/kern_synch.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_synch.c,v retrieving revision 1.110 diff -u -r1.110 kern_synch.c --- kern/kern_synch.c 2000/11/22 07:41:58 1.110 +++ kern/kern_synch.c 2000/11/26 00:55:54 @@ -70,6 +70,9 @@ int lbolt; int sched_quantum; /* Roundrobin scheduling quantum in ticks. */ +static struct callout schedcpu_callout; +static struct callout roundrobin_callout; + static int curpriority_cmp __P((struct proc *p)); static void endtsleep __P((void *)); static void maybe_resched __P((struct proc *chk)); @@ -175,7 +178,7 @@ need_resched(); #endif - timeout(roundrobin, NULL, sched_quantum); + callout_reset(&roundrobin_callout, sched_quantum, roundrobin, NULL); } /* @@ -344,7 +347,7 @@ lockmgr(&allproc_lock, LK_RELEASE, NULL, CURPROC); vmmeter(); wakeup((caddr_t)&lbolt); - timeout(schedcpu, (void *)0, hz); + callout_reset(&schedcpu_callout, hz, schedcpu, NULL); } /* @@ -414,7 +417,6 @@ { struct proc *p = curproc; int s, sig, catch = priority & PCATCH; - struct callout_handle thandle; int rval = 0; WITNESS_SAVE_DECL(mtx); @@ -465,7 +467,7 @@ p, p->p_pid, p->p_comm, (void *) sched_lock.mtx_lock); TAILQ_INSERT_TAIL(&slpque[LOOKUP(ident)], p, p_slpq); if (timo) - thandle = timeout(endtsleep, (void *)p, timo); + callout_reset(&p->p_slpcallout, timo, endtsleep, p); /* * We put ourselves on the sleep queue and start our timeout * before calling CURSIG, as we could stop there, and a wakeup @@ -517,7 +519,7 @@ goto out; } } else if (timo) - untimeout(endtsleep, (void *)p, thandle); + callout_stop(&p->p_slpcallout); mtx_exit(&sched_lock, MTX_SPIN); if (catch && (sig != 0 || (sig = CURSIG(p)))) { @@ -628,7 +630,6 @@ s = splhigh(); if (p->p_wchan != NULL) { - struct callout_handle thandle; int sig; int catch; @@ -646,7 +647,7 @@ */ if (timo) - thandle = timeout(endtsleep, (void *)p, timo); + callout_reset(&p->p_slpcallout, timo, endtsleep, p); sig = 0; catch = priority & PCATCH; @@ -687,7 +688,7 @@ goto out; } } else if (timo) - untimeout(endtsleep, (void *)p, thandle); + callout_stop(&p->p_slpcallout); mtx_exit(&sched_lock, MTX_SPIN); if (catch && (sig != 0 || (sig = CURSIG(p)))) { @@ -1036,6 +1037,10 @@ sched_setup(dummy) void *dummy; { + + callout_init(&schedcpu_callout, 1); + callout_init(&roundrobin_callout, 0); + /* Kick off timeout driven events by calling first time. */ roundrobin(NULL); schedcpu(NULL); Index: kern/kern_time.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_time.c,v retrieving revision 1.70 diff -u -r1.70 kern_time.c --- kern/kern_time.c 2000/04/18 15:15:20 1.70 +++ kern/kern_time.c 2000/11/26 01:13:48 @@ -513,10 +513,10 @@ s = splclock(); /* XXX: still needed ? */ if (uap->which == ITIMER_REAL) { if (timevalisset(&p->p_realtimer.it_value)) - untimeout(realitexpire, (caddr_t)p, p->p_ithandle); + callout_stop(&p->p_itcallout); if (timevalisset(&aitv.it_value)) - p->p_ithandle = timeout(realitexpire, (caddr_t)p, - tvtohz(&aitv.it_value)); + callout_reset(&p->p_itcallout, tvtohz(&aitv.it_value), + realitexpire, p); getmicrouptime(&ctv); timevaladd(&aitv.it_value, &ctv); p->p_realtimer = aitv; @@ -560,8 +560,8 @@ if (timevalcmp(&p->p_realtimer.it_value, &ctv, >)) { ntv = p->p_realtimer.it_value; timevalsub(&ntv, &ctv); - p->p_ithandle = timeout(realitexpire, (caddr_t)p, - tvtohz(&ntv) - 1); + callout_reset(&p->p_itcallout, tvtohz(&ntv) - 1, + realitexpire, p); splx(s); return; } Index: kern/uipc_domain.c =================================================================== RCS file: /home/ncvs/src/sys/kern/uipc_domain.c,v retrieving revision 1.22 diff -u -r1.22 uipc_domain.c --- kern/uipc_domain.c 1999/08/28 00:46:21 1.22 +++ kern/uipc_domain.c 2000/11/26 07:09:06 @@ -61,6 +61,9 @@ static void domaininit __P((void *)); SYSINIT(domain, SI_SUB_PROTO_DOMAIN, SI_ORDER_FIRST, domaininit, NULL) +static struct callout pffast_callout; +static struct callout pfslow_callout; + static void pffasttimo __P((void *)); static void pfslowtimo __P((void *)); @@ -136,9 +139,12 @@ if (max_linkhdr < 16) /* XXX */ max_linkhdr = 16; + + callout_init(&pffast_callout, 0); + callout_init(&pfslow_callout, 0); - timeout(pffasttimo, (void *)0, 1); - timeout(pfslowtimo, (void *)0, 1); + callout_reset(&pffast_callout, 1, pffasttimo, NULL); + callout_reset(&pfslow_callout, 1, pfslowtimo, NULL); } @@ -214,7 +220,7 @@ for (pr = dp->dom_protosw; pr < dp->dom_protoswNPROTOSW; pr++) if (pr->pr_slowtimo) (*pr->pr_slowtimo)(); - timeout(pfslowtimo, (void *)0, hz/2); + callout_reset(&pfslow_callout, hz/2, pfslowtimo, NULL); } static void @@ -228,5 +234,5 @@ for (pr = dp->dom_protosw; pr < dp->dom_protoswNPROTOSW; pr++) if (pr->pr_fasttimo) (*pr->pr_fasttimo)(); - timeout(pffasttimo, (void *)0, hz/5); + callout_reset(&pffast_callout, hz/5, pffasttimo, NULL); } Index: sys/proc.h =================================================================== RCS file: /home/ncvs/src/sys/sys/proc.h,v retrieving revision 1.124 diff -u -r1.124 proc.h --- sys/proc.h 2000/11/22 07:42:01 1.124 +++ sys/proc.h 2000/11/26 00:28:23 @@ -157,10 +157,6 @@ LIST_ENTRY(proc) p_sibling; /* List of sibling processes. */ LIST_HEAD(, proc) p_children; /* Pointer to list of children. */ - struct callout_handle p_ithandle; /* - * Callout handle for scheduling - * p_realtimer. - */ /* The following fields are all zeroed upon creation in fork. */ #define p_startzero p_oppid @@ -173,11 +169,13 @@ u_int p_estcpu; /* Time averaged value of p_cpticks. */ int p_cpticks; /* Ticks of cpu time. */ fixpt_t p_pctcpu; /* %cpu for this process during p_swtime */ + struct callout p_slpcallout; /* Callout for sleep. */ void *p_wchan; /* Sleep address. */ const char *p_wmesg; /* Reason for sleep. */ u_int p_swtime; /* Time swapped in or out. */ u_int p_slptime; /* Time since last blocked. */ + struct callout p_itcallout; /* Interval timer callout. */ struct itimerval p_realtimer; /* Alarm timer. */ u_int64_t p_runtime; /* Real time in microsec. */ u_int64_t p_uu; /* Previous user time in microsec. */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Nov 26 13:45: 3 2000 Delivered-To: freebsd-smp@freebsd.org Received: from thelab.hub.org (CDR22-173.accesscable.net [24.138.22.173]) by hub.freebsd.org (Postfix) with ESMTP id 3EE5937B479; Sun, 26 Nov 2000 13:44:59 -0800 (PST) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.11.1/8.11.1) with ESMTP id eAQLiOm67228; Sun, 26 Nov 2000 17:44:24 -0400 (AST) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Sun, 26 Nov 2000 17:44:24 -0400 (AST) From: The Hermit Hacker To: Alfred Perlstein Cc: smp@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: disk IO terrible in smpng? In-Reply-To: <20001125112853.P8051@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is this with the latest -current? I'm noticing some unexpected lags on my machine recently, but hadn't looked as far as the I/O yet ... I'm still getting the periodic system hangs, where I have to hit the reset button, so figured it was all inter-laced with that ... On Sat, 25 Nov 2000, Alfred Perlstein wrote: > I've been trying to generate some patches on a SMPng box, but the > IO is killing me, anything disk bound seems to hog the CPU > and make the machine terribly sluggish. > > Is this to be expected? > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Nov 26 13:56:49 2000 Delivered-To: freebsd-smp@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 1324A37B479; Sun, 26 Nov 2000 13:56:46 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id eAQLtQ433741; Sun, 26 Nov 2000 15:55:26 -0600 (CST) (envelope-from jlemon) Date: Sun, 26 Nov 2000 15:55:26 -0600 From: Jonathan Lemon To: Jake Burkholder Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: review: callout patch Message-ID: <20001126155526.K69183@prism.flugsvamp.com> References: <20001126210014.D824BBA7A@io.yi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20001126210014.D824BBA7A@io.yi.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Nov 26, 2000 at 01:00:14PM -0800, Jake Burkholder wrote: > > This patch makes most of sys/kern/* sources use callout_reset for > registering callouts rather than timeout(9). This should greatly > reduce the use of the fixed size callfree allocator pool. Currently > we panic when it runs out. > > This was motivated by NetBSD, who have completely removed timeout(9) > from their kernel. Looks good to me. I was moving the the same direction, but didn't know that NetBSD had already done this. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Nov 26 14: 7:52 2000 Delivered-To: freebsd-smp@freebsd.org Received: from io.yi.org (unknown [24.70.218.157]) by hub.freebsd.org (Postfix) with ESMTP id 08FA937B479 for ; Sun, 26 Nov 2000 14:07:50 -0800 (PST) Received: from io.yi.org (localhost.gvcl1.bc.wave.home.com [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id BFB35BA7A for ; Sun, 26 Nov 2000 14:07:49 -0800 (PST) X-Mailer: exmh version 2.1.1 10/15/1999 To: smp@freebsd.org Subject: BSD/OS interrupt code Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 26 Nov 2000 14:07:49 -0800 From: Jake Burkholder Message-Id: <20001126220749.BFB35BA7A@io.yi.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, If anyone with access to the BSD/OS code is interested, I've written a little program that runs their interrupt stub code generator in userland. You can then abort(); and disassemble the stub from the core dump to look at the code all in one piece. Makes it much easier to follow. In case you haven't looked, their interrupt handlers are generated by bcopy-ing various blocks of assembler code into an array at runtime, and then poking in arguments and relocating branches. Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Nov 26 14:12: 9 2000 Delivered-To: freebsd-smp@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 0749937B479; Sun, 26 Nov 2000 14:12:07 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eAQMC4E08332; Sun, 26 Nov 2000 14:12:04 -0800 (PST) Date: Sun, 26 Nov 2000 14:12:04 -0800 From: Alfred Perlstein To: The Hermit Hacker Cc: smp@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: disk IO terrible in smpng? Message-ID: <20001126141204.Y8051@fw.wintelcom.net> References: <20001125112853.P8051@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from scrappy@hub.org on Sun, Nov 26, 2000 at 05:44:24PM -0400 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Sat, 25 Nov 2000, Alfred Perlstein wrote: > > > I've been trying to generate some patches on a SMPng box, but the > > IO is killing me, anything disk bound seems to hog the CPU > > and make the machine terribly sluggish. > > > > Is this to be expected? * The Hermit Hacker [001126 13:45] wrote: > > Is this with the latest -current? I'm noticing some unexpected lags on my > machine recently, but hadn't looked as far as the I/O yet ... I'm still > getting the periodic system hangs, where I have to hit the reset button, > so figured it was all inter-laced with that ... > This is with -current from yesterday, Tor Egge told me to remove some of the debugging code like MUTEX_DEBUG and the WITNESS stuff, it seems quicker now. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Nov 26 14:16:47 2000 Delivered-To: freebsd-smp@freebsd.org Received: from thelab.hub.org (CDR22-173.accesscable.net [24.138.22.173]) by hub.freebsd.org (Postfix) with ESMTP id 7DE7237B479; Sun, 26 Nov 2000 14:16:44 -0800 (PST) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.11.1/8.11.1) with ESMTP id eAQMG5u84299; Sun, 26 Nov 2000 18:16:05 -0400 (AST) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Sun, 26 Nov 2000 18:16:05 -0400 (AST) From: The Hermit Hacker To: Alfred Perlstein Cc: smp@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: disk IO terrible in smpng? In-Reply-To: <20001126141204.Y8051@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 26 Nov 2000, Alfred Perlstein wrote: > > On Sat, 25 Nov 2000, Alfred Perlstein wrote: > > > > > I've been trying to generate some patches on a SMPng box, but the > > > IO is killing me, anything disk bound seems to hog the CPU > > > and make the machine terribly sluggish. > > > > > > Is this to be expected? > > * The Hermit Hacker [001126 13:45] wrote: > > > > Is this with the latest -current? I'm noticing some unexpected lags on my > > machine recently, but hadn't looked as far as the I/O yet ... I'm still > > getting the periodic system hangs, where I have to hit the reset button, > > so figured it was all inter-laced with that ... > > > > This is with -current from yesterday, Tor Egge told me to remove > some of the debugging code like MUTEX_DEBUG and the WITNESS > stuff, it seems quicker now. 'K, definitely not my problem ... I don't have any of that turned on ... ah well, isn't killing me too much, just grin and bear it :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Nov 26 16:20:48 2000 Delivered-To: freebsd-smp@freebsd.org Received: from echunga.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id 6CAEA37B4C5 for ; Sun, 26 Nov 2000 16:20:44 -0800 (PST) Received: (from grog@localhost) by echunga.lemis.com (8.11.1/8.9.3) id eAR0BmK27419; Mon, 27 Nov 2000 10:41:48 +1030 (CST) (envelope-from grog) Date: Mon, 27 Nov 2000 10:41:48 +1030 From: Greg Lehey To: Jake Burkholder Cc: smp@FreeBSD.ORG Subject: Re: BSD/OS interrupt code Message-ID: <20001127104147.B27186@echunga.lemis.com> References: <20001126220749.BFB35BA7A@io.yi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001126220749.BFB35BA7A@io.yi.org>; from jburkhol@home.com on Sun, Nov 26, 2000 at 02:07:49PM -0800 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sunday, 26 November 2000 at 14:07:49 -0800, Jake Burkholder wrote: > Hi, > > If anyone with access to the BSD/OS code is interested, I've written > a little program that runs their interrupt stub code generator in > userland. You can then abort(); and disassemble the stub from > the core dump to look at the code all in one piece. Makes it much > easier to follow. > > In case you haven't looked, their interrupt handlers are generated > by bcopy-ing various blocks of assembler code into an array at > runtime, and then poking in arguments and relocating branches. Interesting. I was wondering whether something similar would be a good idea. On the other hand, We don't waste much space by having multiple alternate stubs. What's your feeling? Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Nov 26 17:50: 8 2000 Delivered-To: freebsd-smp@freebsd.org Received: from io.yi.org (unknown [24.70.218.157]) by hub.freebsd.org (Postfix) with ESMTP id 65E0B37B479 for ; Sun, 26 Nov 2000 17:50:06 -0800 (PST) Received: from io.yi.org (localhost.gvcl1.bc.wave.home.com [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id 5B7BDBA7A; Sun, 26 Nov 2000 17:50:06 -0800 (PST) X-Mailer: exmh version 2.1.1 10/15/1999 To: Greg Lehey Cc: smp@FreeBSD.ORG Subject: Re: BSD/OS interrupt code In-Reply-To: Message from Greg Lehey of "Mon, 27 Nov 2000 10:41:48 +1030." <20001127104147.B27186@echunga.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 26 Nov 2000 17:50:06 -0800 From: Jake Burkholder Message-Id: <20001127015006.5B7BDBA7A@io.yi.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Sunday, 26 November 2000 at 14:07:49 -0800, Jake Burkholder wrote: > > Hi, > > > > If anyone with access to the BSD/OS code is interested, I've written > > a little program that runs their interrupt stub code generator in > > userland. You can then abort(); and disassemble the stub from > > the core dump to look at the code all in one piece. Makes it much > > easier to follow. > > > > In case you haven't looked, their interrupt handlers are generated > > by bcopy-ing various blocks of assembler code into an array at > > runtime, and then poking in arguments and relocating branches. > > Interesting. I was wondering whether something similar would be a > good idea. On the other hand, We don't waste much space by having > multiple alternate stubs. What's your feeling? I suspect that it would be hard to do this for architectures other than x86, which has a relatively simple instruction format. I also think that BSD/OS went a little too far with this, and have produced code that is very difficult to understand, let alone maintain. I think its cool what they did, I'm humbled and amazed that they made it work, but I don't know that its right for FreeBSD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Nov 26 18: 6:53 2000 Delivered-To: freebsd-smp@freebsd.org Received: from echunga.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id C270937B479 for ; Sun, 26 Nov 2000 18:06:48 -0800 (PST) Received: (from grog@localhost) by echunga.lemis.com (8.11.1/8.9.3) id eAR1vaF28731; Mon, 27 Nov 2000 12:27:36 +1030 (CST) (envelope-from grog) Date: Mon, 27 Nov 2000 12:27:36 +1030 From: Greg Lehey To: Jake Burkholder Cc: smp@FreeBSD.ORG Subject: Re: BSD/OS interrupt code Message-ID: <20001127122736.G27697@echunga.lemis.com> References: <20001127015006.5B7BDBA7A@io.yi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001127015006.5B7BDBA7A@io.yi.org>; from jburkhol@home.com on Sun, Nov 26, 2000 at 05:50:06PM -0800 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sunday, 26 November 2000 at 17:50:06 -0800, Jake Burkholder wrote: >> On Sunday, 26 November 2000 at 14:07:49 -0800, Jake Burkholder wrote: >>> Hi, >>> >>> If anyone with access to the BSD/OS code is interested, I've written >>> a little program that runs their interrupt stub code generator in >>> userland. You can then abort(); and disassemble the stub from >>> the core dump to look at the code all in one piece. Makes it much >>> easier to follow. >>> >>> In case you haven't looked, their interrupt handlers are generated >>> by bcopy-ing various blocks of assembler code into an array at >>> runtime, and then poking in arguments and relocating branches. >> >> Interesting. I was wondering whether something similar would be a >> good idea. On the other hand, We don't waste much space by having >> multiple alternate stubs. What's your feeling? > > I suspect that it would be hard to do this for architectures > other than x86, which has a relatively simple instruction format. > > I also think that BSD/OS went a little too far with this, and > have produced code that is very difficult to understand, let > alone maintain. I think its cool what they did, I'm humbled > and amazed that they made it work, but I don't know that its > right for FreeBSD. That's a reasonable objection. Where's your program? Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Nov 26 18:39:27 2000 Delivered-To: freebsd-smp@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id B6F0C37B479 for ; Sun, 26 Nov 2000 18:39:24 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id eAR2c4R55543; Sun, 26 Nov 2000 20:38:04 -0600 (CST) (envelope-from jlemon) Date: Sun, 26 Nov 2000 20:38:04 -0600 (CST) From: Jonathan Lemon Message-Id: <200011270238.eAR2c4R55543@prism.flugsvamp.com> To: jburkhol@home.com, smp@freebsd.org Subject: Re: BSD/OS interrupt code X-Newsgroups: local.mail.freebsd-smp In-Reply-To: References: Organization: Cc: Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you write: >I also think that BSD/OS went a little too far with this, and >have produced code that is very difficult to understand, let >alone maintain. I think its cool what they did, I'm humbled >and amazed that they made it work, but I don't know that its >right for FreeBSD. Seconded. This pretty much sums up my feeling too. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Nov 26 20:14: 2 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mobile.wemm.org (adsl-64-163-195-99.dsl.snfc21.pacbell.net [64.163.195.99]) by hub.freebsd.org (Postfix) with ESMTP id 0F40F37B4C5 for ; Sun, 26 Nov 2000 20:13:59 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id eAR46wD45035; Sun, 26 Nov 2000 20:06:58 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200011270406.eAR46wD45035@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jake Burkholder Cc: Greg Lehey , smp@FreeBSD.ORG Subject: Re: BSD/OS interrupt code In-Reply-To: <20001127015006.5B7BDBA7A@io.yi.org> Date: Sun, 26 Nov 2000 20:06:58 -0800 From: Peter Wemm Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jake Burkholder wrote: > > On Sunday, 26 November 2000 at 14:07:49 -0800, Jake Burkholder wrote: > > > Hi, > > > > > > If anyone with access to the BSD/OS code is interested, I've written > > > a little program that runs their interrupt stub code generator in > > > userland. You can then abort(); and disassemble the stub from > > > the core dump to look at the code all in one piece. Makes it much > > > easier to follow. > > > > > > In case you haven't looked, their interrupt handlers are generated > > > by bcopy-ing various blocks of assembler code into an array at > > > runtime, and then poking in arguments and relocating branches. > > > > Interesting. I was wondering whether something similar would be a > > good idea. On the other hand, We don't waste much space by having > > multiple alternate stubs. What's your feeling? > > I suspect that it would be hard to do this for architectures > other than x86, which has a relatively simple instruction format. > > I also think that BSD/OS went a little too far with this, and > have produced code that is very difficult to understand, let > alone maintain. I think its cool what they did, I'm humbled > and amazed that they made it work, but I don't know that its > right for FreeBSD. I was looking at taking a shot at doing something like this a few days ago. While in .au I went through the leftovers of our old interrupt code and did a cleanup. I also made the APIC code support 32 hardware IRQ sources instead of the old 24 limit. The 24->32 IRQ change affected no less than 6 or 7 places where there are static tables. It is kind of a shame that we're still stuck with it given the large multi-pci bus systems we're running into these days with 32 or 48 hardware interrupt sources. The other reason for looking at this was for certain broken hardware that has IRQ sources connected *only* to the PIC (ie: the apic pin connection is missing). Right now, we cheat by using *one* pic source in auto-EOI mode and daisy-chaining it all to the APIC. This doesn't work if the PIC->APIC interlink is missing (as I believe it is on this box) or there are multiple PIC-only interrupt sources that we need (ie: timer0 and rtc). I dont have the actual hardware in my hands yet, but I have an awful feeling that it is going to require running the PIC *and* APIC at the same time, with different IDT vectors. The stub generation code might help keep down the cost of replicating another 16 sets of slow and fast interrupt handlers.. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Nov 26 21: 7:26 2000 Delivered-To: freebsd-smp@freebsd.org Received: from io.yi.org (unknown [24.70.218.157]) by hub.freebsd.org (Postfix) with ESMTP id 2D5A137B479 for ; Sun, 26 Nov 2000 21:07:20 -0800 (PST) Received: from io.yi.org (localhost.gvcl1.bc.wave.home.com [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id 89779BA7A for ; Sun, 26 Nov 2000 21:07:19 -0800 (PST) X-Mailer: exmh version 2.1.1 10/15/1999 To: smp@FreeBSD.ORG Subject: Re: BSD/OS interrupt code In-Reply-To: Message from Greg Lehey of "Mon, 27 Nov 2000 12:27:36 +1030." <20001127122736.G27697@echunga.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 26 Nov 2000 21:07:19 -0800 From: Jake Burkholder Message-Id: <20001127050719.89779BA7A@io.yi.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > That's a reasonable objection. Where's your program? > I didn't change any copyrights and its not being intergrated into FreeBSD, so I don't know about the legality of posting this stuff publicly. If anyone else wants it email me privately. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 27 1:33:59 2000 Delivered-To: freebsd-smp@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id A339437B479; Mon, 27 Nov 2000 01:33:56 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.1/8.11.1) id eAR9Yio49857; Mon, 27 Nov 2000 01:34:44 -0800 (PST) (envelope-from kris) Date: Mon, 27 Nov 2000 01:34:44 -0800 From: Kris Kennaway To: The Hermit Hacker Cc: Alfred Perlstein , smp@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: disk IO terrible in smpng? Message-ID: <20001127013444.A49774@citusc17.usc.edu> References: <20001126141204.Y8051@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from scrappy@hub.org on Sun, Nov 26, 2000 at 06:16:05PM -0400 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Nov 26, 2000 at 06:16:05PM -0400, The Hermit Hacker wrote: > > This is with -current from yesterday, Tor Egge told me to remove > > some of the debugging code like MUTEX_DEBUG and the WITNESS > > stuff, it seems quicker now. Ah, I wondered what that was. Doing e.g. a cvs update can cause my machine to spend 90% CPU time in the kernel. I'll remove the debug options. > 'K, definitely not my problem ... I don't have any of that turned on > ... ah well, isn't killing me too much, just grin and bear it :) That might have been a problem with /dev/random..Mark committed a change to not make it malloc all the time, I havent had a wedge since then and I've been stressing my system reasonably hard today. Kris --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjoiKrQACgkQWry0BWjoQKWEJQCfaolL9bY8N6/2lpFpXaYe8hxL PR4AoNK90J1jIBCMeyHgE40GnXfkqr6P =F2b8 -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 27 5:55:51 2000 Delivered-To: freebsd-smp@freebsd.org Received: from averroe.polito.it (averroe.polito.it [130.192.4.32]) by hub.freebsd.org (Postfix) with SMTP id D910437B479 for ; Mon, 27 Nov 2000 05:55:47 -0800 (PST) Received: (qmail 4760 invoked by uid 10003); 27 Nov 2000 13:55:32 -0000 Received: from demostene.polito.it (HELO demostene.sb.polito.it) (130.192.4.73) by averroe.polito.it with SMTP; 27 Nov 2000 13:55:32 -0000 Message-Id: <5.0.1.4.0.20001127143906.00a68290@sbpop.polito.it> X-Sender: tealdi@sbpop.polito.it X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Mon, 27 Nov 2000 14:55:34 +0100 To: freebsd-hardware@frebbsd.org, freebsd-smp@freebsd.org From: paolo tealdi Subject: Compaq DL370 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello all. I'm trying to annoy again with DL370 telenovela.... Today arrived me the first system and ... tadaa i tried to install 4.2 Freebsd. All seemed to go well, no problem with SCSI DISK configuration at all, the server bootstrapped very well (SCSI disk is seen by sym driver ... but .... I tried to recompile the kernel with SMP option and when i boot the new kernel the system hung after written this little log ----------------------------------------- .... blah blah .... real memory = 268419072 (262128 K bytes) avail memory = 256995328 (250976 K bytes) Changing APIC ID for IO APIC #0 from 0 to 8 on chip Programming 35 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 IOAPIC #0 intpin 24 -> irq 16 IOAPIC #0 intpin 25 -> irq 2 sleep -------------------------- What can i do/try ? Is there any configuration to do on server setup to make the system bootstrapping ? A kernel debugging can be useful (i don't know if it is possible to do kernel debugging at boot startup) ? Very nasty things .... Best regards, Paolo Tealdi Ing. Paolo Tealdi Library & News System Administrator Politecnico Torino Phone : +39-011-5646714 , FAX : +39-011-5646799 C.so D. degli Abruzzi, 24 - 10129 Torino - ITALY Email : tealdi@sb.polito.it To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 27 10:33: 4 2000 Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 9F12B37B479; Mon, 27 Nov 2000 10:32:53 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eARIWpC39794; Mon, 27 Nov 2000 10:32:51 -0800 (PST) (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: <20001126210014.D824BBA7A@io.yi.org> Date: Mon, 27 Nov 2000 10:33:04 -0800 (PST) From: John Baldwin To: Jake Burkholder Subject: RE: review: callout patch Cc: smp@FreeBSD.org, arch@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 26-Nov-00 Jake Burkholder wrote: > > This patch makes most of sys/kern/* sources use callout_reset for > registering callouts rather than timeout(9). This should greatly > reduce the use of the fixed size callfree allocator pool. Currently > we panic when it runs out. > > This was motivated by NetBSD, who have completely removed timeout(9) > from their kernel. > > Please review it. Looks good to me. :) Having a callout.9 manpage to go along with it would be nice as well. :) -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 27 10:33: 7 2000 Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 18A3337B4D7 for ; Mon, 27 Nov 2000 10:32:59 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eARIWlC39789; Mon, 27 Nov 2000 10:32:51 -0800 (PST) (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: <20001126110554.H69183@prism.flugsvamp.com> Date: Mon, 27 Nov 2000 10:32:59 -0800 (PST) From: John Baldwin To: Jonathan Lemon Subject: RE: patch to make bpf mpsafe Cc: smp@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 26-Nov-00 Jonathan Lemon wrote: > Attached is a patch to make bpf mpsafe (and also cleans up some cruft). > BPF happened to be the first subsystem called by ether_input, so was the > first thing that I looked at. > > 3 levels of mutexes are added: > > bpf_mtx - global to BPF, protects BPF interface list, device open > (bif_next, bif_ifp) > bpf interface mtx - protects per-interface descriptor list > (bd_next, bd_bif, ifp->if_bpf) > bpf descriptor mtx - protects fields in the individual descriptor. > > Locking order is top to bottom, but the hierarchy can be entered at > any point. > > Network drivers start by locking the interface mutex, then walking the > list, locking each descriptor as it is manipulated. > > User level code reading from the bpf descriptor sleeps on the descriptor > mutex. This has been lightly tested with an mpsafe network driver. > Comments welcome. Couple of things: - need to add the explicit lock order to the witness code :) - go ahead and kill the splimp()'s. If this is all they are protecting and they are now protected by mutexes, the spl()'s can die. They just obfuscate the code otherwise. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 27 10:33:10 2000 Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id CF70B37B4C5 for ; Mon, 27 Nov 2000 10:32:53 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eARIWqC39798; Mon, 27 Nov 2000 10:32:52 -0800 (PST) (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: <20001126220749.BFB35BA7A@io.yi.org> Date: Mon, 27 Nov 2000 10:33:05 -0800 (PST) From: John Baldwin To: Jake Burkholder Subject: RE: BSD/OS interrupt code Cc: smp@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 26-Nov-00 Jake Burkholder wrote: > Hi, > > If anyone with access to the BSD/OS code is interested, I've written > a little program that runs their interrupt stub code generator in > userland. You can then abort(); and disassemble the stub from > the core dump to look at the code all in one piece. Makes it much > easier to follow. > > In case you haven't looked, their interrupt handlers are generated > by bcopy-ing various blocks of assembler code into an array at > runtime, and then poking in arguments and relocating branches. Hmm. The best way to do this probably is to have stubs with psuedo-relocation information. I.e., have 1 stub interrupt handler template for each type (fast, threaded, fast apic, threaded apic, etc.), then have a "relocation" table on the side that specifies offsets in the code that should receive one of a number of things: vector number, vector address, etc. Alternatively, we could store all of that info in a struct (gee, we already do with intrhand :)) and just have the code always dereference a pointer to that struct and have the relocation entries simply point to places that that pointer should be written. Granted, on sparc this could get much uglier (based on my understanding of relocation address on sparc since an address can be formed across several instructions. Yuck.) > Jake -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 27 11:26: 4 2000 Delivered-To: freebsd-smp@freebsd.org Received: from io.yi.org (unknown [24.70.218.157]) by hub.freebsd.org (Postfix) with ESMTP id C8F1337B479; Mon, 27 Nov 2000 11:25:59 -0800 (PST) Received: from io.yi.org (localhost.gvcl1.bc.wave.home.com [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id 897B3BA7A; Mon, 27 Nov 2000 11:25:58 -0800 (PST) X-Mailer: exmh version 2.1.1 10/15/1999 To: John Baldwin Cc: smp@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: review: callout patch In-Reply-To: Message from John Baldwin of "Mon, 27 Nov 2000 10:33:04 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Nov 2000 11:25:58 -0800 From: Jake Burkholder Message-Id: <20001127192558.897B3BA7A@io.yi.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > On 26-Nov-00 Jake Burkholder wrote: > > > > This patch makes most of sys/kern/* sources use callout_reset for > > registering callouts rather than timeout(9). This should greatly > > reduce the use of the fixed size callfree allocator pool. Currently > > we panic when it runs out. > > > > This was motivated by NetBSD, who have completely removed timeout(9) > > from their kernel. > > > > Please review it. > > Looks good to me. :) > > Having a callout.9 manpage to go along with it would be nice as well. :) timeout.9 exists, its just not linked. > > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" 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 Mon Nov 27 11:27:20 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by hub.freebsd.org (Postfix) with ESMTP id D1AA537B479; Mon, 27 Nov 2000 11:27:17 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA06709; Mon, 27 Nov 2000 11:27:17 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id eARJREW27393; Mon, 27 Nov 2000 11:27:14 -0800 X-Virus-Scanned: Mon, 27 Nov 2000 11:27:14 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from radio.iprg.nokia.com (205.226.1.150, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdypuZrd; Mon, 27 Nov 2000 11:27:06 PST Message-ID: <3A22B58C.DA0B554B@iprg.nokia.com> Date: Mon, 27 Nov 2000 11:27:08 -0800 From: Joe Eykholt Organization: Nokia IPRG X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin Cc: Jake Burkholder , smp@FreeBSD.ORG Subject: Re: BSD/OS interrupt code References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John Baldwin wrote: > > On 26-Nov-00 Jake Burkholder wrote: > > Hi, > > > > If anyone with access to the BSD/OS code is interested, I've written > > a little program that runs their interrupt stub code generator in > > userland. You can then abort(); and disassemble the stub from > > the core dump to look at the code all in one piece. Makes it much > > easier to follow. > > > > In case you haven't looked, their interrupt handlers are generated > > by bcopy-ing various blocks of assembler code into an array at > > runtime, and then poking in arguments and relocating branches. > > Hmm. The best way to do this probably is to have stubs with psuedo-relocation > information. I.e., have 1 stub interrupt handler template for each type (fast, > threaded, fast apic, threaded apic, etc.), then have a "relocation" table on > the side that specifies offsets in the code that should receive one of a number > of things: vector number, vector address, etc. Alternatively, we could store > all of that info in a struct (gee, we already do with intrhand :)) and just > have the code always dereference a pointer to that struct and have the > relocation entries simply point to places that that pointer should be written. > Granted, on sparc this could get much uglier (based on my understanding of > relocation address on sparc since an address can be formed across several > instructions. Yuck.) True, but on SPARC you have more registers to play with in the interrupt handler and you tend not to have to do this sort of code changing at all. All the interrupt vectors can easily jump to one or two common routines. Joe Eykholt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 27 11:34:54 2000 Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 64A9137B479; Mon, 27 Nov 2000 11:34:51 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eARJYnC43140; Mon, 27 Nov 2000 11:34:49 -0800 (PST) (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: <20001127192558.897B3BA7A@io.yi.org> Date: Mon, 27 Nov 2000 11:35:02 -0800 (PST) From: John Baldwin To: Jake Burkholder Subject: Re: review: callout patch Cc: arch@FreeBSD.org, smp@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 27-Nov-00 Jake Burkholder wrote: >> >> On 26-Nov-00 Jake Burkholder wrote: >> > >> > This patch makes most of sys/kern/* sources use callout_reset for >> > registering callouts rather than timeout(9). This should greatly >> > reduce the use of the fixed size callfree allocator pool. Currently >> > we panic when it runs out. >> > >> > This was motivated by NetBSD, who have completely removed timeout(9) >> > from their kernel. >> > >> > Please review it. >> >> Looks good to me. :) >> >> Having a callout.9 manpage to go along with it would be nice as well. :) > > timeout.9 exists, its just not linked. Ah, I had thought timeout(9) didn't document those. Well, then updating timeout(9) and adding appropriate MLINK's would be cool. :) -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 27 11:38:31 2000 Delivered-To: freebsd-smp@freebsd.org Received: from io.yi.org (unknown [24.70.218.157]) by hub.freebsd.org (Postfix) with ESMTP id D73BD37B479; Mon, 27 Nov 2000 11:38:23 -0800 (PST) Received: from io.yi.org (localhost.gvcl1.bc.wave.home.com [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id BAA5EBA7A; Mon, 27 Nov 2000 11:38:23 -0800 (PST) X-Mailer: exmh version 2.1.1 10/15/1999 To: John Baldwin Cc: smp@FreeBSD.org Subject: Re: BSD/OS interrupt code In-Reply-To: Message from John Baldwin of "Mon, 27 Nov 2000 10:33:05 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Nov 2000 11:38:23 -0800 From: Jake Burkholder Message-Id: <20001127193823.BAA5EBA7A@io.yi.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > On 26-Nov-00 Jake Burkholder wrote: > > Hi, > > > > If anyone with access to the BSD/OS code is interested, I've written > > a little program that runs their interrupt stub code generator in > > userland. You can then abort(); and disassemble the stub from > > the core dump to look at the code all in one piece. Makes it much > > easier to follow. > > > > In case you haven't looked, their interrupt handlers are generated > > by bcopy-ing various blocks of assembler code into an array at > > runtime, and then poking in arguments and relocating branches. > > Hmm. The best way to do this probably is to have stubs with psuedo-relocation > information. I.e., have 1 stub interrupt handler template for each type (fast, > threaded, fast apic, threaded apic, etc.), then have a "relocation" table on > the side that specifies offsets in the code that should receive one of a number > of things: vector number, vector address, etc. Alternatively, we could store > all of that info in a struct (gee, we already do with intrhand :)) and just > have the code always dereference a pointer to that struct and have the > relocation entries simply point to places that that pointer should be written. > Granted, on sparc this could get much uglier (based on my understanding of > relocation address on sparc since an address can be formed across several > instructions. Yuck.) > Yeah, that's basically how its done in the BSD/OS interrupt generator. As I said, I wouldn't want to do this for any architecture that I know of other than x86. Its not overly difficult on x86 because everything is on a byte boundary. sparc, alpha, all the risc architectures that I know anything about have operands at wierd bit offsets in the instruction. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 27 12:55:46 2000 Delivered-To: freebsd-smp@freebsd.org Received: from wi4.vwl.uni-freiburg.de (wi4.vwl.uni-freiburg.de [132.230.53.12]) by hub.freebsd.org (Postfix) with ESMTP id 58E8D37B479; Mon, 27 Nov 2000 12:55:29 -0800 (PST) Received: from gromit.vwl.uni-freiburg.de ([132.230.49.49]) by wi4.vwl.uni-freiburg.de with esmtp (Exim 3.11 #1) id 140VJA-0007I6-00; Mon, 27 Nov 2000 21:55:28 +0100 Date: Mon, 27 Nov 2000 21:55:27 +0100 (MET) From: Thies Lehmann To: , Subject: unable to boot generic+smp-Kernel with SuperMicro 370DLE Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-427544271-1747042400-975358527=:11696" Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---427544271-1747042400-975358527=:11696 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, after installing 4.2-Release I built a GENERIC Kernel (plus SMP,APIC_IO minus I386_CPU, I486_CPU options); with that, booting stops at APIC_IO: Testing 8254 interrupt delivery it is a - dual Pentium III 800 MHz (256kB L1) - SuperMicro 370DLE Mainboard 512MB ECC-RAM - Adaptec 29160 we changed VGA cards, the 29160 for an Adaptec 2930, played around with BIOS settings, and tried the 4.1-RELEASE GENERIC Kernel (with options NAPIC=2) but did not get it booting. Searching through deja and the mailinglists produced no results, so any hints would be appreciated. attached to this message is the output of mptable -dmesg. regards, Thies -- Thies Lehmann Information Systems - Faculty of Economics Freiburg University ---427544271-1747042400-975358527=:11696 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="mptable.out" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="mptable.out" DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCk1QVGFi bGUsIHZlcnNpb24gMi4wLjE1DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KTVAgRmxvYXRpbmcgUG9pbnRlciBTdHJ1Y3R1cmU6 DQoNCiAgbG9jYXRpb246CQkJQklPUw0KICBwaHlzaWNhbCBhZGRyZXNzOgkJ MHgwMDBmZjc4MA0KICBzaWduYXR1cmU6CQkJJ19NUF8nDQogIGxlbmd0aDoJ CQkxNiBieXRlcw0KICB2ZXJzaW9uOgkJCTEuNA0KICBjaGVja3N1bToJCQkw eGI1DQogIG1vZGU6CQkJCVZpcnR1YWwgV2lyZQ0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk1QIENvbmZpZyBUYWJsZSBIZWFk ZXI6DQoNCiAgcGh5c2ljYWwgYWRkcmVzczoJCTB4MDAwZjBjZDANCiAgc2ln bmF0dXJlOgkJCSdQQ01QJw0KICBiYXNlIHRhYmxlIGxlbmd0aDoJCTI2OA0K ICB2ZXJzaW9uOgkJCTEuNA0KICBjaGVja3N1bToJCQkweGZiDQogIE9FTSBJ RDoJCQknQU1JICAgICAnDQogIFByb2R1Y3QgSUQ6CQkJJ0NOQjMwTEUgICAg ICcNCiAgT0VNIHRhYmxlIHBvaW50ZXI6CQkweDAwMDAwMDAwDQogIE9FTSB0 YWJsZSBzaXplOgkJMA0KICBlbnRyeSBjb3VudDoJCQkyNQ0KICBsb2NhbCBB UElDIGFkZHJlc3M6CQkweGZlZTAwMDAwDQogIGV4dGVuZGVkIHRhYmxlIGxl bmd0aDoJMjAwDQogIGV4dGVuZGVkIHRhYmxlIGNoZWNrc3VtOgkxMDUNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpNUCBDb25m aWcgQmFzZSBUYWJsZSBFbnRyaWVzOg0KDQotLQ0KUHJvY2Vzc29yczoJQVBJ QyBJRAlWZXJzaW9uCVN0YXRlCQlGYW1pbHkJTW9kZWwJU3RlcAlGbGFncw0K CQkgMAkgMHgxMQkgQlNQLCB1c2FibGUJIDYJIDgJIDYJIDB4Mzg3ZmJmZg0K CQkgMQkgMHgxMQkgQVAsIHVzYWJsZQkgNgkgOAkgNgkgMHgzODdmYmZmDQot LQ0KQnVzOgkJQnVzIElECVR5cGUNCgkJIDAJIFBDSSAgIA0KCQkgMQkgUENJ ICAgDQoJCSAyCSBJU0EgICANCi0tDQpJL08gQVBJQ3M6CUFQSUMgSUQJVmVy c2lvbglTdGF0ZQkJQWRkcmVzcw0KCQkgNAkgMHgxMQkgdXNhYmxlCQkgMHhm ZWMwMDAwMA0KCQkgNQkgMHgxMQkgdXNhYmxlCQkgMHhmZWMwMTAwMA0KLS0N CkkvTyBJbnRzOglUeXBlCVBvbGFyaXR5ICAgIFRyaWdnZXIJQnVzIElECSBJ UlEJQVBJQyBJRAlQSU4jDQoJCUlOVAlhY3RpdmUtbG8gICAgICAgbGV2ZWwJ ICAgICAwCSAxOkEJICAgICAgNQkgICAwDQoJCUlOVAlhY3RpdmUtbG8gICAg ICAgbGV2ZWwJICAgICAxCSAxOkEJICAgICAgNQkgICA4DQoJCUlOVAlhY3Rp dmUtbG8gICAgICAgbGV2ZWwJICAgICAwCSA2OkEJICAgICAgNQkgIDE1DQoJ CUV4dElOVAlhY3RpdmUtaGkgICAgICAgIGVkZ2UJICAgICAyCSAgIDAJICAg ICAgNAkgICAwDQoJCUlOVAlhY3RpdmUtaGkgICAgICAgIGVkZ2UJICAgICAy CSAgIDEJICAgICAgNAkgICAxDQoJCUlOVAlhY3RpdmUtaGkgICAgICAgIGVk Z2UJICAgICAyCSAgIDAJICAgICAgNAkgICAyDQoJCUlOVAlhY3RpdmUtaGkg ICAgICAgIGVkZ2UJICAgICAyCSAgIDMJICAgICAgNAkgICAzDQoJCUlOVAlh Y3RpdmUtaGkgICAgICAgIGVkZ2UJICAgICAyCSAgIDQJICAgICAgNAkgICA0 DQoJCUlOVAlhY3RpdmUtaGkgICAgICAgIGVkZ2UJICAgICAyCSAgIDUJICAg ICAgNAkgICA1DQoJCUlOVAlhY3RpdmUtaGkgICAgICAgIGVkZ2UJICAgICAy CSAgIDYJICAgICAgNAkgICA2DQoJCUlOVAlhY3RpdmUtaGkgICAgICAgIGVk Z2UJICAgICAyCSAgIDcJICAgICAgNAkgICA3DQoJCUlOVAlhY3RpdmUtaGkg ICAgICAgIGVkZ2UJICAgICAyCSAgIDgJICAgICAgNAkgICA4DQoJCUlOVAlh Y3RpdmUtaGkgICAgICAgIGVkZ2UJICAgICAyCSAgMTIJICAgICAgNAkgIDEy DQoJCUlOVAlhY3RpdmUtaGkgICAgICAgIGVkZ2UJICAgICAyCSAgMTMJICAg ICAgNAkgIDEzDQoJCUlOVAlhY3RpdmUtaGkgICAgICAgIGVkZ2UJICAgICAy CSAgMTQJICAgICAgNAkgIDE0DQoJCUlOVAlhY3RpdmUtaGkgICAgICAgIGVk Z2UJICAgICAyCSAgMTUJICAgICAgNAkgIDE1DQotLQ0KTG9jYWwgSW50czoJ VHlwZQlQb2xhcml0eSAgICBUcmlnZ2VyCUJ1cyBJRAkgSVJRCUFQSUMgSUQJ UElOIw0KCQlFeHRJTlQJYWN0aXZlLWhpICAgICAgICBlZGdlCSAgICAgMgkg ICAwCSAgICAyNTUJICAgMA0KCQlOTUkJYWN0aXZlLWhpICAgICAgICBlZGdl CSAgICAgMAkgMDpBCSAgICAyNTUJICAgMQ0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNCk1QIENvbmZpZyBFeHRlbmRlZCBUYWJs ZSBFbnRyaWVzOg0KDQotLQ0KU3lzdGVtIEFkZHJlc3MgU3BhY2UNCiBidXMg SUQ6IDAgYWRkcmVzcyB0eXBlOiBJL08gYWRkcmVzcw0KIGFkZHJlc3MgYmFz ZTogMHhkMDAwDQogYWRkcmVzcyByYW5nZTogMHgxMDAwDQotLQ0KU3lzdGVt IEFkZHJlc3MgU3BhY2UNCiBidXMgSUQ6IDAgYWRkcmVzcyB0eXBlOiBJL08g YWRkcmVzcw0KIGFkZHJlc3MgYmFzZTogMHgwDQogYWRkcmVzcyByYW5nZTog MHgxMDANCi0tDQpTeXN0ZW0gQWRkcmVzcyBTcGFjZQ0KIGJ1cyBJRDogMCBh ZGRyZXNzIHR5cGU6IG1lbW9yeSBhZGRyZXNzDQogYWRkcmVzcyBiYXNlOiAw eGZkODAwMDAwDQogYWRkcmVzcyByYW5nZTogMHgxMzAwMDAwDQotLQ0KU3lz dGVtIEFkZHJlc3MgU3BhY2UNCiBidXMgSUQ6IDAgYWRkcmVzcyB0eXBlOiBw cmVmZXRjaCBhZGRyZXNzDQogYWRkcmVzcyBiYXNlOiAweGZkNjAwMDAwDQog YWRkcmVzcyByYW5nZTogMHgxMDAwMDANCi0tDQpTeXN0ZW0gQWRkcmVzcyBT cGFjZQ0KIGJ1cyBJRDogMSBhZGRyZXNzIHR5cGU6IEkvTyBhZGRyZXNzDQog YWRkcmVzcyBiYXNlOiAweGUwMDANCiBhZGRyZXNzIHJhbmdlOiAweDEwMDAN Ci0tDQpTeXN0ZW0gQWRkcmVzcyBTcGFjZQ0KIGJ1cyBJRDogMSBhZGRyZXNz IHR5cGU6IG1lbW9yeSBhZGRyZXNzDQogYWRkcmVzcyBiYXNlOiAweGZlYjAw MDAwDQogYWRkcmVzcyByYW5nZTogMHgxMDAwMDANCi0tDQpTeXN0ZW0gQWRk cmVzcyBTcGFjZQ0KIGJ1cyBJRDogMSBhZGRyZXNzIHR5cGU6IHByZWZldGNo IGFkZHJlc3MNCiBhZGRyZXNzIGJhc2U6IDB4ZmQ3MDAwMDANCiBhZGRyZXNz IHJhbmdlOiAweDEwMDAwMA0KLS0NCkJ1cyBIZWlyYXJjaHkNCiBidXMgSUQ6 IDIgYnVzIGluZm86IDB4MDEgcGFyZW50IGJ1cyBJRDogMA0KLS0NCkNvbXBh dGliaWxpdHkgQnVzIEFkZHJlc3MNCiBidXMgSUQ6IDAgYWRkcmVzcyBtb2Rp ZmllcjogYWRkDQogcHJlZGVmaW5lZCByYW5nZTogMHgwMDAwMDAwMA0KLS0N CkNvbXBhdGliaWxpdHkgQnVzIEFkZHJlc3MNCiBidXMgSUQ6IDEgYWRkcmVz cyBtb2RpZmllcjogc3VidHJhY3QNCiBwcmVkZWZpbmVkIHJhbmdlOiAweDAw MDAwMDAwDQotLQ0KU3lzdGVtIEFkZHJlc3MgU3BhY2UNCiBidXMgSUQ6IDAg YWRkcmVzcyB0eXBlOiBtZW1vcnkgYWRkcmVzcw0KIGFkZHJlc3MgYmFzZTog MHhhMDAwMA0KIGFkZHJlc3MgcmFuZ2U6IDB4MjAwMDANCi0tDQpDb21wYXRp YmlsaXR5IEJ1cyBBZGRyZXNzDQogYnVzIElEOiAwIGFkZHJlc3MgbW9kaWZp ZXI6IGFkZA0KIHByZWRlZmluZWQgcmFuZ2U6IDB4MDAwMDAwMDENCi0tDQpD b21wYXRpYmlsaXR5IEJ1cyBBZGRyZXNzDQogYnVzIElEOiAxIGFkZHJlc3Mg bW9kaWZpZXI6IHN1YnRyYWN0DQogcHJlZGVmaW5lZCByYW5nZTogMHgwMDAw MDAwMQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN CiMgU01QIGtlcm5lbCBjb25maWcgZmlsZSBvcHRpb25zOg0KDQoNCiMgUmVx dWlyZWQ6DQpvcHRpb25zCQlTTVAJCQkjIFN5bW1ldHJpYyBNdWx0aVByb2Nl c3NvciBLZXJuZWwNCm9wdGlvbnMJCUFQSUNfSU8JCQkjIFN5bW1ldHJpYyAo QVBJQykgSS9PDQoNCiMgT3B0aW9uYWwgKGJ1aWx0LWluIGRlZmF1bHRzIHdp bGwgd29yayBpbiBtb3N0IGNhc2VzKToNCiNvcHRpb25zCQlOQ1BVPTIJCQkj IG51bWJlciBvZiBDUFVzDQojb3B0aW9ucwkJTkJVUz0zCQkJIyBudW1iZXIg b2YgYnVzc2VzDQojb3B0aW9ucwkJTkFQSUM9MgkJCSMgbnVtYmVyIG9mIElP IEFQSUNzDQojb3B0aW9ucwkJTklOVFI9MjQJCSMgbnVtYmVyIG9mIElOVHMN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpkbWVz ZyBvdXRwdXQ6DQoNCkNvcHlyaWdodCAoYykgMTk5Mi0yMDAwIFRoZSBGcmVl QlNEIFByb2plY3QuDQpDb3B5cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5ODMs IDE5ODYsIDE5ODgsIDE5ODksIDE5OTEsIDE5OTIsIDE5OTMsIDE5OTQNCglU aGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBB bGwgcmlnaHRzIHJlc2VydmVkLg0KRnJlZUJTRCA0LjItUkVMRUFTRSAjMDog TW9uIE5vdiAyMCAxMzowMjo1NSBHTVQgMjAwMA0KICAgIGpraEBiZW50by5G cmVlQlNELm9yZzovdXNyL3NyYy9zeXMvY29tcGlsZS9HRU5FUklDDQpUaW1l Y291bnRlciAiaTgyNTQiICBmcmVxdWVuY3kgMTE5MzE4MiBIeg0KQ1BVOiBQ ZW50aXVtIElJSS9QZW50aXVtIElJSSBYZW9uL0NlbGVyb24gKDc5OS42Mi1N SHogNjg2LWNsYXNzIENQVSkNCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRlbCIg IElkID0gMHg2ODYgIFN0ZXBwaW5nID0gNg0KICBGZWF0dXJlcz0weDM4M2Zi ZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNF UCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsTU1YLEZYU1IsU1NFPg0K cmVhbCBtZW1vcnkgID0gNTM2ODA1Mzc2ICg1MjQyMjRLIGJ5dGVzKQ0KYXZh aWwgbWVtb3J5ID0gNTE4NDIyNTI4ICg1MDYyNzJLIGJ5dGVzKQ0KUHJlbG9h ZGVkIGVsZiBrZXJuZWwgImtlcm5lbCIgYXQgMHhjMDQzNjAwMC4NClBlbnRp dW0gUHJvIE1UUlIgc3VwcG9ydCBlbmFibGVkDQptZDA6IE1hbGxvYyBkaXNr DQpucHgwOiA8bWF0aCBwcm9jZXNzb3I+IG9uIG1vdGhlcmJvYXJkDQpucHgw OiBJTlQgMTYgaW50ZXJmYWNlDQpwY2liMDogPFNlcnZlcldvcmtzIE5CNjYz NSAzLjBMRSBob3N0IHRvIFBDSSBicmlkZ2U+IG9uIG1vdGhlcmJvYXJkDQpw Y2kwOiA8UENJIGJ1cz4gb24gcGNpYjANCnBjaTA6IDxTMyBUcmlvIGdyYXBo aWNzIGFjY2VsZXJhdG9yPiBhdCAxLjAgaXJxIDExDQpmeHAwOiA8SW50ZWwg UHJvIDEwLzEwMEIvMTAwKyBFdGhlcm5ldD4gcG9ydCAweGQ4MDAtMHhkODNm IG1lbSAweGZlOTAwMDAwLTB4ZmU5ZmZmZmYsMHhmZWFlZTAwMC0weGZlYWVl ZmZmIGlycSA5IGF0IGRldmljZSA2LjAgb24gcGNpMA0KZnhwMDogRXRoZXJu ZXQgYWRkcmVzcyAwMDozMDo0ODoyMTo1NDpmZg0KaXNhYjA6IDxTZXJ2ZXJX b3JrcyBJQjY1NjYgUENJIHRvIElTQSBicmlkZ2U+IGF0IGRldmljZSAxNS4w IG9uIHBjaTANCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMA0KYXRhcGNpMDog PFNlcnZlcldvcmtzIFJPU0I0IEFUQTMzIGNvbnRyb2xsZXI+IGF0IGRldmlj ZSAxNS4xIG9uIHBjaTANCmF0YXBjaTA6IEJ1c21hc3RlcmluZyBETUEgbm90 IHN1cHBvcnRlZA0Kb2hjaTA6IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJv bGxlcj4gaXJxIDAgYXQgZGV2aWNlIDE1LjIgb24gcGNpMA0Kb2hjaTA6IElu dmFsaWQgaXJxIDANCm9oY2kwOiBQbGVhc2Ugc3dpdGNoIG9uIFVTQiBzdXBw b3J0IGFuZCBzd2l0Y2ggUE5QLU9TIHRvICdObycgaW4gQklPUw0KZGV2aWNl X3Byb2JlX2FuZF9hdHRhY2g6IG9oY2kwIGF0dGFjaCByZXR1cm5lZCA2DQpw Y2liMTogPFNlcnZlcldvcmtzIE5CNjYzNSAzLjBMRSBob3N0IHRvIFBDSSBi cmlkZ2U+IG9uIG1vdGhlcmJvYXJkDQpwY2kxOiA8UENJIGJ1cz4gb24gcGNp YjENCmFoYzA6IDxBZGFwdGVjIDI5MTYwIFVsdHJhMTYwIFNDU0kgYWRhcHRl cj4gcG9ydCAweGU4MDAtMHhlOGZmIG1lbSAweGZlYmZmMDAwLTB4ZmViZmZm ZmYgaXJxIDEwIGF0IGRldmljZSAxLjAgb24gcGNpMQ0KYWljNzg5MjogV2lk ZSBDaGFubmVsIEEsIFNDU0kgSWQ9NywgMzIvMjU1IFNDQnMNCmZkYzA6IDxO RUMgNzIwNjVCIG9yIGNsb25lPiBhdCBwb3J0IDB4M2YwLTB4M2Y1LDB4M2Y3 IGlycSA2IGRycSAyIG9uIGlzYTANCmF0a2JkYzA6IDxLZXlib2FyZCBjb250 cm9sbGVyIChpODA0Mik+IGF0IHBvcnQgMHg2MCwweDY0IG9uIGlzYTANCmF0 a2JkMDogPEFUIEtleWJvYXJkPiBmbGFncyAweDEgaXJxIDEgb24gYXRrYmRj MA0Ka2JkMCBhdCBhdGtiZDANCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0 IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlz YTANCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBp c2EwDQpzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgz MDA+DQpzaW8wOiBjb25maWd1cmVkIGlycSA0IG5vdCBpbiBiaXRtYXAgb2Yg cHJvYmVkIGlycXMgMA0Kc2lvMCBhdCBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0 IGZsYWdzIDB4MTAgb24gaXNhMA0Kc2lvMDogdHlwZSA4MjUwDQpzaW8xOiBj b25maWd1cmVkIGlycSAzIG5vdCBpbiBiaXRtYXAgb2YgcHJvYmVkIGlycXMg MA0KcHBjMDogcGFyYWxsZWwgcG9ydCBub3QgZm91bmQuDQpXYWl0aW5nIDE1 IHNlY29uZHMgZm9yIFNDU0kgZGV2aWNlcyB0byBzZXR0bGUNCk1vdW50aW5n IHJvb3QgZnJvbSB1ZnM6L2Rldi9kYTBzMWENCmRhMCBhdCBhaGMwIGJ1cyAw IHRhcmdldCAwIGx1biAwDQpkYTA6IDxJQk0gRFBTUy0zMDkxNzBOIFM5M0U+ IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS0zIGRldmljZSANCmRhMDogMTYw LjAwME1CL3MgdHJhbnNmZXJzICg4MC4wMDBNSHosIG9mZnNldCA2MywgMTZi aXQpLCBUYWdnZWQgUXVldWVpbmcgRW5hYmxlZA0KZGEwOiA4NzQ4TUIgKDE3 OTE2MjQwIDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgMTExNUMpDQpk YTEgYXQgYWhjMCBidXMgMCB0YXJnZXQgMSBsdW4gMA0KZGExOiA8SUJNIERQ U1MtMzA5MTcwTiBTOTNFPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktMyBk ZXZpY2UgDQpkYTE6IDE2MC4wMDBNQi9zIHRyYW5zZmVycyAoODAuMDAwTUh6 LCBvZmZzZXQgNjMsIDE2Yml0KSwgVGFnZ2VkIFF1ZXVlaW5nIEVuYWJsZWQN CmRhMTogODc0OE1CICgxNzkxNjI0MCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVI IDYzUy9UIDExMTVDKQ0KZGEyIGF0IGFoYzAgYnVzIDAgdGFyZ2V0IDIgbHVu IDANCmRhMjogPElCTSBEUFNTLTMwOTE3ME4gUzkzRT4gRml4ZWQgRGlyZWN0 IEFjY2VzcyBTQ1NJLTMgZGV2aWNlIA0KZGEyOiAxNjAuMDAwTUIvcyB0cmFu c2ZlcnMgKDgwLjAwME1Ieiwgb2Zmc2V0IDYzLCAxNmJpdCksIFRhZ2dlZCBR dWV1ZWluZyBFbmFibGVkDQpkYTI6IDg3NDhNQiAoMTc5MTYyNDAgNTEyIGJ5 dGUgc2VjdG9yczogMjU1SCA2M1MvVCAxMTE1QykNCmRhMyBhdCBhaGMwIGJ1 cyAwIHRhcmdldCAzIGx1biAwDQpkYTM6IDxJQk0gRFBTUy0zMDkxNzBOIFM5 M0U+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS0zIGRldmljZSANCmRhMzog MTYwLjAwME1CL3MgdHJhbnNmZXJzICg4MC4wMDBNSHosIG9mZnNldCA2Mywg MTZiaXQpLCBUYWdnZWQgUXVldWVpbmcgRW5hYmxlZA0KZGEzOiA4NzQ4TUIg KDE3OTE2MjQwIDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgMTExNUMp DQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0K ---427544271-1747042400-975358527=:11696-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 27 15:51: 5 2000 Delivered-To: freebsd-smp@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 3424937B479 for ; Mon, 27 Nov 2000 15:51:03 -0800 (PST) Received: from berserker.bsdi.com (cp@localhost.bsdi.com [127.0.0.1]) by berserker.bsdi.com (8.11.1/8.9.3) with ESMTP id eARNolt02111; Mon, 27 Nov 2000 16:50:47 -0700 (MST) (envelope-from cp@berserker.bsdi.com) Message-Id: <200011272350.eARNolt02111@berserker.bsdi.com> To: Jake Burkholder Cc: Greg Lehey , smp@FreeBSD.ORG Subject: Re: BSD/OS interrupt code In-reply-to: Your message of "Sun, 26 Nov 2000 17:50:06 PST." <20001127015006.5B7BDBA7A@io.yi.org> From: Chuck Paterson Date: Mon, 27 Nov 2000 16:50:47 -0700 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org } }I also think that BSD/OS went a little too far with this, and }have produced code that is very difficult to understand, let }alone maintain. I think its cool what they did, I'm humbled }and amazed that they made it work, but I don't know that its }right for FreeBSD. } This code was done to make the interrupt path as fast as it was in the previous releases. Speed not code size was the real reason. The primary goal was to get rid of any branches that could be resolved at setup time. I would stongly urge FreeBSD to NOT go down this path. To say this stuff was a nightmare to develop is an under statement. BSDi might well have completed the SMPng kernel by now if it weren't for the huge amount of time that went into getting this code right, including tracking back seemingly totally unrelated problems to screw ups in a lite weight context switch because of bugs in this stuff. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 27 16:38:24 2000 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 8433837B479 for ; Mon, 27 Nov 2000 16:38:20 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id LAA00562; Tue, 28 Nov 2000 11:18:51 +1100 Date: Tue, 28 Nov 2000 11:19:24 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Jonathan Lemon Cc: jburkhol@home.com, smp@FreeBSD.ORG Subject: Re: BSD/OS interrupt code In-Reply-To: <200011270238.eAR2c4R55543@prism.flugsvamp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 26 Nov 2000, Jonathan Lemon wrote: > In article you write: > >I also think that BSD/OS went a little too far with this, and > >have produced code that is very difficult to understand, let > >alone maintain. I think its cool what they did, I'm humbled > >and amazed that they made it work, but I don't know that its > >right for FreeBSD. > > Seconded. This pretty much sums up my feeling too. Me too. I thought of implementing this for plain 386's 8 years ago, but didn't think it would be worth doing for 486's. Even our interrupt macros probably aren't worth doing starting with 386's (they may have negative benefits by generating large code which busts the cache). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 27 17: 9:11 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by hub.freebsd.org (Postfix) with ESMTP id F2A4F37B479 for ; Mon, 27 Nov 2000 17:09:08 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA08927; Mon, 27 Nov 2000 17:09:08 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id eAS195318688; Mon, 27 Nov 2000 17:09:05 -0800 X-Virus-Scanned: Mon, 27 Nov 2000 17:09:05 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from maxdialin16.iprg.nokia.com (205.226.20.246, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdWalW1q; Mon, 27 Nov 2000 17:09:00 PST Message-ID: <3A2307B1.A2715334@iprg.nokia.com> Date: Mon, 27 Nov 2000 17:17:37 -0800 From: Michael Williams Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Greg Lehey Cc: Jake Burkholder , smp@FreeBSD.ORG Subject: Re: BSD/OS interrupt code References: <20001127015006.5B7BDBA7A@io.yi.org> <20001127122736.G27697@echunga.lemis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org One application Solaris has for this "trick" of building handlers on the fly, is to install debugging/verbose handlers dynamically, especially where the initial handlers do some vectoring (small branches) before jumping off to do hard work. The miss handlers do this for example. As far as which instruction format is "simple", I'm curious, why do you suggest x86 as an example? Cheers, Michael Greg Lehey wrote: > On Sunday, 26 November 2000 at 17:50:06 -0800, Jake Burkholder wrote: > >> On Sunday, 26 November 2000 at 14:07:49 -0800, Jake Burkholder wrote: > >>> Hi, > >>> > >>> If anyone with access to the BSD/OS code is interested, I've written > >>> a little program that runs their interrupt stub code generator in > >>> userland. You can then abort(); and disassemble the stub from > >>> the core dump to look at the code all in one piece. Makes it much > >>> easier to follow. > >>> > >>> In case you haven't looked, their interrupt handlers are generated > >>> by bcopy-ing various blocks of assembler code into an array at > >>> runtime, and then poking in arguments and relocating branches. > >> > >> Interesting. I was wondering whether something similar would be a > >> good idea. On the other hand, We don't waste much space by having > >> multiple alternate stubs. What's your feeling? > > > > I suspect that it would be hard to do this for architectures > > other than x86, which has a relatively simple instruction format. > > > > I also think that BSD/OS went a little too far with this, and > > have produced code that is very difficult to understand, let > > alone maintain. I think its cool what they did, I'm humbled > > and amazed that they made it work, but I don't know that its > > right for FreeBSD. > > That's a reasonable objection. Where's your program? > > Greg > -- > Finger grog@lemis.com for PGP public key > See complete headers for address and phone numbers > > 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 Mon Nov 27 17:31: 7 2000 Delivered-To: freebsd-smp@freebsd.org Received: from io.yi.org (unknown [24.70.218.157]) by hub.freebsd.org (Postfix) with ESMTP id 014D837B4C5 for ; Mon, 27 Nov 2000 17:31:06 -0800 (PST) Received: from io.yi.org (localhost.gvcl1.bc.wave.home.com [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id 1A217BA78; Mon, 27 Nov 2000 17:31:05 -0800 (PST) X-Mailer: exmh version 2.1.1 10/15/1999 To: Michael Williams Cc: smp@FreeBSD.ORG Subject: Re: BSD/OS interrupt code In-Reply-To: Message from Michael Williams of "Mon, 27 Nov 2000 17:17:37 PST." <3A2307B1.A2715334@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Nov 2000 17:31:05 -0800 From: Jake Burkholder Message-Id: <20001128013105.1A217BA78@io.yi.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > One application Solaris has for this "trick" of building handlers on the fly, is > to install debugging/verbose handlers dynamically, especially where the initial > handlers do some vectoring (small branches) before jumping off to do hard work. > The miss handlers do this for example. > > As far as which instruction format is "simple", I'm curious, why do you suggest > x86 as an example? > I just meant that everything is on a byte boundary, so poking in the arguments is relatively easy. No shifting or masking is required and you can fit a full virtual address in one piece in the instruction stream. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 27 20:19:29 2000 Delivered-To: freebsd-smp@freebsd.org Received: from echunga.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id BEDD537B4F9; Mon, 27 Nov 2000 20:19:22 -0800 (PST) Received: (from grog@localhost) by echunga.lemis.com (8.11.1/8.9.3) id eAS4I3M37191; Tue, 28 Nov 2000 14:48:03 +1030 (CST) (envelope-from grog) Date: Tue, 28 Nov 2000 14:48:03 +1030 From: Greg Lehey To: John Baldwin Cc: Jake Burkholder , smp@FreeBSD.ORG Subject: Re: BSD/OS interrupt code Message-ID: <20001128144803.C36542@echunga.lemis.com> References: <20001126220749.BFB35BA7A@io.yi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.ORG on Mon, Nov 27, 2000 at 10:33:05AM -0800 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Monday, 27 November 2000 at 10:33:05 -0800, John Baldwin wrote: > > On 26-Nov-00 Jake Burkholder wrote: >> Hi, >> >> If anyone with access to the BSD/OS code is interested, I've written >> a little program that runs their interrupt stub code generator in >> userland. You can then abort(); and disassemble the stub from >> the core dump to look at the code all in one piece. Makes it much >> easier to follow. >> >> In case you haven't looked, their interrupt handlers are generated >> by bcopy-ing various blocks of assembler code into an array at >> runtime, and then poking in arguments and relocating branches. > > Hmm. The best way to do this probably is to have stubs with psuedo-relocation > information. I.e., have 1 stub interrupt handler template for each type (fast, > threaded, fast apic, threaded apic, etc.), then have a "relocation" table on > the side that specifies offsets in the code that should receive one of a number > of things: vector number, vector address, etc. Alternatively, we could store > all of that info in a struct (gee, we already do with intrhand :)) and just > have the code always dereference a pointer to that struct and have the > relocation entries simply point to places that that pointer should be written. > Granted, on sparc this could get much uglier (based on my understanding of > relocation address on sparc since an address can be formed across several > instructions. Yuck.) I assume you're talking about doing this at run time, presumably from a function like inthand_add. This is a nice, structured way to do things. One of the parameters might be the type of interrupt, so instead of three stubs for each possible interrupt, we'd only have one. Why didn't we do that from the start? Because it's slower. No, I haven't tried to prove this, but I'm pretty sure you'd have difficulties getting it small enough. One alternative would be to really create the entire interrupt handler stub in inthand_add. It's not as difficult as it probably sounds, but in general I agree with Bruce that the saving is probably not worth it. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 27 22: 8: 7 2000 Delivered-To: freebsd-smp@freebsd.org Received: from server.baldwin.cx (server.geekhouse.net [64.81.6.52]) by hub.freebsd.org (Postfix) with ESMTP id 920F637B4C5 for ; Mon, 27 Nov 2000 22:08:03 -0800 (PST) Received: from john.baldwin.cx (root@john.baldwin.cx [192.168.1.18]) by server.baldwin.cx (8.9.3/8.9.3) with ESMTP id WAA90688; Mon, 27 Nov 2000 22:01:37 -0800 (PST) (envelope-from john@baldwin.cx) Received: (from john@localhost) by john.baldwin.cx (8.9.3/8.9.3) id WAA36325; Mon, 27 Nov 2000 22:01:20 -0800 (PST) (envelope-from john) Message-Id: <200011280601.WAA36325@john.baldwin.cx> 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: <20001128144803.C36542@echunga.lemis.com> Date: Mon, 27 Nov 2000 22:01:20 -0800 (PST) From: John Baldwin To: Greg Lehey Subject: Re: BSD/OS interrupt code Cc: smp@FreeBSD.ORG, Jake Burkholder Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 28-Nov-00 Greg Lehey wrote: > On Monday, 27 November 2000 at 10:33:05 -0800, John Baldwin wrote: >> >> On 26-Nov-00 Jake Burkholder wrote: >>> Hi, >>> >>> If anyone with access to the BSD/OS code is interested, I've written >>> a little program that runs their interrupt stub code generator in >>> userland. You can then abort(); and disassemble the stub from >>> the core dump to look at the code all in one piece. Makes it much >>> easier to follow. >>> >>> In case you haven't looked, their interrupt handlers are generated >>> by bcopy-ing various blocks of assembler code into an array at >>> runtime, and then poking in arguments and relocating branches. >> >> Hmm. The best way to do this probably is to have stubs with psuedo-relocation >> information. I.e., have 1 stub interrupt handler template for each type (fast, >> threaded, fast apic, threaded apic, etc.), then have a "relocation" table on >> the side that specifies offsets in the code that should receive one of a number >> of things: vector number, vector address, etc. Alternatively, we could store >> all of that info in a struct (gee, we already do with intrhand :)) and just >> have the code always dereference a pointer to that struct and have the >> relocation entries simply point to places that that pointer should be written. >> Granted, on sparc this could get much uglier (based on my understanding of >> relocation address on sparc since an address can be formed across several >> instructions. Yuck.) > > I assume you're talking about doing this at run time, presumably from > a function like inthand_add. This is a nice, structured way to do > things. One of the parameters might be the type of interrupt, so > instead of three stubs for each possible interrupt, we'd only have > one. Why didn't we do that from the start? Because it's slower. No, > I haven't tried to prove this, but I'm pretty sure you'd have > difficulties getting it small enough. > > One alternative would be to really create the entire interrupt handler > stub in inthand_add. It's not as difficult as it probably sounds, but > in general I agree with Bruce that the saving is probably not worth > it. Doing this would be a pain as Chuck kindly pointed out. One not so difficult step that can be taken is to make the stubs smaller and have them use more code in common. For example, you could probably reduce the per-interrupt source portion of the stub to just 'pusha; mov $irq_num, %eax; jmp common_code;' in the x86 case. However, the savings wouldn't be but so great. Nevertheless, it's something I may play with at some point in time. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Nov 28 3:22:11 2000 Delivered-To: freebsd-smp@freebsd.org Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by hub.freebsd.org (Postfix) with ESMTP id C8DDC37B400; Tue, 28 Nov 2000 03:22:08 -0800 (PST) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 140ipq-000J9u-0B; Tue, 28 Nov 2000 11:22:06 +0000 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id LAA16836; Tue, 28 Nov 2000 11:26:45 GMT (envelope-from dfr@nlsystems.com) Date: Tue, 28 Nov 2000 11:22:56 +0000 (GMT) From: Doug Rabson To: Jake Burkholder Cc: John Baldwin , smp@freebsd.org Subject: Re: BSD/OS interrupt code In-Reply-To: <20001127193823.BAA5EBA7A@io.yi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 27 Nov 2000, Jake Burkholder wrote: > As I said, I wouldn't want to do this for any architecture that I know > of other than x86. Its not overly difficult on x86 because everything > is on a byte boundary. sparc, alpha, all the risc architectures that > I know anything about have operands at wierd bit offsets in the > instruction. I have written a runtime code-generator for alpha in the past for another project with similar requirements (pasting together 3D geometry code fragments) and its actually pretty easy. As far as I remember, it only took a couple of hours to write. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Nov 28 4:25:31 2000 Delivered-To: freebsd-smp@freebsd.org Received: from iraun1.ira.uka.de (iraun1.ira.uka.de [129.13.10.90]) by hub.freebsd.org (Postfix) with ESMTP id 2022737B400 for ; Tue, 28 Nov 2000 04:25:29 -0800 (PST) Received: from i30nb2.ira.uka.de by iraun1 (PP) with ESMTP; Tue, 28 Nov 2000 13:25:08 +0100 Received: (from esk@localhost) by i30nb2.ira.uka.de (8.11.0/8.11.1) id eASCP7V03566; Tue, 28 Nov 2000 13:25:07 +0100 (CET) (envelope-from esk) From: Espen Skoglund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14883.42019.97348.29186@i30nb2.ira.uka.de> Date: Tue, 28 Nov 2000 13:25:07 +0100 (CET) To: Doug Rabson Cc: smp@FreeBSD.ORG Subject: Re: BSD/OS interrupt code In-Reply-To: References: <20001127193823.BAA5EBA7A@io.yi.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Doug Rabson] > On Mon, 27 Nov 2000, Jake Burkholder wrote: >> As I said, I wouldn't want to do this for any architecture that I >> know of other than x86. Its not overly difficult on x86 because >> everything is on a byte boundary. sparc, alpha, all the risc >> architectures that I know anything about have operands at wierd bit >> offsets in the instruction. > I have written a runtime code-generator for alpha in the past for > another project with similar requirements (pasting together 3D > geometry code fragments) and its actually pretty easy. As far as I > remember, it only took a couple of hours to write. I have not followed this discussion closely, so I might be a bit far out here. I just wanted to say that if you do consider using run time generated code, would it not be better to look into things that other people have worked on before. You might for instance use Dawson Engler's vcode: As far as I can remember it was used to generate dynamic packet filters in the Exokernel, but it should be possible to use it for other things as well. eSk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Dec 1 23:47:11 2000 Delivered-To: freebsd-smp@freebsd.org Received: from cube.gelatinous.com (cube.gelatinous.com [207.82.194.150]) by hub.freebsd.org (Postfix) with SMTP id 319FE37B401 for ; Fri, 1 Dec 2000 23:47:10 -0800 (PST) Received: (qmail 24023 invoked by uid 1005); 2 Dec 2000 07:47:09 -0000 Date: 2 Dec 2000 07:47:09 -0000 Message-ID: <20001202074709.24022.qmail@cube.gelatinous.com> From: danh@gelatinous.com To: freebsd-smp@freebsd.org Subject: odd problem / lock up / smp kernel/ HP Vectra Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have an HP Vectra with 2 Pentium Pro 180 processors in it I was able to compile and happily run a 4-1-stable kernel with both processors turned on I upgraded to 4-2-stable, compiled an SMP kernel, and my machine locks up very early, after this: Changing APIC ID for IO APIC # from 16 to 2 in MP table Programming 16 pins in IOAPIC #0 IOAPIC # intpn 2 -> irq 0 I am now running a one processor 4-2 kernel any ideas why this would happen? thanks -danh@gelatinous.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message