From owner-freebsd-alpha Wed Jun 13 11:10: 6 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 2A86D37B403; Wed, 13 Jun 2001 11:09:57 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo (mjacob@beppo [192.67.166.79]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f5DI9ug41083; Wed, 13 Jun 2001 11:09:56 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Wed, 13 Jun 2001 11:09:55 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: freebsd-alpha@FreeBSD.org, wilko@FreeBSD.org, Andrew Gallatin Subject: Re: followup on 8 way SMP pani In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Hang on a second. Clock interrupts are used for _two_ different things > here, which is where you are getting confused I think. One is > timekeeping, another is to handle things like per-process statclock, etc. > All that per-process stuff we do on _all_ cpu's when we get a clock > interrupt. Alpha is nice in that it broadcasts clock interrupts for this > purpose. On x86, for example, we only have one clock interrupt and we > have to IPI all the other CPU's to get this info. But, in fact, in this case this is *not* a broadcast interrupt. Each TLSB CPU board can have up to two CPUs. Each TLSB CPU board has an interval timer and a Zilog duart. You use the TLINTRMASK{0,1} registers for each TLSB CPU board to control whether one or both CPUs get DUART or Interval Timer or IPI (or any other, for that matter) interrupt. > Now, the second purpose is for timekeeping, and that is what hte i8254 is > used for on SMP systems, because it is a timer that is system wide and not > per-CPU. Does that make sense? What tlsb needs is a non-per-CPU, > system-wide timer to be used for the timecounter stuff. That's all. No > changes to any of the other clock code is needed. And, to be safe, we should probably do the forward dance here as well- this would guarantee that at least all CPUs notion of statclock is monotonically delayed and ordered from the primary CPU. That is, it would be alway true that: CPU 0 - time tau CPU 1 - time tau + epsilon1 CPU 2 - time tau + epsilon1 + epsilon2 ... I still have trouble believing that it won't screw things up to have different (per cpu) time bases for statclock if you allow processes to move from one cpu to the other. But I'll freely admit I'm an ignorant twit about the current setup. > > In my first reply, (when you were going to disable clock interrupts on > secondary cpu's) I was dealing with the first thing (per-process signals and > stats) and noted that those should work fine as is. Doug then reminded me that > I was a bit off track due to the way that nanotime, microtime, etc. all work. > > > I'm still trying to get it to work period for turbolaser. I think I tracked > > down the panic and can move ahead I believe. This other issue has to really > > be > > slightly orthogonal. > > tlsb panics cause it has no timecounter on an SMP system. It needs a > timecounter. That will fix the panic. So it's the same issue. :) Well, I supposedly had *fixed* this lack of a timecounter issue some weeks back (by hacking around it). I guess I need to look at this again. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message