From owner-freebsd-smp Thu Jul 24 06:47:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA28550 for smp-outgoing; Thu, 24 Jul 1997 06:47:59 -0700 (PDT) Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA28545 for ; Thu, 24 Jul 1997 06:47:57 -0700 (PDT) Received: from fast.cs.utah.edu by cs.utah.edu (8.8.4/utah-2.21-cs) id HAA24835; Thu, 24 Jul 1997 07:47:51 -0600 (MDT) Received: by fast.cs.utah.edu (8.6.10/utah-2.15-leaf) id HAA29271; Thu, 24 Jul 1997 07:47:50 -0600 Date: Thu, 24 Jul 1997 07:47:50 -0600 From: vanmaren@fast.cs.utah.edu (Kevin Van Maren) Message-Id: <199707241347.HAA29271@fast.cs.utah.edu> To: cbrown@aracnet.com, smp@csn.net Subject: Re: Lots 'o PCI slots Cc: freebsd-smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hi, > > >Well, I just thumbed through the I2O spec, and it made no mention of > >APICs or even much about how interrupts with the host system are > >handled. I am guessing that this is implementation specific. If I > >find out anything more that I can tell you, I'll let you know. The I/O processor is off the PCI bus. In fact, Intel's i960 RP/RD has two bridges integrated, which provides for a secondary PCI bus with just one chip. Since the i960 is on the `other side' of the PCI bus, I think it would be pretty stupid to have an x86-specific multiprocessor support bus on the controller. However, it appears that is exactly what they do: http://134.134.214.1/design/iio/des.htm which is annother reason Digital has their own I2O processor based on the StrongARM. http://www.digital.com/info/semiconductor/press0303hm.htm > Indeed it is implementation specific. However the I2O boards I've noticed > so far use the i960 for that "specific hardware". I can picture such boards > using the APIC system for interprocessor communications. I'll try to find > time to go look at the i960 datasheet... > -- The i960 is the INTEL embedded processor for the "Intelligent I/O" system. DEC (of course) has their own processor; the I2O spec doesn't specify which I/O procesor should be used; most people (WinTel anyway) are using the i960 from Intel. So using a i960 IS implementation-specific. Try looking from Intel's site: http://www1.intel.com/design/iio/ The I2O Sig is at: http://www.i2osig.org/ I don't think releasing technical info about the I2O spec is really any different than not releasing info about a RAID controller or a proprietary system bus. Many companies still want NDAs for their hardware specs; this is just a `big company' that has lots of little companies (like IBM and Intel :) This doesn't mean that I like it, nor do I even remotely resemble a lawyer. It would be much better if the specs were $30 and available to everyone (like the PCI spec). Hopefully in a few years it will be that way. http://134.134.214.1/design/i960/prodbref/27274001.htm Shows the logical layout of the i960 RP. Note that cycles are NOT allowed in the PCI spec; however, intel `fudged' this one by having the i960 connected to both PCI busses: there are now two ways for a message (data) to flow, which invalidates the consistency guarantees. Of course, it is also broken with PCI 2.1's split transactions across a bridge chip, as the requests aren't tagged. (A reads C, told to `retry', bridge gets value from C, B reads C and bridge gives it to B instead of C). HP did formal verification work to prove these problems exist, although they have not publically released `fixes'. Kevin