From owner-freebsd-smp Sun Apr 15 7:45:35 2001 Delivered-To: freebsd-smp@freebsd.org Received: from alma.tavrida.net (alma.tavrida.net [193.220.126.131]) by hub.freebsd.org (Postfix) with ESMTP id 0E35537B43F for ; Sun, 15 Apr 2001 07:45:27 -0700 (PDT) (envelope-from kirill@tavrida.net) Received: from localhost (kirill@localhost) by alma.tavrida.net (8.11.2/8.11.2) with ESMTP id f3FE16a03893; Sun, 15 Apr 2001 17:01:08 +0300 Date: Sun, 15 Apr 2001 17:01:06 +0300 (EEST) From: Kirill To: "G.W.Adkins" Cc: freebsd-smp@FreeBSD.ORG Subject: Re: 4-way SMP on a Proliant 6500 under 4.2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 13 Apr 2001, G.W.Adkins wrote: > I seem to be having trouble compiling a kernel under 4.2 which will boot on a 4 way PPro 200/1024K cache machine, > it hangs early in the boot, while programming APIC #2. Is this a common thing? I've compiled dual SMP kernels with this release before, and they gave me no trouble at all... Excuse me for my English. I have the same problem. I read that I may choose in bios option APIC in Full table and all will be ok. But I don't found this option on my Compaq proliant 6000 with 4 Pentiunpro200. Where can I find upgrade for bios or may be I need to go another way. Help :( Kirill Zhizduk. > George Adkins > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Apr 15 10:45:34 2001 Delivered-To: freebsd-smp@freebsd.org Received: from alma.tavrida.net (alma.tavrida.net [193.220.126.131]) by hub.freebsd.org (Postfix) with ESMTP id 27B2937B443 for ; Sun, 15 Apr 2001 10:45:28 -0700 (PDT) (envelope-from kirill@tavrida.net) Received: from localhost (kirill@localhost) by alma.tavrida.net (8.11.2/8.11.2) with ESMTP id f3FHiqM05905; Sun, 15 Apr 2001 20:44:52 +0300 Date: Sun, 15 Apr 2001 20:44:52 +0300 (EEST) From: Kirill To: "G.W.Adkins" Cc: freebsd-smp@FreeBSD.ORG Subject: Re: 4-way SMP on a Proliant 6500 under 4.2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 15 Apr 2001, Kirill wrote: > On Fri, 13 Apr 2001, G.W.Adkins wrote: > > > I seem to be having trouble compiling a kernel under 4.2 which will boot on a 4 way PPro 200/1024K cache machine, > > it hangs early in the boot, while programming APIC #2. Is this a common thing? I've compiled dual SMP kernels with this release before, and they gave me no trouble at all... > Excuse me for my English. > I have the same problem. I read that I may choose in bios option APIC in > Full table and all will be ok. But I don't found this option on my Compaq > proliant 6000 with 4 Pentiunpro200. Where can I find upgrade for bios or > may be I need to go another way. Help :( I found the answer. I save my configuration with new compaq system configuration utility. Kirill Zhizduk. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Apr 15 15:48:50 2001 Delivered-To: freebsd-smp@freebsd.org Received: from klima.physik.uni-mainz.de (klima.Physik.Uni-Mainz.DE [134.93.180.162]) by hub.freebsd.org (Postfix) with ESMTP id 97F0F37B424; Sun, 15 Apr 2001 15:48:44 -0700 (PDT) (envelope-from ohartman@klima.physik.uni-mainz.de) Received: from klima.Physik.Uni-Mainz.DE (Linux@klima.Physik.Uni-Mainz.DE [134.93.180.162]) by klima.physik.uni-mainz.de (8.11.3/8.11.3) with ESMTP id f3FMmg239463; Mon, 16 Apr 2001 00:48:43 +0200 (CEST) (envelope-from ohartman@klima.physik.uni-mainz.de) Date: Mon, 16 Apr 2001 00:48:42 +0200 (CEST) From: "Hartmann, O." To: Cc: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear Sirs. I would like to ask for stability for several SMP systems running FreeBSD. As I heard about some rumours SMP systems under FreeBSD tend to reboot spontanously after a while and the fact, that we here reboot our systems nearly every week due a frequent cvsupdate, I feel a little bit confused and would like to hear about other experiences. Our mainservers use TYAN's Thunder 2500 mainboard with AMI MegaRAID Enterprise 1600 RAID controllers and all other servers use SCSI, not IDE. I realized, that switching APM on in the kernel of the TYAN SMP system causes the system to reboot sponanously, maybe due the fact that the BIOS (1.4) is not APM capable (why for servers?). All right, to make this short: are there any experiences about how long SMP systems under recent FreeBSD systems can run under heavy or moderate load and keep on duty without forced reboots or reboot by crash? The focus should be on ServerWorks based chipsets used with SCSI and modern SMP boards of the lower range of the pricing list, like ASUS CUV4X-D. We use TYAN (Thunder 2500, LSI869 and LSI1010 based Slot-1 boards) and ASUS CUV4X-d boards (FC-PGA) with SCSI equipment. Nearby: I heard about a roumor that ServerWorks based IDE systems tend to have problems. Please then note this: we have two ASUS A7V based system, both the same CPU, both the same memory type, both the same newest BIOS revision, but one is SCSI, one is IDE (ATA100) based. We changed SCSI and IDE (swapping the drives) and for that, this phenomenon was stuck on IDE: 'shutdown -r now' does not work on IDE, we must reboot our system by 'reboot'. -- MfG O. Hartmann ohartman@klima.physik.uni-mainz.de ---------------------------------------------------------------- IT-Administration des Institut fuer Physik der Atmosphaere (IPA) ---------------------------------------------------------------- Johannes Gutenberg Universitaet Mainz Becherweg 21 55099 Mainz Tel: +496131/3924662 (Maschinensaal) Tel: +496131/3924144 FAX: +496131/3923532 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Apr 15 15:52:47 2001 Delivered-To: freebsd-smp@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 8CAEC37B43C; Sun, 15 Apr 2001 15:52:43 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3FMqex12073; Sun, 15 Apr 2001 15:52:40 -0700 (PDT) Date: Sun, 15 Apr 2001 15:52:40 -0700 From: Alfred Perlstein To: "Hartmann, O." Cc: freebsd-smp@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: your mail Message-ID: <20010415155240.A976@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ohartman@klima.physik.uni-mainz.de on Mon, Apr 16, 2001 at 12:48:42AM +0200 X-all-your-base: are belong to us. Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Hartmann, O. [010415 15:48] wrote: > Dear Sirs. > > I would like to ask for stability for several SMP systems running > FreeBSD. > As I heard about some rumours SMP systems under FreeBSD tend to reboot > spontanously after a while and the fact, that we here reboot our systems > nearly every week due a frequent cvsupdate, I feel a little bit confused > and would like to hear about other experiences. ~ % uname -srm FreeBSD 4.2-STABLE i386 ~ % uptime 3:49PM up 64 days, 12:54, 1 user, load averages: 0.29, 0.22, 0.45 ~ % uptime 3:50PM up 64 days, 12:56, 2 users, load averages: 0.61, 0.55, 0.41 ~ % uname -srm FreeBSD 4.2-STABLE i386 ~ % uptime 3:50PM up 12 days, 18:51, 1 user, load averages: 0.04, 0.17, 0.23 ~ % uname -srm FreeBSD 4.3-RC i386 These are some pretty heavily loaded databases under my care atm. All downtime has been scheduled. I really haven't seen any stability issues in the 4.x series for pretty generic setups along with SMP. However, you shouldn't be using APM with SMP, afaik most APM BIOS are not smp safe. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Apr 15 15:59:23 2001 Delivered-To: freebsd-smp@freebsd.org Received: from cs.utep.edu (mail.cs.utep.edu [129.108.5.3]) by hub.freebsd.org (Postfix) with ESMTP id 02F5B37B43C; Sun, 15 Apr 2001 15:59:17 -0700 (PDT) (envelope-from janb@cs.utep.edu) Received: from gecko (gecko [129.108.5.51]) by cs.utep.edu (8.11.3/8.11.3) with ESMTP id f3FMx1K27176; Sun, 15 Apr 2001 16:59:01 -0600 (MDT) Date: Sun, 15 Apr 2001 16:59:02 -0600 (MDT) From: X-Sender: To: "Hartmann, O." Cc: , Subject: Re: your mail In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org AFAIK there have been some reports on this for the 5.0 version. I think they are reworking the SMP... JAn On Mon, 16 Apr 2001, Hartmann, O. wrote: > Dear Sirs. > > I would like to ask for stability for several SMP systems running > FreeBSD. > As I heard about some rumours SMP systems under FreeBSD tend to reboot > spontanously after a while and the fact, that we here reboot our systems > nearly every week due a frequent cvsupdate, I feel a little bit confused > and would like to hear about other experiences. > > Our mainservers use TYAN's Thunder 2500 mainboard with AMI MegaRAID Enterprise > 1600 RAID controllers and all other servers use SCSI, not IDE. > I realized, that switching APM on in the kernel of the TYAN SMP system > causes the system to reboot sponanously, maybe due the fact that the BIOS (1.4) > is not APM capable (why for servers?). > > All right, to make this short: are there any experiences about how long SMP > systems under recent FreeBSD systems can run under heavy or moderate load > and keep on duty without forced reboots or reboot by crash? > > The focus should be on ServerWorks based chipsets used with SCSI and modern > SMP boards of the lower range of the pricing list, like ASUS CUV4X-D. > > We use TYAN (Thunder 2500, LSI869 and LSI1010 based Slot-1 boards) and > ASUS CUV4X-d boards (FC-PGA) with SCSI equipment. > > Nearby: I heard about a roumor that ServerWorks based IDE systems tend to > have problems. > Please then note this: we have two ASUS A7V based system, both the same CPU, > both the same memory type, both the same newest BIOS revision, but one is SCSI, > one is IDE (ATA100) based. We changed SCSI and IDE (swapping the drives) and > for that, this phenomenon was stuck on IDE: 'shutdown -r now' does not work > on IDE, we must reboot our system by 'reboot'. > > -- > MfG > O. Hartmann > > ohartman@klima.physik.uni-mainz.de > ---------------------------------------------------------------- > IT-Administration des Institut fuer Physik der Atmosphaere (IPA) > ---------------------------------------------------------------- > Johannes Gutenberg Universitaet Mainz > Becherweg 21 > 55099 Mainz > > Tel: +496131/3924662 (Maschinensaal) > Tel: +496131/3924144 > FAX: +496131/3923532 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Apr 15 16: 8:22 2001 Delivered-To: freebsd-smp@freebsd.org Received: from snoop.burghcom.com (burgcom.cust.stargate.net [209.166.166.21]) by hub.freebsd.org (Postfix) with SMTP id 75F2737B43F for ; Sun, 15 Apr 2001 16:08:14 -0700 (PDT) (envelope-from jl@burghcom.com) Received: (qmail 84316 invoked from network); 15 Apr 2001 23:08:12 -0000 Received: from host111.64-31-14.bignet.net (HELO celery) (64.31.14.111) by snoop.burghcom.com with SMTP; 15 Apr 2001 23:08:12 -0000 Message-ID: <002101c0c600$55cfdf40$060aa8c0@celery> From: "JL" To: "Hartmann, O." , Cc: References: Subject: Re: Date: Sun, 15 Apr 2001 19:03:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've had 180+ day uptimes on SMP FreeBSD4.x servers. I have never had one reboot unless I type the command. Jeff Love ----- Original Message ----- From: "Hartmann, O." To: Cc: Sent: Sunday, April 15, 2001 6:48 PM > Dear Sirs. > > I would like to ask for stability for several SMP systems running > FreeBSD. > As I heard about some rumours SMP systems under FreeBSD tend to reboot > spontanously after a while and the fact, that we here reboot our systems > nearly every week due a frequent cvsupdate, I feel a little bit confused > and would like to hear about other experiences. > > Our mainservers use TYAN's Thunder 2500 mainboard with AMI MegaRAID Enterprise > 1600 RAID controllers and all other servers use SCSI, not IDE. > I realized, that switching APM on in the kernel of the TYAN SMP system > causes the system to reboot sponanously, maybe due the fact that the BIOS (1.4) > is not APM capable (why for servers?). > > All right, to make this short: are there any experiences about how long SMP > systems under recent FreeBSD systems can run under heavy or moderate load > and keep on duty without forced reboots or reboot by crash? > > The focus should be on ServerWorks based chipsets used with SCSI and modern > SMP boards of the lower range of the pricing list, like ASUS CUV4X-D. > > We use TYAN (Thunder 2500, LSI869 and LSI1010 based Slot-1 boards) and > ASUS CUV4X-d boards (FC-PGA) with SCSI equipment. > > Nearby: I heard about a roumor that ServerWorks based IDE systems tend to > have problems. > Please then note this: we have two ASUS A7V based system, both the same CPU, > both the same memory type, both the same newest BIOS revision, but one is SCSI, > one is IDE (ATA100) based. We changed SCSI and IDE (swapping the drives) and > for that, this phenomenon was stuck on IDE: 'shutdown -r now' does not work > on IDE, we must reboot our system by 'reboot'. > > -- > MfG > O. Hartmann > > ohartman@klima.physik.uni-mainz.de > ---------------------------------------------------------------- > IT-Administration des Institut fuer Physik der Atmosphaere (IPA) > ---------------------------------------------------------------- > Johannes Gutenberg Universitaet Mainz > Becherweg 21 > 55099 Mainz > > Tel: +496131/3924662 (Maschinensaal) > Tel: +496131/3924144 > FAX: +496131/3923532 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Apr 15 16:40:55 2001 Delivered-To: freebsd-smp@freebsd.org Received: from mail.webmonster.de (datasink.webmonster.de [194.162.162.209]) by hub.freebsd.org (Postfix) with SMTP id 28B9937B43F for ; Sun, 15 Apr 2001 16:40:45 -0700 (PDT) (envelope-from karsten@rohrbach.de) Received: (qmail 75678 invoked by uid 1000); 15 Apr 2001 23:41:05 -0000 Date: Mon, 16 Apr 2001 01:41:05 +0200 From: "Karsten W. Rohrbach" To: "Hartmann, O." Cc: freebsd-smp@freebsd.org, freebsd-stable@freebsd.org Subject: Re: your mail Message-ID: <20010416014105.A74927@mail.webmonster.de> Mail-Followup-To: "Karsten W. Rohrbach" , "Hartmann, O." , freebsd-smp@freebsd.org, freebsd-stable@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ohartman@klima.physik.uni-mainz.de on Mon, Apr 16, 2001 at 12:48:42AM +0200 X-Arbitrary-Number-Of-The-Day: 42 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org at my former employers site, there is a standard setup of freebsd boxen that runs the 4.x series on 200+ smp machines without a problem. the boards are either asus p2b-ds (version 1.03+) (adaptec onboard u2w scsi) or p2b-d with adaptec 2940u2w scsi controller. processors are intel pii-400 or piii-500 stepping 4 and up. the disks are ibm ddrs 9 or 18gb u2w, the memory used is pc100 specified sdram from directmemory taht comes with warranty. gfx cards are ati mach64 oem agp models that cost about EUR10. the server chassis are really cheap 4u rackmount chassis with 3 fans and (mandatory in this case) maxpower or comparable redundant 350w power supplies. ethernet is serviced by intel etherexpress 100/+ (8255[89]/fxp driver) or netgear ga620 (tigon ii/ti driver) cards. the kernels are of course custom built, the distribution was generated inhouse with make release and a custom package installation procedure. in times where serverworks based boards are still expensive or not in stock (i speak about germany) at the most resellers, the bx based boards have always had the greatest stability. together with freebsd4, this is, from my experiences of the last years, by far the most stable - though not fastest - platform we ever had in production. most of the boxes have uptimes greater than 100 days, some 3.4 based servers in the field are now running over a year (mainly backends that are not in official address space). /k Hartmann, O.(ohartman@klima.physik.uni-mainz.de)@2001.04.16 00:48:42 +0000: > Dear Sirs. > > I would like to ask for stability for several SMP systems running > FreeBSD. > As I heard about some rumours SMP systems under FreeBSD tend to reboot > spontanously after a while and the fact, that we here reboot our systems > nearly every week due a frequent cvsupdate, I feel a little bit confused > and would like to hear about other experiences. > > Our mainservers use TYAN's Thunder 2500 mainboard with AMI MegaRAID Enterprise > 1600 RAID controllers and all other servers use SCSI, not IDE. > I realized, that switching APM on in the kernel of the TYAN SMP system > causes the system to reboot sponanously, maybe due the fact that the BIOS (1.4) > is not APM capable (why for servers?). > > All right, to make this short: are there any experiences about how long SMP > systems under recent FreeBSD systems can run under heavy or moderate load > and keep on duty without forced reboots or reboot by crash? > > The focus should be on ServerWorks based chipsets used with SCSI and modern > SMP boards of the lower range of the pricing list, like ASUS CUV4X-D. > > We use TYAN (Thunder 2500, LSI869 and LSI1010 based Slot-1 boards) and > ASUS CUV4X-d boards (FC-PGA) with SCSI equipment. > > Nearby: I heard about a roumor that ServerWorks based IDE systems tend to > have problems. > Please then note this: we have two ASUS A7V based system, both the same CPU, > both the same memory type, both the same newest BIOS revision, but one is SCSI, > one is IDE (ATA100) based. We changed SCSI and IDE (swapping the drives) and > for that, this phenomenon was stuck on IDE: 'shutdown -r now' does not work > on IDE, we must reboot our system by 'reboot'. > > -- > MfG > O. Hartmann > > ohartman@klima.physik.uni-mainz.de > ---------------------------------------------------------------- > IT-Administration des Institut fuer Physik der Atmosphaere (IPA) > ---------------------------------------------------------------- > Johannes Gutenberg Universitaet Mainz > Becherweg 21 > 55099 Mainz > > Tel: +496131/3924662 (Maschinensaal) > Tel: +496131/3924144 > FAX: +496131/3923532 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message -- > Those who do not understand Unix are condemned to reinvent it, poorly. > -- Henry Spencer KR433/KR11-RIPE -- http://www.webmonster.de -- ftp://ftp.webmonster.de [Key] [KeyID---] [Created-] [Fingerprint-------------------------------------] GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Apr 16 12:41:50 2001 Delivered-To: freebsd-smp@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 24DBB37B443 for ; Mon, 16 Apr 2001 12:41:43 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.3/8.11.3) with ESMTP id f3GJfYw69230 for ; Mon, 16 Apr 2001 21:41:37 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200104161941.f3GJfYw69230@gratis.grondar.za> To: smp@freebsd.org Subject: Please review - header cleanups Date: Mon, 16 Apr 2001 21:42:37 +0200 From: Mark Murray Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi The SMPng project has a TODO list at http://people.freebsd.org/~jasone/smp/ And I grabbed what I thought would be an easy job one of moving sys/mutex.h out of other "system" headers. I have done this, and the results of my work (which compile and link for the LINT case, BTW) are available at http://people.freebsd.org/~markm/patches/sys.SYS_MUTEX.diff so please review/test! NOTES: A Helluva lot of files are affected (818, to be precise). The huge majority of them are .c files. Less that 20 are .h's. sys/lock.h is pretty closely bound to sys/mutex, so it also got the same treatment. Some parts of the kernel (mainly device drivers) have headers in other headers. I didn't undo this - in fact I cooperated with it. This ONLY does #include movement. There is no hidden payload. There is lots more work to be done. sys/lockmgr.h gives me the willies. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Apr 16 13:10:15 2001 Delivered-To: freebsd-smp@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id C6F0837B440 for ; Mon, 16 Apr 2001 13:10:01 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3GK9gG72957; Mon, 16 Apr 2001 13:09:42 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200104161941.f3GJfYw69230@gratis.grondar.za> Date: Mon, 16 Apr 2001 13:09:06 -0700 (PDT) From: John Baldwin To: Mark Murray Subject: RE: Please review - header cleanups Cc: smp@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 16-Apr-01 Mark Murray wrote: > Hi > > The SMPng project has a TODO list at > http://people.freebsd.org/~jasone/smp/ > And I grabbed what I thought would be an easy job one of > moving sys/mutex.h out of other "system" headers. > > I have done this, and the results of my work (which compile > and link for the LINT case, BTW) are available at > http://people.freebsd.org/~markm/patches/sys.SYS_MUTEX.diff > so please review/test! It will need a buildworld test as well. > NOTES: > A Helluva lot of files are affected (818, to be precise). The > huge majority of them are .c files. Less that 20 are .h's. > > sys/lock.h is pretty closely bound to sys/mutex, so it also got > the same treatment. > > Some parts of the kernel (mainly device drivers) have headers in > other headers. I didn't undo this - in fact I cooperated with it. > > This ONLY does #include movement. There is no hidden payload. > > There is lots more work to be done. sys/lockmgr.h gives me the willies. Don't bother with that one right now. Well, if you want I guess it wouldn't hurt. The goal would be to remove the sys/lockmgr.h include in sys/lock.h. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Apr 16 13:14:35 2001 Delivered-To: freebsd-smp@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 2D4A637B422; Mon, 16 Apr 2001 13:14:19 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.3/8.11.3) with ESMTP id f3GKDLw69602; Mon, 16 Apr 2001 22:14:07 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200104162014.f3GKDLw69602@gratis.grondar.za> To: John Baldwin Cc: smp@FreeBSD.org Subject: Re: Please review - header cleanups References: In-Reply-To: ; from John Baldwin "Mon, 16 Apr 2001 13:09:06 MST." Date: Mon, 16 Apr 2001 22:14:24 +0200 From: Mark Murray Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > It will need a buildworld test as well. Roger that. On its way. > > There is lots more work to be done. sys/lockmgr.h gives me the willies. > > Don't bother with that one right now. Well, if you want I guess it wouldn't > hurt. The goal would be to remove the sys/lockmgr.h include in sys/lock.h. I can do that. Lemme get the other stuff done first. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Apr 17 4:24:23 2001 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 5A34737B42C; Tue, 17 Apr 2001 04:24:18 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA01448; Tue, 17 Apr 2001 21:24:06 +1000 Date: Tue, 17 Apr 2001 21:23:09 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Baldwin Cc: Mark Murray , smp@FreeBSD.ORG Subject: RE: Please review - header cleanups In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 16 Apr 2001, John Baldwin wrote: > On 16-Apr-01 Mark Murray wrote: > > Hi > > > > The SMPng project has a TODO list at > > http://people.freebsd.org/~jasone/smp/ > > And I grabbed what I thought would be an easy job one of > > moving sys/mutex.h out of other "system" headers. This is not an easy job. It involves redesigning as many system structs as possible (without significant loss of space or time efficiency) to use `struct mtx *' instead of `struct mtx' so that not so many headers depend on and/or moving the declaration of `struct mtx' to its own header and including this header instead of the full in system headers. > > I have done this, and the results of my work (which compile > > and link for the LINT case, BTW) are available at > > http://people.freebsd.org/~markm/patches/sys.SYS_MUTEX.diff > > so please review/test! > > It will need a buildworld test as well. Parts of userland certainly depends on . The main pollution is `struct mtx' in struct proc, struct ucred and in structs in . Everything that includes will fail the buildworld test. > > NOTES: > > A Helluva lot of files are affected (818, to be precise). The > > huge majority of them are .c files. Less that 20 are .h's. Moving the includes to files that don't depend on directly just gives a larger mess. Note that in all other cases except for networking headers and vm headers, we have chosen spamming system headers with with includes that they need directly over spamming .c files with includes that they need only indirectly (due to headers not being self-sufficient). For network headers, this is for ancient historical reasons. For vm headers, it is because David Greenman was annoyed enough at the spam in the headers to move it to .c files. This is not the correct fix, but it affects more like 18 files than 818 (since fundamental system headers like and don't depend on any vm headers. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Apr 17 17:21:52 2001 Delivered-To: freebsd-smp@freebsd.org Received: from a.mx.everquick.net (a.mx.everquick.net [216.89.137.3]) by hub.freebsd.org (Postfix) with ESMTP id 3281637B42C; Tue, 17 Apr 2001 17:21:41 -0700 (PDT) (envelope-from eddy+public+spam@noc.everquick.net) Received: from localhost (eddy@localhost) by a.mx.everquick.net (8.10.2/8.10.2) with ESMTP id f3I0Las13653; Wed, 18 Apr 2001 00:21:36 GMT X-EverQuick-No-Abuse: Report any e-mail abuse to Date: Wed, 18 Apr 2001 00:21:36 +0000 (GMT) From: "E.B. Dreger" To: current@FreeBSD.ORG, smp@FreeBSD.ORG Cc: Alfred Perlstein , Matt Dillon , "Justin T. Gibbs" , Doug Barton Subject: SMP architecture (Re: FW: Filesystem gets a huge performance boost) In-Reply-To: <20010417160418.X976@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org (cross-posting to SMP and renaming in an effort to move the thread) > Date: Tue, 17 Apr 2001 16:04:18 -0700 > From: Alfred Perlstein (Repeat disclaimer: I am not a kernel hacker.) > seriously, it would be _trivial_ to: > > 1) make interrupts the only thing that could switch, or > 2) turn interrupt related locks into spinlocks that do the equivelant > of splhigh on that cpu. I just don't like the idea of preempting interrupts. > any further discussion of the underlying implementation is a waste of > time and I refuse to do it any further. No, it's not. We all want greater meaningful concurrency. (i.e., having one CPU do something productive while seven spin or fight over a mutex is pointless.) The underlying implementation is of utmost importance, because we don't want to have a 500% increase in overhead for a 5% increase in concurrency. Sort of like trying to have a 486-based router compressing T3 traffic... [ snip bit about dislike of asleep()/await() ] Okay. Let me rephrase. I meant in a manner similar to asleep()/await(), not necessarily those specific calls. I was thinking about passing a token. Imagine this for a central CPU loop: do { if (cpu_with_token == this_cpu) { whatever_needs_big_lock(); pass_token_to_next_cpu(); } standard_scheduler(); } Cooperatively share a token, as opposed to spinning/sleeping for a mutex. Interrupt handlers are inherently unsafe, because we may or may not have the token. Fine, most handlers are for I/O anyhow; pull/push data to/from a buffer, then go back to the main loop. The portion of the "interrupt handler" that requires the big lock can wait until the proper CPU has the token... it's better than spinning or blocking other CPUs, right? Am I missing something? ("What am I missing?", maybe?) Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet / EternalCommerce Division Phone: (316) 794-8922 --------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Apr 18 4:21:14 2001 Delivered-To: freebsd-smp@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 9446237B422; Wed, 18 Apr 2001 04:21:06 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.3/8.11.3) with ESMTP id f3IBKkw89864; Wed, 18 Apr 2001 13:20:50 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200104181120.f3IBKkw89864@gratis.grondar.za> To: Bruce Evans Cc: John Baldwin , smp@FreeBSD.ORG Subject: Re: Please review - header cleanups References: In-Reply-To: ; from Bruce Evans "Tue, 17 Apr 2001 21:23:09 +1000." Date: Wed, 18 Apr 2001 13:22:19 +0200 From: Mark Murray Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Said Bruce Evans : > > > The SMPng project has a TODO list at > > > http://people.freebsd.org/~jasone/smp/ > > > And I grabbed what I thought would be an easy job one of > > > moving sys/mutex.h out of other "system" headers. > > This is not an easy job. It involves redesigning as many system > structs as possible (without significant loss of space or time > efficiency) to use `struct mtx *' instead of `struct mtx' so that > not so many headers depend on and/or moving the > declaration of `struct mtx' to its own header and including this > header instead of the full in system headers. This is, as you say difficult. I took a look at the "struct mutex p_mtx" in struct proc. Its use looks scary :-(. My change is, I believe, in agreement with the first paragraph of http://people.freebsd.org/~jasone/smp/ "Project Goal" in that it achieves _something_ in the quest of de-threading the chain of #includes. Not the whole story, perhaps, but a step in that direction. > > It will need a buildworld test as well. > > Parts of userland certainly depends on . The main > pollution is `struct mtx' in struct proc, struct ucred and in structs > in . Everything that includes will fail > the buildworld test. Yeah. Not nearly as much in userland as the kernel, thank ${DEITY}. :-) > > > NOTES: > > > A Helluva lot of files are affected (818, to be precise). The > > > huge majority of them are .c files. Less that 20 are .h's. > > Moving the includes to files that don't depend on > directly just gives a larger mess. Removing unneeded #includes at a later date is a job that lends itself to automation (see some scripts by PHK in src/tools/). I'd certainly like to do this once the #includes have been untangled. > Note that in all other cases except for networking headers and vm > headers, we have chosen spamming system headers with with includes > that they need directly over spamming .c files with includes that they > need only indirectly (due to headers not being self-sufficient). For > network headers, this is for ancient historical reasons. For vm > headers, it is because David Greenman was annoyed enough at the spam > in the headers to move it to .c files. This is not the correct fix, > but it affects more like 18 files than 818 (since fundamental system > headers like and don't depend on any vm > headers. Undoing the tangled mess is a big problem. We need a transitional state to achieve it - I believe the spam is it. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Apr 18 9:14:58 2001 Delivered-To: freebsd-smp@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 01CE137B423 for ; Wed, 18 Apr 2001 09:14:56 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3IGEdG48598; Wed, 18 Apr 2001 09:14:39 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200104181120.f3IBKkw89864@gratis.grondar.za> Date: Wed, 18 Apr 2001 09:13:59 -0700 (PDT) From: John Baldwin To: Mark Murray Subject: Re: Please review - header cleanups Cc: smp@FreeBSD.org, Bruce Evans Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 18-Apr-01 Mark Murray wrote: > Said Bruce Evans : >> > > The SMPng project has a TODO list at >> > > http://people.freebsd.org/~jasone/smp/ >> > > And I grabbed what I thought would be an easy job one of >> > > moving sys/mutex.h out of other "system" headers. >> >> This is not an easy job. It involves redesigning as many system >> structs as possible (without significant loss of space or time >> efficiency) to use `struct mtx *' instead of `struct mtx' so that >> not so many headers depend on and/or moving the >> declaration of `struct mtx' to its own header and including this >> header instead of the full in system headers. > > This is, as you say difficult. I took a look at the "struct mutex > p_mtx" in struct proc. Its use looks scary :-(. > > My change is, I believe, in agreement with the first paragraph > of http://people.freebsd.org/~jasone/smp/ "Project Goal" in that > it achieves _something_ in the quest of de-threading the chain of >#includes. Not the whole story, perhaps, but a step in that direction. Well, I put that up there because I was under the impression that nested includes were to be avoided at all costs based on previous discussions with Bruce. It seems now that Bruce was more just trying to discourage the practice but not condemning those particular cases as the alternatives were worse. In the case of determing if headers should use nested #includes, etc. I defer to Bruce as he is more authoritative in this area. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Apr 18 14: 3:30 2001 Delivered-To: freebsd-smp@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id C0E6737B424 for ; Wed, 18 Apr 2001 14:03:23 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.3/8.11.3) with ESMTP id f3IL3Hw95208 for ; Wed, 18 Apr 2001 23:03:20 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200104182103.f3IL3Hw95208@gratis.grondar.za> To: smp@FreeBSD.org Subject: Re: Please review - header cleanups References: In-Reply-To: ; from John Baldwin "Wed, 18 Apr 2001 09:13:59 MST." Date: Wed, 18 Apr 2001 23:04:54 +0200 From: Mark Murray Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Said John Baldwin : > Well, I put that up there because I was under the impression that > nested includes were to be avoided at all costs based on previous > discussions with Bruce. It seems now that Bruce was more just trying > to discourage the practice but not condemning those particular cases > as the alternatives were worse. In the case of determing if headers > should use nested #includes, etc. I defer to Bruce as he is more > authoritative in this area. Abandon project? M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Apr 18 14:51: 9 2001 Delivered-To: freebsd-smp@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 3925637B641 for ; Wed, 18 Apr 2001 14:51:01 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3ILofG59968; Wed, 18 Apr 2001 14:50:41 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200104182103.f3IL3Hw95208@gratis.grondar.za> Date: Wed, 18 Apr 2001 14:50:06 -0700 (PDT) From: John Baldwin To: Mark Murray Subject: Re: Please review - header cleanups Cc: smp@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 18-Apr-01 Mark Murray wrote: > Said John Baldwin : >> Well, I put that up there because I was under the impression that >> nested includes were to be avoided at all costs based on previous >> discussions with Bruce. It seems now that Bruce was more just trying >> to discourage the practice but not condemning those particular cases >> as the alternatives were worse. In the case of determing if headers >> should use nested #includes, etc. I defer to Bruce as he is more >> authoritative in this area. > > Abandon project? Whatever Bruce says is to happen as far as header cleanups basically. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Apr 18 16:38:30 2001 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 2C65637B422; Wed, 18 Apr 2001 16:38:27 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id JAA18324; Thu, 19 Apr 2001 09:38:22 +1000 Date: Thu, 19 Apr 2001 09:37:18 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Baldwin Cc: Mark Murray , smp@FreeBSD.org Subject: Re: Please review - header cleanups In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 18 Apr 2001, John Baldwin wrote: > On 18-Apr-01 Mark Murray wrote: > > My change is, I believe, in agreement with the first paragraph > > of http://people.freebsd.org/~jasone/smp/ "Project Goal" in that > > it achieves _something_ in the quest of de-threading the chain of > >#includes. Not the whole story, perhaps, but a step in that direction. > > Well, I put that up there because I was under the impression that nested > includes were to be avoided at all costs based on previous discussions with > Bruce. It seems now that Bruce was more just trying to discourage the practice > but not condemning those particular cases as the alternatives were worse. > In the case of determing if headers should use nested #includes, etc. I defer > to Bruce as he is more authoritative in this area. It's nested includes of primary headers (ones that declare standard kernel or application interfaces) that should be avoided. Nested includes of secondary headers (ones that declare only common implementation details, e.g., and , or a carefully selected (small) set of primary interfaces, e.g., ) are OK. Including secondary headers, especially lots of little ones, still gives lots of includes, but shouldn't give nearly as many symbols if the secondary headers are properly implemented, since the secondary headers need not depend on as many other headers. Possible implementations: 1) Do the same things as are planned for `struct timespec': use a tiny header that declares just `struct mtx' and include this header as necessary. 2) Do the same things as are done for size_t: define a macro that declares `struct mtx' in a not so tiny secondary header; include this header and expand it as necessary. This is uglier than (1), but doesn't require so many headers. 3) Combination/variation of on (1)-(2): conditionally declare various structs and types in a not so tiny secondary header; include this header with only the required declarations selected. This method is used in glibc. This is not as ugly as (2), but I think it is slower than both (1) and (2). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Apr 18 17:36:37 2001 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 35CF037B422; Wed, 18 Apr 2001 17:36:35 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id KAA25311; Thu, 19 Apr 2001 10:36:33 +1000 Date: Thu, 19 Apr 2001 10:35:28 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Baldwin Cc: Mark Murray , smp@FreeBSD.ORG Subject: Re: Please review - header cleanups In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 18 Apr 2001, John Baldwin wrote: > On 18-Apr-01 Mark Murray wrote: > > Said John Baldwin : > >> Well, I put that up there because I was under the impression that > >> nested includes were to be avoided at all costs based on previous > >> discussions with Bruce. It seems now that Bruce was more just trying > >> to discourage the practice but not condemning those particular cases > >> as the alternatives were worse. In the case of determing if headers > >> should use nested #includes, etc. I defer to Bruce as he is more > >> authoritative in this area. > > > > Abandon project? > > Whatever Bruce says is to happen as far as header cleanups basically. Try the secondary include idea (see other mail). Then some of your patch will still be relevant. Possible strategy for finding the relevant parts: apply it all, then run phk's include script to find unnecessary parts. I don't want to touch more than the headers now. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Apr 18 23:34:10 2001 Delivered-To: freebsd-smp@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 5C4EC37B422 for ; Wed, 18 Apr 2001 23:34:04 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.3/8.11.3) with ESMTP id f3J6Xvw99980 for ; Thu, 19 Apr 2001 08:34:00 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200104190634.f3J6Xvw99980@gratis.grondar.za> To: smp@FreeBSD.org Subject: Re: Please review - header cleanups References: In-Reply-To: ; from Bruce Evans "Thu, 19 Apr 2001 09:37:18 +1000." Date: Thu, 19 Apr 2001 08:35:31 +0200 From: Mark Murray Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Said Bruce Evans : > Possible implementations: > 1) Do the same things as are planned for `struct timespec': use a tiny > header that declares just `struct mtx' and include this header as > necessary. Ok so this would be a header with only the "struct mtx { ... };" in it, and it would be included in all the headers that need to know the size and shape of struct mtx (including sys/mutex.h)? > 2) Do the same things as are done for size_t: define a macro that declares > `struct mtx' in a not so tiny secondary header; include this header and > expand it as necessary. This is uglier than (1), but doesn't require > so many headers. I think I prefer 1). > 3) Combination/variation of on (1)-(2): conditionally declare various > structs and types in a not so tiny secondary header; include this > header with only the required declarations selected. This method is > used in glibc. This is not as ugly as (2), but I think it is slower > than both (1) and (2). ONE header to declare _all_/lots_of the "internal" structures? Hmmm... M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Apr 19 3:36:15 2001 Delivered-To: freebsd-smp@freebsd.org Received: from web13402.mail.yahoo.com (web13402.mail.yahoo.com [216.136.175.60]) by hub.freebsd.org (Postfix) with SMTP id 1F75437B423 for ; Thu, 19 Apr 2001 03:36:13 -0700 (PDT) (envelope-from kave_ram@yahoo.com) Message-ID: <20010419103613.50885.qmail@web13402.mail.yahoo.com> Received: from [193.10.106.15] by web13402.mail.yahoo.com; Thu, 19 Apr 2001 03:36:13 PDT Date: Thu, 19 Apr 2001 03:36:13 -0700 (PDT) From: "kave p.Ram" Subject: heavy load for no reason on 4.2R To: freebsd-smp@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi ! the load of my machine raises (from currently 0.2) up to 3.0 for no reason every now and then. ( i haven't measured the intervals , but it's like something about each 15 minutes) i use 4.2 Release on my smp machine . if i boot the GENERIC , i have not the load problem. but then why load GENERIC on a smp machine ? i have even checked by 'top -S' during this heavy load. none of system or user land program/daemons are eating that much CPU time. acctually the most CPU intensive program is xmms which uses 6% of all cpu power. i would be very thankful for any suggestion/help/guide. regards, /kave __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Apr 19 10:47:59 2001 Delivered-To: freebsd-smp@freebsd.org Received: from burns.tns.utk.edu (BURNS.TNS.UTK.EDU [128.169.48.192]) by hub.freebsd.org (Postfix) with ESMTP id 4F2F537B424 for ; Thu, 19 Apr 2001 10:47:53 -0700 (PDT) (envelope-from haili@tns.utk.edu) Received: from localhost (haili@localhost) by burns.tns.utk.edu (8.11.1/8.11.1) with ESMTP id f3JHlqA02932 for ; Thu, 19 Apr 2001 13:47:52 -0400 (EDT) Date: Thu, 19 Apr 2001 13:47:52 -0400 (EDT) From: Hai Li To: Subject: SRPM8 & SRKA4 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Question, Is there a master list of board and processors that has been tested with SMPng? Specifically, we are looking for confirmation that Intel SRPM8 and SRKA4 with 700/900Mhz Xeon processors have been tested & supported. Anything we should watch out for? Thanks! Hai Li To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Apr 19 11: 0:12 2001 Delivered-To: freebsd-smp@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id B735C37B424 for ; Thu, 19 Apr 2001 11:00:09 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3JHxwG91283; Thu, 19 Apr 2001 10:59:58 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 19 Apr 2001 10:59:19 -0700 (PDT) From: John Baldwin To: Hai Li Subject: RE: SRPM8 & SRKA4 Cc: freebsd-smp@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 19-Apr-01 Hai Li wrote: > > Question, > > Is there a master list of board and processors that has been tested > with SMPng? No, but if it works with 4.x, it will work with SMPng. We haven't been changing the x86-specific SMP code. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Apr 19 14:38:37 2001 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id A012637B42C for ; Thu, 19 Apr 2001 14:38:26 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id HAA31291; Fri, 20 Apr 2001 07:38:04 +1000 Date: Fri, 20 Apr 2001 07:35:24 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Mark Murray Cc: smp@FreeBSD.ORG Subject: Re: Please review - header cleanups In-Reply-To: <200104190634.f3J6Xvw99980@gratis.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 19 Apr 2001, Mark Murray wrote: > Said Bruce Evans : > > Possible implementations: > > 1) Do the same things as are planned for `struct timespec': use a tiny > > header that declares just `struct mtx' and include this header as > > necessary. > > Ok so this would be a header with only the "struct mtx { ... };" in it, > and it would be included in all the headers that need to know the size > and shape of struct mtx (including sys/mutex.h)? --- diff -c2 mutex_types.h~ mutex_types.h *** mutex_types.h~ Fri Apr 20 06:09:31 2001 --- mutex_types.h Thu Apr 19 21:13:40 2001 *************** *** 0 **** --- 1,27 ---- + #ifndef _SYS_MUTEX_TYPES_H_ + #define _SYS_MUTEX_TYPES_H_ + + struct lock_object { + struct lock_class *lo_class; + const char *lo_name; + const char *lo_file; /* File and line of last acquire. */ + int lo_line; + u_int lo_flags; + STAILQ_ENTRY(lock_object) lo_list; /* List of all locks in system. */ + struct witness *lo_witness; + }; + + /* + * Sleep/spin mutex + */ + + struct mtx { + struct lock_object mtx_object; /* Common lock properties. */ + volatile uintptr_t mtx_lock; /* owner (and state for sleep locks) */ + volatile u_int mtx_recurse; /* number of recursive holds */ + critical_t mtx_savecrit; /* saved flags (for spin locks) */ + TAILQ_HEAD(, proc) mtx_blocked; /* threads blocked on this lock */ + LIST_ENTRY(mtx) mtx_contested; /* list of all contested locks */ + }; + + #endif /* !_SYS_MUTEX_TYPES_H_ */ Index: lock.h =================================================================== RCS file: /home/ncvs/src/sys/sys/lock.h,v retrieving revision 1.29 diff -c -2 -r1.29 lock.h *** lock.h 2001/04/06 21:37:52 1.29 --- lock.h 2001/04/19 11:02:46 *************** *** 40,43 **** --- 40,44 ---- #include + #include /* *************** *** 60,75 **** #define LC_SLEEPABLE 0x00000004 /* Sleeping allowed with this lock. */ #define LC_RECURSABLE 0x00000008 /* Locks of this type may recurse. */ - - struct witness; - - struct lock_object { - struct lock_class *lo_class; - const char *lo_name; - const char *lo_file; /* File and line of last acquire. */ - int lo_line; - u_int lo_flags; - STAILQ_ENTRY(lock_object) lo_list; /* List of all locks in system. */ - struct witness *lo_witness; - }; #define LO_CLASSFLAGS 0x0000ffff /* Class specific flags. */ --- 61,64 ---- Index: mbuf.h =================================================================== RCS file: /home/ncvs/src/sys/sys/mbuf.h,v retrieving revision 1.76 diff -c -2 -r1.76 mbuf.h *** mbuf.h 2001/04/05 03:55:27 1.76 --- mbuf.h 2001/04/19 11:03:22 *************** *** 39,46 **** #ifdef _KERNEL ! #include /* XXX */ ! #include /* XXX */ ! #include /* XXX */ ! #endif /* _KERNEL */ /* --- 39,45 ---- #ifdef _KERNEL ! #include /* XXX */ ! #include ! #endif /* Index: mutex.h =================================================================== RCS file: /home/ncvs/src/sys/sys/mutex.h,v retrieving revision 1.29 diff -c -2 -r1.29 mutex.h *** mutex.h 2001/03/28 09:03:24 1.29 --- mutex.h 2001/04/19 11:02:38 *************** *** 35,38 **** --- 35,39 ---- #ifndef LOCORE #include + #include #ifdef _KERNEL *************** *** 79,97 **** /* - * Sleep/spin mutex - */ - - struct lock_object; - - struct mtx { - struct lock_object mtx_object; /* Common lock properties. */ - volatile uintptr_t mtx_lock; /* owner (and state for sleep locks) */ - volatile u_int mtx_recurse; /* number of recursive holds */ - critical_t mtx_savecrit; /* saved flags (for spin locks) */ - TAILQ_HEAD(, proc) mtx_blocked; /* threads blocked on this lock */ - LIST_ENTRY(mtx) mtx_contested; /* list of all contested locks */ - }; - - /* * XXX: Friendly reminder to fix things in MP code that is presently being * XXX: worked on. --- 80,83 ---- Index: resourcevar.h =================================================================== RCS file: /home/ncvs/src/sys/sys/resourcevar.h,v retrieving revision 1.21 diff -c -2 -r1.21 resourcevar.h *** resourcevar.h 2001/03/28 09:17:56 1.21 --- resourcevar.h 2001/04/19 11:04:07 *************** *** 40,45 **** #include #include ! #include /* XXX */ ! #include /* XXX */ /* --- 40,46 ---- #include #include ! #ifdef _KERNEL ! #include ! #endif /* Index: sx.h =================================================================== RCS file: /home/ncvs/src/sys/sys/sx.h,v retrieving revision 1.6 diff -c -2 -r1.6 sx.h *** sx.h 2001/03/28 09:03:24 1.6 --- sx.h 2001/04/19 11:04:44 *************** *** 32,40 **** #ifndef LOCORE ! #include /* XXX */ ! #include /* XXX */ #include /* XXX */ - - struct lock_object; struct sx { --- 32,37 ---- #ifndef LOCORE ! #include #include /* XXX */ struct sx { Index: ucred.h =================================================================== RCS file: /home/ncvs/src/sys/sys/ucred.h,v retrieving revision 1.22 diff -c -2 -r1.22 ucred.h *** ucred.h 2001/03/28 09:17:56 1.22 --- ucred.h 2001/04/19 11:22:22 *************** *** 38,43 **** #define _SYS_UCRED_H_ ! #include /* XXX */ ! #include /* XXX */ /* --- 38,43 ---- #define _SYS_UCRED_H_ ! #include ! #include /* Index: user.h =================================================================== RCS file: /home/ncvs/src/sys/sys/user.h,v retrieving revision 1.36 diff -c -2 -r1.36 user.h *** user.h 2001/03/28 09:17:56 1.36 --- user.h 2001/04/19 11:05:13 *************** *** 46,51 **** #include #include ! #include /* XXX */ ! #include /* XXX */ #include #include /* XXX */ --- 46,50 ---- #include #include ! #include #include #include /* XXX */ Index: vnode.h =================================================================== RCS file: /home/ncvs/src/sys/sys/vnode.h,v retrieving revision 1.143 diff -c -2 -r1.143 vnode.h *** vnode.h 2001/04/17 04:33:33 1.143 --- vnode.h 2001/04/19 11:16:37 *************** *** 38,43 **** #define _SYS_VNODE_H_ - #include - #include #include #include --- 38,43 ---- #define _SYS_VNODE_H_ #include + #include /* XXX */ + #include #include --- This removes all the nested includes of except the one in (the inline functions there should probably not be inline). It only removes a couple of nested includes of (ones related to ). LINT compiles after adding includes of (and sometimes ) to "only" about 50 .c files. Many more probably depend on the pollution in :-(. About 1/2 of the 50 really should include . The others mostly use the PROC_* locking macros in these expand to mtx_lock(), etc. mtx_lock() is another macro so it can't just be declared. It needs the MPASS() macros from , so everything that uses the PROC_* macros needs both and . > > 2) Do the same things as are done for size_t: define a macro that declares > > `struct mtx' in a not so tiny secondary header; include this header and > > expand it as necessary. This is uglier than (1), but doesn't require > > so many headers. > > I think I prefer 1). I've put 2 structs in to test things quickly. Strictly, struct lock_object belongs in a header by itself. > > 3) Combination/variation of on (1)-(2): conditionally declare various > > structs and types in a not so tiny secondary header; include this > > header with only the required declarations selected. This method is > > used in glibc. This is not as ugly as (2), but I think it is slower > > than both (1) and (2). > > ONE header to declare _all_/lots_of the "internal" structures? Hmmm... See glibc or stddef.h under contrib/gcc. The __need_foo_t stuff selects the types that will be declared. Ugly, isn't it. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Apr 19 18:26: 7 2001 Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 0989E37B423; Thu, 19 Apr 2001 18:26:02 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f3K1PuK19503; Thu, 19 Apr 2001 18:25:56 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f3K1O2331600; Thu, 19 Apr 2001 18:24:02 -0700 (PDT) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Thu, 19 Apr 2001 18:24:01 -0700 (PDT) Organization: BSD, Inc. From: John Baldwin To: hackers@FreeBSD.org Subject: Patch to change pfind() to lock the process it returns Cc: des@FreeBSD.org, yokota@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The pfind() and zpfind() functions obtain a shared lock while accessing the PID hash table and zombie process lists so that they will have a consistent list to work with while searching for a process. However, since these functions release the lock before returning, there is a race condition whereby a process may be modified in between the time that pfind() locates it and releases its lock and the time that the process that called pfind() gets a pointer to said process. One solution is to require all callers of pfind() and zpfind() to acquire the shared allproc lock before calling the function and then to release it after taking appropriate measures with the returned process. However, this is somewhat painful for users of pfind(). Thus, I've chosen instead to change pfind() and zpfind() use the PROC_LOCK() macro to lock the process that they find before they release the allproc lock and return. Note that if pfind() and zpfind() return NULL, there is no process to lock. This patch changes pfind() and zpfind() to follow this behavior and attempts to adjust all callers of pfind() and zpfind() appropriately. I've attempted to cc appropriate maintainers as well as the list as this change does touch a few areas. Some cases of pfind() in the system can probably be eliminated or changed to use a simpler algorithm, but I'd prefer that that discussion happen later. For now, please review the patch below for correctness, etc.: http://www.FreeBSD.org/~jhb/patches/pfind.patch Thanks. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Apr 20 7: 8:18 2001 Delivered-To: freebsd-smp@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id A501737B43E for ; Fri, 20 Apr 2001 07:08:11 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.3/8.11.3) with ESMTP id f3KE83w16255 for ; Fri, 20 Apr 2001 16:08:06 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200104201408.f3KE83w16255@gratis.grondar.za> To: smp@FreeBSD.ORG Subject: Re: Please review - header cleanups References: In-Reply-To: ; from Bruce Evans "Fri, 20 Apr 2001 07:35:24 +1000." Date: Fri, 20 Apr 2001 16:09:39 +0200 From: Mark Murray Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Said Bruce Evans : > > Ok so this would be a header with only the "struct mtx { ... };" in it, > > and it would be included in all the headers that need to know the size > > and shape of struct mtx (including sys/mutex.h)? > > --- > diff -c2 mutex_types.h~ mutex_types.h [ snippage of patches ] > This removes all the nested includes of except the one in > (the inline functions there should probably not be inline). > It only removes a couple of nested includes of (ones related > to ). Nice! :-) This is an excellent base to work off. Thanks! > LINT compiles after adding includes of (and sometimes > ) to "only" about 50 .c files. Many more probably depend > on the pollution in :-(. About 1/2 of the 50 really should > include . The others mostly use the PROC_* locking macros > in these expand to mtx_lock(), etc. mtx_lock() is another > macro so it can't just be declared. It needs the MPASS() macros from > , so everything that uses the PROC_* macros needs both > and . Eeew. > > > 2) Do the same things as are done for size_t: define a macro that declares > > > `struct mtx' in a not so tiny secondary header; include this header and > > > expand it as necessary. This is uglier than (1), but doesn't require > > > so many headers. > > > > I think I prefer 1). > > I've put 2 structs in to test things quickly. Strictly, > struct lock_object belongs in a header by itself. So making a seems to be on the cards. > > ONE header to declare _all_/lots_of the "internal" structures? Hmmm... > > See glibc or stddef.h under contrib/gcc. The __need_foo_t stuff selects > the types that will be declared. Ugly, isn't it. Eeew. :-( Now I need a drink... (please don't show be code like that again without warning me!) Seriously - I think I have a pretty good idea now on how to do this. I'll come up with a new patch, and see if I can do something about the PROC_*/mutex entanglement. How bad does a sound? How bad does any <*/*_macros.h> sound (for both macros and inline code) where the header contains approximately _only_ executable stuff as opposed to "pure" declarations? M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Apr 20 15:21:42 2001 Delivered-To: freebsd-smp@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 510E537B446; Fri, 20 Apr 2001 15:21:22 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3KMLDG37903; Fri, 20 Apr 2001 15:21:14 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Fri, 20 Apr 2001 15:20:36 -0700 (PDT) From: John Baldwin To: smp@FreeBSD.org Subject: Athlon AMD SMP Runs Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Completely stock -current as of Thursday on a dual Athlon test box graciously provided by AMD with the prodding of David O`Brien. > dmesg Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-SNAP-20010419 #1: Fri Apr 20 14:59:46 PDT 2001 root@:/usr/src/sys/compile/GUINESS-smp Timecounter "i8254" frequency 1193182 Hz CPU: AMD Athlon(tm) Processor (1194.68-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x661 Stepping = 1 Features=0x183fbff AMD Features=0xc0440000<,AMIE,DSP,3DNow!> real memory = 1073741824 (1048576K bytes) avail memory = 1041207296 (1016804K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040010, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040010, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc043b000. Pentium Pro MTRR support enabled Using $PIR table, 268435454 entries at 0xc00fdef0 npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 7.3 (no driver attached) ohci0: mem 0xdc000-0xdcfff irq 11 at device 7.4 on pci0 usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: (unknown) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered ahc0: port 0x1000-0x10ff mem 0xf4001000-0xf4001fff irq 5 at device 13.0 on pci0 aic7899: Wide Channel A, SCSI Id=7, 32/255 SCBs ahc1: port 0x1400-0x14ff mem 0xf4002000-0xf4002fff irq 11 at device 13.1 on pci0 aic7899: Wide Channel B, SCSI Id=7, 32/255 SCBs pci0: at 14.0 (no driver attached) xl0: <3Com 3c980 Fast Etherlink XL> port 0x1c00-0x1c7f mem 0xf4004000-0xf400407f irq 3 at device 15.0 on pci0 xl0: command never completed! xl0: command never completed! xl0: Ethernet address: 00:e0:81:02:ac:38 miibus0: on xl0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl1: <3Com 3c980 Fast Etherlink XL> port 0x1c80-0x1cff mem 0xf4004400-0xf400447f irq 11 at device 16.0 on pci0 xl0: command never completed! xl0: command never completed! xl1: Ethernet address: 00:e0:81:02:ac:39 miibus1: on xl1 ukphy1: on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto eisa0: on motherboard eisa0: unknown card @@@0000 (0x00000000) at slot 1 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 ata1-slave: ata_command: timeout waiting for intr ata1-slave: identify failed acd0: DVD-ROM at ata1-master PIO4 Waiting 2 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s2a da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) SMP: AP CPU #1 Launched! acquring duplicate lock of same type: "allproc" 1st @ ../../kern/kern_proc.c:584 2nd @ ../../kern/kern_proc.c:143 lock order reversal 1st vnode interlock last acquired @ ../../kern/vfs_vnops.c:625 2nd 0xc03c9fc0 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:967 3rd 0xdf104e2c vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:976 # mptable =============================================================================== MPTable, version 2.0.15 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f7a40 signature: '_MP_' length: 16 bytes version: 1.4 checksum: 0x2f mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x0009f870 signature: 'PCMP' base table length: 324 version: 1.4 checksum: 0x67 OEM ID: 'TYAN ' Product ID: 'GUINNESS ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 32 local APIC address: 0xfee00000 extended table length: 344 extended table checksum: 16 ------------------------------------------------------------------------------- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 1 0x10 BSP, usable 6 6 1 0x183fbff 0 0x10 AP, usable 6 6 1 0x183fbff -- 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 PIN# ExtINT active-hi edge 2 0 2 0 INT active-hi edge 2 1 2 1 INT active-hi edge 2 0 2 2 INT active-lo level 2 3 2 3 INT active-hi edge 2 4 2 4 INT active-lo level 2 5 2 5 INT active-hi edge 2 6 2 6 INT active-hi edge 2 7 2 7 INT active-hi edge 2 8 2 8 INT active-hi edge 2 9 2 9 INT active-hi edge 2 10 2 10 INT active-lo level 2 11 2 11 INT active-hi edge 2 12 2 12 INT active-hi edge 2 13 2 13 INT active-hi edge 2 14 2 14 INT active-hi edge 2 15 2 15 INT active-hi edge 2 16 2 16 INT active-hi edge 2 17 2 17 INT active-hi edge 2 18 2 18 INT active-lo level 2 19 2 19 INT active-hi edge 2 20 2 20 INT active-lo level 2 21 2 21 INT active-hi edge 2 22 2 22 INT active-hi edge 2 23 2 23 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT active-hi edge 2 0 255 0 NMI active-hi edge 1 0:A 255 1 ------------------------------------------------------------------------------- MP Config Extended Table Entries: -- System Address Space bus ID: 0 address type: I/O address address base: 0x0 address range: 0x10000 -- System Address Space bus ID: 0 address type: memory address address base: 0x40000000 address range: 0xb4000000 -- System Address Space bus ID: 0 address type: prefetch address address base: 0xf4000000 address range: 0x8000000 -- System Address Space bus ID: 0 address type: memory address address base: 0xfc000000 address range: 0x2e00000 -- System Address Space bus ID: 0 address type: memory address address base: 0xfee01000 address range: 0x11ff000 -- System Address Space bus ID: 0 address type: memory address address base: 0xa0000 address range: 0x24000 -- System Address Space bus ID: 0 address type: memory address address base: 0xc8000 address range: 0x2000 -- System Address Space bus ID: 0 address type: memory address address base: 0xcc000 address range: 0x2000 -- System Address Space bus ID: 0 address type: memory address address base: 0xd0000 address range: 0x1000 -- System Address Space bus ID: 0 address type: memory address address base: 0xd2000 address range: 0x1000 -- System Address Space bus ID: 0 address type: memory address address base: 0xd4000 address range: 0x1000 -- System Address Space bus ID: 0 address type: memory address address base: 0xd6000 address range: 0x1000 -- System Address Space bus ID: 0 address type: memory address address base: 0xd8000 address range: 0x2000 -- System Address Space bus ID: 0 address type: memory address address base: 0xe0000 address range: 0x12000 -- System Address Space bus ID: 0 address type: memory address address base: 0xf4000 address range: 0x2000 -- System Address Space bus ID: 0 address type: memory address address base: 0xf8000 address range: 0x4000 -- Bus Heirarchy bus ID: 2 bus info: 0x01 parent bus ID: 0 -- Compatibility Bus Address bus ID: 0 address modifier: add predefined range: 0x00000000 -- Compatibility Bus Address bus ID: 0 address modifier: add predefined range: 0x00000001 =============================================================================== -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Apr 20 15:28:42 2001 Delivered-To: freebsd-smp@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id AD78137B43E; Fri, 20 Apr 2001 15:28:40 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (msmith@localhost [127.0.0.1]) by mass.dis.org (8.11.2/8.11.2) with ESMTP id f3KMVMf06515; Fri, 20 Apr 2001 15:31:22 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200104202231.f3KMVMf06515@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: John Baldwin Cc: smp@FreeBSD.org Subject: Re: Athlon AMD SMP Runs In-reply-to: Your message of "Fri, 20 Apr 2001 15:20:36 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Apr 2001 15:31:22 -0700 From: Mike Smith Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Completely stock -current as of Thursday on a dual Athlon test box graciously > provided by AMD with the prodding of David O`Brien. *blink* Well, that was easy now, wasn't it? 8) Who'd have thought they were just going to use the Intel MP spec after all that? Many thanks to David for getting the hardware to verify this! -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Apr 20 15:43: 4 2001 Delivered-To: freebsd-smp@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id CCBCE37B43C; Fri, 20 Apr 2001 15:43:02 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3KMgsG38552; Fri, 20 Apr 2001 15:42:55 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200104202231.f3KMVMf06515@mass.dis.org> Date: Fri, 20 Apr 2001 15:42:17 -0700 (PDT) From: John Baldwin To: Mike Smith Subject: Re: Athlon AMD SMP Runs Cc: smp@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 20-Apr-01 Mike Smith wrote: >> Completely stock -current as of Thursday on a dual Athlon test box >> graciously >> provided by AMD with the prodding of David O`Brien. > > *blink* Well, that was easy now, wasn't it? 8) Who'd have thought they > were just going to use the Intel MP spec after all that? I know, takes all the fun out of it. Granted, alpha SMP is turning out to be enough fun as it is. :-P > Many thanks to David for getting the hardware to verify this! Yes, very big Kudos to David. :) -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Apr 20 15:44:11 2001 Delivered-To: freebsd-smp@freebsd.org Received: from dualcpus.com (dualcpus.com [65.160.20.195]) by hub.freebsd.org (Postfix) with SMTP id 3C42937B42C for ; Fri, 20 Apr 2001 15:44:09 -0700 (PDT) (envelope-from jgowdy@home.com) Received: (qmail 28850 invoked from network); 20 Apr 2001 22:44:07 -0000 Received: from cx443070-b.vista1.sdca.home.com (HELO cx443070b) (24.0.36.170) by dualcpus.com with SMTP; 20 Apr 2001 22:44:07 -0000 Message-ID: <004001c0c9eb$d481fc80$aa240018@cx443070b> From: "Jeremiah Gowdy" To: "John Baldwin" , References: Subject: Re: Athlon AMD SMP Runs Date: Fri, 20 Apr 2001 15:47:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Completely stock -current as of Thursday on a dual Athlon test box graciously > provided by AMD with the prodding of David O`Brien. > :O To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Apr 20 22: 2:41 2001 Delivered-To: freebsd-smp@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id B95EB37B422 for ; Fri, 20 Apr 2001 22:02:38 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f3L52cM41701 for ; Fri, 20 Apr 2001 22:02:38 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 7072938FE; Fri, 20 Apr 2001 22:02:38 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Hai Li Cc: freebsd-smp@FreeBSD.ORG Subject: Re: SRPM8 & SRKA4 In-Reply-To: Date: Fri, 20 Apr 2001 22:02:38 -0700 From: Peter Wemm Message-Id: <20010421050238.7072938FE@overcee.netplex.com.au> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hai Li wrote: > > Question, > > Is there a master list of board and processors that has been tested > with SMPng? > > Specifically, we are looking for confirmation that Intel SRPM8 > and SRKA4 with 700/900Mhz Xeon processors have been tested & > supported. Anything we should watch out for? I have a prototype SRKA4 at work since before its release. It runs fine. We have Quad 550MHz Xeons in it. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Apr 20 22:56:42 2001 Delivered-To: freebsd-smp@freebsd.org Received: from one.net (ip-216-23-50-9.adsl.one.net [216.23.50.9]) by hub.freebsd.org (Postfix) with ESMTP id C796437B423; Fri, 20 Apr 2001 22:56:36 -0700 (PDT) (envelope-from cokane@one.net) Received: (from cokane@localhost) by one.net (8.11.3/8.11.3) id f3L6CMX43337; Sat, 21 Apr 2001 02:12:22 -0400 (EDT) (envelope-from cokane) Date: Sat, 21 Apr 2001 02:12:22 -0400 From: Coleman Kane To: John Baldwin Cc: Mike Smith , smp@FreeBSD.ORG Subject: Re: Athlon AMD SMP Runs Message-ID: <20010421021222.A43240@cokane.yi.org> References: <200104202231.f3KMVMf06515@mass.dis.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" X-Mailer: Mutt 1.0.1i In-Reply-To: ; from jhb@FreeBSD.ORG on Fri, Apr 20, 2001 at 03:42:17PM -0700 X-Vim: vim:tw=70:ts=4:sw=4 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Ooooooohhhhh..... Now I must clean the pool of drool that is beginning to soak through the woodwork. I can't wait for benchmarks....Good work, man! John Baldwin had the audacity to say: > On 20-Apr-01 Mike Smith wrote: > >> Completely stock -current as of Thursday on a dual Athlon test box > >> graciously > >> provided by AMD with the prodding of David O`Brien. > >=20 > > *blink* Well, that was easy now, wasn't it? 8) Who'd have thought th= ey=20 > > were just going to use the Intel MP spec after all that? >=20 > I know, takes all the fun out of it. Granted, alpha SMP is turning out t= o be > enough fun as it is. :-P >=20 > > Many thanks to David for getting the hardware to verify this! >=20 > Yes, very big Kudos to David. :) >=20 > --=20 >=20 > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message >=20 --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE64STGERViMObJ880RAWizAJ4zg/HAZjOtsyoBC421MIL1CAPYCQCgvk+x 394vCkgyZsc9uV9/2Fku8SE= =Wz0m -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Apr 21 14:47:34 2001 Delivered-To: freebsd-smp@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id A5A3337B422 for ; Sat, 21 Apr 2001 14:47:28 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.3/8.11.3) with ESMTP id f3LLlMw34206 for ; Sat, 21 Apr 2001 23:47:25 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200104212147.f3LLlMw34206@gratis.grondar.za> To: smp@freebsd.org Subject: Include file cleanup, take #2 Date: Sat, 21 Apr 2001 23:48:57 +0200 From: Mark Murray Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi BDE sent me a much better way of doing the #include cleanup, which I have built upon. This sorts out , and being included in some other "system" includes. At some stage, will need similar treatment. Also - PHK's clever script to remove unused #includes may need to be invoked after this has a chance to settle down. Please review and comment. http://prople.freebsd.org/~mark/patches/sys.SYS_MUTEX.diff.0 Thanks! (Many thanks Bruce!) M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Apr 21 18:58:40 2001 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id B02CA37B424 for ; Sat, 21 Apr 2001 18:58:36 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id LAA22058; Sun, 22 Apr 2001 11:58:18 +1000 Date: Sun, 22 Apr 2001 11:57:19 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Mark Murray Cc: smp@FreeBSD.ORG Subject: Re: Please review - header cleanups In-Reply-To: <200104201408.f3KE83w16255@gratis.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 20 Apr 2001, Mark Murray wrote: > Said Bruce Evans : > [ snippage of patches ] > > > This removes all the nested includes of except the one in > > (the inline functions there should probably not be inline). > > It only removes a couple of nested includes of (ones related > > to ). > > Nice! :-) This is an excellent base to work off. Thanks! > > > LINT compiles after adding includes of (and sometimes > > ) to "only" about 50 .c files. Many more probably depend > > on the pollution in :-(. About 1/2 of the 50 really should I tried cleaning up and didn't find a good way. There is also pollution related to curproc in . includes to get curproc defined so that the inlines in compile. Compiling these inlines only when they are used and not including shows that many places have come to depend on for its side effect of declaring curproc. > > include . The others mostly use the PROC_* locking macros > > in these expand to mtx_lock(), etc. mtx_lock() is another > > macro so it can't just be declared. It needs the MPASS() macros from > > , so everything that uses the PROC_* macros needs both > > and . > > Eeew. > > > I've put 2 structs in to test things quickly. Strictly, > > struct lock_object belongs in a header by itself. > > So making a seems to be on the cards. The mess for is much older and messier than for . Now, is sort of an extension of , but most places that include it are for its (intentional) side effect of including the old lock interface, . The old lock interface will be going away, so we shouldn't move the include of to *.c. OTOH, the entanglement of makes it difficult to include in the right places (if any). I think the next step should be to include instead of in *.h. > Seriously - I think I have a pretty good idea now on how to do > this. I'll come up with a new patch, and see if I can do something > about the PROC_*/mutex entanglement. > > How bad does a sound? > > How bad does any <*/*_macros.h> sound (for both macros and inline > code) where the header contains approximately _only_ executable > stuff as opposed to "pure" declarations? I don't see how this would help. .c files can't include *_macros.h without knowing too many implementation details, and .h files can't include them without getting lots of pollution (since lots of interfaces are needed to implement complicated inline functions or to call complicated macros like mtx_lock()) (unless *_macros.h provide alternative non-polluting interfaces for _everything_ relevant, which I think would be too much work). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message