From owner-freebsd-smp Mon Jul 14 10:51:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA04729 for smp-outgoing; Mon, 14 Jul 1997 10:51:47 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA04706; Mon, 14 Jul 1997 10:51:35 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id LAA02683; Mon, 14 Jul 1997 11:51:33 -0600 (MDT) Message-Id: <199707141751.LAA02683@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: smp@freebsd.org cc: hackers@freebsd.org Subject: interrupt latency Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Jul 1997 11:51:32 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Can anyone recommend a test suite/methodology for evaluating interrupt latency? I have some ideas for improving the (currently poor) int response of the SMP kernel, but need a way to determine if I am actually bettering things. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Mon Jul 14 12:17:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA08882 for smp-outgoing; Mon, 14 Jul 1997 12:17:33 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA08860; Mon, 14 Jul 1997 12:17:10 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id NAA00523; Mon, 14 Jul 1997 13:16:06 -0600 (MDT) Message-Id: <199707141916.NAA00523@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Luigi Rizzo cc: smp@freebsd.org, hackers@freebsd.org Subject: Re: interrupt latency In-reply-to: Your message of "Mon, 14 Jul 1997 19:33:51 +0200." <199707141733.TAA11310@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Jul 1997 13:16:06 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > what are the starting and ending event that you are looking for ? > > start: hw_irq, handler (glue code) called ? > end: handler called, driver called ? thats a good question. the problem: in our SMP system an INT may be sent to a CPU that can't enter the kernel because another CPU is currently inside the kernel. this causes a long delay between the time the INT tickels the hardware and the time the ISR actually runs. --- So I guess the 2 points in time are the actual instance of hardware INT and the time the ISR completes. The closest the software can get to determining the start point would be on entry to _XintrNN (isa/apic_vector.s) A convenient stop point would be immediately after the lock is acquired (ie, after GET_MPLOCK in _XintrNN), the completion of the ISR code should be constant. But this hides the time between the actual firing of the hardware INT and the time a CPU accepts it. This could be fairly long if the "accepting CPU" is stuck behing the "giant lock", as hardware INTs are blocked during this time. The "ideal hardware solution" would be a card with a counter per INT source. each counter would be started by an INT, stopped & read via the ISR specific to that INT. I guess 2 cards, PCI & ISA, would be required for a complete solution. And MBs with onboard periphials such as disk and net would hide the most important INTs. WHich suggests an ISA card for the counters with an umbilical cord to attach to the APIC on the MB (a discrete chip with the natoma/triton chipset). --- Having said all this perhaps what I need are repeatable, disk/net IO intensive tests that benefit from latency improvements. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Mon Jul 14 12:53:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA10645 for smp-outgoing; Mon, 14 Jul 1997 12:53:16 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA10620; Mon, 14 Jul 1997 12:53:06 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id UAA11489; Mon, 14 Jul 1997 20:49:00 +0200 From: Luigi Rizzo Message-Id: <199707141849.UAA11489@labinfo.iet.unipi.it> Subject: Re: interrupt latency To: smp@csn.net (Steve Passe) Date: Mon, 14 Jul 1997 20:48:59 +0200 (MET DST) Cc: smp@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <199707141916.NAA00523@Ilsa.StevesCafe.com> from "Steve Passe" at Jul 14, 97 01:15:47 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hi, > > > what are the starting and ending event that you are looking for ? > > > > start: hw_irq, handler (glue code) called ? > > end: handler called, driver called ? > > thats a good question. > > the problem: > > in our SMP system an INT may be sent to a CPU that can't enter the kernel > because another CPU is currently inside the kernel. this causes a long delay > between the time the INT tickels the hardware and the time the ISR actually > runs. I am not familiar at all with the SMP code or the apic, but using a hardware solution seems extremely complex. Since you are looking at solution to improve the int latency anyways, can you consider the following approach: Replace the "giant lock" with a couple of nested locks; the most external one would only allow the posting of the hardware intr to some cpu, but not the acquisition of the "giant lock" (i.e. the right to enter the kernel). The nested lock is what you currently call 'the giant lock'. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-smp Mon Jul 14 13:02:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA11124 for smp-outgoing; Mon, 14 Jul 1997 13:02:56 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA11101; Mon, 14 Jul 1997 13:02:44 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id OAA00792; Mon, 14 Jul 1997 14:02:38 -0600 (MDT) Message-Id: <199707142002.OAA00792@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Luigi Rizzo cc: smp@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: interrupt latency In-reply-to: Your message of "Mon, 14 Jul 1997 20:48:59 +0200." <199707141849.UAA11489@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Jul 1997 14:02:37 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > I am not familiar at all with the SMP code or the apic, but using > a hardware solution seems extremely complex. Since you are looking > at solution to improve the int latency anyways, can you consider > the following approach: > > Replace the "giant lock" with a couple of nested locks; the most > external one would only allow the posting of the hardware intr to > some cpu, but not the acquisition of the "giant lock" (i.e. the > right to enter the kernel). The nested lock is what you currently > call 'the giant lock'. The APICs don't quite work that way. There is an IO APIC connected to the external INT sources, and a local APIC in each CPU. All the APICs communicate thru a private bus. The IO APIC sends the INT to whichever CPU it determines is the best candidate based on several algorithms. for more info on the APIC as currently used, see: http://www.freebsd.org/~fsmp/SMP/papers/apicsubsystem.txt -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Mon Jul 14 14:00:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA13988 for smp-outgoing; Mon, 14 Jul 1997 14:00:18 -0700 (PDT) Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA13930; Mon, 14 Jul 1997 14:00:01 -0700 (PDT) Received: from gid.co.uk (uucp@localhost) by isbalham.ist.co.uk (8.8.4/8.8.4) with UUCP id VAA11169; Mon, 14 Jul 1997 21:43:10 +0100 (BST) Received: from [194.32.164.2] by seagoon.gid.co.uk; Mon, 14 Jul 1997 21:42:00 +0100 X-Sender: rb@194.32.164.1 Message-Id: In-Reply-To: <199707141751.LAA02683@Ilsa.StevesCafe.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Jul 1997 21:38:11 +0100 To: Steve Passe From: Bob Bishop Subject: Re: interrupt latency Cc: hackers@FreeBSD.ORG, smp@FreeBSD.ORG Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 18:51 +0100 14/7/97, Steve Passe wrote: >Hi, > >Can anyone recommend a test suite/methodology for evaluating interrupt >latency? >I have some ideas for improving the (currently poor) int response of the SMP >kernel, but need a way to determine if I am actually bettering things. A digital output port and an oscilloscope, logic analyser or something similar. Any other (ie non-hardware) method is just inviting confusion. -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK From owner-freebsd-smp Mon Jul 14 14:14:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA14665 for smp-outgoing; Mon, 14 Jul 1997 14:14:42 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA14653; Mon, 14 Jul 1997 14:14:36 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id PAA01080; Mon, 14 Jul 1997 15:13:49 -0600 (MDT) Message-Id: <199707142113.PAA01080@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Bob Bishop cc: hackers@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: interrupt latency In-reply-to: Your message of "Mon, 14 Jul 1997 21:38:11 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Jul 1997 15:13:48 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > >Can anyone recommend a test suite/methodology for evaluating interrupt > >latency? > >I have some ideas for improving the (currently poor) int response of the SMP > >kernel, but need a way to determine if I am actually bettering things. > > A digital output port and an oscilloscope, logic analyser or something > similar. Any other (ie non-hardware) method is just inviting confusion. I tend to agree, but I think the "hardware" solution could be a 4 CPU MB. I was just discussing another possibility that goes as follows: program the first 2/3 CPUsas a 2/3 CPU SMP system. program the 4th CPU as a standalone INT receiver/statistic counter. program the APIC to send all INTs to the 4th CPU. the 4th CPU could then do nothing but accept INTs from the APIC, record the time, then dispatch them to the APIC bus, in a manner identical to that used by the IO APIC. The mainline ISR code could then be modified to send an IPI to the 4th CPU when the ISR was done. The 4th CPU would record the total time and record it in global memory. The 1st 3 CPUs wouldn't have a clue that they weren't getting them from the APIC, and the 4th CPU could service the real INTs almost as fast as they occur. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Mon Jul 14 15:42:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA19049 for smp-outgoing; Mon, 14 Jul 1997 15:42:40 -0700 (PDT) Received: from server.local.sunyit.edu (A-V25.rh.sunyit.edu [150.156.211.85]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA19037; Mon, 14 Jul 1997 15:42:31 -0700 (PDT) Received: from localhost (brightmn@localhost) by server.local.sunyit.edu (8.8.5/8.8.5) with SMTP id SAA05440; Thu, 26 Jun 1997 18:44:25 GMT Date: Thu, 26 Jun 1997 18:44:25 +0000 (GMT) From: BRiGHTMN To: Steve Passe cc: Bob Bishop , hackers@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: interrupt latency In-Reply-To: <199707142113.PAA01080@Ilsa.StevesCafe.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk dedicate a 600+$ CPU only to interupt control? doesn't sound very cost effective, that would mean a 2 CPU machine would almost "loose" a CPU... > I tend to agree, but I think the "hardware" solution could be a 4 CPU MB. > I was just discussing another possibility that goes as follows: > > program the first 2/3 CPUsas a 2/3 CPU SMP system. > program the 4th CPU as a standalone INT receiver/statistic counter. > program the APIC to send all INTs to the 4th CPU. > > the 4th CPU could then do nothing but accept INTs from the APIC, record > the time, then dispatch them to the APIC bus, in a manner identical to > that used by the IO APIC. The mainline ISR code could then be modified > to send an IPI to the 4th CPU when the ISR was done. The 4th CPU would > record the total time and record it in global memory. The 1st 3 CPUs > wouldn't have a clue that they weren't getting them from the APIC, and the 4th > CPU could service the real INTs almost as fast as they occur. > > -- > Steve Passe | powered by > smp@csn.net | Symmetric MultiProcessor FreeBSD > > > From owner-freebsd-smp Mon Jul 14 15:44:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA19153 for smp-outgoing; Mon, 14 Jul 1997 15:44:19 -0700 (PDT) Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA19108; Mon, 14 Jul 1997 15:44:02 -0700 (PDT) Received: from gid.co.uk (uucp@localhost) by isbalham.ist.co.uk (8.8.4/8.8.4) with UUCP id XAA12178; Mon, 14 Jul 1997 23:28:12 +0100 (BST) Received: from [194.32.164.2] by seagoon.gid.co.uk; Mon, 14 Jul 1997 23:30:30 +0100 X-Sender: rb@194.32.164.1 Message-Id: In-Reply-To: <199707142113.PAA01080@Ilsa.StevesCafe.com> References: Your message of "Mon, 14 Jul 1997 21:38:11 BST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Jul 1997 23:26:41 +0100 To: Steve Passe From: Bob Bishop Subject: Re: interrupt latency Cc: hackers@FreeBSD.ORG, smp@FreeBSD.ORG Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 22:13 +0100 14/7/97, Steve Passe wrote: [...] >> A digital output port and an oscilloscope, logic analyser or something >> similar. Any other (ie non-hardware) method is just inviting confusion. [...] >... and the 4th >CPU could service the real INTs almost as fast as they occur. ^^^^^^ |||||| As I was saying... :-) -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK From owner-freebsd-smp Mon Jul 14 16:08:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA20401 for smp-outgoing; Mon, 14 Jul 1997 16:08:07 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA20344; Mon, 14 Jul 1997 16:06:48 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id RAA01584; Mon, 14 Jul 1997 17:05:43 -0600 (MDT) Message-Id: <199707142305.RAA01584@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: BRiGHTMN cc: Bob Bishop , hackers@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: interrupt latency In-reply-to: Your message of "Thu, 26 Jun 1997 18:44:25 -0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Jul 1997 17:05:43 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, --- > dedicate a 600+$ CPU only to interupt control? this is STRICTLY for purposes of testing algorithms, NOT for normal use. --- > doesn't sound very cost effective, that would mean a 2 CPU machine would > almost "loose" a CPU... thats why I said a 4 CPU board would be necessary for this testing method -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Tue Jul 15 00:40:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA12341 for smp-outgoing; Tue, 15 Jul 1997 00:40:52 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA12336; Tue, 15 Jul 1997 00:40:46 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id RAA10413; Tue, 15 Jul 1997 17:32:50 +1000 Date: Tue, 15 Jul 1997 17:32:50 +1000 From: Bruce Evans Message-Id: <199707150732.RAA10413@godzilla.zeta.org.au> To: smp@csn.net, smp@FreeBSD.ORG Subject: Re: interrupt latency Cc: hackers@FreeBSD.ORG Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Can anyone recommend a test suite/methodology for evaluating interrupt latency? I sent Steve some code. Bruce From owner-freebsd-smp Tue Jul 15 01:02:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA13582 for smp-outgoing; Tue, 15 Jul 1997 01:02:35 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id BAA13549 for ; Tue, 15 Jul 1997 01:02:17 -0700 (PDT) Received: (qmail 9365 invoked by uid 1000); 15 Jul 1997 08:02:10 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199707141751.LAA02683@Ilsa.StevesCafe.com> Date: Tue, 15 Jul 1997 01:02:10 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Steve Passe Subject: RE: interrupt latency Cc: hackers@FreeBSD.ORG, smp@FreeBSD.ORG Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Steve Passe; On 14-Jul-97 you wrote: > Hi, > > Can anyone recommend a test suite/methodology for evaluating interrupt > latency? > I have some ideas for improving the (currently poor) int response of the > SMP > kernel, but need a way to determine if I am actually bettering things. > > -- > Steve Passe | powered by > smp@csn.net | Symmetric MultiProcessor FreeBSD > > I have microtime calls in the DPT driver. If I understand it correctly, on a P6-200 I could have 200 times better resolution with access to the registers in the CPU. I see interrupt latency of 0-3us with UP, and about the same with SMP, but suspect the timers resolution at these low numbers. Will be glad to acomodate. Simon From owner-freebsd-smp Tue Jul 15 01:24:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA14743 for smp-outgoing; Tue, 15 Jul 1997 01:24:08 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id BAA14722; Tue, 15 Jul 1997 01:24:00 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id JAA12495; Tue, 15 Jul 1997 09:19:25 +0200 From: Luigi Rizzo Message-Id: <199707150719.JAA12495@labinfo.iet.unipi.it> Subject: Re: interrupt latency To: Shimon@i-connect.net (Simon Shapiro) Date: Tue, 15 Jul 1997 09:19:25 +0200 (MET DST) Cc: smp@csn.net, hackers@FreeBSD.ORG, smp@FreeBSD.ORG In-Reply-To: from "Simon Shapiro" at Jul 15, 97 01:01:51 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I have microtime calls in the DPT driver. If I understand it correctly, on > a P6-200 I could have 200 times better resolution with access to the > registers in the CPU. I see interrupt latency of 0-3us with UP, and about perhaps 200 is too much (since any cpu stall, cache miss, etc. will hit you with a fair number of wasted cycles) but certainly 10-20 times better resolution. Luigi From owner-freebsd-smp Tue Jul 15 05:37:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA24384 for smp-outgoing; Tue, 15 Jul 1997 05:37:55 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA24379; Tue, 15 Jul 1997 05:37:52 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id WAA21429; Tue, 15 Jul 1997 22:34:34 +1000 Date: Tue, 15 Jul 1997 22:34:34 +1000 From: Bruce Evans Message-Id: <199707151234.WAA21429@godzilla.zeta.org.au> To: luigi@labinfo.iet.unipi.it, smp@csn.net Subject: Re: interrupt latency Cc: hackers@FreeBSD.ORG, smp@FreeBSD.ORG Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >the problem: > > in our SMP system an INT may be sent to a CPU that can't enter the kernel >because another CPU is currently inside the kernel. this causes a long delay >between the time the INT tickels the hardware and the time the ISR actually >runs. > >--- >So I guess the 2 points in time are the actual instance of hardware >INT and the time the ISR completes. The closest the software can get to >determining the start point would be on entry to _XintrNN (isa/apic_vector.s) >A convenient stop point would be immediately after the lock is acquired >(ie, after GET_MPLOCK in _XintrNN), the completion of the ISR code should be >constant. High-resolution kernel profiling (option GUPROF + kgmon -B) would show the time spent by interrupt handlers (if it worked on SMP systems :-]). The results wouldn't be very interesting. Some ISRs take several msec. You don't need hardware to measure such gross latency. I think a latency of several msec is actually only bad (relative to the uniprocessor case) for clock and fast interrupts. Network interrupts probably should have higher priority than disk interrupts, but disk interrupts can currently preempt network interrupts, and vice versa. Handling pcaudio (clock) interrupts at 16KHz is a good test. The clock interrupts should not be affected by disk and network ISRs. >But this hides the time between the actual firing of the hardware INT and >the time a CPU accepts it. This could be fairly long if the "accepting CPU" >is stuck behing the "giant lock", as hardware INTs are blocked during this >time. You'll have to arrange for INTs sent to CPUs not in the kernel to be sent to the one in the kernel just to match uniprocessor interrupt latency. Bruce From owner-freebsd-smp Tue Jul 15 14:21:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA24976 for smp-outgoing; Tue, 15 Jul 1997 14:21:15 -0700 (PDT) Received: from mail.rwth-aachen.de (mail.RWTH-Aachen.DE [137.226.144.9]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA24962 for ; Tue, 15 Jul 1997 14:21:06 -0700 (PDT) Received: from s2m181.dialup.RWTH-Aachen.DE (s2m181.dialup.RWTH-Aachen.DE) by mail (PMDF V5.0-6 #16313) id <01ILA7JPH57A8WVYK0@mail> for smp@freebsd.org; Tue, 15 Jul 1997 23:21:24 +0000 (GMT) Date: Wed, 16 Jul 1997 23:20:40 +0200 From: Heiko Heiken Subject: subscripe freebsd-smp [Heiko.Heiken@post.rwth-aachen.de] To: smp@freebsd.org Message-id: <01ILA7JPP0P48WVYK0@mail> MIME-version: 1.0 X-Mailer: Microsoft Internet Mail 4.70.1161 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-MSMail-Priority: Normal X-Priority: 3 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk From owner-freebsd-smp Tue Jul 15 17:55:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA09583 for smp-outgoing; Tue, 15 Jul 1997 17:55:01 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA09570 for ; Tue, 15 Jul 1997 17:54:58 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id SAA06095 for ; Tue, 15 Jul 1997 18:54:56 -0600 (MDT) Message-Id: <199707160054.SAA06095@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: smp@freebsd.org Subject: Latest code. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Jul 1997 18:54:56 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, This would be a good time to update your source trees. I have made some fairly substantial changes in the INT code and would like to see it tested on as many machines as possible before I start to depend on it. I'm planning on going after the giant lock soon and will probably be introducing some instability with those changes so thats another good reason to update now. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Tue Jul 15 19:08:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA13114 for smp-outgoing; Tue, 15 Jul 1997 19:08:31 -0700 (PDT) Received: from byako.lovett.com (root@byako.lovett.com [193.195.45.9]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id TAA13109 for ; Tue, 15 Jul 1997 19:08:27 -0700 (PDT) Received: from ade by byako.lovett.com with esmtp (Exim 1.62 #1) id 0woJVb-0007gY-00; Wed, 16 Jul 1997 03:08:03 +0100 To: Steve Passe Cc: smp@freebsd.org Organization: Demon Internet Ltd. Subject: Re: Latest code. In-reply-to: Your message of "Tue, 15 Jul 1997 18:54:56 MDT." <199707160054.SAA06095@Ilsa.StevesCafe.com> Date: Wed, 16 Jul 1997 03:08:03 +0100 From: Ade Lovett Message-Id: Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe writes: > >This would be a good time to update your source trees. I have made some fairly >substantial changes in the INT code and would like to see it tested on as many >machines as possible before I start to depend on it. I'm planning on going >after the giant lock soon and will probably be introducing some instability >with those changes so thats another good reason to update now. Spookily enough, I completely blew away my SMP machine here earlier on this morning (pilot error, which included nuking my repository *sigh*) so am in the process of re-cvsup'ing the entire tree again (in fact, it completed about 2 hours ago -- 16/07/97 0100 GMT -- is that recent enough for the code updates you made?) Is there anything in particular that needs to be 'tested to destruction'? I'm good at breaking OS'es.. I turn them into news servers :) -aDe -- Ade Lovett, Demon Internet Ltd. From owner-freebsd-smp Tue Jul 15 19:20:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA13762 for smp-outgoing; Tue, 15 Jul 1997 19:20:50 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA13752 for ; Tue, 15 Jul 1997 19:20:42 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id UAA06349; Tue, 15 Jul 1997 20:20:25 -0600 (MDT) Message-Id: <199707160220.UAA06349@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Ade Lovett cc: smp@freebsd.org Subject: Re: Latest code. In-reply-to: Your message of "Wed, 16 Jul 1997 03:08:03 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Jul 1997 20:20:25 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > >This would be a good time to update your source trees. ... > Spookily enough, I completely blew away my SMP machine here earlier on > this morning (pilot error, which included nuking my repository *sigh*) > so am in the process of re-cvsup'ing the entire tree again (in fact, it > completed about 2 hours ago -- 16/07/97 0100 GMT -- is that recent enough > for the code updates you made?) yes, my last commit was: fsmp 1997/07/14 21:56:59 PDT > Is there anything in particular that needs to be 'tested to destruction'? > I'm good at breaking OS'es.. I turn them into news servers :) the major changes affect INT service so lots of IO is a good test. Also changed the way systems using "options SMP_TIMER_NC" are setup, so a works/no works yell from anyone running those would be nice ( I always get the "no works" yells, but seldom the "works" variety!). -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Tue Jul 15 22:37:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA22227 for smp-outgoing; Tue, 15 Jul 1997 22:37:21 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA22216 for ; Tue, 15 Jul 1997 22:37:14 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id HAA27890; Wed, 16 Jul 1997 07:15:47 +0200 (MET DST) Received: (from andreas@localhost) by klemm.gtn.com (8.8.6/8.8.6) id XAA22445; Tue, 15 Jul 1997 23:28:39 +0200 (CEST) Message-ID: <19970715232839.14500@gtn.com> Date: Tue, 15 Jul 1997 23:28:39 +0200 From: Andreas Klemm To: Steve Passe Cc: david.myers@Corp.Sun.COM, freebsd-smp@freebsd.org Subject: Re: SMP current status? References: <199706201738.KAA25205@concord.Corp.Sun.COM> <199706231740.LAA06459@Ilsa.StevesCafe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199706231740.LAA06459@Ilsa.StevesCafe.com>; from Steve Passe on Mon, Jun 23, 1997 at 11:40:46AM -0600 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT SMP Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, Jun 23, 1997 at 11:40:46AM -0600, Steve Passe wrote: > > How stable? > > hard to quantify, but it builds world and runs for weeks on most systems > without problems. Had no problems since months ! Very stable, no panics. -- Andreas Klemm | klemm.gtn.com - powered by Symmetric MultiProcessor FreeBSD http://www.freebsd.org/~fsmp/SMP/SMP.html http://www.freebsd.org/~fsmp/SMP/benches.html From owner-freebsd-smp Tue Jul 15 22:51:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA22840 for smp-outgoing; Tue, 15 Jul 1997 22:51:03 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA22835 for ; Tue, 15 Jul 1997 22:51:00 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id XAA06975 for ; Tue, 15 Jul 1997 23:51:00 -0600 (MDT) Message-Id: <199707160551.XAA06975@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: smp@freebsd.org Subject: HEADS UP: EISA cards. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Jul 1997 23:51:00 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, DESIGN DECISION: I am about to make a design decision that will forever-more make the use of EISA cards that use the EISA chipset DMA circuit impossible in the SMP kernel. I posted a rather long email about this several days ago but got ZERO response. So I can conclude that either: a: everyone agrees with this decision. OR b: no one with such hardware read that far. In the future I will use this "HEADS UP" format to get a summary of such info to the top of email. For the record, here is a repost of the pertinant info: ----------------------------------- cut ----------------------------------- Till now we have been using "mixed mode programming" where the 8259 PIC's INT output is routed thru the APIC and handled as an 'ExtInt' on those machines that don't route the 8254 to the APIC. ... It turns out that when you do this the 8254 timer INTs (or any INT from the 8259) are NOT reflected in the APIC IRR/ISR registers, and CANNOT be masked via the APIC TPR register/process priority scheme. This is unacceptable ... Intel has a solution in: Intel486(TM) MicroProcessors and related Products, order #241731-002 pp 4-220 thru 4-302: 82489DX Advanced Programmable Interrupt Controller ... - program the 8259 to pass ONLY the DMA chaining INT - program the IO APIC to handle this as a regular (ie not 'ExtInt') input - abandon the 8254 timer, instead using the APIC's internal timer. ... I believe that we don't want to abandon the 8254, but instead should abandon the DMA chaining INTs (who uses these anyways???) Then we can program in a similar way, but instead pass the 8254 INT thru as a regular INT. ... we need to make a policy decision as to whether we can say bye-bye to the DMA chaining INTs. If I don't get thoughtful feedback on this I will just nmake an arbitrary decision (which I suspect to be axing the DMA INTs). I think the only situation needing them is non-busmaster EISA hardware that does DMA via the motherboard chipset DMA registers. Please correct me if I am wrong on this point. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Tue Jul 15 23:57:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA25872 for smp-outgoing; Tue, 15 Jul 1997 23:57:11 -0700 (PDT) Received: from critter.dk.tfs.com (critter.phk.freebsd.dk [195.8.133.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA25867 for ; Tue, 15 Jul 1997 23:57:07 -0700 (PDT) Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.6/8.8.5) with ESMTP id IAA15532; Wed, 16 Jul 1997 08:56:24 +0200 (CEST) To: Steve Passe cc: smp@freebsd.org From: Poul-Henning Kamp Subject: Re: HEADS UP: EISA cards. In-reply-to: Your message of "Tue, 15 Jul 1997 23:51:00 MDT." <199707160551.XAA06975@Ilsa.StevesCafe.com> Date: Wed, 16 Jul 1997 08:56:23 +0200 Message-ID: <15530.869036183@critter.dk.tfs.com> Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >DESIGN DECISION: > >I am about to make a design decision that will forever-more make the use >of EISA cards that use the EISA chipset DMA circuit impossible in the SMP >kernel. I posted a rather long email about this several days ago but got ZERO >response. So I can conclude that either: About the only card this could affect is the AHA1742 (ahb%d driver). Does anybody know if this card uses this feature ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-smp Wed Jul 16 00:03:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA26084 for smp-outgoing; Wed, 16 Jul 1997 00:03:16 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA26078 for ; Wed, 16 Jul 1997 00:03:10 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id BAA07318; Wed, 16 Jul 1997 01:03:06 -0600 (MDT) Message-Id: <199707160703.BAA07318@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Poul-Henning Kamp cc: smp@freebsd.org Subject: Re: HEADS UP: EISA cards. In-reply-to: Your message of "Wed, 16 Jul 1997 08:56:23 +0200." <15530.869036183@critter.dk.tfs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jul 1997 01:03:06 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > About the only card this could affect is the AHA1742 (ahb%d driver). > Does anybody know if this card uses this feature ? Peter Wemm was using it in his old dual P5 without problem. This was with APIC code that did NOT support the DMA chaining INTs (at least not thru the 8259 PIC). The fact is that we have never supported them in the APIC code and no one has complained so far. Its just that I am about to go down a path that makes it "final" and want everyone to be aware. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Jul 16 01:26:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA29199 for smp-outgoing; Wed, 16 Jul 1997 01:26:53 -0700 (PDT) Received: from scorpion.aracnet.com (root@scorpion.aracnet.com [204.188.47.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA29193 for ; Wed, 16 Jul 1997 01:26:50 -0700 (PDT) Received: from speedy (ppp-r29.aracnet.com [205.238.13.31]) by scorpion.aracnet.com (8.8.5/8.8.5) with ESMTP id BAA22555; Wed, 16 Jul 1997 01:26:44 -0700 Message-ID: <33CC9317.9C7588D8@earthling.net> Date: Wed, 16 Jul 1997 01:23:35 -0800 From: Chris Browning Reply-To: cbrown@aracnet.com X-Mailer: Mozilla 4.01 [en] (WinNT; I) MIME-Version: 1.0 To: Steve Passe CC: smp@FreeBSD.ORG Subject: Re: HEADS UP: EISA cards. X-Priority: 3 (Normal) References: <199707160551.XAA06975@Ilsa.StevesCafe.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Steve, This is a very interesting question. I would like to dig into this to see what the "right" thing to do is. Unfortunately, I am not that familar with some of the issues on the SW side of things. I will try to look into this DMA chaining impact. I have a few questions/comments about your proposal. Please excuse any ignorance on my part. I always try to error on the side of completeness :-). > Till now we have been using "mixed mode programming" where the 8259 > PIC's > INT output is routed thru the APIC and handled as an 'ExtInt' on those > machines that don't route the 8254 to the APIC. I DEFINIATELY agree with the drop mix-mode thing. It is a nightmare. NT and some of the other unixes have already sucessfully done this. In addition, you can't support more than one IOAPIC with just mixed-mode (I think). > It turns out that when you do this the 8254 timer INTs (or any INT > from the > 8259) are NOT reflected in the APIC IRR/ISR registers, and CANNOT be > masked > via the APIC TPR register/process priority scheme. This is > unacceptable Interesting. Do you have an 8259 or 8254 in your machine? I doubt it. The south bridge / IOAPIC in your machine is emulating their behavior. This is done for backwards compatibility for brain-dead OSes like DOS. I am also curious about why this would be unacceptible. It might have been mentioned in the full decription. > Intel486(TM) MicroProcessors and related Products, order #241731-002 > pp 4-220 thru 4-302: 82489DX Advanced Programmable Interrupt > Controller > ... > - program the 8259 to pass ONLY the DMA chaining INT > - program the IO APIC to handle this as a regular (ie not 'ExtInt') > input > - abandon the 8254 timer, instead using the APIC's internal timer. > ... > I believe that we don't want to abandon the 8254, but instead should > abandon the DMA chaining INTs (who uses these anyways???) Then we > can program in a similar way, but instead pass the 8254 INT thru as > a regular INT. Why would you not want to abandon the 8254? Why not use the APIC's timer? I would imagine that it was put there for this purpose when running in full symetric mode. Also, why would you not want to program the IOAPIC to handle "this" as normal INTs? > we need to make a policy decision as to whether we can say > bye-bye to the DMA chaining INTs. If I don't get thoughtful feedback > on this > I will just nmake an arbitrary decision (which I suspect to be axing > the DMA > INTs). I think the only situation needing them is non-busmaster EISA > hardware > that does DMA via the motherboard chipset DMA registers. Please > correct me > if I am wrong on this point. What about ISA non-busmastering (most ISA cards) that use MB DMA for operation. Sound cards come to mind :-). Do you not use the chipset DMA for this (you know, when you set the DMA channels on your SB16 to 0 and 1)? Well, I hope this help and is not confusing for you. Chris Intel Corporation Enterprise Servers Group Product Engineering Competitive Development I don't speak for anyone, especially Intel. From owner-freebsd-smp Wed Jul 16 03:34:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA04027 for smp-outgoing; Wed, 16 Jul 1997 03:34:40 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.visint.co.uk [194.207.134.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA04019 for ; Wed, 16 Jul 1997 03:34:31 -0700 (PDT) Received: from dylan.visint.co.uk (dylan.visint.co.uk [194.207.134.180]) by bagpuss.visint.co.uk (8.7.5/8.7.3) with SMTP id LAA00332; Wed, 16 Jul 1997 11:34:23 +0100 (BST) Date: Wed, 16 Jul 1997 11:34:23 +0100 (BST) From: Stephen Roome To: Steve Passe cc: smp@FreeBSD.ORG Subject: Re: HEADS UP: EISA cards. In-Reply-To: <199707160551.XAA06975@Ilsa.StevesCafe.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 15 Jul 1997, Steve Passe wrote: > I am about to make a design decision that will forever-more make the use > of EISA cards that use the EISA chipset DMA circuit impossible in the SMP > kernel. I posted a rather long email about this several days ago but got ZERO > response. So I can conclude that either: > > a: everyone agrees with this decision. > OR > b: no one with such hardware read that far. (Warning: uninformed gut-reactions follow) I think you missed out c: which was that some folks, me included, didn't entirely follow the implications, but IMHO, I wouldn't build an SMP system relying heavily or even using EISA. It sounds to me like a small loss, but as I'm not sure exactly how much is gained out of it I couldn't make the decision either. Basically: 1) I don't use EISA cards except in one 486 here, and that's going asap as well. 2) In an SMP system I would always use PCI instead of EISA, only because if I'm buying an SMP system it's due to performance/newness issues and EISA wouldn't be my choice of performance/newest peripherals. > we need to make a policy decision as to whether we can say > bye-bye to the DMA chaining INTs. If I don't get thoughtful feedback on this > I will just nmake an arbitrary decision (which I suspect to be axing the DMA > INTs). I think the only situation needing them is non-busmaster EISA hardware > that does DMA via the motherboard chipset DMA registers. Please correct me > if I am wrong on this point. Well, if you're right these don't sound like the sort of cards I'd be buying for a smp machine. -- Steve Roome - Vision Interactive Ltd. Tel:+44(0)117 9730597 Home:+44(0)976 241342 WWW: http://dylan.visint.co.uk/ From owner-freebsd-smp Wed Jul 16 04:08:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA04964 for smp-outgoing; Wed, 16 Jul 1997 04:08:37 -0700 (PDT) Received: from spinner.dialix.com.au (spinner.dialix.com.au [192.203.228.67]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA04951 for ; Wed, 16 Jul 1997 04:08:29 -0700 (PDT) Received: from spinner.dialix.com.au (localhost.dialix.com.au [127.0.0.1]) by spinner.dialix.com.au with ESMTP id TAA15825; Wed, 16 Jul 1997 19:08:01 +0800 (WST) Message-Id: <199707161108.TAA15825@spinner.dialix.com.au> X-Mailer: exmh version 2.0delta 6/3/97 To: Steve Passe cc: smp@FreeBSD.ORG Subject: Re: HEADS UP: EISA cards. In-reply-to: Your message of "Tue, 15 Jul 1997 23:51:00 CST." <199707160551.XAA06975@Ilsa.StevesCafe.com> Date: Wed, 16 Jul 1997 19:08:00 +0800 From: Peter Wemm Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote: > ... > I believe that we don't want to abandon the 8254, but instead should > abandon the DMA chaining INTs (who uses these anyways???) Then we > can program in a similar way, but instead pass the 8254 INT thru as > a regular INT. > ... > we need to make a policy decision as to whether we can say > bye-bye to the DMA chaining INTs. If I don't get thoughtful feedback on this > I will just nmake an arbitrary decision (which I suspect to be axing the DMA > INTs). I think the only situation needing them is non-busmaster EISA hardwar e > that does DMA via the motherboard chipset DMA registers. Please correct me > if I am wrong on this point. I believe, that we don't support the DMA chaining interrupt in any way, shape or form at present. I would not think it would be a big loss. I think you are correct, it's only used for motherboard driven DMA. Busmastering DMA (any EISA card worth using would do this anyway) is unrelated to that. I vote for declaring it stillborn, especially as EISA is apparently not on the "cool hardware of the day" list. Cheers, -Peter From owner-freebsd-smp Wed Jul 16 08:16:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA16853 for smp-outgoing; Wed, 16 Jul 1997 08:16:47 -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 IAA16842 for ; Wed, 16 Jul 1997 08:16:43 -0700 (PDT) Received: from fast.cs.utah.edu by cs.utah.edu (8.8.4/utah-2.21-cs) id JAA11464; Wed, 16 Jul 1997 09:16:36 -0600 (MDT) Received: by fast.cs.utah.edu (8.6.10/utah-2.15-leaf) id JAA02892; Wed, 16 Jul 1997 09:16:35 -0600 Date: Wed, 16 Jul 1997 09:16:35 -0600 From: vanmaren@fast.cs.utah.edu (Kevin Van Maren) Message-Id: <199707161516.JAA02892@fast.cs.utah.edu> To: smp@FreeBSD.ORG, smp@csn.net Subject: Re: HEADS UP: EISA cards. Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Okay, I'll bite. First off, I think that you DO want to abandon the 8254 timer under SMP. The APIC's internal timer is much nicer. Second, while I'm not very familiar with DMA under FreeBSD, but you made it sound like only EISA cards would be affected, and not ISA network cards or sound cards. Is this certain? Also, there are still a lot more EISA machines than SMP machines, especially when you consider that almost every new server still comes with EISA. It seems that if you use the APIC timer, you get more functionality and higher resolution, while still retaining compatability with EISA hardware. This seems like a good idea. Kevin From owner-freebsd-smp Wed Jul 16 09:35:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA21554 for smp-outgoing; Wed, 16 Jul 1997 09:35:16 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA21539 for ; Wed, 16 Jul 1997 09:35:08 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id KAA08806; Wed, 16 Jul 1997 10:34:55 -0600 (MDT) Message-Id: <199707161634.KAA08806@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: cbrown@aracnet.com cc: Steve Passe , smp@FreeBSD.ORG Subject: Re: HEADS UP: EISA cards. In-reply-to: Your message of "Wed, 16 Jul 1997 01:23:35 -0800." <33CC9317.9C7588D8@earthling.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jul 1997 10:34:55 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, --- > > Till now we have been using "mixed mode programming" where the 8259 > > PIC's > > INT output is routed thru the APIC and handled as an 'ExtInt' on those > > machines that don't route the 8254 to the APIC. > > I DEFINIATELY agree with the drop mix-mode thing. It is a nightmare. > NT and some of the other unixes have already sucessfully done this. > In addition, you can't support more than one IOAPIC with just > mixed-mode (I think). do you have any references to anything written about how NT or others deal with the APIC? --- > > It turns out that when you do this the 8254 timer INTs (or any INT > > from the > > 8259) are NOT reflected in the APIC IRR/ISR registers, and CANNOT be > > masked > > via the APIC TPR register/process priority scheme. This is > > unacceptable > > Interesting. Do you have an 8259 or 8254 in your machine? I doubt it. > The south bridge / IOAPIC in your machine is emulating their behavior. > This is done for backwards compatibility for brain-dead OSes like DOS. > I am also curious about why this would be unacceptible. It might > have been mentioned in the full decription. your technically correct, but the "emulation" is essentually the same thing from a programming point of view. The "unacceptable" part refers to giving up the ability to use the TPR/PPR registers to block/accept INTs by priority level. It is necessary to receive IPIs while hardware INTs are blocked, and I know of no other way to do this. --- > > ... > > - program the 8259 to pass ONLY the DMA chaining INT > > - program the IO APIC to handle this as a regular (ie not 'ExtInt') > > input > > - abandon the 8254 timer, instead using the APIC's internal timer. > > ... > > I believe that we don't want to abandon the 8254, but instead should > > abandon the DMA chaining INTs (who uses these anyways???) Then we > > can program in a similar way, but instead pass the 8254 INT thru as > > a regular INT. > > Why would you not want to abandon the 8254? Why not use the APIC's > timer? I would imagine that it was put there for this purpose when > running in full symetric mode. > Also, why would you not want to program the IOAPIC to handle > "this" as normal INTs? we have alot invested in 8254 code for one thing. using the APIC timer would require alot of work. maybe sometime in the future. there is also the issue of distributed timers vs. a central timer. which CPU is the "central" timer? do you distribute the tick code across each, or broadcast from one. there are alot of ways to go, and someday an analysis might suggest a "better way" involving the APIC timers, but for now I would rather stick with the 8254. --- > > we need to make a policy decision as to whether we can say > > bye-bye to the DMA chaining INTs. If I don't get thoughtful feedback > > on this > > I will just nmake an arbitrary decision (which I suspect to be axing > > the DMA > > INTs). I think the only situation needing them is non-busmaster EISA > > hardware > > that does DMA via the motherboard chipset DMA registers. Please > > correct me > > if I am wrong on this point. > > What about ISA non-busmastering (most ISA cards) that use MB DMA for > operation. Sound cards come to mind :-). Do you not use the > chipset DMA for this (you know, when you set the DMA channels on > your SB16 to 0 and 1)? I believe this is different circuitry. The DMA hardware I am speaking of is a feature of EISA chipsets only. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Jul 16 09:55:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA22481 for smp-outgoing; Wed, 16 Jul 1997 09:55:15 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA22468 for ; Wed, 16 Jul 1997 09:54:54 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id KAA08913; Wed, 16 Jul 1997 10:52:10 -0600 (MDT) Message-Id: <199707161652.KAA08913@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Stephen Roome cc: smp@FreeBSD.ORG Subject: Re: HEADS UP: EISA cards. In-reply-to: Your message of "Wed, 16 Jul 1997 11:34:23 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jul 1997 10:52:09 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > > response. So I can conclude that either: > > > > a: everyone agrees with this decision. > > OR > > b: no one with such hardware read that far. > > (Warning: uninformed gut-reactions follow) > I think you missed out c: which was that some folks, me included, didn't > entirely follow the implications, but IMHO, I wouldn't build an SMP system > relying heavily or even using EISA. It sounds to me like a small loss, but > as I'm not sure exactly how much is gained out of it I couldn't make the > decision either. FreeBSD has a tradition for not being "snobbish" in the area of dictating what hardware "deserves" to be supported. I see support for some things I wouldn't pass the trash can to put into a junk box on the other side of the room. So I don't want to ignore this side of things. (Don't take this paragraph too literally, I agree with the policy in general, I'm just saying you sometimes have to draw a line. Consider this a "blowing off some steam" rant.) --- > Basically: > 1) I don't use EISA cards except in one 486 here, and that's going asap as > well. > > 2) In an SMP system I would always use PCI instead of EISA, only because > if I'm buying an SMP system it's due to performance/newness issues and > EISA wouldn't be my choice of performance/newest peripherals. the bottom line is that an ISA/EISA machine is a BAD choice for SMP. Intel put things in the MP spec to allow use of some of their "older" technology, including earlier EISA chip-sets. This is the root cause for this particular problem. There are several GOOD PCI/EISA machine out the (asus comes to mind), but think of them as PCI/ISA, and don't consider using EISA cards in them. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Jul 16 10:10:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA23339 for smp-outgoing; Wed, 16 Jul 1997 10:10:42 -0700 (PDT) Received: from cais.cais.com (root@cais.com [199.0.216.4]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA23334 for ; Wed, 16 Jul 1997 10:10:39 -0700 (PDT) Received: from earth.mat.net (root@earth.mat.net [205.252.122.1]) by cais.cais.com (8.8.5/CJKv1.99-CAIS) with SMTP id NAA26603; Wed, 16 Jul 1997 13:10:22 -0400 (EDT) Received: from Journey2.mat.net (journey2.mat.net [205.252.122.116]) by earth.mat.net (8.6.12/8.6.12) with SMTP id NAA25889; Wed, 16 Jul 1997 13:10:20 -0400 Date: Wed, 16 Jul 1997 13:10:12 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@Journey2.mat.net To: Steve Passe cc: smp@FreeBSD.ORG Subject: Re: HEADS UP: EISA cards. In-Reply-To: <199707160551.XAA06975@Ilsa.StevesCafe.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 15 Jul 1997, Steve Passe wrote: > Hi, > > DESIGN DECISION: > > I am about to make a design decision that will forever-more make the use > of EISA cards that use the EISA chipset DMA circuit impossible in the SMP > kernel. I posted a rather long email about this several days ago but got ZERO > response. So I can conclude that either: > > a: everyone agrees with this decision. > OR > b: no one with such hardware read that far. > > In the future I will use this "HEADS UP" format to get a summary of such > info to the top of email. For the record, here is a repost of the > pertinant info: Steve, I don't have an EISA smp board, so I felt I didn't need to reply, but your suggestion is fine with me. Thinking about it, the only EISA boards out there would be getting a little aged, and it seems fairly safe to exclude them from smp work. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-smp Wed Jul 16 10:19:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA23809 for smp-outgoing; Wed, 16 Jul 1997 10:19:41 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA23800 for ; Wed, 16 Jul 1997 10:19:38 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.6/8.6.9) with ESMTP id KAA14374; Wed, 16 Jul 1997 10:03:45 -0700 (PDT) To: Steve Passe cc: Stephen Roome , smp@FreeBSD.ORG Subject: Re: HEADS UP: EISA cards. In-reply-to: Your message of "Wed, 16 Jul 1997 10:52:09 MDT." <199707161652.KAA08913@Ilsa.StevesCafe.com> Date: Wed, 16 Jul 1997 10:03:43 -0700 Message-ID: <14370.869072623@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > FreeBSD has a tradition for not being "snobbish" in the area of dictating > what hardware "deserves" to be supported. I see support for some things > I wouldn't pass the trash can to put into a junk box on the other side of > the room. So I don't want to ignore this side of things. (Don't take this > paragraph too literally, I agree with the policy in general, I'm just saying > you sometimes have to draw a line. Consider this a "blowing off some > steam" rant.) While this is all true, I think that SMP falls also pretty squarely into the new feature category and, as such, could easily get away with saying that old feature or system xxx is incompatible with new feature yyy and yyy simply isn't going to support it. Now if you were talking about taking out all EISA support in the uniprocessor version, well, that'd be something different. ;) JOrdan From owner-freebsd-smp Wed Jul 16 10:29:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA24305 for smp-outgoing; Wed, 16 Jul 1997 10:29:08 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA24286 for ; Wed, 16 Jul 1997 10:28:42 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id LAA09048; Wed, 16 Jul 1997 11:19:27 -0600 (MDT) Message-Id: <199707161719.LAA09048@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: vanmaren@fast.cs.utah.edu (Kevin Van Maren) cc: smp@FreeBSD.ORG Subject: Re: HEADS UP: EISA cards. In-reply-to: Your message of "Wed, 16 Jul 1997 09:16:35 MDT." <199707161516.JAA02892@fast.cs.utah.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jul 1997 11:19:27 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > First off, I think that you DO want to abandon the 8254 timer > under SMP. The APIC's internal timer is much nicer. i've gotten several such responses, this issue (8254 vs. APIC timer) needs more study... --- > Second, while I'm not very familiar with DMA under FreeBSD, but > you made it sound like only EISA cards would be affected, and > not ISA network cards or sound cards. Is this certain? its certain that it ONLY affects EISA cards, whats not certain is whether it affects busmastering EISA cards. Experience shows that it doesn't affect the adaptec 1742 EISA card, which is probably the only EISA issue for +90% of our user base. --- > Also, there are still a lot more EISA machines than SMP machines, > especially when you consider that almost every new server still > comes with EISA. This is stricly an SMP/APIC code issue, has NO affect on the UP system, so its only an issue for SMP hardware using EISA cards, of which I suggest there are few to none. --- > It seems that if you use the APIC timer, you get more functionality > and higher resolution, while still retaining compatability with > EISA hardware. This seems like a good idea. In the abstract, but the reality is that it would have to be coded and supported. We are really talking 2 differenrt issues here. The EISA compatibility loss is strictly because you cannot properly support more than one device thru the 8259 properly. So I am going to "cast that in stone" now. If in the future we do go from the 8254 timer to the APIC timers we would magically get the EISA capability back. So maybe saying "forever-more" is a bit harsh, just "if/until its decided to forgo the 8254 for the APIC timers" -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Jul 16 11:07:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA26834 for smp-outgoing; Wed, 16 Jul 1997 11:07:06 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA26538 for ; Wed, 16 Jul 1997 11:02:11 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id LAA09161; Wed, 16 Jul 1997 11:38:11 -0600 (MDT) Message-Id: <199707161738.LAA09161@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Peter Wemm cc: smp@FreeBSD.ORG Subject: Re: HEADS UP: EISA cards. In-reply-to: Your message of "Wed, 16 Jul 1997 19:08:00 +0800." <199707161108.TAA15825@spinner.dialix.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jul 1997 11:38:11 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Peter, > I believe, that we don't support the DMA chaining interrupt in any way, > shape or form at present. I would not think it would be a big loss. I > think you are correct, it's only used for motherboard driven DMA. > Busmastering DMA (any EISA card worth using would do this anyway) is > unrelated to that. I vote for declaring it stillborn, especially as EISA > is apparently not on the "cool hardware of the day" list. this appears to be the consensus, its dead! (but as I mentioned earlier, if we ever go to exclusive use of the APIC timers, it could rise from the grave!) -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Jul 16 12:27:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA01673 for smp-outgoing; Wed, 16 Jul 1997 12:27:59 -0700 (PDT) Received: from proxy.lkb.lv (proxy.lkb.lv [195.244.134.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA01579 for ; Wed, 16 Jul 1997 12:23:35 -0700 (PDT) Received: from cave.lkb.lv (cave.lkb.lv [195.244.134.13]) by proxy.lkb.lv (8.7.6/8.7.3) with SMTP id VAA21081 for ; Wed, 16 Jul 1997 21:49:09 +0300 (EET DST) Message-ID: <33CD17DC.38E8@proxy.lkb.lv> Date: Wed, 16 Jul 1997 21:50:04 +0300 From: Uldis Mikelsons Reply-To: ulmik@proxy.lkb.lv Organization: AS Latvijas Krajbanka X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: freebsd-smp@freebsd.org Subject: 3.0-970716-SNAP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi. I just installed minimum SNAP ( bin + ssys ( kernel src )) and result is : ------------------------------------------------------------------------ cd /sys/i386/conf/ config SMP-GENERIC cd ../../compile/SMP-GENERIC make all [skip] loading kernel mp_machdep.o: Undefined symbol `_db_printf' referenced from text segment mp_machdep.o: Undefined symbol `_db_printf' referenced from text segment mp_machdep.o: Undefined symbol `_db_printf' referenced from text segment mp_machdep.o: Undefined symbol `_db_printf' referenced from text segment mp_machdep.o: Undefined symbol `_db_printf' referenced from text segment *** Error code 1 Stop. ------------------------------------------------------------------------ when making GENERIC kernel it compiles without a problems Uldis From owner-freebsd-smp Wed Jul 16 12:35:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA01931 for smp-outgoing; Wed, 16 Jul 1997 12:35:32 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA01734 for ; Wed, 16 Jul 1997 12:29:16 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id LAA09133; Wed, 16 Jul 1997 11:33:58 -0600 (MDT) Message-Id: <199707161733.LAA09133@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: "Jordan K. Hubbard" cc: Stephen Roome , smp@FreeBSD.ORG Subject: Re: HEADS UP: EISA cards. In-reply-to: Your message of "Wed, 16 Jul 1997 10:03:43 PDT." <14370.869072623@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jul 1997 11:33:58 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > > FreeBSD has a tradition for not being "snobbish" in the area of dictating > > ... > While this is all true, I think that SMP falls also pretty squarely > into the new feature category and, as such, could easily get away with > saying that old feature or system xxx is incompatible with new feature > yyy and yyy simply isn't going to support it. > > Now if you were talking about taking out all EISA support in > the uniprocessor version, well, that'd be something different. ;) which I'm not. For awhile I was ready to chuck support for all those ugly machines that claim to be routing the timer via the APIC, but that dont! Unfortunately there are far too many of them to consider this. And we can lay the blame clearly on Intel's doorstep. If they would have thought to the future and used the policy you state above we wouldn't be saddled with these brain-dead hardware configurations in the first place! (more rant...) -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Jul 16 13:44:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA06321 for smp-outgoing; Wed, 16 Jul 1997 13:44:23 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA06268; Wed, 16 Jul 1997 13:44:11 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id OAA09705; Wed, 16 Jul 1997 14:42:55 -0600 (MDT) Message-Id: <199707162042.OAA09705@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: smp@freebsd.org cc: current@freebsd.org Subject: self modifying kernel code Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jul 1997 14:42:55 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I see the possible usefullness for "self-modifying-code" in several places in the SMP kernel. I currently am doing some "redirected calls" for INT resumption routines because we don't know till run time where several of the vectors will be. Peter pointed out a technique where another SMP kernel puts calls in the kernel to a pseudo-lock routine. This routine then determines whether it is running on a UP or SMP motherboard. If UP it replaces the call with a near jump to the return address. If SMP it replaces the call TARGET address with the address of the real lock routine. Note that this means a modification the 1st time EACH call to a lock/unlock routine is encountered, NOT "just once". This is a win for both UP and SMP, while allowing one kernel to support both. So what is the policy/reality of self-modifying code in the -current source? The 1st example above can be handled during boot, so I suspect that the modifications should be easy enough. The second involves modification of the kernel code space after going multi-user (probaly dozens of times b4 its finished), I'm not so sure about modifying kernel code-space at that point... Comments? -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Jul 16 13:58:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA07333 for smp-outgoing; Wed, 16 Jul 1997 13:58:52 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA07279; Wed, 16 Jul 1997 13:57:59 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id OAA09649; Wed, 16 Jul 1997 14:25:35 -0600 (MDT) Message-Id: <199707162025.OAA09649@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: smp@freebsd.org cc: Peter Wemm , dyson@freebsd.org Subject: pushdown of "giant lock" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jul 1997 14:25:34 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, DESIGN PROPOSAL: The following documents a 1st draft proposal for achieving finer-grained locking. Please comment, paying particular attention to the pseudo-code I propose for doing it. ----------------------------------- cut ----------------------------------- Proposed 1st cut at "giant lock" pushdown. A design proposal for the 1st step in pushing down the "giant lock" (GL) to achieve finer grained locking. --- Create 3 basic get/rel lock functions from the current get/rel_mplock(). Each of these supports 3 basic entry types, respectively: - getISR_mplock/relISR_mplock: interrupt routines - getSYS_mplock/relSYS_mplock: system calls - getTRAP_mplock/relTRAP_mplock: exceptions, traps, etc. For the 1st step, each of these 3 variations will behave identically. Their purpose is to achieve a LOGICAL differentiation. Eventually they will divert as their needs dictate. --- Modify the getISR_mplock/relISR_mplock routines to deal with "MP-safe" and "MP-unsafe" ISRs: The basic idea is to label each ISR as MP-unsafe by default, and let individual ISRs declare themselves to be MP-safe if appropriate. Modify the getISR_mplock() routine to allow one-and-only-one MP-unsafe ISR into the kernal at once, but all MP-safe ISRs in at the same time. If any MP-safe ISR is in the kernel, all MP-unsafe ISRs are blocked. If any MP-unsafe ISR (or SYS/TRAP routine) is in the kernel, all other ISR/SYS/TRAP routines are blocked. As SYS/TRAP routines are made MP-safe, these routines will be modified to allow them to co-exist in the kernel in a similar manner. --- The current code: Review i386/i386/mplock.s for details of the current code. The general algorithm is: - a free lock is 0xffffffff - an 'owned' lock is 0xID00000n where ID is the LOGICAL id of the CPU running the process and n is the lock count. the count allows the lock to be recursive, eg. a process holding the lock can catch a page exception and reacquire it for the page fault. - first attempt to get a lock == current lock + 1 || cpuid (ie process CPU id) - failing that, attempt to get a free lock - failing that, wait for lock to become free then goto step 2 (get free lock) --- Modify the lock as follows: Create a third value-class for the lock, MP-safelock. The lock is represented by the value 0xff0xxxxn where the 1st 3 digits, ff0, represent the MP-safe class type. This pattern is unique to both a free lock and a MP-unsafe GL. getISR_mplock now does: if ( isMPsafe( intnum ) == FALSE ) { /* we are an MP-unsafe ISR */ useOldStyleCode(); /* this blocks if NOT free */ } else { /* we are an MP-safe ISR */ if ( (mp_lock & 0xff000000) == 0xff000000 ) { /* lock held by MP-safe routine */ newval = (mp_lock & 0x000fffff) + 1; newval |= 0xff000000; /* add MP-safe class tag */ /* compete for lock */ } else if ( mp_lock == 0xffffffff ) { /* lock is free, compete for free lock */ newval = 0xff000000 + 1; /* 1st MP-safe lock */ /* compete for lock */ } else { /* lock must be held by MP-unsafe routine, wait for free lock */ /* compete for free lock */ } } --- Summary: the object is to allow both MP-safe and MP-unsafe ISR(SYS/TRAP) routines to co-exist while we transition to a fully MP-safe system. The theory is that you can allow only 1 MP-unsafe routine in the kernal at any one instance, but multiple MP-safe routines (IF no MP-unsafe routines are already in the kernel). The above modifications are a proposal for achieving that goal. --- Related issues: We will probably always have some MP-unsafe drivers, as new drivers will usually first be coded UP. But once we have the majority of drivers MP-safe, we can change the build logic to cause a default SMP kernel to panic if a MP-unsafe ISR is called (during probe perhaps). If a user needs to link an MP-unsafe ISR he can invoker a config option removing this behaviour. Then we can remove the overhead for handling MP-unsafe routines from most SMP kernels. ----------------------------------- cut ----------------------------------- -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Jul 16 14:17:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA08946 for smp-outgoing; Wed, 16 Jul 1997 14:17:00 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA08941 for ; Wed, 16 Jul 1997 14:16:58 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA01479; Wed, 16 Jul 1997 14:16:11 -0700 From: Terry Lambert Message-Id: <199707162116.OAA01479@phaeton.artisoft.com> Subject: Re: HEADS UP: EISA cards. To: smp@csn.net (Steve Passe) Date: Wed, 16 Jul 1997 14:16:11 -0700 (MST) Cc: smp@FreeBSD.ORG In-Reply-To: <199707160551.XAA06975@Ilsa.StevesCafe.com> from "Steve Passe" at Jul 15, 97 11:51:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > DESIGN DECISION: > > I am about to make a design decision that will forever-more make the use > of EISA cards that use the EISA chipset DMA circuit impossible in the SMP > kernel. I posted a rather long email about this several days ago but got ZERO > response. So I can conclude that either: > > a: everyone agrees with this decision. > OR > b: no one with such hardware read that far. c: there was a fiber cut in California which cut some of us off the net. I have EISA machines and I would prefer you not do this. As an alternative, I suggest that you assume the timer is properly forwarded on EISA hardware. EISA hardware can be easily detected. I also thought that Poul's machine, which was Jack Vogel's machine, was an EISA/PCI combo (actually, I know this for a fact, since I bought the ISA/PCI version of the board for spread testing with Jack). > I believe that we don't want to abandon the 8254, but instead should > abandon the DMA chaining INTs (who uses these anyways???) Then we > can program in a similar way, but instead pass the 8254 INT thru as > a regular INT. > ... > we need to make a policy decision as to whether we can say > bye-bye to the DMA chaining INTs. If I don't get thoughtful feedback on this > I will just nmake an arbitrary decision (which I suspect to be axing the DMA > INTs). I think the only situation needing them is non-busmaster EISA hardware > that does DMA via the motherboard chipset DMA registers. Please correct me > if I am wrong on this point. It wasn't clear from this that you would be spamming EISA hardware; note that I am not personally running EISA hardware, but I think it is a mistake to work around the problem on a platform where it's not necessary. Correct me if I'm wrong, and there's an EISA platform that exhibits the timer routing bug. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Wed Jul 16 14:19:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA09065 for smp-outgoing; Wed, 16 Jul 1997 14:19:27 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA09056 for ; Wed, 16 Jul 1997 14:19:23 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA01494; Wed, 16 Jul 1997 14:17:55 -0700 From: Terry Lambert Message-Id: <199707162117.OAA01494@phaeton.artisoft.com> Subject: Re: HEADS UP: EISA cards. To: smp@csn.net (Steve Passe) Date: Wed, 16 Jul 1997 14:17:55 -0700 (MST) Cc: phk@dk.tfs.com, smp@FreeBSD.ORG In-Reply-To: <199707160703.BAA07318@Ilsa.StevesCafe.com> from "Steve Passe" at Jul 16, 97 01:03:06 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > About the only card this could affect is the AHA1742 (ahb%d driver). > > Does anybody know if this card uses this feature ? > > Peter Wemm was using it in his old dual P5 without problem. This was > with APIC code that did NOT support the DMA chaining INTs (at least not > thru the 8259 PIC). The fact is that we have never supported them in the > APIC code and no one has complained so far. Its just that I am about to go > down a path that makes it "final" and want everyone to be aware. I was specifically thinking of the 1742, actually. If this works, I believe I will withdraw my objection. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Wed Jul 16 14:23:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA09375 for smp-outgoing; Wed, 16 Jul 1997 14:23:44 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA09368 for ; Wed, 16 Jul 1997 14:23:41 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA01516; Wed, 16 Jul 1997 14:22:51 -0700 From: Terry Lambert Message-Id: <199707162122.OAA01516@phaeton.artisoft.com> Subject: Re: HEADS UP: EISA cards. To: cbrown@aracnet.com Date: Wed, 16 Jul 1997 14:22:50 -0700 (MST) Cc: smp@csn.net, smp@FreeBSD.ORG In-Reply-To: <33CC9317.9C7588D8@earthling.net> from "Chris Browning" at Jul 16, 97 01:23:35 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Why would you not want to abandon the 8254? Why not use the APIC's > timer? I would imagine that it was put there for this purpose when > running in full symetric mode. This is a HAL issue. The problem, I suspect, is that we Steve wants the kernel to run on non-APIC machines as well (correct me if I'm wrong), and the kernel expects timer services. Ideally, you would want to abstract the service provision from the hardware selected to provide the service. To do this would require abstracting it at the "this IC provides these services" hardware level... in other words a HAL. I suspect that this will be necessary for the Alpha port (it was necessary for the non-ISA bridged Alpha ports of the FreeBSD console code to NetBSD -- also a general problem of "what hardware will provide these services that the console expects the kernel to provide for it"; specifically, the PCaudio stuff has to modularly drop out when there is no coupling to the speaker wave generator of the IC providing the timer services). > Also, why would you not want to program the IOAPIC to handle > "this" as normal INTs? Most likely because the INT will happen whether you want it to or not. 8-|. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Wed Jul 16 14:32:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA10060 for smp-outgoing; Wed, 16 Jul 1997 14:32:28 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA10053 for ; Wed, 16 Jul 1997 14:32:23 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id PAA09942; Wed, 16 Jul 1997 15:30:37 -0600 (MDT) Message-Id: <199707162130.PAA09942@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Terry Lambert cc: cbrown@aracnet.com, smp@FreeBSD.ORG Subject: Re: HEADS UP: EISA cards. In-reply-to: Your message of "Wed, 16 Jul 1997 14:22:50 PDT." <199707162122.OAA01516@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jul 1997 15:30:37 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > > Also, why would you not want to program the IOAPIC to handle > > "this" as normal INTs? > > Most likely because the INT will happen whether you want it to or > not. 8-|. this is precisely the problem! ExtInts are NOT handled by the APIC system in any way except to pass the electrical level thru from the 8259 INTOUT to the CPU INTR input. All the vector cycles, etc. are from CPU core to 8259. Thus no priority (APIC TPR/PPR regs) control is possible. This is a subtle point that escaped me till recently. The only intel literature that deals with this fact appears to be the old 486 APIC stuff... -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Jul 16 14:38:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA10570 for smp-outgoing; Wed, 16 Jul 1997 14:38:34 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA10562; Wed, 16 Jul 1997 14:38:27 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA01575; Wed, 16 Jul 1997 14:37:42 -0700 From: Terry Lambert Message-Id: <199707162137.OAA01575@phaeton.artisoft.com> Subject: Re: pushdown of "giant lock" To: smp@csn.net (Steve Passe) Date: Wed, 16 Jul 1997 14:37:42 -0700 (MST) Cc: smp@FreeBSD.ORG, peter@spinner.dialix.com.au, dyson@FreeBSD.ORG In-Reply-To: <199707162025.OAA09649@Ilsa.StevesCafe.com> from "Steve Passe" at Jul 16, 97 02:25:34 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The following documents a 1st draft proposal for achieving finer-grained > locking. Please comment, paying particular attention to the pseudo-code > I propose for doing it. > > ----------------------------------- cut ----------------------------------- > Proposed 1st cut at "giant lock" pushdown. > > A design proposal for the 1st step in pushing down the "giant lock" (GL) > to achieve finer grained locking. > > --- > Create 3 basic get/rel lock functions from the current get/rel_mplock(). > Each of these supports 3 basic entry types, respectively: > > - getISR_mplock/relISR_mplock: interrupt routines > - getSYS_mplock/relSYS_mplock: system calls > - getTRAP_mplock/relTRAP_mplock: exceptions, traps, etc. > > For the 1st step, each of these 3 variations will behave identically. Their > purpose is to achieve a LOGICAL differentiation. Eventually they will > divert as their needs dictate. The ONLY issue I have with this proposed implementation is "what happens if...": A) getSYS_mplock B) getTRAP_mplock A) getTRAP_mplock << BLOCK B) getSYS_mplock << DEADLOCK This is even more problematic for interrupts, unless each processor has its own kernel stack for interrupts (which poses a number of VM problems which I'm pretty sure you aren't interested in fighting at this time). I think that there is a requirement for: 1) A hierarchical arrangment in which all locks are inferior to a top level lock, such that deadlock conditions can be *avoided* rather than *detected*; there is no clean way to back out state, otherwise. 2) Intention modes should be implemented such that it is not necessary to synchronize locks between processors unless the locks would potentially result in a deadlock 3) There should be the concept of a processor local domain; that is, I would not make an interface distinction between mutexes vs. semaphores at the programmatic interface, but a call should use semaphores where there is no processor contention within a domain. This sets up nicely for per processor resource pools filled from (and drained to) system resource pools. > the object is to allow both MP-safe and MP-unsafe ISR(SYS/TRAP) routines > to co-exist while we transition to a fully MP-safe system. The theory > is that you can allow only 1 MP-unsafe routine in the kernal at any one > instance, but multiple MP-safe routines (IF no MP-unsafe routines are already > in the kernel). The above modifications are a proposal for achieving that > goal. This is a good objective; I don't think my observations make it any less obtainable. I would mopdify it to be "in the kernel on a given processor" in the case where there are per processor kernel stacks for use by ISR's. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Wed Jul 16 14:42:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA10761 for smp-outgoing; Wed, 16 Jul 1997 14:42:18 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA10741; Wed, 16 Jul 1997 14:42:11 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA01599; Wed, 16 Jul 1997 14:41:26 -0700 From: Terry Lambert Message-Id: <199707162141.OAA01599@phaeton.artisoft.com> Subject: Re: self modifying kernel code To: smp@csn.net (Steve Passe) Date: Wed, 16 Jul 1997 14:41:26 -0700 (MST) Cc: smp@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <199707162042.OAA09705@Ilsa.StevesCafe.com> from "Steve Passe" at Jul 16, 97 02:42:55 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I see the possible usefullness for "self-modifying-code" in several places in > the SMP kernel. [ ... discussion of patch vectors vs. indirected jump tables ... ] > So what is the policy/reality of self-modifying code in the -current source? > The 1st example above can be handled during boot, so I suspect that the > modifications should be easy enough. The second involves modification of the > kernel code space after going multi-user (probaly dozens of times b4 its > finished), I'm not so sure about modifying kernel code-space at that point... > > Comments? Are we assuming that the processors will be Pentium only? The icache is not written back prior to the P5. This takes a significant number of NOP's to flush the pipeline (as discussed in Van Guilluwe's "The Undocumented PC" in the section where he investigates instruction cache depth using self-modifying code). Note that these patches would have to be done for 386/486 in the UP case. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Wed Jul 16 14:44:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA10933 for smp-outgoing; Wed, 16 Jul 1997 14:44:56 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA10926 for ; Wed, 16 Jul 1997 14:44:49 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA01630; Wed, 16 Jul 1997 14:43:50 -0700 From: Terry Lambert Message-Id: <199707162143.OAA01630@phaeton.artisoft.com> Subject: Re: HEADS UP: EISA cards. To: smp@csn.net (Steve Passe) Date: Wed, 16 Jul 1997 14:43:50 -0700 (MST) Cc: terry@lambert.org, cbrown@aracnet.com, smp@FreeBSD.ORG In-Reply-To: <199707162130.PAA09942@Ilsa.StevesCafe.com> from "Steve Passe" at Jul 16, 97 03:30:37 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Also, why would you not want to program the IOAPIC to handle > > > "this" as normal INTs? > > > > Most likely because the INT will happen whether you want it to or > > not. 8-|. > > this is precisely the problem! ExtInts are NOT handled by the APIC system > in any way except to pass the electrical level thru from the 8259 INTOUT > to the CPU INTR input. All the vector cycles, etc. are from CPU core to 8259. > Thus no priority (APIC TPR/PPR regs) control is possible. This is a subtle > point that escaped me till recently. The only intel literature that deals > with this fact appears to be the old 486 APIC stuff... Yes; there *are* some of us idiots who hold out hope for running on 486 Sequent boxes, some day. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Wed Jul 16 14:48:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA11148 for smp-outgoing; Wed, 16 Jul 1997 14:48:06 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA11071; Wed, 16 Jul 1997 14:47:55 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id PAA10070; Wed, 16 Jul 1997 15:46:29 -0600 (MDT) Message-Id: <199707162146.PAA10070@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Terry Lambert cc: smp@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: self modifying kernel code In-reply-to: Your message of "Wed, 16 Jul 1997 14:41:26 PDT." <199707162141.OAA01599@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jul 1997 15:46:29 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > > I see the possible usefullness for "self-modifying-code" in several places in > > the SMP kernel. > > [ ... discussion of patch vectors vs. indirected jump tables ... ] > > Comments? > > Are we assuming that the processors will be Pentium only? The icache > is not written back prior to the P5. This takes a significant number > of NOP's to flush the pipeline (as discussed in Van Guilluwe's "The > Undocumented PC" in the section where he investigates instruction cache > depth using self-modifying code). > > Note that these patches would have to be done for 386/486 in the UP case. interesting point. we decided along time ago that supporting 486/SMP was not going to happen. There is very little if any such legacy hardware left, and I doubt you could by such a thing anymore. so it could be #ifdef'd in such a way as to NOT happen on SMP + 486 easily enough. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Jul 16 15:00:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA12083 for smp-outgoing; Wed, 16 Jul 1997 15:00:23 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA12072; Wed, 16 Jul 1997 15:00:14 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id PAA10171; Wed, 16 Jul 1997 15:59:26 -0600 (MDT) Message-Id: <199707162159.PAA10171@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Terry Lambert cc: smp@FreeBSD.ORG, peter@spinner.dialix.com.au, dyson@FreeBSD.ORG Subject: Re: pushdown of "giant lock" In-reply-to: Your message of "Wed, 16 Jul 1997 14:37:42 PDT." <199707162137.OAA01575@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jul 1997 15:59:26 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > The ONLY issue I have with this proposed implementation is "what > happens if...": > > A) getSYS_mplock > B) getTRAP_mplock > A) getTRAP_mplock << BLOCK > B) getSYS_mplock << DEADLOCK this wont happen as B would block on getTRAP_mplock (A holds GL). so the following A wont block, no deadlock. this assummes the 1st step, ie both SYS & TRAP continue to use the GL. When we take the next step and make SYS/TRAP MP-safe we may need to make them completely MP-safe in one step to avoid some deadlock issues... -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Jul 16 15:09:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA12577 for smp-outgoing; Wed, 16 Jul 1997 15:09:41 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA12566 for ; Wed, 16 Jul 1997 15:09:33 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id QAA10219; Wed, 16 Jul 1997 16:09:13 -0600 (MDT) Message-Id: <199707162209.QAA10219@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: ulmik@proxy.lkb.lv cc: freebsd-smp@FreeBSD.ORG Subject: Re: 3.0-970716-SNAP In-reply-to: Your message of "Wed, 16 Jul 1997 21:50:04 +0300." <33CD17DC.38E8@proxy.lkb.lv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jul 1997 16:09:13 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > I just installed minimum SNAP ( bin + ssys ( kernel src )) and result is > : > ------------------------------------------------------------------------ > cd /sys/i386/conf/ > config SMP-GENERIC > cd ../../compile/SMP-GENERIC > make all > [skip] > loading kernel > mp_machdep.o: Undefined symbol `_db_printf' referenced from text segment > ... my fault, I forgot that this would happen if you dopn't add DDB to your kernel config file. So I suggest adding DDB via a config file addition: options DDB you could also comment out DEBUG_CPUSTOP in i386/include/smptests.h -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Jul 16 15:12:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA12716 for smp-outgoing; Wed, 16 Jul 1997 15:12:08 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA12683; Wed, 16 Jul 1997 15:11:59 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA01775; Wed, 16 Jul 1997 15:10:58 -0700 From: Terry Lambert Message-Id: <199707162210.PAA01775@phaeton.artisoft.com> Subject: Re: pushdown of "giant lock" To: smp@csn.net (Steve Passe) Date: Wed, 16 Jul 1997 15:10:57 -0700 (MST) Cc: terry@lambert.org, smp@FreeBSD.ORG, peter@spinner.dialix.com.au, dyson@FreeBSD.ORG In-Reply-To: <199707162159.PAA10171@Ilsa.StevesCafe.com> from "Steve Passe" at Jul 16, 97 03:59:26 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The ONLY issue I have with this proposed implementation is "what > > happens if...": > > > > A) getSYS_mplock > > B) getTRAP_mplock > > A) getTRAP_mplock << BLOCK > > B) getSYS_mplock << DEADLOCK > > this wont happen as B would block on getTRAP_mplock (A holds GL). so the > following A wont block, no deadlock. this assummes the 1st step, ie both > SYS & TRAP continue to use the GL. > > When we take the next step and make SYS/TRAP MP-safe we may need to make them > completely MP-safe in one step to avoid some deadlock issues... Yes, this is the occasion I meant; using one lock from three macros is not a very interesting case. ;-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Wed Jul 16 15:36:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA14707 for smp-outgoing; Wed, 16 Jul 1997 15:36:40 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA14696 for ; Wed, 16 Jul 1997 15:36:36 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.5/8.8.5) id RAA22434; Wed, 16 Jul 1997 17:35:39 -0500 (EST) From: "John S. Dyson" Message-Id: <199707162235.RAA22434@dyson.iquest.net> Subject: Re: self modifying kernel code In-Reply-To: <199707162146.PAA10070@Ilsa.StevesCafe.com> from Steve Passe at "Jul 16, 97 03:46:29 pm" To: smp@csn.net (Steve Passe) Date: Wed, 16 Jul 1997 17:35:39 -0500 (EST) Cc: terry@lambert.org, smp@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hi, > > > > I see the possible usefullness for "self-modifying-code" in several places in > > > the SMP kernel. > > > > [ ... discussion of patch vectors vs. indirected jump tables ... ] > > > Comments? > > > > Are we assuming that the processors will be Pentium only? The icache > > is not written back prior to the P5. This takes a significant number > > of NOP's to flush the pipeline (as discussed in Van Guilluwe's "The > > Undocumented PC" in the section where he investigates instruction cache > > depth using self-modifying code). > > > > Note that these patches would have to be done for 386/486 in the UP case. > > interesting point. we decided along time ago that supporting 486/SMP > was not going to happen. There is very little if any such legacy hardware > left, and I doubt you could by such a thing anymore. > IMO only --- There never was that much of the 486/SMP stuff anyway, relatively so. Let's move and look forward, without breaking things much for existing user base. We currently have NO 486/SMP user base, and IMO, our efforts are best placed on things moving us into the future, not the 1980s :-). John From owner-freebsd-smp Wed Jul 16 15:45:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA15257 for smp-outgoing; Wed, 16 Jul 1997 15:45:36 -0700 (PDT) Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA15240; Wed, 16 Jul 1997 15:45:25 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.6/8.8.4) with ESMTP id PAA18838; Wed, 16 Jul 1997 15:44:43 -0700 (PDT) Received: from pdxlx008.intel.com by ichips.intel.com (8.7.4/jIII) id PAA29366; Wed, 16 Jul 1997 15:45:02 -0700 (PDT) Received: from pdxlx008 (localhost [127.0.0.1]) by pdxlx008.intel.com (8.8.6/8.7.3) with ESMTP id PAA07524; Wed, 16 Jul 1997 15:45:25 -0700 (PDT) Message-Id: <199707162245.PAA07524@pdxlx008.intel.com> To: Terry Lambert cc: smp@csn.net (Steve Passe), smp@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: self modifying kernel code In-reply-to: Your message of "Wed, 16 Jul 1997 14:41:26 PDT." <199707162141.OAA01599@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: Wed, 16 Jul 1997 15:45:25 -0700 From: Wayne Scott Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Are we assuming that the processors will be Pentium only? The icache > is not written back prior to the P5. This takes a significant number > of NOP's to flush the pipeline (as discussed in Van Guilluwe's "The > Undocumented PC" in the section where he investigates instruction cache > depth using self-modifying code). At startup the call is to a routine that computes the correct target address. In the fixup routine you change the call address and then jump to the target directly. It will be a long time before you actually execute the modified code. -Wayne Wayne Scott MD6 Architecture wscott@ichips.intel.com Work #: (503) 264-4165 Disclaimer: All views expressed are my own opinions, and not necessarily those of Intel Corporation. From owner-freebsd-smp Wed Jul 16 15:48:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA15407 for smp-outgoing; Wed, 16 Jul 1997 15:48:46 -0700 (PDT) Received: from genghis.eng.demon.net (genghis.eng.demon.net [193.195.45.10]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA15388 for ; Wed, 16 Jul 1997 15:48:40 -0700 (PDT) Received: from genghis.eng.demon.net [193.195.45.10] by genghis.eng.demon.net with esmtp (Exim 1.62 #1) id 0wocrq-0000Tw-00; Wed, 16 Jul 1997 23:48:18 +0100 To: Chuck Robey cc: smp@freebsd.org Subject: Re: HEADS UP: EISA cards. Organization: Demon Internet Ltd. Reply-To: ade@demon.net In-reply-to: Your message of "Wed, 16 Jul 1997 13:10:12 EDT." Date: Wed, 16 Jul 1997 23:48:18 +0100 From: Ade Lovett Message-Id: Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Chuck Robey writes: > >Steve, I don't have an EISA smp board, so I felt I didn't need to reply, >but your suggestion is fine with me. Thinking about it, the only EISA >boards out there would be getting a little aged, and it seems fairly safe >to exclude them from smp work. Bzzzt. Wrong. Micronics do dual (and quad) Pentium/PPro motherboards, which are PCI/(E)ISA configured. Indeed, my personal SMP experimentation machine (though not my 'real' SMP machines) have 3COM EISA cards in them for management interfaces (the 'real' work going out through PCI cards). Fortunately, the 3c579 Vortex is bus-mastering, so would appear to be unaffected by the suggested changes here (please correct me if I'm wrong here -- when it comes to hardware, I'm more of a Sun (so sue me :) person than PC). However, the point remains that until somebody figures out a totally PCI-based motherboard (7-8 PCI slots), we *cannot* afford to completely blow away EISA support, as you would seem to suggest. -aDe -- Ade Lovett, Demon Internet Ltd. From owner-freebsd-smp Wed Jul 16 16:22:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA16923 for smp-outgoing; Wed, 16 Jul 1997 16:22:38 -0700 (PDT) Received: from marker.cs.utah.edu (marker.cs.utah.edu [155.99.212.61]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA16915 for ; Wed, 16 Jul 1997 16:22:32 -0700 (PDT) Received: (from vanmaren@localhost) by marker.cs.utah.edu (8.8.5/8.7.3) id RAA09970 for smp@FreeBSD.ORG; Wed, 16 Jul 1997 17:22:29 -0600 (MDT) Date: Wed, 16 Jul 1997 17:22:29 -0600 (MDT) From: Kevin Van Maren Message-Id: <199707162322.RAA09970@marker.cs.utah.edu> To: smp@FreeBSD.ORG Subject: mptable from DELL 4100 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I tried to add a second CPU, but the stepping wasn't `new enough' to make the BIOS happy. I don't have the machine anymore, but this is what it looked like with 1 processor. Maybe someone has annother DELL server with multiple processors? Kevin =============================================================================== MPTable, version 2.0.12 looking for EBDA pointer @ 0x040e, found, searching EBDA @ 0x0009fc00 searching CMOS 'top of mem' @ 0x0009f800 (638K) searching default 'top of mem' @ 0x0009fc00 (639K) searching BIOS @ 0x000f0000 MP FPS found in BIOS @ physical addr: 0x000fdba0 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000fdba0 signature: '_MP_' length: 16 bytes version: 1.4 checksum: 0x4a mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x0009fd50 signature: 'PCMP' base table length: 240 version: 1.4 checksum: 0xf7 OEM ID: 'DELL ' Product ID: 'POWEREDGE ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 23 local APIC address: 0xfee00000 extended table length: 0 extended table checksum: 0 ------------------------------------------------------------------------------- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 0 0x11 BSP, usable 6 1 9 0xfbff -- Bus: Bus ID Type 0 PCI 1 PCI 2 EISA -- I/O APICs: APIC ID Version State Address 1 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT active-hi edge 2 0 1 0 INT conforms conforms 2 1 1 1 INT conforms conforms 2 0 1 2 INT conforms conforms 2 3 1 3 INT conforms conforms 2 4 1 4 INT conforms conforms 2 5 1 5 INT conforms conforms 2 6 1 6 INT conforms conforms 2 7 1 7 INT conforms conforms 2 8 1 8 INT conforms conforms 2 9 1 9 INT conforms conforms 2 10 1 10 INT conforms conforms 2 11 1 11 INT conforms conforms 2 12 1 12 INT conforms conforms 2 13 1 13 INT conforms conforms 2 14 1 14 INT conforms conforms 2 15 1 15 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT active-hi edge 2 0 255 0 NMI active-hi edge 0 0:A 255 1 ------------------------------------------------------------------------------- # SMP kernel config file options: # Required: options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Useful: #options SMP_AUTOSTART # start the additional CPUs during boot # Optional (built-in defaults will work in most cases): #options NCPU=1 # number of CPUs #options NBUS=3 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs # Rogue hardware: # # Tyan Tomcat II: #options SMP_TIMER_NC # # # SuperMicro P6DNE: #options SMP_TIMER_NC # ------------------------------------------------------------------------------- dmesg output: Copyright (c) 1992-1997 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 2.2.2-RELEASE #0: Sat Jun 21 12:16:35 MDT 1997 root@sloefiz.cs.utah.edu:/usr/src/sys/compile/DELL CPU: Pentium Pro (199.43-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping=9 Features=0xfbff,MTRR,PGE,MCA,CMOV> real memory = 268435456 (262144K bytes) avail memory = 261173248 (255052K bytes) eisa0: Probing for devices on the EISA bus Probing for devices on PCI bus 0: chip0 rev 2 on pci0:0 chip1 rev 2 on pci0:13 chip2 rev 21 on pci0:15:0 fxp0 rev 2 int a irq 9 on pci0:16 fxp0: Ethernet address 00:a0:c9:5d:2c:5a fxp1 rev 2 int a irq 10 on pci0:17 fxp1: Ethernet address 00:a0:c9:5d:0d:35 fxp2 rev 2 int a irq 11 on pci0:19 fxp2: Ethernet address 00:a0:c9:5d:17:de vga0 rev 64 on pci0:20 Probing for devices on PCI bus 1: fxp3 rev 2 int a irq 14 on pci1:8 pci_map_mem failed: device's memrange 0xfbffe000-0xfbffefff is incompatible with its bridge's memrange 0xfdb00000-0xfdcfffff fxp3: Ethernet address 00:a0:c9:5d:2c:86 ahc0 rev 0 int a irq 5 on pci1:10 pcibus_ihandler_attach: counting pci irq5's as clk0 irqs ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs ahc0 waiting for scsi devices to settle (ahc0:0:0): "WDIGTL WDE2170-1808A2 1.70" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 2047MB (4194057 512 byte sectors) sd0(ahc0:0:0): with 5720 cyls, 4 heads, and an average 183 sectors/track ahc0:A:6: refuses WIDE negotiation. Using 8bit transfers ahc0:A:6: refuses synchronous negotiation. Using asynchronous transfers (ahc0:6:0): "DELL 6UW BACKPLANE 7" type 3 fixed SCSI 2 uk0(ahc0:6:0): Unknown ahc1 rev 1 int a irq 5 on pci1:11 pcibus_ihandler_attach: counting pci irq5's as clk0 irqs ahc1: aic7860 Single Channel, SCSI Id=7, 3 SCBs ahc1 waiting for scsi devices to settle (ahc1:5:0): "NEC CD-ROM DRIVE:462 1.14" type 5 removable SCSI 2 cd0(ahc1:5:0): CD-ROM can't get the size (ahc1:6:0): "SONY SDT-9000 125F" type 1 removable SCSI 2 st0(ahc1:6:0): Sequential-Access density code 0x13, drive empty ahc2 rev 0 int a irq 15 on pci1:13 pcibus_ihandler_attach: counting pci irq15's as clk0 irqs ahc2: aic7880 Wide Channel, SCSI Id=7, 16 SCBs ahc2 waiting for scsi devices to settle Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface psm0: disabled, not probed. fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in scd0 not found at 0x230 npx0 flags 0x1 on motherboard npx0: INT 16 interface apm0: disabled, not probed. changing root device to sd0a ccd0-3: Concatenated disk drivers fxp0: warning: unsupported PHY, type = 7, addr = 1 fxp0: warning: unsupported PHY, type = 7, addr = 1 fxp0: warning: unsupported PHY, type = 7, addr = 1 =============================================================================== From owner-freebsd-smp Wed Jul 16 16:31:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA17322 for smp-outgoing; Wed, 16 Jul 1997 16:31:08 -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 QAA17317 for ; Wed, 16 Jul 1997 16:31:06 -0700 (PDT) Received: from fast.cs.utah.edu by cs.utah.edu (8.8.4/utah-2.21-cs) id RAA25188; Wed, 16 Jul 1997 17:29:36 -0600 (MDT) Received: by fast.cs.utah.edu (8.6.10/utah-2.15-leaf) id RAA25871; Wed, 16 Jul 1997 17:29:35 -0600 Date: Wed, 16 Jul 1997 17:29:35 -0600 From: vanmaren@fast.cs.utah.edu (Kevin Van Maren) Message-Id: <199707162329.RAA25871@fast.cs.utah.edu> To: smp@csn.net, toor@dyson.iquest.net Subject: Re: self modifying kernel code Cc: smp@FreeBSD.ORG, terry@lambert.org Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > There never was that much of the 486/SMP stuff anyway, relatively so. Let's move > and look forward, without breaking things much for existing user base. We currently > have NO 486/SMP user base, and IMO, our efforts are best placed on things moving > us into the future, not the 1980s :-). > > John Hey, we have a dual 486 VTECH box that I would love to run SMP freebsd on... It used to run NT fine on dual CPUs, but is not running uniprocessor Linux. But you are right, it is obsolete hardware. From owner-freebsd-smp Wed Jul 16 16:36:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA17665 for smp-outgoing; Wed, 16 Jul 1997 16:36:27 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA17634; Wed, 16 Jul 1997 16:36:18 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id RAA10611; Wed, 16 Jul 1997 17:35:01 -0600 (MDT) Message-Id: <199707162335.RAA10611@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Wayne Scott cc: smp@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: self modifying kernel code In-reply-to: Your message of "Wed, 16 Jul 1997 15:45:25 PDT." <199707162245.PAA07524@pdxlx008.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jul 1997 17:35:01 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > At startup the call is to a routine that computes the correct target > address. In the fixup routine you change the call address and then > jump to the target directly. It will be a long time before you > actually execute the modified code. and in the case of UP you would overlay the call with the jump near + nops, then jump directly to the jump near's target, so again plenty of time to flush... -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Jul 16 16:36:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA17690 for smp-outgoing; Wed, 16 Jul 1997 16:36: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 QAA17685 for ; Wed, 16 Jul 1997 16:36:56 -0700 (PDT) Received: from fast.cs.utah.edu by cs.utah.edu (8.8.4/utah-2.21-cs) id RAA25410; Wed, 16 Jul 1997 17:36:53 -0600 (MDT) Received: by fast.cs.utah.edu (8.6.10/utah-2.15-leaf) id RAA26588; Wed, 16 Jul 1997 17:36:53 -0600 Date: Wed, 16 Jul 1997 17:36:53 -0600 From: vanmaren@fast.cs.utah.edu (Kevin Van Maren) Message-Id: <199707162336.RAA26588@fast.cs.utah.edu> To: smp@FreeBSD.ORG Subject: Re: mptable from DELL 4100 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Oh, the interesting thing I wanted to point out was this: % grep irq DELL.mptable fxp0 rev 2 int a irq 9 on pci0:16 fxp1 rev 2 int a irq 10 on pci0:17 fxp2 rev 2 int a irq 11 on pci0:19 fxp3 rev 2 int a irq 14 on pci1:8 ahc0 rev 0 int a irq 5 on pci1:10 pcibus_ihandler_attach: counting pci irq5's as clk0 irqs ahc1 rev 1 int a irq 5 on pci1:11 pcibus_ihandler_attach: counting pci irq5's as clk0 irqs ahc2 rev 0 int a irq 15 on pci1:13 pcibus_ihandler_attach: counting pci irq15's as clk0 irqs sc0 at 0x60-0x6f irq 1 on motherboard sio0 at 0x3f8-0x3ff irq 4 on isa sio1 at 0x2f8-0x2ff irq 3 on isa lpt0 at 0x378-0x37f irq 7 on isa fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa Note that there are 6 different IRQs used by PCI cards. (fxp0:9, fxp1:10, fxp2:11, fxp3:14, ahc0,1:5, ahc2:15) I only actually used fxp0, ahc0, and ahc1, though. Kevin From owner-freebsd-smp Wed Jul 16 16:39:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA17906 for smp-outgoing; Wed, 16 Jul 1997 16:39:53 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA17875 for ; Wed, 16 Jul 1997 16:39:38 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id RAA10636; Wed, 16 Jul 1997 17:39:23 -0600 (MDT) Message-Id: <199707162339.RAA10636@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: ade@demon.net cc: Chuck Robey , smp@FreeBSD.ORG Subject: Re: HEADS UP: EISA cards. In-reply-to: Your message of "Wed, 16 Jul 1997 23:48:18 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jul 1997 17:39:23 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > >boards out there would be getting a little aged, and it seems fairly safe > >to exclude them from smp work. > > Bzzzt. Wrong. > > Micronics do dual (and quad) Pentium/PPro motherboards, which are > PCI/(E)ISA configured. > > Indeed, my personal SMP experimentation machine (though not my 'real' > SMP machines) have 3COM EISA cards in them for management interfaces > (the 'real' work going out through PCI cards). > > Fortunately, the 3c579 Vortex is bus-mastering, so would appear to be > unaffected by the suggested changes here (please correct me if > I'm wrong here -- when it comes to hardware, I'm more of a > Sun (so sue me :) person than PC). > > However, the point remains that until somebody figures out a totally > PCI-based motherboard (7-8 PCI slots), we *cannot* afford to completely > blow away EISA support, as you would seem to suggest. again, I'm NOT eliminating EISA hardware, just NON bus-mastering EISA cards that do DMA via the chipset DMA registers. So far no one has reported using such beasts... -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Jul 16 16:51:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA18711 for smp-outgoing; Wed, 16 Jul 1997 16:51:45 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA18696 for ; Wed, 16 Jul 1997 16:51:39 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id RAA10731; Wed, 16 Jul 1997 17:51:28 -0600 (MDT) Message-Id: <199707162351.RAA10731@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: vanmaren@fast.cs.utah.edu (Kevin Van Maren) cc: smp@FreeBSD.ORG Subject: Re: self modifying kernel code In-reply-to: Your message of "Wed, 16 Jul 1997 17:29:35 MDT." <199707162329.RAA25871@fast.cs.utah.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jul 1997 17:51:28 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Jul 16 16:49:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA18514 for smp-outgoing; Wed, 16 Jul 1997 16:49:23 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA18501 for ; Wed, 16 Jul 1997 16:49:17 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id RAA10695; Wed, 16 Jul 1997 17:49:00 -0600 (MDT) Message-Id: <199707162349.RAA10695@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Kevin Van Maren cc: smp@FreeBSD.ORG Subject: Re: mptable from DELL 4100 In-reply-to: Your message of "Wed, 16 Jul 1997 17:22:29 MDT." <199707162322.RAA09970@marker.cs.utah.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jul 1997 17:49:00 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > I tried to add a second CPU, but the stepping wasn't `new enough' to > make the BIOS happy. I don't have the machine anymore, but this is > what it looked like with 1 processor. Maybe someone has annother > DELL server with multiple processors? > ... If this is related to the current discussion of EISA hardware, this motherboard should have no problem as it (claims*) to have the timer attached directly to the IO APIC: > I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# > ... > INT conforms conforms 2 0 1 2 more specifically since the 8254 is attached to the IO APIC, the 8259 could be used to pass the EISA DMA chaining INTs to the APIC IF someone cared enough to write the code... --- *PS: I'm working on a theory that those systems that currently require "options SMP_TIMER_NC" don't really, but that its an issue of additional programming of the MB chipset. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Jul 16 16:59:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA19082 for smp-outgoing; Wed, 16 Jul 1997 16:59:58 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA19073 for ; Wed, 16 Jul 1997 16:59:54 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id RAA10761; Wed, 16 Jul 1997 17:59:01 -0600 (MDT) Message-Id: <199707162359.RAA10761@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: vanmaren@fast.cs.utah.edu (Kevin Van Maren) cc: smp@FreeBSD.ORG Subject: Re: self modifying kernel code In-reply-to: Your message of "Wed, 16 Jul 1997 17:29:35 MDT." <199707162329.RAA25871@fast.cs.utah.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jul 1997 17:59:01 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, oops, I hit the 'send' button too soon, sorry... anyways: > Hey, we have a dual 486 VTECH box that I would love to run SMP freebsd on... > It used to run NT fine on dual CPUs, but is not running uniprocessor Linux. > > But you are right, it is obsolete hardware. I hate to be a grinch, but IMHO we can't spend resources to support maybe 6 or 7 potential users's of such hardware. I'm sure no one would object to someone adding such support on their own (assumming it could be done in such a way as to add NO overhead to the generic SMP kernel). I have no idea how much effort we are talking about ... -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Jul 16 17:07:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA19490 for smp-outgoing; Wed, 16 Jul 1997 17:07:42 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA19480 for ; Wed, 16 Jul 1997 17:07:38 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id SAA10854; Wed, 16 Jul 1997 18:07:26 -0600 (MDT) Message-Id: <199707170007.SAA10854@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: vanmaren@fast.cs.utah.edu (Kevin Van Maren) cc: smp@FreeBSD.ORG Subject: Re: mptable from DELL 4100 In-reply-to: Your message of "Wed, 16 Jul 1997 17:36:53 MDT." <199707162336.RAA26588@fast.cs.utah.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jul 1997 18:07:26 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > Oh, the interesting thing I wanted to point out was this: > ... > Note that there are 6 different IRQs used by PCI cards. > (fxp0:9, fxp1:10, fxp2:11, fxp3:14, ahc0,1:5, ahc2:15) and you did manage to shoe-horn them all in! unfortunately Dell chose to not attach them to upper IO APIC pins: INT conforms conforms 2 9 1 9 INT conforms conforms 2 10 1 10 INT conforms conforms 2 11 1 11 INT conforms conforms 2 12 1 12 INT conforms conforms 2 13 1 13 INT conforms conforms 2 14 1 14 INT conforms conforms 2 15 1 15 so you wouldn't be able to put much into those empty EISA/ISA slots... -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Jul 16 17:15:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA19882 for smp-outgoing; Wed, 16 Jul 1997 17:15:27 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA19861; Wed, 16 Jul 1997 17:15:21 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id RAA04777; Wed, 16 Jul 1997 17:15:35 -0700 (PDT) Message-Id: <199707170015.RAA04777@implode.root.com> To: Steve Passe cc: smp@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: self modifying kernel code In-reply-to: Your message of "Wed, 16 Jul 1997 14:42:55 MDT." <199707162042.OAA09705@Ilsa.StevesCafe.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 16 Jul 1997 17:15:35 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >So what is the policy/reality of self-modifying code in the -current source? Basically, we don't allow self-modifying code. There are many reasons, for instance the kernel text is protect read-only to catch certain types of bad pointer references, but the main reason is that it's considered bad programming style, obscuring the operation of the code - usually with little or no gain. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-smp Wed Jul 16 17:33:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA20761 for smp-outgoing; Wed, 16 Jul 1997 17:33:59 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA20745; Wed, 16 Jul 1997 17:33:39 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id SAA10984; Wed, 16 Jul 1997 18:33:22 -0600 (MDT) Message-Id: <199707170033.SAA10984@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: dg@root.com cc: smp@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: self modifying kernel code In-reply-to: Your message of "Wed, 16 Jul 1997 17:15:35 PDT." <199707170015.RAA04777@implode.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jul 1997 18:33:22 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > >So what is the policy/reality of self-modifying code in the -current source? > > Basically, we don't allow self-modifying code. There are many reasons, for > instance the kernel text is protect read-only to catch certain types of bad > pointer references, but the main reason is that it's considered bad programming > style, obscuring the operation of the code - usually with little or no gain. I expected this, how about during boot as oppossed to while running? -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Jul 16 17:40:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA21201 for smp-outgoing; Wed, 16 Jul 1997 17:40:34 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA21181; Wed, 16 Jul 1997 17:40:29 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id RAA04953; Wed, 16 Jul 1997 17:40:42 -0700 (PDT) Message-Id: <199707170040.RAA04953@implode.root.com> To: Steve Passe cc: smp@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: self modifying kernel code In-reply-to: Your message of "Wed, 16 Jul 1997 18:33:22 MDT." <199707170033.SAA10984@Ilsa.StevesCafe.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 16 Jul 1997 17:40:42 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Basically, we don't allow self-modifying code. There are many reasons, for >> instance the kernel text is protect read-only to catch certain types of bad >> pointer references, but the main reason is that it's considered bad programming >> style, obscuring the operation of the code - usually with little or no gain. > >I expected this, how about during boot as oppossed to while running? I'd say that you'd get less resistence to it, but then at boot time there are probably other cleaner, slower, ways of accomplishing the same thing. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-smp Wed Jul 16 17:44:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA21401 for smp-outgoing; Wed, 16 Jul 1997 17:44:32 -0700 (PDT) Received: from genghis.eng.demon.net (genghis.eng.demon.net [193.195.45.10]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA21395 for ; Wed, 16 Jul 1997 17:44:23 -0700 (PDT) Received: from genghis.eng.demon.net [193.195.45.10] by genghis.eng.demon.net with esmtp (Exim 1.62 #1) id 0woefS-0000YF-00; Thu, 17 Jul 1997 01:43:38 +0100 To: Steve Passe cc: smp@freebsd.org Subject: Re: HEADS UP: EISA cards. Organization: Demon Internet Ltd. Reply-To: ade@demon.net In-reply-to: Your message of "Wed, 16 Jul 1997 17:39:23 MDT." <199707162339.RAA10636@Ilsa.StevesCafe.com> Date: Thu, 17 Jul 1997 01:43:38 +0100 From: Ade Lovett Message-Id: Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe writes: > >again, I'm NOT eliminating EISA hardware, just NON bus-mastering EISA cards >that do DMA via the chipset DMA registers. So far no one has reported using >such beasts... Yep, I understand that :) Just wanted to make absolutely certain that the proposed changes don't ge somewhat out of hand and end up losing EISA completely (much as we'd all *like* it to go :) On a related note, can someone explain to a PC-hardware ignoramus (ie, me :) why no-one makes completely PCI-based motherboards, say with 7 or 8 slots? [perhaps this question should move over to -hackers?] -aDe -- Ade Lovett, Demon Internet Ltd. From owner-freebsd-smp Wed Jul 16 17:50:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA21793 for smp-outgoing; Wed, 16 Jul 1997 17:50:34 -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 RAA21786 for ; Wed, 16 Jul 1997 17:50:31 -0700 (PDT) Received: from fast.cs.utah.edu by cs.utah.edu (8.8.4/utah-2.21-cs) id SAA26743; Wed, 16 Jul 1997 18:50:27 -0600 (MDT) Received: by fast.cs.utah.edu (8.6.10/utah-2.15-leaf) id SAA28284; Wed, 16 Jul 1997 18:50:26 -0600 Date: Wed, 16 Jul 1997 18:50:26 -0600 From: vanmaren@fast.cs.utah.edu (Kevin Van Maren) Message-Id: <199707170050.SAA28284@fast.cs.utah.edu> To: smp@csn.net Subject: Re: self modifying kernel code Cc: smp@FreeBSD.ORG Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hi, > > oops, I hit the 'send' button too soon, sorry... anyways: > > > Hey, we have a dual 486 VTECH box that I would love to run SMP freebsd on... > > It used to run NT fine on dual CPUs, but is not running uniprocessor Linux. > > > > But you are right, it is obsolete hardware. > > I hate to be a grinch, but IMHO we can't spend resources to support > maybe 6 or 7 potential users's of such hardware. I'm sure no one > would object to someone adding such support on their own (assumming it > could be done in such a way as to add NO overhead to the generic SMP kernel). > I have no idea how much effort we are talking about ... The only big deal with it is that the APICs are all at different addresses -- you have to know which CPU you are on to know what address to use. With the `logical' CPU mapping, that shouldn't be too difficult. The other difficulty is in startup. With the external APIC, you can't just send the startup IPI. It's not difficult, and well documented, but I've never tried to deal with it. Maybe when I have a day or two with nothing else to do, I'll play with it again. Oh, one more thing. There isn't a mptable -- it would have to be `hard coded' based on recognition of the machine. Not a big deal; it doesn't have PCI or anything. But I do have the recognition code for the machine. I don't expect you to try to get it working. However, I do think that the SMP framework should be kept sufficiently generic that it could deal with APICs at different addresses (not they are withing the same physical page, sp mappings don't help) as we can't tell what will happen in version 2.0. The ability to handle different addresses (for IOAPICS) already needs to be added. Kevin From owner-freebsd-smp Wed Jul 16 18:03:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA22493 for smp-outgoing; Wed, 16 Jul 1997 18:03:51 -0700 (PDT) Received: from twinlark.arctic.org (twinlark.arctic.org [204.62.130.91]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id SAA22482 for ; Wed, 16 Jul 1997 18:03:46 -0700 (PDT) Received: (qmail 12474 invoked by uid 500); 17 Jul 1997 01:03:44 -0000 Date: Wed, 16 Jul 1997 18:03:44 -0700 (PDT) From: Dean Gaudet To: Steve Passe cc: smp@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: self modifying kernel code In-Reply-To: <199707162042.OAA09705@Ilsa.StevesCafe.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 16 Jul 1997, Steve Passe wrote: > Peter pointed out a technique where another SMP kernel > puts calls in the kernel to a pseudo-lock routine. This routine then > determines whether it is running on a UP or SMP motherboard. If UP it replaces > the call with a near jump to the return address. If SMP it replaces the call > TARGET address with the address of the real lock routine. DEC OSF/1. I can't get at my bookmarks, but there's a good txt file available on one of dec's many servers that describes the process by which they moved to fine-grained SMP in OSF/1 and it talks about the above technique. Dean From owner-freebsd-smp Wed Jul 16 18:14:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA23025 for smp-outgoing; Wed, 16 Jul 1997 18:14:31 -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 SAA23011 for ; Wed, 16 Jul 1997 18:14:27 -0700 (PDT) Received: from fast.cs.utah.edu by cs.utah.edu (8.8.4/utah-2.21-cs) id TAA27158; Wed, 16 Jul 1997 19:14:20 -0600 (MDT) Received: by fast.cs.utah.edu (8.6.10/utah-2.15-leaf) id TAA28520; Wed, 16 Jul 1997 19:14:20 -0600 Date: Wed, 16 Jul 1997 19:14:20 -0600 From: vanmaren@fast.cs.utah.edu (Kevin Van Maren) Message-Id: <199707170114.TAA28520@fast.cs.utah.edu> To: ade@demon.net Subject: Re: HEADS UP: EISA cards. Cc: smp@FreeBSD.ORG Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On a related note, can someone explain to a PC-hardware ignoramus > (ie, me :) why no-one makes completely PCI-based motherboards, say > with 7 or 8 slots? [perhaps this question should move over to > -hackers?] Because you need ISA slots :) Seriously, there are very few PCI sound cards, and no PCI modems. (Of course, you can go external modem). But the integrated serial ports are `isa', and adding a connector is cheap, especially when most people `need' them. (For a PCI sound card, look at ASUS's site, which uses the ISA connector onthe mediabus, or ensoniq's site at http://www.audiopci.ensoniq.com/) As for more PCI slots, there are a few motherboards with 6+ slots. Usually in high-end servers. A few motherboards support 5 PCI slots, on one PCI bus. But beyond that you need multiple PCI busses which involves a bridge chip. Award BIOS can only deal with one bridge. Cards like the Adaptec 6944 (quad 100Mb ethernet) and the 3940/3985 also use bridge chips to get multiple PCI devices in one slot. Symbios logic has a dual function SCSI controller that has two SCSI controllers in one chip; they also have a SCSI/Ethernet combination chip. Both of those are only one PCI load, and don't require a bridge. If you really want a lot of PCI, there are currently three choices: 1) Buy a very expensive server. You can get 8 or so PCI slots by doing that. 2) Buy a PCI expansion Box. Magma and Bit3 both make them. For ~$1000, you get a computer case that will hold 7 PCI cards, and plugs into a single PCI slot. However, they use bridges three levels deep, which causes problems with some software (and many BIOSes). 3) Buy a SBC (single board computer) and plug it into a passive backplane. There are a lot of choices for pasive backplanes; you can get them with as many as 17 PCI slots (they are bridged, of course). However, since 4-5 PCI slots are enough for 95% of the PC market, all three of the previous options are rather expensive. There are several motherboards that have integrated UW SCSI as well as the 5 PCI slots (ie, www.airwebs.com/p6kdi.html/) AMI (www.ami.com) has announced a dual motherboard with 6 PCI and two ultra-wide SCSI (NCR875) using a bridge. It is likely more than the $480 for the AIR. Annother option would be the SuperMicro I2O motherboard. Also, I wanted to point out that there are known problems with the PCI 2.1 coherence protocol in the presence of PCI bridges. It remains to be seen how much of a problem it will be with the I2O spec in practice. Kevin From owner-freebsd-smp Wed Jul 16 19:07:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA25850 for smp-outgoing; Wed, 16 Jul 1997 19:07:27 -0700 (PDT) Received: from mail.webspan.net (root@mail.webspan.net [206.154.70.7]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA25845 for ; Wed, 16 Jul 1997 19:07:23 -0700 (PDT) Received: from orion.webspan.net (orion.webspan.net [206.154.70.5]) by mail.webspan.net (WEBSPAN/970608) with ESMTP id WAA25444; Wed, 16 Jul 1997 22:07:22 -0400 (EDT) Received: from orion.webspan.net (localhost [127.0.0.1]) by orion.webspan.net (WEBSPAN/970608) with ESMTP id WAA10135; Wed, 16 Jul 1997 22:07:21 -0400 (EDT) To: vanmaren@fast.cs.utah.edu (Kevin Van Maren) cc: ade@demon.net, smp@FreeBSD.ORG From: "Gary Palmer" Subject: Re: HEADS UP: EISA cards. In-reply-to: Your message of "Wed, 16 Jul 1997 19:14:20 MDT." <199707170114.TAA28520@fast.cs.utah.edu> Date: Wed, 16 Jul 1997 22:07:21 -0400 Message-ID: <10133.869105241@orion.webspan.net> Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Kevin Van Maren wrote in message ID <199707170114.TAA28520@fast.cs.utah.edu>: > As for more PCI slots, there are a few motherboards with 6+ slots. > Usually in high-end servers. A few motherboards support 5 PCI > slots, on one PCI bus. But beyond that you need multiple PCI busses > which involves a bridge chip. Award BIOS can only deal with one bridge. Actually, as I'm sure others will tell you, some motherboards have two (non bridged) PCI busses. I believe the Intel Alder server for one. Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-smp Wed Jul 16 19:33:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA27251 for smp-outgoing; Wed, 16 Jul 1997 19:33:54 -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 TAA27245; Wed, 16 Jul 1997 19:33:47 -0700 (PDT) Received: from fast.cs.utah.edu by cs.utah.edu (8.8.4/utah-2.21-cs) id UAA28833; Wed, 16 Jul 1997 20:33:43 -0600 (MDT) Received: by fast.cs.utah.edu (8.6.10/utah-2.15-leaf) id UAA29668; Wed, 16 Jul 1997 20:33:43 -0600 Date: Wed, 16 Jul 1997 20:33:43 -0600 From: vanmaren@fast.cs.utah.edu (Kevin Van Maren) Message-Id: <199707170233.UAA29668@fast.cs.utah.edu> To: gpalmer@FreeBSD.ORG Subject: Re: HEADS UP: EISA cards. Cc: ade@demon.net, smp@FreeBSD.ORG Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Actually, as I'm sure others will tell you, some motherboards have two > (non bridged) PCI busses. I believe the Intel Alder server for one. Right. The Orion chipset supports two `peer' busses. I believe the Goliath motherboard's 6 slots are obtained this way. (I should have said this, sorry.) From owner-freebsd-smp Wed Jul 16 20:09:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA29277 for smp-outgoing; Wed, 16 Jul 1997 20:09:26 -0700 (PDT) Received: from h2o.journey.net (h2o.journey.net [207.227.162.60]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA29265 for ; Wed, 16 Jul 1997 20:09:20 -0700 (PDT) Received: from localhost (listuser@localhost) by h2o.journey.net (8.8.5/8.8.5) with SMTP id XAA06771; Wed, 16 Jul 1997 23:10:16 -0400 (EDT) Date: Wed, 16 Jul 1997 23:10:16 -0400 (EDT) From: listuser To: Chuck Robey cc: Steve Passe , smp@FreeBSD.ORG Subject: Re: HEADS UP: EISA cards. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Just an FYI DELL computer still sells their SMP servers with 3 PCI and 5 EISA slots ... (Or at least two months ago when I bought one from them..) --Matt On Wed, 16 Jul 1997, Chuck Robey wrote: > On Tue, 15 Jul 1997, Steve Passe wrote: > > > Hi, > > > > DESIGN DECISION: > > > > I am about to make a design decision that will forever-more make the use > > of EISA cards that use the EISA chipset DMA circuit impossible in the SMP > > kernel. I posted a rather long email about this several days ago but got ZERO > > response. So I can conclude that either: > > > > a: everyone agrees with this decision. > > OR > > b: no one with such hardware read that far. > > > > In the future I will use this "HEADS UP" format to get a summary of such > > info to the top of email. For the record, here is a repost of the > > pertinant info: > > Steve, I don't have an EISA smp board, so I felt I didn't need to reply, > but your suggestion is fine with me. Thinking about it, the only EISA > boards out there would be getting a little aged, and it seems fairly safe > to exclude them from smp work. > > ----------------------------+----------------------------------------------- > Chuck Robey | Interests include any kind of voice or data > chuckr@eng.umd.edu | communications topic, C programming, and Unix. > 213 Lakeside Drive Apt T-1 | > Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD > (301) 220-2114 | version 3.0 current -- and great FUN! > ----------------------------+----------------------------------------------- > > From owner-freebsd-smp Wed Jul 16 20:30:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA00136 for smp-outgoing; Wed, 16 Jul 1997 20:30:40 -0700 (PDT) Received: from shoe.cs.utah.edu (shoe.cs.utah.edu [155.99.212.77]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA00131 for ; Wed, 16 Jul 1997 20:30:37 -0700 (PDT) Received: (from vanmaren@localhost) by shoe.cs.utah.edu (8.8.5/8.8.5) id VAA02748 for smp@freebsd.org; Wed, 16 Jul 1997 21:31:18 -0600 (MDT) Date: Wed, 16 Jul 1997 21:31:18 -0600 (MDT) From: Kevin Van Maren Message-Id: <199707170331.VAA02748@shoe.cs.utah.edu> To: smp@freebsd.org Subject: Re: HEADS UP: EISA cards. Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Just an FYI DELL computer still sells their SMP servers with 3 PCI and 5 > EISA slots ... > (Or at least two months ago when I bought one from them..) The 4100 we had came with 5 PCI and 3 EISA. Can you send a MPTABLE output with dual CPUs? Kevin From owner-freebsd-smp Wed Jul 16 20:38:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA00541 for smp-outgoing; Wed, 16 Jul 1997 20:38:10 -0700 (PDT) Received: from spinner.dialix.com.au (spinner.dialix.com.au [192.203.228.67]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA00532 for ; Wed, 16 Jul 1997 20:37:53 -0700 (PDT) Received: from spinner.dialix.com.au (localhost.dialix.com.au [127.0.0.1]) by spinner.dialix.com.au with ESMTP id LAA23469; Thu, 17 Jul 1997 11:36:58 +0800 (WST) Message-Id: <199707170336.LAA23469@spinner.dialix.com.au> X-Mailer: exmh version 2.0delta 6/3/97 To: listuser cc: Chuck Robey , Steve Passe , smp@FreeBSD.ORG Subject: Re: HEADS UP: EISA cards. In-reply-to: Your message of "Wed, 16 Jul 1997 23:10:16 -0400." Date: Thu, 17 Jul 1997 11:36:57 +0800 From: Peter Wemm Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk listuser wrote: > Just an FYI DELL computer still sells their SMP servers with 3 PCI and 5 > EISA slots ... > (Or at least two months ago when I bought one from them..) > > --Matt Again, remember that the feature that we are talking about (DMA Chaining) is *not* implemented in the uniprocessor kernel either! I do not know of *any* devices that use it. All the EISA DMA devices that I know of (eg: AHA 1742, 2742, BusLogic etc controllers) use Busmaster DMA, not the lame 64K-at-a-time DMA chunking driven by the motherboard DMA counters. The DMA Chaining interrupt is (I think) used to try and work around of that lameness. In fact, the only devices that I can think of that use the motherboard DMA counters are ISA soundcards and the floppy controller. I can't recall ever seeing an EISA soundblaster clone type card. Most decent (if you can call it that) ISA hardware that uses DMA does busmastering too (eg: the adaptec scsi host adapters). What we are talking about is making a design choice that will prevent us from implementing DMA chaining in the future. I think the possibility of needing to do that that is exceedingly unlikely. And I would argue that doing that sort of non-busmastering DMA would be kind of defeating the purpose of building a high performance system with multiple CPUs anyway. Cheers, -Peter > On Wed, 16 Jul 1997, Chuck Robey wrote: > > > On Tue, 15 Jul 1997, Steve Passe wrote: > > > > > Hi, > > > > > > DESIGN DECISION: > > > > > > I am about to make a design decision that will forever-more make the use > > > of EISA cards that use the EISA chipset DMA circuit impossible in the SMP > > > kernel. I posted a rather long email about this several days ago but got ZERO > > > response. So I can conclude that either: > > > > > > a: everyone agrees with this decision. > > > OR > > > b: no one with such hardware read that far. > > > > > > In the future I will use this "HEADS UP" format to get a summary of such > > > info to the top of email. For the record, here is a repost of the > > > pertinant info: > > > > Steve, I don't have an EISA smp board, so I felt I didn't need to reply, > > but your suggestion is fine with me. Thinking about it, the only EISA > > boards out there would be getting a little aged, and it seems fairly safe > > to exclude them from smp work. > > > > ----------------------------+---------------------------------------------- - > > Chuck Robey | Interests include any kind of voice or data > > chuckr@eng.umd.edu | communications topic, C programming, and Unix . > > 213 Lakeside Drive Apt T-1 | > > Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD > > (301) 220-2114 | version 3.0 current -- and great FUN! > > ----------------------------+---------------------------------------------- From owner-freebsd-smp Wed Jul 16 20:47:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA01018 for smp-outgoing; Wed, 16 Jul 1997 20:47:27 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA01012; Wed, 16 Jul 1997 20:47:20 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id NAA02736; Thu, 17 Jul 1997 13:43:26 +1000 Date: Thu, 17 Jul 1997 13:43:26 +1000 From: Bruce Evans Message-Id: <199707170343.NAA02736@godzilla.zeta.org.au> To: dg@root.com, smp@csn.net Subject: Re: self modifying kernel code Cc: current@FreeBSD.ORG, smp@FreeBSD.ORG Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>So what is the policy/reality of self-modifying code in the -current source? > > Basically, we don't allow self-modifying code. There are many reasons, for >instance the kernel text is protect read-only to catch certain types of bad >pointer references, but the main reason is that it's considered bad programming >style, obscuring the operation of the code - usually with little or no gain. Yes, things like LKM's and kldload(2) don't exist ;-). They give little or no gain. Bruce From owner-freebsd-smp Wed Jul 16 20:54:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA01540 for smp-outgoing; Wed, 16 Jul 1997 20:54:15 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA01527 for ; Wed, 16 Jul 1997 20:54:01 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id VAA11792; Wed, 16 Jul 1997 21:52:30 -0600 (MDT) Message-Id: <199707170352.VAA11792@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Peter Wemm cc: listuser , Chuck Robey , smp@FreeBSD.ORG Subject: Re: HEADS UP: EISA cards. In-reply-to: Your message of "Thu, 17 Jul 1997 11:36:57 +0800." <199707170336.LAA23469@spinner.dialix.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jul 1997 21:52:30 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Peter, > Again, remember that the feature that we are talking about (DMA Chaining) > ... > purpose of building a high performance system with multiple CPUs anyway. a related aspect of this is the functionality we gain by programming IO APIC pin 0 as a 'regular' INT. Specifically, the 8259 becomes nothing more than a buffer chip for the 8254 timer. It probably delays the clock INT by about 10nsec, but this is probably pretty constant. And the timer returns to being on vec[ 0 ] as a result. We might consider programming ALL systems this way, whether they connect the timer to IO APIC pin 2 or not. This would eliminate the "song and dance" I go thru using the vec[] array and the indirections thru it to get to the hardware resumption routines. This may well be why intel designed the PR440FX board to NOT have an IO APIC pin 2 connection to the timer. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Jul 16 21:32:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA02755 for smp-outgoing; Wed, 16 Jul 1997 21:32:11 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA02740 for ; Wed, 16 Jul 1997 21:32:08 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id GAA02619 for ; Thu, 17 Jul 1997 06:31:58 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.4/8.6.12) with UUCP id GAA32138 for smp@FreeBSD.ORG; Thu, 17 Jul 1997 06:31:46 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.6/keltia-uucp-2.9) id AAA23357; Thu, 17 Jul 1997 00:13:07 +0200 (CEST) Message-ID: <19970717001307.44931@keltia.freenix.fr> Date: Thu, 17 Jul 1997 00:13:07 +0200 From: Ollivier Robert To: smp@FreeBSD.ORG Subject: Re: HEADS UP: EISA cards. References: <199707161516.JAA02892@fast.cs.utah.edu> <199707161719.LAA09048@Ilsa.StevesCafe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199707161719.LAA09048@Ilsa.StevesCafe.com>; from Steve Passe on Wed, Jul 16, 1997 at 11:19:27AM -0600 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3461 AMD-K6 MMX @ 208 MHz Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Steve Passe: > it affects busmastering EISA cards. Experience shows that it doesn't > affect the adaptec 1742 EISA card, which is probably the only EISA > issue for +90% of our user base. Just do a test with a Buslogic BT-742A / BT-747S. They're probably not as common as the 174x and they share the same bus-mastering way of working but who knows... I won't cry over it anyway especially after reading the thread. :-) -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #22: Sun Jul 13 22:07:09 CEST 1997 From owner-freebsd-smp Wed Jul 16 22:31:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA05017 for smp-outgoing; Wed, 16 Jul 1997 22:31:01 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id WAA05011; Wed, 16 Jul 1997 22:30:57 -0700 (PDT) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0woj9G-0003RJ-00; Wed, 16 Jul 1997 23:30:42 -0600 To: dg@root.com Subject: Re: self modifying kernel code Cc: Steve Passe , smp@freebsd.org, current@freebsd.org In-reply-to: Your message of "Wed, 16 Jul 1997 17:40:42 PDT." <199707170040.RAA04953@implode.root.com> References: <199707170040.RAA04953@implode.root.com> Date: Wed, 16 Jul 1997 23:30:42 -0600 From: Warner Losh Message-Id: Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199707170040.RAA04953@implode.root.com> David Greenman writes: : I'd say that you'd get less resistence to it, but then at boot time there : are probably other cleaner, slower, ways of accomplishing the same thing. I know that the MIPS based OSes generally bcopy a routine into the trap handler location based on what architecture it is running (MIPS I or MIPS III) on. The MIPS hardware wants this trap routine to be of a certain size at a fixed location. Since this is for TLB handling, and there are a limited number of TLB slots, this routine generally is as hand tweaked as you can get. Warner From owner-freebsd-smp Thu Jul 17 00:17:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA10429 for smp-outgoing; Thu, 17 Jul 1997 00:17:26 -0700 (PDT) Received: from jumping-spider.aracnet.com (root@jumping-spider.aracnet.com [204.188.47.14]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA10423 for ; Thu, 17 Jul 1997 00:17:22 -0700 (PDT) Received: from speedy (ppp-r37.aracnet.com [205.238.13.39]) by jumping-spider.aracnet.com (8.8.5/8.8.5) with ESMTP id AAA20177; Thu, 17 Jul 1997 00:21:32 -0700 Message-ID: <33CDD447.25F5C25B@earthling.net> Date: Thu, 17 Jul 1997 00:13:59 -0800 From: Chris Browning Reply-To: cbrown@aracnet.com X-Mailer: Mozilla 4.01 [en] (WinNT; I) MIME-Version: 1.0 To: Terry Lambert CC: cbrown@aracnet.com, smp@csn.net, smp@FreeBSD.ORG Subject: Re: HEADS UP: EISA cards. X-Priority: 3 (Normal) References: <199707162122.OAA01516@phaeton.artisoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote: > > > Why would you not want to abandon the 8254? Why not use the APIC's > > timer? I would imagine that it was put there for this purpose when > > running in full symetric mode. > > This is a HAL issue. > > The problem, I suspect, is that we Steve wants the kernel to run > on non-APIC machines as well (correct me if I'm wrong), and > the kernel expects timer services. And which SMP machines do not have a APIC? Maybe I should have made myself more clear. Why not abandon the 8254 completely when in Full symmetric mode. You have to do a bunch of stuff when you switch modes, so why not add this to it. Chris Not speaking for Intel From owner-freebsd-smp Thu Jul 17 00:50:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA12622 for smp-outgoing; Thu, 17 Jul 1997 00:50:53 -0700 (PDT) Received: from bugs.us.dell.com (bugs.us.dell.com [143.166.169.147]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA12610 for ; Thu, 17 Jul 1997 00:50:49 -0700 (PDT) Received: from moth.us.dell.com (moth.us.dell.com [143.166.169.152]) by bugs.us.dell.com (8.6.12/8.6.12) with SMTP id CAA05393; Thu, 17 Jul 1997 02:50:14 -0500 Message-Id: <3.0.1.32.19970717024955.0068eb64@bugs.us.dell.com> X-Sender: tony@bugs.us.dell.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 17 Jul 1997 02:49:55 -0500 To: Steve Passe , smp@FreeBSD.ORG From: Tony Overfield Subject: Re: Latest code. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Hi, > >This would be a good time to update your source trees. While following the suggestion to try out the latest code, I attempted to install the 3.0-970716-SNAP but it failed for me. After booting the boot floppy and choosing an ordinary "Novice", "Kernel Developer" install, and just before the "can't turn back" screen appears, I get this result: +---------- Information Dialog ----------+ | Adding default route to 143.166.169.1.panic: page fault +----------------------------------------+ syncing disks... done Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot <-- This is not likely to be a problem with SMP support since the install floppy is the thing that's not working, but since I was wanting to try out the SMP stuff, I didn't let this stop me. Then I tried 3.0-970713-SNAP and it seems to work fine. At least it works well enough to produce the information below. Does anyone see anything wrong that might prevent the 3.0-970716-SNAP from working? The first few lines come from the GENERIC kernel, but since they aren't displayed by the SMP-GENERIC kernel, I've included them here: FreeBSD 3.0-970713-SNAP #0: Sun Jul 13 09:16:03 GMT 1997 root@make.ican.net:/usr/src/sys/compile/GENERIC Calibrating clock(s) ... i586 clock: 299945805 Hz, i8254 clock: 1193200 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency CLK_USE_I586_CALIBRATION not specified - using old calibration method CPU: Pentium Pro (299.94-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x633 Stepping=3 Features=0x80fbff Here's the 'mptable -dmesg' output using the SMP-GENERIC kernel: ============================================================================ === MPTable, version 2.0.12 ---------------------------------------------------------------------------- --- MP Floating Pointer Structure: location: BIOS physical address: 0x000fe710 signature: '_MP_' length: 16 bytes version: 1.4 checksum: 0x91 mode: Virtual Wire ---------------------------------------------------------------------------- --- MP Config Table Header: physical address: 0x000f0000 signature: 'PCMP' base table length: 428 version: 1.4 checksum: 0xce OEM ID: 'DELL ' Product ID: 'System WS ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 45 local APIC address: 0xfee00000 extended table length: 0 extended table checksum: 0 ---------------------------------------------------------------------------- --- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 0 0x11 BSP, usable 6 3 3 0x80fbff 1 0x11 AP, usable 6 3 3 0x80fbff -- Bus: Bus ID Type 0 PCI 1 PCI 2 ISA -- I/O APICs: APIC ID Version State Address 2 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT active-hi edge 2 0 2 0 INT conforms conforms 2 1 2 1 INT conforms conforms 2 3 2 3 INT conforms conforms 2 4 2 4 INT conforms conforms 2 5 2 5 INT conforms conforms 2 6 2 6 INT conforms conforms 2 7 2 7 INT conforms conforms 2 8 2 8 INT conforms conforms 2 9 2 9 INT conforms conforms 2 10 2 10 INT conforms conforms 2 11 2 11 INT conforms conforms 2 12 2 12 INT conforms conforms 2 13 2 13 INT conforms conforms 2 14 2 14 INT conforms conforms 2 15 2 15 INT conforms conforms 0 16:A 2 16 INT conforms conforms 0 17:D 2 16 INT conforms conforms 1 9:B 2 16 INT conforms conforms 1 10:C 2 16 INT conforms conforms 1 11:C 2 16 INT conforms conforms 0 16:B 2 17 INT conforms conforms 0 17:A 2 17 INT conforms conforms 1 9:C 2 17 INT conforms conforms 1 10:D 2 17 INT conforms conforms 1 11:D 2 17 INT conforms conforms 0 16:C 2 18 INT conforms conforms 0 17:B 2 18 INT conforms conforms 1 9:D 2 18 INT conforms conforms 1 10:A 2 18 INT conforms conforms 1 11:A 2 18 INT conforms conforms 0 13:D 2 19 INT conforms conforms 0 16:D 2 19 INT conforms conforms 0 17:C 2 19 INT conforms conforms 1 8:A 2 19 INT conforms conforms 1 9:A 2 19 INT conforms conforms 1 10:B 2 19 INT conforms conforms 1 11:B 2 19 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT active-hi edge 2 0 255 0 NMI active-hi edge 2 0 255 1 ---------------------------------------------------------------------------- --- # SMP kernel config file options: # Required: options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Useful: #options SMP_AUTOSTART # start the additional CPUs during boot # Optional (built-in defaults will work in most cases): #options NCPU=2 # number of CPUs #options NBUS=3 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=37 # number of INTs # Rogue hardware: # # Tyan Tomcat II: #options SMP_TIMER_NC # # # SuperMicro P6DNE: #options SMP_TIMER_NC # ---------------------------------------------------------------------------- --- dmesg output: Copyright (c) 1992-1997 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-970713-SNAP #0: Thu Jul 17 01:35:33 CDT 1997 root@mantis.us.dell.com:/usr/src/sys/compile/SMP-GENERIC Calibrating clock(s) ... i8254 clock: 1193198 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency CPU: Pentium Pro (686-class CPU) Origin = "GenuineIntel" Id = 0x633 Stepping=3 Features=0x80fbff real memory = 33554432 (32768K bytes) avail memory = 30236672 (29528K bytes) SMP: CPU00 bsp_apic_configure() lint0: 0x00000700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x0000016f FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 SMP: CPU00 bsp_apic_configure() lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000010 SVR: 0x0000016f pci_open(1): mode 1 addr port (0x0cf8) is 0x80000058 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=12378086) Probing for devices on PCI bus 0: found-> vendor=0x8086, dev=0x1237, revid=0x02 class=06-00-00, hdrtype=0x00, mfdev=0 chip0: rev 0x02 on pci0.0.0 found-> vendor=0x8086, dev=0x7000, revid=0x01 class=06-01-00, hdrtype=0x00, mfdev=1 chip1: rev 0x01 on pci0.13.0 found-> vendor=0x8086, dev=0x7010, revid=0x00 class=01-01-80, hdrtype=0x00, mfdev=0 chip2: rev 0x00 on pci0.13.1 I/O Recovery Timing: 8-bit 3.5 clocks, 16-bit 3.5 clocks Extended BIOS: disabled Lower BIOS: disabled Coprocessor IRQ13: disabled Mouse IRQ12: disabled Interrupt Routing: A: , B: , C: , D: MB0: , MB1: found-> vendor=0x1011, dev=0x0024, revid=0x01 class=06-04-00, hdrtype=0x01, mfdev=0 chip3: rev 0x01 on pci0.14.0 Freeing (NOT implemented) redirected PCI irq 9. found-> vendor=0x102b, dev=0x0519, revid=0x01 class=03-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=16 map[0]: type 1, range 32, base fe800000, size 14 map[1]: type 3, range 32, base fe000000, size 23 vga0: rev 0x01 int a irq 16 on pci0.16.0 Probing for devices on PCI bus 1: Freeing (NOT implemented) redirected PCI irq 11. found-> vendor=0x10b7, dev=0x9050, revid=0x00 class=02-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=19 map[0]: type 4, range 32, base 0000ecc0, size 6 vx0: <3COM 3C905 Fast Etherlink XL PCI> rev 0x00 int a irq 19 on pci1.8.0 mii[*mii*]: disable 'auto select' with DOS util! address 00:c0:4f:11:61:18 Probing for devices on the ISA bus: sc0: the current keyboard controller command byte 0065 kbdio: DIAGNOSE status:0055 kbdio: TEST_KBD_PORT status:0000 kbdio: RESET_KBD return code:00fa kbdio: RESET_KBD status:00aa sc0 at 0x60-0x6f irq 1 on motherboard sc0: BIOS video mode:3 sc0: VGA registers upon power-up 50 18 10 00 10 00 03 00 02 67 60 4f 50 83 55 81 bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff sc0: video mode:24 sc0: VGA registers for mode:24 50 18 10 00 10 00 03 00 02 67 60 4f 50 83 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff sc0: VGA color <16 virtual consoles, flags=0x0> ed0: disabled, not probed. ed1: disabled, not probed. fe0: disabled, not probed. sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2: disabled, not probed. sio3: disabled, not probed. lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface lpt1: disabled, not probed. mse0: disabled, not probed. psm0: current command byte:0065 kbdio: TEST_AUX_PORT status:0000 kbdio: RESET_AUX return code:00fa kbdio: RESET_AUX status:00aa kbdio: RESET_AUX ID:0000 psm0: status after reset 00 02 64 psm: status 00 00 64 (get_mouse_buttons) psm0: status 00 02 64 psm0 at 0x60-0x64 irq 12 on motherboard psm0: device ID 0, 2 buttons fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in fd1: 1.2MB 5.25in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 325MB (666600 sectors), 1010 cyls, 12 heads, 55 S/T, 512 B/S wdc1: disabled, not probed. bt0: disabled, not probed. uha0: disabled, not probed. aha0: disabled, not probed. aic0: disabled, not probed. nca0: disabled, not probed. nca1: disabled, not probed. sea0: disabled, not probed. wt0: disabled, not probed. mcd0: disabled, not probed. matcdc0: disabled, not probed. scd0: disabled, not probed. ie0: disabled, not probed. ie1: disabled, not probed. ep0: disabled, not probed. ex0: disabled, not probed. le0: disabled, not probed. lnc0: disabled, not probed. ze0: disabled, not probed. zp0: disabled, not probed. npx0 on motherboard npx0: INT 16 interface apm0: disabled, not probed. imasks: bio c0004040, tty c308109a, net c308109a BIOS Geometries: 0:03f00b37 0..1008=1009 cylinders, 0..11=12 heads, 1..55=55 sectors 0 accounted for Device configuration finished. Considering FFS root f/s. configure() finished. APIC missing 8254 connection SMP: using ALT timer setup Enabled INTs: 0, 1, 3, 4, 6, 7, 8, 12, 14, 19, imen: 0x00f7ae24 wd0s1: type 0xa5, start 55, end = 666599, size 666545 : OK SMP: All idle procs online. SMP: *** AUTO *** starting 1st AP! SMP: AP CPU #1 LAUNCHED!! Starting Scheduling... SMP: TADA! CPU #1 made it into the scheduler!. SMP: CPU01 bsp_apic_configure() lint0: 0x00010700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x0000016f SMP: All 2 CPU's are online! ============================================================================ === - Tony From owner-freebsd-smp Thu Jul 17 00:53:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA12806 for smp-outgoing; Thu, 17 Jul 1997 00:53:27 -0700 (PDT) Received: from spinner.dialix.com.au (spinner.dialix.com.au [192.203.228.67]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA12799 for ; Thu, 17 Jul 1997 00:53:20 -0700 (PDT) Received: from spinner.dialix.com.au (localhost.dialix.com.au [127.0.0.1]) by spinner.dialix.com.au with ESMTP id PAA25589; Thu, 17 Jul 1997 15:48:56 +0800 (WST) Message-Id: <199707170748.PAA25589@spinner.dialix.com.au> X-Mailer: exmh version 2.0delta 6/3/97 To: Steve Passe cc: listuser , Chuck Robey , smp@FreeBSD.ORG Subject: Re: HEADS UP: EISA cards. In-reply-to: Your message of "Wed, 16 Jul 1997 21:52:30 CST." <199707170352.VAA11792@Ilsa.StevesCafe.com> Date: Thu, 17 Jul 1997 15:48:55 +0800 From: Peter Wemm Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote: > Peter, > > > Again, remember that the feature that we are talking about (DMA Chaining) > > ... > > purpose of building a high performance system with multiple CPUs anyway. > > a related aspect of this is the functionality we gain by programming IO APIC > pin 0 as a 'regular' INT. Specifically, the 8259 becomes nothing more than a > buffer chip for the 8254 timer. It probably delays the clock INT by about > 10nsec, but this is probably pretty constant. And the timer returns > to being on vec[ 0 ] as a result. We might consider programming ALL systems > this way, whether they connect the timer to IO APIC pin 2 or not. This would > eliminate the "song and dance" I go thru using the vec[] array and the > indirections thru it to get to the hardware resumption routines. > This may well be why intel designed the PR440FX board to NOT have an IO APIC > pin 2 connection to the timer. They dont??? I thought the ones we were using did have the connection.. Hmm.. I see what you mean. Anyway, I think the reason it's not done is in order to support an extra steerable IDE interrupt (irq 15) with a limited number of pins on the chip package. After all, we all know how much the Wintel crowd love IDE. Dont forget the boards also have an ISA PNP Crystal SB16-clone chip onboard, how's that for priorities for a high-performance server board... > -- > Steve Passe | powered by > smp@csn.net | Symmetric MultiProcessor FreeBSD > > Cheers, -Peter From owner-freebsd-smp Thu Jul 17 00:58:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA13267 for smp-outgoing; Thu, 17 Jul 1997 00:58:42 -0700 (PDT) Received: from spinner.dialix.com.au (spinner.dialix.com.au [192.203.228.67]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA13248 for ; Thu, 17 Jul 1997 00:58:31 -0700 (PDT) Received: from spinner.dialix.com.au (localhost.dialix.com.au [127.0.0.1]) by spinner.dialix.com.au with ESMTP id PAA25690; Thu, 17 Jul 1997 15:57:59 +0800 (WST) Message-Id: <199707170757.PAA25690@spinner.dialix.com.au> X-Mailer: exmh version 2.0delta 6/3/97 To: vanmaren@fast.cs.utah.edu (Kevin Van Maren) cc: smp@FreeBSD.ORG, smp@csn.net Subject: Re: HEADS UP: EISA cards. In-reply-to: Your message of "Wed, 16 Jul 1997 09:16:35 CST." <199707161516.JAA02892@fast.cs.utah.edu> Date: Thu, 17 Jul 1997 15:57:59 +0800 From: Peter Wemm Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Kevin Van Maren wrote: > Okay, I'll bite. > > First off, I think that you DO want to abandon the 8254 timer > under SMP. The APIC's internal timer is much nicer. Not necessarily. The 8254 timer has the advantage that it's global, and is calibrated at boot. The APIC timers are per cpu and are (apparently) implemented as memory bus devices on the silicon, so it's just the same as an off-chip non-cacheable access (hence the elimination of accesses to the APIC_ID register after boot). The APIC timer is currently used for timing the IPI state sequences, and appears to be ideally suited for the precise timing that it needs. We can't easily use the single APIC timer for IPI timing *and* the system clock at the same time. It might be nice to build a precision event system around it at some later point (can you say, high resolution realtime sleeps, select sleeps, etc), and use the elapsed time of the IPI interval in the "time to next event" arithmatic etc, but we've got bigger things to worry about until then. Cheers, -Peter From owner-freebsd-smp Thu Jul 17 01:09:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA13998 for smp-outgoing; Thu, 17 Jul 1997 01:09:39 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA13990 for ; Thu, 17 Jul 1997 01:09:36 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id CAA12791; Thu, 17 Jul 1997 02:07:26 -0600 (MDT) Message-Id: <199707170807.CAA12791@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Peter Wemm cc: listuser , Chuck Robey , smp@FreeBSD.ORG Subject: Re: HEADS UP: EISA cards. In-reply-to: Your message of "Thu, 17 Jul 1997 15:48:55 +0800." <199707170748.PAA25589@spinner.dialix.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Jul 1997 02:07:26 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Peter, > > This may well be why intel designed the PR440FX board to NOT have an IO APIC > > pin 2 connection to the timer. > > They dont??? I thought the ones we were using did have the connection.. > Hmm.. I see what you mean. no they don't. but they are among the few to get this fact properly documented in the mptable, so they get some credit! At least we have no need for the ugly "options SMP_TIMER_NC" thingy. --- > Anyway, I think the reason it's not done is in order to support an extra > steerable IDE interrupt (irq 15) with a limited number of pins on the > chip package. After all, we all know how much the Wintel crowd love IDE. > Dont forget the boards also have an ISA PNP Crystal SB16-clone chip > onboard, how's that for priorities for a high-performance server board... this is also a part of the equation, in their datasheets intel states that if there is an IO APIC the pin should be connected to it, and programmed as INT0 out, but if there is no IO APIC, it should be attached to the secondary IDE and programmed as MIRQ0. so pin sharing is intel's goal, at the chip level at least. On this particular board however, how much ISA INT steerinmg do you really need with 1 stinking ISA slot? (perhaps you can tell that I need another ISA slot at this point...) -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Thu Jul 17 01:10:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA14108 for smp-outgoing; Thu, 17 Jul 1997 01:10:51 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA14100 for ; Thu, 17 Jul 1997 01:10:48 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id CAA12815; Thu, 17 Jul 1997 02:10:46 -0600 (MDT) Message-Id: <199707170810.CAA12815@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: cbrown@aracnet.com cc: smp@FreeBSD.ORG Subject: Re: HEADS UP: EISA cards. In-reply-to: Your message of "Thu, 17 Jul 1997 00:13:59 -0800." <33CDD447.25F5C25B@earthling.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Jul 1997 02:10:46 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, >And which SMP machines do not have a APIC? Maybe I should have made >myself more clear. Why not abandon the 8254 completely when in >Full symmetric mode. You have to do a bunch of stuff when >you switch modes, so why not add this to it. The answer is that we haven't studied the issue well enough to make a decision as to what we should do for timer services. Having a central timer that is not tied to any particular CPU has advantages also. Among these is the possibility for any available CPU to handle its INTerrupt. Given our limited resources, alot of design decisions go along the lines of "what needs doing next, and what can we put off for awhile" as oppossed to a commercial operation where the decision is instead "who can we assign this task to?". The bottom line here is that we can probably get along with the 8254 timer and existing code for quite awhile, while we can forsee no need to the EISA DMA chaining. And going to the APIC timers will be a fair amount of time & code to achieve. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Thu Jul 17 01:31:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA15275 for smp-outgoing; Thu, 17 Jul 1997 01:31:34 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA15259 for ; Thu, 17 Jul 1997 01:31:30 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id CAA12958 for ; Thu, 17 Jul 1997 02:31:31 -0600 (MDT) Message-Id: <199707170831.CAA12958@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: smp@FreeBSD.ORG Subject: Re: Latest code. In-reply-to: Your message of "Thu, 17 Jul 1997 02:49:55 CDT." <3.0.1.32.19970717024955.0068eb64@bugs.us.dell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Jul 1997 02:31:31 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Tony, > While following the suggestion to try out the latest code, I > attempted to install the 3.0-970716-SNAP but it failed for me. After > ... > Then I tried 3.0-970713-SNAP and it seems to work fine. At least it > works well enough to produce the information below. Does anyone see > anything wrong that might prevent the 3.0-970716-SNAP from working? I tried sending this directly to you, but it bounced: I think there was a short time where a bug got committed to "route", this was probably the cause of the panic. Remember that SNAPs are autogenerated from -current each day, and -current can be broken at any point in time. Thats just the price you pay for using the very latest code. I take it that your SMP system is now happy... -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Thu Jul 17 01:38:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA15648 for smp-outgoing; Thu, 17 Jul 1997 01:38:03 -0700 (PDT) Received: from proxy.lkb.lv (proxy.lkb.lv [195.244.134.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA15617; Thu, 17 Jul 1997 01:37:47 -0700 (PDT) Received: from cave.lkb.lv (cave.lkb.lv [195.244.134.13]) by proxy.lkb.lv (8.7.6/8.7.3) with SMTP id LAA23301; Thu, 17 Jul 1997 11:34:58 +0300 (EET DST) Message-ID: <33CDD96B.722F@proxy.lkb.lv> Date: Thu, 17 Jul 1997 11:35:55 +0300 From: Uldis Mikelsons Reply-To: ulmik@proxy.lkb.lv Organization: AS Latvijas Krajbanka X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: freebsd-smp@freebsd.org CC: current@freebsd.org Subject: SNAP-970716 (wuz Re: Latest code.) References: <3.0.1.32.19970717024955.0068eb64@bugs.us.dell.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Tony Overfield wrote: Hi. > While following the suggestion to try out the latest code, I > attempted to install the 3.0-970716-SNAP but it failed for me. After > booting the boot floppy and choosing an ordinary "Novice", "Kernel > Developer" install, and just before the "can't turn back" screen > appears, I get this result: > > +---------- Information Dialog ----------+ > | Adding default route to 143.166.169.1.panic: page fault > +----------------------------------------+ > syncing disks... done > Automatic reboot in 15 seconds - press a key on the console to abort > --> Press a key on the console to reboot <-- if you installing from local server ( eg on same network ) dont add def. gateway and it works fine > This is not likely to be a problem with SMP support since the install > floppy is the thing that's not working, but since I was wanting to try > out the SMP stuff, I didn't let this stop me. if you simply remove default gateway from configs it works fine, if you add gateway at booting with any kernel GENERIC / SMP-GENERIC -------------------------------------------------------------------------- fatal trap 12: page fault while in kernel mode cpuid = 0 fault virtual adress = 0x80 fault code = supervisor read, page not present instruction pointer = 0x8:0xf14cf7c stack pointer = 0x10:0xf3b00df0 frame pointer = 0x10:0xf3b00e04 code segment = base 0x0, limit 0xfffff , type 0x1b = DPL 0, pres 1, def32, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 courent process = 53 (route) interupt mask = CPU0 stopping CPUs: 0x00000002 spin spun stopped stopped at: _rt_xaddrs+0x24 movzbl 0(%esi),%eax db> -------------------------------------------------------------------------- From owner-freebsd-smp Thu Jul 17 07:58:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA07266 for smp-outgoing; Thu, 17 Jul 1997 07:58:29 -0700 (PDT) Received: from scorpion.aracnet.com (root@scorpion.aracnet.com [204.188.47.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA07257 for ; Thu, 17 Jul 1997 07:58:26 -0700 (PDT) Received: from shelob.aracnet.com (cbrown@shelob.aracnet.com [204.188.47.2]) by scorpion.aracnet.com (8.8.5/8.8.5) with ESMTP id HAA28815; Thu, 17 Jul 1997 07:58:11 -0700 From: Chris Browning Received: by shelob.aracnet.com (8.8.5) id IAA13319; Thu, 17 Jul 1997 08:09:38 -0700 Message-Id: <199707171509.IAA13319@shelob.aracnet.com> Subject: Re: HEADS UP: EISA cards. To: peter@spinner.dialix.com.au (Peter Wemm) Date: Thu, 17 Jul 1997 08:09:38 -0700 (PDT) Cc: smp@csn.net, listuser@h2o.journey.net, chuckr@Glue.umd.edu, smp@FreeBSD.ORG In-Reply-To: <199707170748.PAA25589@spinner.dialix.com.au> from "Peter Wemm" at Jul 17, 97 03:48:55 pm Content-Type: text Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > eliminate the "song and dance" I go thru using the vec[] array and the > > indirections thru it to get to the hardware resumption routines. > > This may well be why intel designed the PR440FX board to NOT have an IO APIC > > pin 2 connection to the timer. > > They dont??? I thought the ones we were using did have the connection.. > Hmm.. I see what you mean. > > Anyway, I think the reason it's not done is in order to support an extra > steerable IDE interrupt (irq 15) with a limited number of pins on the > chip package. After all, we all know how much the Wintel crowd love IDE. > Dont forget the boards also have an ISA PNP Crystal SB16-clone chip > onboard, how's that for priorities for a high-performance server board... The PR440FX is NOT a server board. It was designed by the desktop group as a "workstation" like board. This is why it has a built-in NIC, Sound, and SCSI. It is missing serveral of the features I would consider necessary to perform as a "high performance" server board (only 512MB of mem, only 1 PCI bus, etc.) Chris Not speaking for Intel From owner-freebsd-smp Thu Jul 17 11:39:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA23866 for smp-outgoing; Thu, 17 Jul 1997 11:39:36 -0700 (PDT) Received: from bugs.us.dell.com (bugs.us.dell.com [143.166.169.147]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA23836; Thu, 17 Jul 1997 11:39:26 -0700 (PDT) Received: from ant.us.dell.com (ant.us.dell.com [198.64.66.34]) by bugs.us.dell.com (8.6.12/8.6.12) with SMTP id NAA06290; Thu, 17 Jul 1997 13:38:10 -0500 Message-Id: <3.0.1.32.19970717133807.006b8890@bugs.us.dell.com> X-Sender: tony@bugs.us.dell.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 17 Jul 1997 13:38:07 -0500 To: ulmik@proxy.lkb.lv, freebsd-smp@FreeBSD.ORG From: Tony Overfield Subject: Re: SNAP-970716 (wuz Re: Latest code.) Cc: current@FreeBSD.ORG In-Reply-To: <33CDD96B.722F@proxy.lkb.lv> References: <3.0.1.32.19970717024955.0068eb64@bugs.us.dell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 11:35 AM 7/17/97 +0300, Uldis Mikelsons wrote: >> | Adding default route to 143.166.169.1.panic: page fault >> syncing disks... done >if you installing from local server ( eg on same network ) dont add def. >gateway and it works fine Thanks, Uldis. Since I need to go through a router, I'll just wait and try this again after the bug is fixed. From owner-freebsd-smp Thu Jul 17 12:17:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA27134 for smp-outgoing; Thu, 17 Jul 1997 12:17:12 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA27090; Thu, 17 Jul 1997 12:16:54 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id NAA14845; Thu, 17 Jul 1997 13:16:00 -0600 (MDT) Message-Id: <199707171916.NAA14845@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Tony Overfield cc: ulmik@proxy.lkb.lv, freebsd-smp@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: SNAP-970716 (wuz Re: Latest code.) In-reply-to: Your message of "Thu, 17 Jul 1997 13:38:07 CDT." <3.0.1.32.19970717133807.006b8890@bugs.us.dell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Jul 1997 13:16:00 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > >> | Adding default route to 143.166.169.1.panic: page > fault > >> syncing disks... done > > >if you installing from local server ( eg on same network ) dont add def. > >gateway and it works fine > > Thanks, Uldis. Since I need to go through a router, I'll just wait and > try this again after the bug is fixed. I think it might be fixed in the src: ------------------------------------------------------------------------------- julian 1997/07/16 07:55:16 PDT Modified files: sys/net rtsock.c Log: Bungled cut/paste leaves kernel with page faults.. (read all about it!) Revision Changes Path 1.29 +3 -2 src/sys/net/rtsock.c ------------------------------------------------------------------------------- msmith 1997/07/17 02:21:37 PDT Modified files: sys/net rtsock.c Log: Fix Julian's fixed fix. Routing is weird. We need to accept at least one sockaddr with zero length, in order to be able to set the default route. Suggested by: Phone conversation with Julian (sleep well!) Revision Changes Path 1.30 +6 -3 src/sys/net/rtsock.c -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Thu Jul 17 13:30:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA02654 for smp-outgoing; Thu, 17 Jul 1997 13:30:20 -0700 (PDT) Received: from critter.dk.tfs.com (critter.phk.freebsd.dk [195.8.133.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA02637; Thu, 17 Jul 1997 13:30:09 -0700 (PDT) Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.6/8.8.5) with ESMTP id WAA18582; Thu, 17 Jul 1997 22:27:40 +0200 (CEST) To: Steve Passe cc: smp@freebsd.org, Peter Wemm , dyson@freebsd.org From: Poul-Henning Kamp Subject: Re: pushdown of "giant lock" In-reply-to: Your message of "Wed, 16 Jul 1997 14:25:34 MDT." <199707162025.OAA09649@Ilsa.StevesCafe.com> Date: Thu, 17 Jul 1997 22:27:40 +0200 Message-ID: <18580.869171260@critter.dk.tfs.com> Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199707162025.OAA09649@Ilsa.StevesCafe.com>, Steve Passe writes: >Hi, > >DESIGN PROPOSAL: > >The following documents a 1st draft proposal for achieving finer-grained >locking. Please comment, paying particular attention to the pseudo-code >I propose for doing it. As the guy who's done it before and in this case did it last time, let me add some other input to this topic: 1. Add a optional (possibly compile-option) circular buffer which will record the lock actions. 2. Add a permanent version of the ugly serial-port stuff, under a compile- time option of course, to record the lock actions. 3. Consider redesigning the lock implementation for the purpose, rather that try to modify the rather special lock we have now... Just my .25 DKR. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-smp Thu Jul 17 13:33:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA03025 for smp-outgoing; Thu, 17 Jul 1997 13:33:58 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA03020 for ; Thu, 17 Jul 1997 13:33:54 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA03759; Thu, 17 Jul 1997 13:31:55 -0700 From: Terry Lambert Message-Id: <199707172031.NAA03759@phaeton.artisoft.com> Subject: Re: HEADS UP: EISA cards. To: cbrown@aracnet.com Date: Thu, 17 Jul 1997 13:31:55 -0700 (MST) Cc: terry@lambert.org, smp@csn.net, smp@FreeBSD.ORG In-Reply-To: <33CDD447.25F5C25B@earthling.net> from "Chris Browning" at Jul 17, 97 00:13:59 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Why would you not want to abandon the 8254? Why not use the APIC's > > > timer? I would imagine that it was put there for this purpose when > > > running in full symetric mode. > > > > This is a HAL issue. > > > > The problem, I suspect, is that we Steve wants the kernel to run > > on non-APIC machines as well (correct me if I'm wrong), and > > the kernel expects timer services. > > And which SMP machines do not have a APIC? Maybe I should have made > myself more clear. Why not abandon the 8254 completely when in > Full symmetric mode. You have to do a bunch of stuff when > you switch modes, so why not add this to it. Because we want one kernel, not seperate SMP and UP kernels. That was the whole point of Steve's self-modifying code proposal. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Thu Jul 17 14:09:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA05025 for smp-outgoing; Thu, 17 Jul 1997 14:09:46 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA04988; Thu, 17 Jul 1997 14:09:05 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id PAA15231; Thu, 17 Jul 1997 15:08:46 -0600 (MDT) Message-Id: <199707172108.PAA15231@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Poul-Henning Kamp cc: smp@freebsd.org, Peter Wemm , dyson@freebsd.org Subject: Re: pushdown of "giant lock" In-reply-to: Your message of "Thu, 17 Jul 1997 22:27:40 +0200." <18580.869171260@critter.dk.tfs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Jul 1997 15:08:46 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > >DESIGN PROPOSAL: > > ... > As the guy who's done it before and in this case did it last time, let > me add some other input to this topic: > > 1. Add a optional (possibly compile-option) circular buffer which will > record the lock actions. somewher I have debug code for the lock that uses an XXX-kbyte buffer of INTs to record each lock transition, allowing you to record the last XXX,000 transitions if you wish. I also built a tool to scarf this buffer and present it in a nice formatted fashon. It was quite useful for getting the XXPRESS system working (first >2 CPU system to work properly). --- > 2. Add a permanent version of the ugly serial-port stuff, under a compile- > time option of course, to record the lock actions. the above tool eliminates the need for this, it sucks the buffer via /dev/kmem. --- > 3. Consider redesigning the lock implementation for the purpose, rather > that try to modify the rather special lock we have now... eventually we will diverge in many different locks/primatives for specific purposes. my proposal is just for the 1st step on that path. I envision each of the 3 classes I mentioned to develop their own unique form. I do think the modified version I outlined should serve well as a start, but I am also open to suggestions for alternate algorithms. thanx for the input, lets get some more discussion of this so I can get started with the code! -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Thu Jul 17 14:24:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA05924 for smp-outgoing; Thu, 17 Jul 1997 14:24:10 -0700 (PDT) Received: from critter.dk.tfs.com (critter.phk.freebsd.dk [195.8.133.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA05878; Thu, 17 Jul 1997 14:24:01 -0700 (PDT) Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.6/8.8.5) with ESMTP id XAA18791; Thu, 17 Jul 1997 23:21:12 +0200 (CEST) To: Steve Passe cc: Poul-Henning Kamp , smp@freebsd.org, Peter Wemm , dyson@freebsd.org From: Poul-Henning Kamp Subject: Re: pushdown of "giant lock" In-reply-to: Your message of "Thu, 17 Jul 1997 15:08:46 MDT." <199707172108.PAA15231@Ilsa.StevesCafe.com> Date: Thu, 17 Jul 1997 23:21:11 +0200 Message-ID: <18789.869174471@critter.dk.tfs.com> Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199707172108.PAA15231@Ilsa.StevesCafe.com>, Steve Passe writes: >--- >> 2. Add a permanent version of the ugly serial-port stuff, under a compile- >> time option of course, to record the lock actions. >the above tool eliminates the need for this, it sucks the buffer via /dev/kmem >. Belive me, it doesn't. To get to /dev/kmem, quite a bit of locking has to work... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-smp Fri Jul 18 04:20:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA16003 for smp-outgoing; Fri, 18 Jul 1997 04:20:07 -0700 (PDT) Received: from proxy.lkb.lv (proxy.lkb.lv [195.244.134.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA15939 for ; Fri, 18 Jul 1997 04:19:59 -0700 (PDT) Received: from cave.lkb.lv (cave.lkb.lv [195.244.134.13]) by proxy.lkb.lv (8.7.6/8.7.3) with SMTP id OAA01194 for ; Fri, 18 Jul 1997 14:19:23 +0300 (EET DST) Message-ID: <33CF516D.2A98@proxy.lkb.lv> Date: Fri, 18 Jul 1997 14:20:13 +0300 From: Uldis Mikelsons Reply-To: ulmik@proxy.lkb.lv Organization: AS Latvijas Krajbanka X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: freebsd-smp@freebsd.org Subject: SNAP-970716 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi. I finaly got SNAP-970716 installed and now getting some strange things .. if il boot in GENERIC kernel all works fine .. if im booting into SMP-GENERIC ( with uncomented SMP_TIMER_NC ) im getting strange things with network .. eg .. if im pinging from another uniprocesor 2.1.6 or nt it shows: ---------------------------------------------------------------- PING 195.244.134.17 (195.244.134.17): 56 data bytes 64 bytes from 195.244.134.17: icmp_seq=0 ttl=255 time=1824.267 ms 64 bytes from 195.244.134.17: icmp_seq=1 ttl=255 time=817.873 ms 64 bytes from 195.244.134.17: icmp_seq=2 ttl=255 time=802.643 ms 64 bytes from 195.244.134.17: icmp_seq=3 ttl=255 time=792.548 ms 64 bytes from 195.244.134.17: icmp_seq=4 ttl=255 time=782.449 ms 64 bytes from 195.244.134.17: icmp_seq=5 ttl=255 time=772.393 ms 64 bytes from 195.244.134.17: icmp_seq=6 ttl=255 time=762.113 ms ---------------------------------------------------------------- if il boot in GENERIC il get somethin like: ---------------------------------------------------------------- 64 bytes from 195.244.134.17: icmp_seq=1 ttl=255 time=0.809 ms 64 bytes from 195.244.134.17: icmp_seq=2 ttl=255 time=0.827 ms 64 bytes from 195.244.134.17: icmp_seq=3 ttl=255 time=0.815 ms ---------------------------------------------------------------- Any ideas ? SNAP 0618 had no such problems PS I have installed : vx0: <3COM 3C900 Etherlink XL PCI> rev 0x00 int a irq 9 on pci1.8.0 on that box Uldis From owner-freebsd-smp Fri Jul 18 10:04:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA03372 for smp-outgoing; Fri, 18 Jul 1997 10:04:41 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA03363 for ; Fri, 18 Jul 1997 10:04:34 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id LAA18719; Fri, 18 Jul 1997 11:03:38 -0600 (MDT) Message-Id: <199707181703.LAA18719@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: ulmik@proxy.lkb.lv cc: freebsd-smp@FreeBSD.ORG Subject: Re: SNAP-970716 In-reply-to: Your message of "Fri, 18 Jul 1997 14:20:13 +0300." <33CF516D.2A98@proxy.lkb.lv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Jul 1997 11:03:38 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > I finaly got SNAP-970716 installed and now getting some strange > things .. if il boot in GENERIC kernel all works fine .. if im booting > into SMP-GENERIC ( with uncomented SMP_TIMER_NC ) im getting strange > things with network .. eg .. if im pinging from another uniprocesor > 2.1.6 or nt it shows: > ---------------------------------------------------------------- > PING 195.244.134.17 (195.244.134.17): 56 data bytes > 64 bytes from 195.244.134.17: icmp_seq=0 ttl=255 time=1824.267 ms > 64 bytes from 195.244.134.17: icmp_seq=1 ttl=255 time=817.873 ms > 64 bytes from 195.244.134.17: icmp_seq=2 ttl=255 time=802.643 ms > 64 bytes from 195.244.134.17: icmp_seq=3 ttl=255 time=792.548 ms > 64 bytes from 195.244.134.17: icmp_seq=4 ttl=255 time=782.449 ms > 64 bytes from 195.244.134.17: icmp_seq=5 ttl=255 time=772.393 ms > 64 bytes from 195.244.134.17: icmp_seq=6 ttl=255 time=762.113 ms > ---------------------------------------------------------------- > > if il boot in GENERIC il get somethin like: > ---------------------------------------------------------------- > 64 bytes from 195.244.134.17: icmp_seq=1 ttl=255 time=0.809 ms > 64 bytes from 195.244.134.17: icmp_seq=2 ttl=255 time=0.827 ms > 64 bytes from 195.244.134.17: icmp_seq=3 ttl=255 time=0.815 ms > ---------------------------------------------------------------- > > Any ideas ? SNAP 0618 had no such problems > > PS > > I have installed : > vx0: <3COM 3C900 Etherlink XL PCI> rev 0x00 int a irq 9 on pci1.8.0 > on that box Something is clearly wrong with those times for the SMP case. But I can't recreate anything similar here. Larry is a dual P6 which uses the "SMP_TIMER_NC" code (implicitly, the mptable directs it to). Moe is a 2.2 UP system: ----------------------------------- cut -------------------------------------- 265 % uname -a FreeBSD Moe.StevesCafe.com 2.2.1-RELEASE FreeBSD 2.2.1-RELEASE #0: Tue May 13 19:58:33 MDT 1997 root@Moe.StevesCafe.com:/usr/src/sys/compile/LOCAL i386 266 % ping larry PING Larry.StevesCafe.com (205.168.38.140): 56 data bytes 64 bytes from 205.168.38.140: icmp_seq=0 ttl=255 time=0.377 ms 64 bytes from 205.168.38.140: icmp_seq=1 ttl=255 time=0.256 ms 64 bytes from 205.168.38.140: icmp_seq=2 ttl=255 time=0.257 ms 64 bytes from 205.168.38.140: icmp_seq=3 ttl=255 time=0.260 ms 64 bytes from 205.168.38.140: icmp_seq=4 ttl=255 time=0.247 ms ^C --- Larry.StevesCafe.com ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0.247/0.279/0.377 ms ----------------------------------- cut -------------------------------------- I would suggest cvsupping to get the latest sources, I was mucking with alot of the code on the 16th. If that doesn't help, try to substitute another type of network card (anything using a driver other than vx0) to see if that makes a difference. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Fri Jul 18 11:59:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA10075 for smp-outgoing; Fri, 18 Jul 1997 11:59:16 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA10069 for ; Fri, 18 Jul 1997 11:59:10 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id MAA19089; Fri, 18 Jul 1997 12:58:17 -0600 (MDT) Message-Id: <199707181858.MAA19089@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: ulmik@proxy.lkb.lv cc: smp@freebsd.org Subject: Re: SNAP-970716 In-reply-to: Your message of "Fri, 18 Jul 1997 20:49:18 +0300." <33CFAC9E.98@proxy.lkb.lv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Jul 1997 12:58:17 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > > Something is clearly wrong with those times for the SMP case. But I can't > > recreate anything similar here. Larry is a dual P6 which uses the > > "SMP_TIMER_NC" code (implicitly, the mptable directs it to). Moe is a > > 2.2 UP system: > > > > I would suggest cvsupping to get the latest sources, I was mucking with alot > > of > > the code on the 16th. > I done it already but problem remained so i got another PCI 3com but it > recreate problem .. after that i changed to ISA 3com ( ep0 ) and it > works fine ( as usualy :) .. dunno what can be problem so this means it might be ISA vs. PCI related. my tests were also PCI based, so this probably isn't the difference. Sounds more like its related to the vx0 driver under SMP. You previously stated that it worked with an earlier SNAP, was this an identical system otherwise? Specifically, were you using the 3com/vx0 driver in that working SNAP? -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Fri Jul 18 21:43:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA06255 for smp-outgoing; Fri, 18 Jul 1997 21:43:50 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA06250 for ; Fri, 18 Jul 1997 21:43:46 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id WAA20958 for ; Fri, 18 Jul 1997 22:43:14 -0600 (MDT) Message-Id: <199707190443.WAA20958@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: smp@freebsd.org Subject: HEADS UP: major timer/APIC code changes. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Jul 1997 22:43:14 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I have done major hacking to the APIC code in the areas of the 8254 timer and RTC timer. Some of these involve the EISA changes discussed earlier. Others are an attempt to bury the SMP_TIMER_NC code. The latest code will fail to build with "options SMP_TIMER_NC" set in your config file, remove & reconfig to build a new kernel. Its working well on my dual P6 which needs the timer redirect code, but paniced my dual P5 which doesn't. The panic was in modload, removing the "star" screensaver from sysconfig allowed it to boot, so I am assumming its unrelated. I am in the middle of a cvsup of the world for that machine and will report after a make world. Please send me reports for ANY new kernel builds, working or not. I need to know ASAP whether I've broken anything. This is one of those changes that may behave differently on various hardware. The affected code is identifiable by sys/i386/include/smptests.h: * $Id: smptests.h,v 1.13 1997/07/19 03:56:30 fsmp Exp $ -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Fri Jul 18 22:53:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA08801 for smp-outgoing; Fri, 18 Jul 1997 22:53:37 -0700 (PDT) Received: from shidahara1.planet.kobe-u.ac.jp (shidahara1.planet.kobe-u.ac.jp [133.30.50.200]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA08792 for ; Fri, 18 Jul 1997 22:53:30 -0700 (PDT) Received: (from todoroki@localhost) by shidahara1.planet.kobe-u.ac.jp (8.7.5+2.6Wbeta6/3.4W4-MX) id OAA15434; Sat, 19 Jul 1997 14:47:36 +0900 (JST) Date: Sat, 19 Jul 1997 14:47:36 +0900 (JST) Message-Id: <199707190547.OAA15434@shidahara1.planet.kobe-u.ac.jp> From: Yoshinori Todoroki To: freebsd-smp@freebsd.org Subject: unsubscribe Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk unsubscribe From owner-freebsd-smp Sat Jul 19 00:54:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA12924 for smp-outgoing; Sat, 19 Jul 1997 00:54:18 -0700 (PDT) Received: from twinlark.arctic.org (twinlark.arctic.org [204.62.130.91]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA12917 for ; Sat, 19 Jul 1997 00:54:16 -0700 (PDT) Received: (qmail 5527 invoked by uid 500); 19 Jul 1997 07:54:15 -0000 Date: Sat, 19 Jul 1997 00:54:15 -0700 (PDT) From: Dean Gaudet To: smp@freebsd.org Subject: Re: self modifying kernel code In-Reply-To: <199707190449.WAA21027@Ilsa.StevesCafe.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > DEC OSF/1. > > > > I can't get at my bookmarks, but there's a good txt file available on one > > of dec's many servers that describes the process by which they moved to > > fine-grained SMP in OSF/1 and it talks about the above technique. > > have you by chance had an opportunity to find the bookmarks to this? I > would appreciate it if you could forward it to me. Yep, . Dean From owner-freebsd-smp Sat Jul 19 04:37:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA21034 for smp-outgoing; Sat, 19 Jul 1997 04:37:27 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA21025 for ; Sat, 19 Jul 1997 04:37:10 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id NAA16199; Sat, 19 Jul 1997 13:30:18 +0200 (MET DST) Received: (from andreas@localhost) by klemm.gtn.com (8.8.6/8.8.6) id NAA01819; Sat, 19 Jul 1997 13:23:13 +0200 (CEST) Message-ID: <19970719132313.61472@gtn.com> Date: Sat, 19 Jul 1997 13:23:13 +0200 From: Andreas Klemm To: Steve Passe Cc: smp@FreeBSD.ORG Subject: Re: HEADS UP: major timer/APIC code changes. References: <199707190443.WAA20958@Ilsa.StevesCafe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199707190443.WAA20958@Ilsa.StevesCafe.com>; from Steve Passe on Fri, Jul 18, 1997 at 10:43:14PM -0600 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT SMP Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Jul 18, 1997 at 10:43:14PM -0600, Steve Passe wrote: > > Please send me reports for ANY new kernel builds, working or not. I need > to know ASAP whether I've broken anything. This is one of those changes > that may behave differently on various hardware. > > The affected code is identifiable by sys/i386/include/smptests.h: > > * $Id: smptests.h,v 1.13 1997/07/19 03:56:30 fsmp Exp $ -current of today && SMP kernel of today. No problem with tyan titan pro atx mainboard. -- Andreas Klemm | klemm.gtn.com - powered by Symmetric MultiProcessor FreeBSD http://www.freebsd.org/~fsmp/SMP/SMP.html http://www.freebsd.org/~fsmp/SMP/benches.html From owner-freebsd-smp Sat Jul 19 05:39:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA23924 for smp-outgoing; Sat, 19 Jul 1997 05:39:48 -0700 (PDT) Received: from ic.net (qmailr@srv1b.ic.net [152.160.72.20]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id FAA23916 for ; Sat, 19 Jul 1997 05:39:44 -0700 (PDT) Received: (qmail 3665 invoked from network); 19 Jul 1997 12:39:23 -0000 Received: from unknown (HELO lurch.rickl.org) (152.160.108.34) by unknown with SMTP; 19 Jul 1997 12:39:23 -0000 Received: from lurch.rickl.org (lurch.rickl.org [192.168.255.1]) by lurch.rickl.org (8.8.6/8.7.3) with ESMTP id IAA03618; Sat, 19 Jul 1997 08:39:36 -0400 (EDT) Date: Sat, 19 Jul 1997 08:39:36 -0400 (EDT) From: Rick Lotoczky Reply-To: Rick Lotoczky Subject: Re: HEADS UP: major timer/APIC code changes. To: smp@csn.net cc: smp@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, Jul 18, 1997 at 10:43:14PM -0600, Steve Passe wrote: > > Please send me reports for ANY new kernel builds, working or not. I need > to know ASAP whether I've broken anything. This is one of those changes > that may behave differently on various hardware. > > The affected code is identifiable by sys/i386/include/smptests.h: > > * $Id: smptests.h,v 1.13 1997/07/19 03:56:30 fsmp Exp $ -current of today and SMP kernel of today (7/19/97). the uniprocessor kernel runs fine, but the SMP kernel panics with something like "can't physically attach 8254 to PIN0" This is a SuperMicro P6DOF motherboard. Last kernel built was 7/13/97 and all seemed to work okay. How do I disable the automatic attachment of PIN0 to the 8254?? rick From owner-freebsd-smp Sat Jul 19 07:32:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA27489 for smp-outgoing; Sat, 19 Jul 1997 07:32:15 -0700 (PDT) Received: from atlantis.nconnect.net (root@atlantis.nconnect.net [207.227.50.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA27484 for ; Sat, 19 Jul 1997 07:32:13 -0700 (PDT) Received: from arabian.astrolab.org (randyd@dial175.nconnect.net [207.227.50.175]) by atlantis.nconnect.net (8.8.4/8.7.3) with ESMTP id JAA10431; Sat, 19 Jul 1997 09:19:49 -0500 (CDT) Message-ID: <33D0CFB4.836C2826@nconnect.net> Date: Sat, 19 Jul 1997 14:31:16 +0000 From: Randy DuCharme Organization: Astrolab Development X-Mailer: Mozilla 4.01b6C [en] (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: Steve Passe CC: smp@FreeBSD.ORG Subject: Re: HEADS UP: major timer/APIC code changes. X-Priority: 3 (Normal) References: <199707190443.WAA20958@Ilsa.StevesCafe.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote: > > Hi, > > I have done major hacking to the APIC code in the areas of the 8254 timer > and RTC timer. Some of these involve the EISA changes discussed earlier. > Others are an attempt to bury the SMP_TIMER_NC code. > > The latest code will fail to build with "options SMP_TIMER_NC" set > in your config file, remove & reconfig to build a new kernel. > > Its working well on my dual P6 which needs the timer redirect code, but > paniced my dual P5 which doesn't. The panic was in modload, removing the > "star" screensaver from sysconfig allowed it to boot, so I am assumming its > unrelated. I am in the middle of a cvsup of the world for that machine > and will report after a make world. > > Please send me reports for ANY new kernel builds, working or not. I need > to know ASAP whether I've broken anything. This is one of those changes > that may behave differently on various hardware. > > The affected code is identifiable by sys/i386/include/smptests.h: > > * $Id: smptests.h,v 1.13 1997/07/19 03:56:30 fsmp Exp $ > > -- > Steve Passe | powered by > smp@csn.net | Symmetric MultiProcessor FreeBSD My Tyan Tomcat II runs better than ever! ( That's not entirely true, since it *never* had problems! ) GREAT JOB PEOPLE! -- Randall D DuCharme Systems Engineer Novell, Microsoft, and UNIX Networking Support Computer Specialists BSDI Internet Success Partners 414-253-9998 414-253-9919 (fax) BSD/OS Authorized Resellers From owner-freebsd-smp Sat Jul 19 09:12:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA01154 for smp-outgoing; Sat, 19 Jul 1997 09:12:06 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA01136 for ; Sat, 19 Jul 1997 09:12:00 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id KAA26262; Sat, 19 Jul 1997 10:11:57 -0600 (MDT) Message-Id: <199707191611.KAA26262@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Rick Lotoczky cc: smp@FreeBSD.ORG Subject: Re: HEADS UP: major timer/APIC code changes. In-reply-to: Your message of "Sat, 19 Jul 1997 08:39:36 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Jul 1997 10:11:57 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > > Please send me reports for ANY new kernel builds, working or not. I need > > to know ASAP whether I've broken anything. This is one of those changes > > that may behave differently on various hardware. > > > > The affected code is identifiable by sys/i386/include/smptests.h: > > > > * $Id: smptests.h,v 1.13 1997/07/19 03:56:30 fsmp Exp $ > > -current of today and SMP kernel of today (7/19/97). > > the uniprocessor kernel runs fine, but the SMP kernel panics with > something like "can't physically attach 8254 to PIN0" > > This is a SuperMicro P6DOF motherboard. Last kernel built was 7/13/97 > and all seemed to work okay. How do I disable the automatic attachment > of PIN0 to the 8254?? well, the theory is that you don't. We need to figure out why it doesn't work. I need to see the output of "mptable -dmesg", either from a current UP kernel or the previous working SMP kernel. Also, did you remove ?SMP_TIMER_NC" from your config? And did you change smptests.h in any way? -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Sat Jul 19 09:23:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA01554 for smp-outgoing; Sat, 19 Jul 1997 09:23:57 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA01546 for ; Sat, 19 Jul 1997 09:23:50 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id KAA26327 for ; Sat, 19 Jul 1997 10:23:49 -0600 (MDT) Message-Id: <199707191623.KAA26327@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: smp@FreeBSD.ORG Subject: Re: HEADS UP: major timer/APIC code changes. In-reply-to: Your message of "Fri, 18 Jul 1997 22:43:14 MDT." <199707190443.WAA20958@Ilsa.StevesCafe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Jul 1997 10:23:49 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, >Its working well on my dual P6 which needs the timer redirect code, but >paniced my dual P5 which doesn't. The panic was in modload, removing the >"star" screensaver from sysconfig allowed it to boot, so I am assumming its >unrelated. I am in the middle of a cvsup of the world for that machine >and will report after a make world. following up, "make world" ran & completed without error using the new kernel on the dual P5. I rebuilt the kernel, restored the "star" screensaver, and rebooted. The panic was gone. Only other problems reported so far is one SuperMicro P6DOF having trouble attaching to the 8254 timer via the new code. I'm waiting for further info on that problem... Keep the reports coming! -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Sat Jul 19 11:07:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA05608 for smp-outgoing; Sat, 19 Jul 1997 11:07:54 -0700 (PDT) Received: from icicle.winternet.com (adm@icicle.winternet.com [198.174.169.13]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA05602 for ; Sat, 19 Jul 1997 11:07:42 -0700 (PDT) Received: (from adm@localhost) by icicle.winternet.com (8.7.5/8.7.5) id NAA28013; Sat, 19 Jul 1997 13:07:35 -0500 (CDT) Posted-Date: Sat, 19 Jul 1997 13:07:35 -0500 (CDT) Received: from tundra.winternet.com(198.174.169.11) by icicle.winternet.com via smap (V2.0) id xma027997; Sat, 19 Jul 97 13:07:11 -0500 Received: from localhost (mestery@localhost) by tundra.winternet.com (8.8.4/8.8.4) with SMTP id NAA22908; Sat, 19 Jul 1997 13:07:10 -0500 (CDT) X-Authentication-Warning: tundra.winternet.com: mestery owned process doing -bs Date: Sat, 19 Jul 1997 13:07:10 -0500 (CDT) From: Kyle Mestery To: Steve Passe cc: smp@FreeBSD.ORG Subject: Re: HEADS UP: major timer/APIC code changes. In-Reply-To: <199707190443.WAA20958@Ilsa.StevesCafe.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Please send me reports for ANY new kernel builds, working or not. I need > to know ASAP whether I've broken anything. This is one of those changes > that may behave differently on various hardware. > Everything is working fine here. I am running a Tyan Tomcat II with world from 7-16-97 and a kernel from today. Great job! Kyle Mestery StorageTek's Network Systems Group 7600 Boone Ave. N., Brooklyn Park, MN 55428 mesteka@anubis.network.com, mestery@winternet.com From owner-freebsd-smp Sat Jul 19 12:45:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA09034 for smp-outgoing; Sat, 19 Jul 1997 12:45:47 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA09026 for ; Sat, 19 Jul 1997 12:45:44 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id NAA26940; Sat, 19 Jul 1997 13:45:35 -0600 (MDT) Message-Id: <199707191945.NAA26940@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Rick Lotoczky cc: smp@freebsd.org Subject: Re: HEADS UP: major timer/APIC code changes. In-reply-to: Your message of "Sat, 19 Jul 1997 08:39:36 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Jul 1997 13:45:35 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > -current of today and SMP kernel of today (7/19/97). > > the uniprocessor kernel runs fine, but the SMP kernel panics with > something like "can't physically attach 8254 to PIN0" > > This is a SuperMicro P6DOF motherboard. Last kernel built was 7/13/97 > and all seemed to work okay. How do I disable the automatic attachment > of PIN0 to the 8254?? looks like I need to fall back and punt... For now, anyone seeing a panic message like: 8254 redirect via APIC pin0 impossible! should comment out i386/include/smptests.h: #define APIC_PIN0_TIMER Please don't do this unless you encounter this panic, then try it and report results. Include your mptable (-dmesg not necessary). -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Sat Jul 19 12:51:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA09358 for smp-outgoing; Sat, 19 Jul 1997 12:51:11 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA09351; Sat, 19 Jul 1997 12:51:08 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id NAA26969; Sat, 19 Jul 1997 13:51:06 -0600 (MDT) Message-Id: <199707191951.NAA26969@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: current@freebsd.org cc: smp@freebsd.org Subject: INT priorities Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Jul 1997 13:51:06 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I am currently struggling with INT code in the SMP kernel. To solve the "problem of the day", I think I need to make a leap and re-arrange the hw INTs to different APIC priority levels. For the first stab this means 'constant' INTs like the 8254, RTC and possibly keyboard. I have 7 or 8 prio levels to play with. Any suggestions where these should end up relative to the rest of the INTs? -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Sat Jul 19 21:05:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA27145 for smp-outgoing; Sat, 19 Jul 1997 21:05:55 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA27137; Sat, 19 Jul 1997 21:05:47 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id OAA23396; Sun, 20 Jul 1997 14:03:37 +1000 Date: Sun, 20 Jul 1997 14:03:37 +1000 From: Bruce Evans Message-Id: <199707200403.OAA23396@godzilla.zeta.org.au> To: current@FreeBSD.ORG, smp@csn.net Subject: Re: INT priorities Cc: smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I am currently struggling with INT code in the SMP kernel. To solve >the "problem of the day", I think I need to make a leap and re-arrange >the hw INTs to different APIC priority levels. For the first stab this >means 'constant' INTs like the 8254, RTC and possibly keyboard. I have 7 or 8 >prio levels to play with. Any suggestions where these should end up relative >to the rest of the INTs? The (non-SMP) kernel doesn't really care. It uses spl priorities for essentially everything except fast interrupt handlers. For fast interrupt handlers, the priorities only matter for interrupts that arrive concurrently. Bruce From owner-freebsd-smp Sat Jul 19 21:24:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA27877 for smp-outgoing; Sat, 19 Jul 1997 21:24:57 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA27872; Sat, 19 Jul 1997 21:24:51 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id WAA28515; Sat, 19 Jul 1997 22:24:28 -0600 (MDT) Message-Id: <199707200424.WAA28515@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Bruce Evans cc: current@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: INT priorities In-reply-to: Your message of "Sun, 20 Jul 1997 14:03:37 +1000." <199707200403.OAA23396@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Jul 1997 22:24:28 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bruce, > The (non-SMP) kernel doesn't really care. It uses spl priorities > for essentially everything except fast interrupt handlers. For fast > interrupt handlers, the priorities only matter for interrupts that > arrive concurrently. I guess I should give a little background: The APIC provides 16 different priority levels for handling INTs. Because they are handled as messages, and each level has a 2 deep fifo, ideally we want at most 2 INTs assigned per level to avoid "message bounce". Because the timer and possibly other INTs can occur on non-standard IRQ #s, we can't compile in values for them. They can only be determined at run time. Another factor is that the APIC doesn't have 1 mask register like the 8259. Instead its an individual bit in a per-source register set, ie the 24 possible INTs sources are masked across 24 different registers. So keeping a bitmask in imen, and the bitmasks in the isa dev struct is of little use. Its actually counter-productive as many operations require a search of the mask for the particular bit of interest. It would be much better to keep INTs organized as logical INT #s, and use the # as an index into various tables, registers, etc. Given the need to reorganize INTs for the above reasons we might as well put a little thought into what goes where. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD