From owner-freebsd-smp Sun Nov 5 1:42:25 2000 Delivered-To: freebsd-smp@freebsd.org Received: from peorth.iteration.net (peorth.iteration.net [208.190.180.178]) by hub.freebsd.org (Postfix) with ESMTP id 7E00437B4C5 for ; Sun, 5 Nov 2000 01:42:23 -0800 (PST) Received: by peorth.iteration.net (Postfix, from userid 1001) id EB5F75730B; Sun, 5 Nov 2000 03:42:22 -0600 (CST) Date: Sun, 5 Nov 2000 03:42:22 -0600 From: "Michael C . Wu" To: oneflower Cc: "smp @ freebsd . org" Subject: Re: about HP Lt6000r??? Message-ID: <20001105034222.A593@peorth.iteration.net> Reply-To: "Michael C . Wu" 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 oneflower@china.com on Sun, Nov 05, 2000 at 03:16:16PM +0800 X-PGP-Fingerprint: 5025 F691 F943 8128 48A8 5025 77CE 29C5 8FA1 2E20 X-PGP-Key-ID: 0x8FA12E20 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Nov 05, 2000 at 03:16:16PM +0800, oneflower scribbled: | Now I want to install FreeBSD4.1.1 release on HP Lt6000r. | It has 6 PIII Xeon 550 Mhz 512k cpu , 2GB memory. | Can FreeBSD 4.1.1 run well on Hp Lt6000r? yes, and please only send one message to the list for the same question. -- +------------------------------------------------------------------+ | keichii@peorth.iteration.net | keichii@bsdconspiracy.net | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +------------------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Nov 5 16:49: 9 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-178-14.dsl.snfc21.pacbell.net [63.202.178.14]) by hub.freebsd.org (Postfix) with ESMTP id 8036D37B4CF for ; Sun, 5 Nov 2000 16:49:07 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eA60s3F15997; Sun, 5 Nov 2000 16:54:04 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200011060054.eA60s3F15997@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Michael C . Wu" Cc: oneflower , "smp @ freebsd . org" Subject: Re: about HP Lt6000r??? In-reply-to: Your message of "Sun, 05 Nov 2000 03:42:22 CST." <20001105034222.A593@peorth.iteration.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 05 Nov 2000 16:54:03 -0800 From: Mike Smith Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Sun, Nov 05, 2000 at 03:16:16PM +0800, oneflower scribbled: > | Now I want to install FreeBSD4.1.1 release on HP Lt6000r. > | It has 6 PIII Xeon 550 Mhz 512k cpu , 2GB memory. > | Can FreeBSD 4.1.1 run well on Hp Lt6000r? > > yes, and please only send one message to the list for the same question. I've tested (briefly) on one of these systems with a stock 4.1 installation. It seemed to work just fine. -- ... 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 Sun Nov 5 17:59:47 2000 Delivered-To: freebsd-smp@freebsd.org Received: from sydney.worldwide.lemis.com (ad202.166.98.224.magix.com.sg [202.166.98.224]) by hub.freebsd.org (Postfix) with ESMTP id A3A0437B479; Sun, 5 Nov 2000 17:59:43 -0800 (PST) Received: (from grog@localhost) by sydney.worldwide.lemis.com (8.11.0/8.9.3) id eA5B3Z102817; Sun, 5 Nov 2000 19:03:35 +0800 (SGT) (envelope-from grog) Date: Sun, 5 Nov 2000 22:03:35 +1100 From: Greg Lehey To: Chuck Paterson Cc: Alfred Perlstein , Robert Watson , freebsd-smp@FreeBSD.org Subject: Re: Reference count invariants in a fine-grained threaded environment Message-ID: <20001105220335.B307@sydney.worldwide.lemis.com> References: <20001031140838.A22110@fw.wintelcom.net> <200010312220.PAA04420@berserker.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200010312220.PAA04420@berserker.bsdi.com>; from cp@bsdi.com on Tue, Oct 31, 2000 at 03:20:32PM -0700 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tuesday, 31 October 2000 at 15:20:32 -0700, Chuck Paterson wrote: (yes, I'm behind on my mail) >> >> However it's impossible to stick a mutex into a 'uint'. >> > > I agree that we really want to have atomic types. However > you are making the assumption that there is a one to one mapping > between atomic variables and mutice when they are implemented as > mutexs. OK, now you've lost me completely. I had already come to accept the use of the word "mutex" as a specific term for our locking constructs, and "mutexes" for the plural, with the possible variants "mutexs" and "mutices", but now I'm completely confused. What's the difference between the terms "mutice" and "mutexs"? Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 6 7:15:39 2000 Delivered-To: freebsd-smp@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 98B2137B479; Mon, 6 Nov 2000 07:15:36 -0800 (PST) Received: from berserker.bsdi.com (cp@localhost.bsdi.com [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id IAA55682; Mon, 6 Nov 2000 08:15:22 -0700 (MST) (envelope-from cp@berserker.bsdi.com) Message-Id: <200011061515.IAA55682@berserker.bsdi.com> To: Greg Lehey Cc: Alfred Perlstein , Robert Watson , freebsd-smp@FreeBSD.org Subject: Re: Reference count invariants in a fine-grained threaded environment In-reply-to: Your message of "Sun, 05 Nov 2000 22:03:35 +1100." <20001105220335.B307@sydney.worldwide.lemis.com> From: Chuck Paterson Date: Mon, 06 Nov 2000 08:15:22 -0700 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Grr, my mistake, should be mutex. Chuck ----- Begin Included Message ----- Date: Sun, 05 Nov 2000 22:03:35 +1100 From: Greg Lehey To: Chuck Paterson Subject: Re: Reference count invariants in a fine-grained threaded environment cc: Alfred Perlstein , Robert Watson , freebsd-smp@FreeBSD.org On Tuesday, 31 October 2000 at 15:20:32 -0700, Chuck Paterson wrote: (yes, I'm behind on my mail) >> >> However it's impossible to stick a mutex into a 'uint'. >> > > I agree that we really want to have atomic types. However > you are making the assumption that there is a one to one mapping > between atomic variables and mutice when they are implemented as > mutexs. OK, now you've lost me completely. I had already come to accept the use of the word "mutex" as a specific term for our locking constructs, and "mutexes" for the plural, with the possible variants "mutexs" and "mutices", but now I'm completely confused. What's the difference between the terms "mutice" and "mutexs"? Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers ----- End Included Message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Nov 8 11:16:53 2000 Delivered-To: freebsd-smp@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id D6F2937B4CF for ; Wed, 8 Nov 2000 11:16:49 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id eA8JDhm15133 for smp@freebsd.org; Wed, 8 Nov 2000 13:13:43 -0600 (CST) (envelope-from jlemon) Date: Wed, 8 Nov 2000 13:13:43 -0600 From: Jonathan Lemon To: smp@freebsd.org Subject: SMP safe interface queues Message-ID: <20001108131343.A72943@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've converted the ifqueue structure and the IF* macros to be SMP safe. The conversion was done with an eye towards modifying the ethernet drivers as little as possible. An explanation of the changes is below, and at the end is a design question of what to do with "misbehaved" drivers. Borrowing from the mbuf model, the existing IF_DEQUEUE, IF_ENQUEUE and IF_PREPEND macros are prepended with an underscore, and new macros are defined that obtain and release the lock around the call. E.g.: #define IF_DEQUEUE(ifq, m) do { \ IF_LOCK(ifq); \ _IF_DEQUEUE(ifq, m); \ IF_UNLOCK(ifq); \ } while (0) #define IF_PREPEND(ifq, m) do { \ IF_LOCK(ifq); \ _IF_PREPEND(ifq, m); \ IF_UNLOCK(ifq); \ } while (0) With this approach, no change at all is required for most drivers. Mutex initialization/destruction is done by if_attach/if_detach(). Most of the upper layer uses a variant of the following model: s = splnet(); if (IF_QFULL(ifq)) { IF_DROP(ifq); m_freem(m); return; } ifp->if_obytes += m->m_pkthdr.len; if (m->m_flags & M_MCAST) ifp->if_omcasts++; IF_ENQUEUE(ifq, m); if ((ifp->if_flags & IFF_OACTIVE) == 0) (*ifp->if_start)(ifp); splx(s); When converting this to use mutexes, the lock has to be dropped before calling the start routine, otherwise we can deadlock. This opens up a possible race where the driver can turn off the OACTIVE flag after a packet is queued. So to make things simpler, the entire block of code above is moved into a new "IF_HANDOFF" macro which takes care of all the details for the caller. The upper layer code simplifies to: if (! IF_HANDOFF(ifq, m, ifp)) ifp->if_oerrors++; For full details, refer to the current patchset against -current which is at: http://www.flugsvamp.com/~jlemon/fbsd/ifq_v3.patch The only warts in this particular model are certain drivers which abuse the ifqueue structure as a convenient way of retaining mbufs that the chip is transmitting. In this case, the ifq is completely private to one driver, and thus does not need to be locked, as it is not an interface queue at all. The question then is should the driver be converted to use the "mutex-free" versions of the macros above, or should it be forced to perform locking/unlocking even though it is unncessary? Some example drivers doing this are midway, de, awi, hea, lmc. Personally, I'd prefer to have these use the 'mutex-free' version of the macro to make it clear that no locks are being used, but this may be a problem for maintainability, especially considering that most (if not all) of the above drivers are from NetBSD. Feedback welcome. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Nov 8 19:17:51 2000 Delivered-To: freebsd-smp@freebsd.org Received: from inetfw.sonycsl.co.jp (inetfw.SonyCSL.CO.JP [203.137.129.4]) by hub.freebsd.org (Postfix) with ESMTP id 5F4C037B479 for ; Wed, 8 Nov 2000 19:17:48 -0800 (PST) Received: from hotaka.csl.sony.co.jp (hotaka.csl.sony.co.jp [43.27.98.57]) by inetfw.sonycsl.co.jp (8.9.3+3.2W/3.7Ws3/inetfw/2000050701/smtpfeed 1.07) with ESMTP id MAA67450; Thu, 9 Nov 2000 12:17:43 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by hotaka.csl.sony.co.jp (8.9.3+3.2W/3.7Ws3/hotaka/2000061722) with ESMTP id MAA60031; Thu, 9 Nov 2000 12:17:43 +0900 (JST) To: jlemon@flugsvamp.com Cc: smp@freebsd.org Subject: Re: SMP safe interface queues In-Reply-To: <20001108131343.A72943@prism.flugsvamp.com> References: <20001108131343.A72943@prism.flugsvamp.com> X-Mailer: Mew version 1.94.2 on Emacs 20.6 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20001109121743Q.kjc@csl.sony.co.jp> Date: Thu, 09 Nov 2000 12:17:43 +0900 From: Kenjiro Cho X-Dispatcher: imput version 20000228(IM140) Lines: 50 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jonathan Lemon wrote: > I've converted the ifqueue structure and the IF* macros to be SMP > safe. The conversion was done with an eye towards modifying the > ethernet drivers as little as possible. An explanation of the > changes is below, and at the end is a design question of what to > do with "misbehaved" drivers. I also looked into the issue of restructuring "struct ifqueue" to support packet scheduling (for ALTQ), and proposed a new design back in July. (available from http://www.csl.sony.co.jp/~kjc/software/altq-new-design.txt) From this experience, I believe we cannot avoid modifying network drivers if we are going to have per-ifq locking, For example, many ethernet drivers does the following: while ((m = ifp->if_snd.ifq_head) != NULL) { /* use m to get resources */ if (something goes wrong) return; IF_DEQUEUE(&ifp->if_snd, m); /* kick the hardware */ } There is a race where the queue could get emptied before IF_DEQUEUE() is called. It would be better to eliminate all direct references to the ifqueue internal fields from all the drivers. (IF_POLL() is used in my proposal.) At least, the drivers should check (m != NULL) after IF_DEQUEUE() even when the driver doesn't use m to get resources. > The only warts in this particular model are certain drivers which > abuse the ifqueue structure as a convenient way of retaining mbufs > that the chip is transmitting. In this case, the ifq is completely > private to one driver, and thus does not need to be locked, as it > is not an interface queue at all. The question then is should the > driver be converted to use the "mutex-free" versions of the macros > above, or should it be forced to perform locking/unlocking even though > it is unncessary? There are not only drivers but also userland programs which use struct ifqueue. It is better to rename "struct ifqueue" and the related macros for backward compatibility if they need to be changed. -Kenjiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Nov 8 21:14:24 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (Postfix) with ESMTP id E0C0137B479 for ; Wed, 8 Nov 2000 21:14:21 -0800 (PST) Received: from sr71.Singapore.Sun.COM ([129.158.72.11]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA10561 for ; Wed, 8 Nov 2000 21:14:20 -0800 (PST) Received: from acm.org (sunray [129.158.130.22]) by sr71.Singapore.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA26146 for ; Thu, 9 Nov 2000 13:14:19 +0800 (SGT) Message-ID: <3A0A32AB.E4E3A8BA@acm.org> Date: Thu, 09 Nov 2000 13:14:19 +0800 From: KT Sin X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-smp@FreeBSD.ORG Subject: via chipset and SMP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I am thinking of getting a dual coppermine board with VIA chipset. Has anyone tried running FreeBSD SMP on such boards? Is the VIA's SMP chipset any good? Thanks kt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Nov 8 23:36:14 2000 Delivered-To: freebsd-smp@freebsd.org Received: from averroe.polito.it (averroe.polito.it [130.192.4.32]) by hub.freebsd.org (Postfix) with SMTP id 91EC137B4CF for ; Wed, 8 Nov 2000 23:36:07 -0800 (PST) Received: (qmail 44207 invoked by uid 10003); 9 Nov 2000 07:35:56 -0000 Received: from demostene.polito.it (130.192.4.73) by averroe.polito.it with SMTP; 9 Nov 2000 07:35:56 -0000 Message-Id: <5.0.0.25.0.20001109083543.00a9a6a0@averroe.polito.it> X-Sender: tealdi@averroe.polito.it X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 09 Nov 2000 08:35:55 +0100 To: freebsd-hardware@freebsd.org, freebsd-smp@freebsd.org From: Paolo Tealdi Subject: Compaq DL370 [long] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As i already asked in the list, i'm trying to understand if FreeBSD support the hardware in subject. I tried to install FreeBSD on a system at my vendor's home and i found some interesting (and funny) things. The system was a single / double processor 733 MHz 128 MB memory standard COMPAQ SCSI controller (symbios) standard COMPAQ ETHERNET controller S.O. : FBSD 4.1 RELEASE 1) First, i tried to start booting directly from Fbsd CDROM. The system seemed to start, system recognized the scsi controller, but when checked the hard disk suddendly presented an error (seemed a parity error on SCSI, if i remember well )and the installation program aborted as it didn't find any disk. 2)consequently I loaded the COMPAQ SYSTEM INSTALLATION CDROM, I configured the system for an "other operating system" and i tried again to start with FreeBSD CDROM. This time all went OK. I installed the system, booted sometimes and all seemed well (also network controller was found). 3) Unfortunately the hardware the vender gave me was a single processor but i would like to buy a double processor system, so the vendor told me that he managed to receive one more and continue the test.And so we did. 4) Yesterday the vendor contacted me the processor was arrived and that i could go to do the final testing, and so i did. 5)The vendor told me that he didn't touched the original system (it is an NT guru and doesn't know ANYTHING about *nix ) and we installed the second processor. The system bootstrapped, all seemed to go well, FreeBSD seemed to recognized the second processor (the last thing i did the first time was to rebuild the kernel with SMP support, and i did it only decommenting the option SMP , option APIC and default for NPROCS ... copying GENERIC configuration) but when it tried to load the root partition again i found the original error (parity on SCSI bus). 6) This time i suggested that there was an hardware problem, so we tried to install NT4 .After one hour of installation (it's not so quick as FBSD) the NT4 server seemed to be installed OK, without any error ( :-(( ) . 7) So i reinstalled FBSD, after server setup installation with two processor and again all seemed to go OK. I recompiled the kernel (again decommenting only SMP options) and this time (for three consecutive time ) FBSD hung on boot after APIC check, one time messaging that it got an uninspected interrupt (43) (kernel config defaults are for 25 interrupts) and the others two without any message. 8) I stopped any kernel rebuilding, as i'm not so skilled with SMP installation. After this (very long) story i'd like to ask : a) All these things are normal for a double processor system ? b) Must i continue to try changing parameters in kernel configurations ? c) Can be an hardware problem ? d) It's normal for COMPAQ hardware ? e) There are significant change on 4.2 for SMP that can avoid this problems ? f) Anybody has found similar SCSI and double processor problems with Compaq or other vendors hardware ? I installed FBSD on a variety of servers ( mostly compatible) but never happened to me these things ... In any case i have never installed a double processor system. Sorry for the long story, and for my not so well english. ... Best regards, Paolo Tealdi Ing. Paolo Tealdi Library & News System Administrator Politecnico Torino Phone : +39-11-5646714 , FAX : +39-11-5646799 C.so D. degli Abruzzi, 24 - 10129 Torino - ITALY Email: tealdi@sb.polito.it To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Nov 9 7:24:38 2000 Delivered-To: freebsd-smp@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 04AA837B479 for ; Thu, 9 Nov 2000 07:24:35 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id eA9FLHf59333; Thu, 9 Nov 2000 09:21:17 -0600 (CST) (envelope-from jlemon) Date: Thu, 9 Nov 2000 09:21:17 -0600 From: Jonathan Lemon To: Kenjiro Cho Cc: jlemon@flugsvamp.com, smp@freebsd.org Subject: Re: SMP safe interface queues Message-ID: <20001109092117.C72943@prism.flugsvamp.com> References: <20001108131343.A72943@prism.flugsvamp.com> <20001109121743Q.kjc@csl.sony.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20001109121743Q.kjc@csl.sony.co.jp> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Nov 09, 2000 at 12:17:43PM +0900, Kenjiro Cho wrote: > >From this experience, I believe we cannot avoid modifying network > drivers if we are going to have per-ifq locking, > For example, many ethernet drivers does the following: > > while ((m = ifp->if_snd.ifq_head) != NULL) { > > /* use m to get resources */ > if (something goes wrong) > return; > > IF_DEQUEUE(&ifp->if_snd, m); > > /* kick the hardware */ > } > > There is a race where the queue could get emptied before IF_DEQUEUE() > is called. > It would be better to eliminate all direct references to the ifqueue > internal fields from all the drivers. (IF_POLL() is used in my > proposal.) > At least, the drivers should check (m != NULL) after IF_DEQUEUE() > even when the driver doesn't use m to get resources. I understand that this is a problem for ALTQ. However, for my purposes, making the interface queues SMP safe, it is not a problem. The queueing discipline remains FIFO at this time, and each driver instance has its own ifq. So the driver can safely peek at the front of the queue, and place packets back using PREPEND() without a problem. (assuming, of course, that the rx or tx routine of the driver is single-threaded). I agree that moving forward it probably will be beneficial to hide the internal queueing details, but it is not needed initially. > > The only warts in this particular model are certain drivers which > > abuse the ifqueue structure as a convenient way of retaining mbufs > > that the chip is transmitting. In this case, the ifq is completely > > private to one driver, and thus does not need to be locked, as it > > is not an interface queue at all. The question then is should the > > driver be converted to use the "mutex-free" versions of the macros > > above, or should it be forced to perform locking/unlocking even though > > it is unncessary? > > There are not only drivers but also userland programs which use struct > ifqueue. It is better to rename "struct ifqueue" and the related > macros for backward compatibility if they need to be changed. In this case, I would argue that the userland programs are broken. This same argument would apply to a program which decided to examine the internal layout of an mbuf; this should not prevent us from changing the structure of the mbuf to better fit the kernel's requirements. Also, any component in the kernel (or 3rd party driver) which is using an ifqueue as an actual interface queue will have to be updated to use mutexes, changing the name of the structure will not help here. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Nov 9 9:32:27 2000 Delivered-To: freebsd-smp@freebsd.org Received: from inetfw.sonycsl.co.jp (inetfw.SonyCSL.CO.JP [203.137.129.4]) by hub.freebsd.org (Postfix) with ESMTP id CD5F337B479 for ; Thu, 9 Nov 2000 09:32:25 -0800 (PST) Received: from hotaka.csl.sony.co.jp (hotaka.csl.sony.co.jp [43.27.98.57]) by inetfw.sonycsl.co.jp (8.9.3+3.2W/3.7Ws3/inetfw/2000050701/smtpfeed 1.07) with ESMTP id CAA81028; Fri, 10 Nov 2000 02:32:24 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by hotaka.csl.sony.co.jp (8.9.3+3.2W/3.7Ws3/hotaka/2000061722) with ESMTP id CAA96209; Fri, 10 Nov 2000 02:32:23 +0900 (JST) To: jlemon@flugsvamp.com Cc: smp@freebsd.org Subject: Re: SMP safe interface queues In-Reply-To: <20001109092117.C72943@prism.flugsvamp.com> References: <20001108131343.A72943@prism.flugsvamp.com> <20001109121743Q.kjc@csl.sony.co.jp> <20001109092117.C72943@prism.flugsvamp.com> X-Mailer: Mew version 1.94.2 on Emacs 20.6 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20001110023223E.kjc@csl.sony.co.jp> Date: Fri, 10 Nov 2000 02:32:23 +0900 From: Kenjiro Cho X-Dispatcher: imput version 20000228(IM140) Lines: 21 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jonathan Lemon wrote: > I understand that this is a problem for ALTQ. However, for my > purposes, making the interface queues SMP safe, it is not a problem. > The queueing discipline remains FIFO at this time, and each driver > instance has its own ifq. So the driver can safely peek at the > front of the queue, and place packets back using PREPEND() without > a problem. (assuming, of course, that the rx or tx routine of the > driver is single-threaded). > > I agree that moving forward it probably will be beneficial to hide > the internal queueing details, but it is not needed initially. How about calling IF_DRAIN() or IF_PREPEND() outside of the interrupt context? Although it might be unlikely in practice, the point is that a locking system needs the design of a self-contained operation model. (defined operations should work when the lock is properly held.) I doubt that it can be done without modifying the existing drivers. -Kenjiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Nov 9 9:58:54 2000 Delivered-To: freebsd-smp@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 4C67C37B479 for ; Thu, 9 Nov 2000 09:58:52 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id eA9HtaL64563; Thu, 9 Nov 2000 11:55:36 -0600 (CST) (envelope-from jlemon) Date: Thu, 9 Nov 2000 11:55:36 -0600 From: Jonathan Lemon To: Kenjiro Cho Cc: jlemon@flugsvamp.com, smp@freebsd.org Subject: Re: SMP safe interface queues Message-ID: <20001109115536.E72943@prism.flugsvamp.com> References: <20001108131343.A72943@prism.flugsvamp.com> <20001109121743Q.kjc@csl.sony.co.jp> <20001109092117.C72943@prism.flugsvamp.com> <20001110023223E.kjc@csl.sony.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20001110023223E.kjc@csl.sony.co.jp> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Nov 10, 2000 at 02:32:23AM +0900, Kenjiro Cho wrote: > > Jonathan Lemon wrote: > > I understand that this is a problem for ALTQ. However, for my > > purposes, making the interface queues SMP safe, it is not a problem. > > The queueing discipline remains FIFO at this time, and each driver > > instance has its own ifq. So the driver can safely peek at the > > front of the queue, and place packets back using PREPEND() without > > a problem. (assuming, of course, that the rx or tx routine of the > > driver is single-threaded). > > > > I agree that moving forward it probably will be beneficial to hide > > the internal queueing details, but it is not needed initially. > > How about calling IF_DRAIN() or IF_PREPEND() outside of the interrupt > context? > Although it might be unlikely in practice, the point is that a locking > system needs the design of a self-contained operation model. > (defined operations should work when the lock is properly held.) > I doubt that it can be done without modifying the existing drivers. I'll grant you that this may be a problem. However, at the moment I can't find any drivers that do this, so we can deal with them if they ever come up. Some drivers may call IF_DRAIN() from their ioctl() routine, but this case should already be protected from conflict by the driver lock. Recall the ifq lock only applies to queue manipulations outside of the driver itself, and I doubt that there is any manipulation done by the upper layers *currently* which is not a simple HANDOFF. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Nov 9 10: 8:11 2000 Delivered-To: freebsd-smp@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 908DA37B479; Thu, 9 Nov 2000 10:08:08 -0800 (PST) Received: from aslan (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id eA9I83a89553; Thu, 9 Nov 2000 11:08:03 -0700 (MST) (envelope-from gibbs@aslan.scsiguy.com) Message-Id: <200011091808.eA9I83a89553@aslan.scsiguy.com> To: Kenjiro Cho Cc: jasone@freebsd.org, cp@freebsd.org, dg@freebsd.org, jlemon@flugsvamp.com, smp@freebsd.org Subject: Re: SMP safe interface queues In-Reply-To: Your message of "Fri, 10 Nov 2000 02:32:23 +0900." <20001110023223E.kjc@csl.sony.co.jp> Date: Thu, 09 Nov 2000 11:08:03 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >Jonathan Lemon wrote: >> I understand that this is a problem for ALTQ. However, for my >> purposes, making the interface queues SMP safe, it is not a problem. >> The queueing discipline remains FIFO at this time, and each driver >> instance has its own ifq. So the driver can safely peek at the >> front of the queue, and place packets back using PREPEND() without >> a problem. (assuming, of course, that the rx or tx routine of the >> driver is single-threaded). >> >> I agree that moving forward it probably will be beneficial to hide >> the internal queueing details, but it is not needed initially. > >How about calling IF_DRAIN() or IF_PREPEND() outside of the interrupt >context? >Although it might be unlikely in practice, the point is that a locking >system needs the design of a self-contained operation model. >(defined operations should work when the lock is properly held.) >I doubt that it can be done without modifying the existing drivers. There was some discussion about this very issue at USENIX. I believe the outcome was that all mutex operations should be made explicit in each driver. Chuck, David, and Jason were more involved in this discussion than I was, so perhaps they can chime in here. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Nov 9 10:37:19 2000 Delivered-To: freebsd-smp@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 6438937B479; Thu, 9 Nov 2000 10:37:16 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id eA9IXwc65958; Thu, 9 Nov 2000 12:33:58 -0600 (CST) (envelope-from jlemon) Date: Thu, 9 Nov 2000 12:33:57 -0600 From: Jonathan Lemon To: "Justin T. Gibbs" Cc: Kenjiro Cho , jasone@freebsd.org, cp@freebsd.org, dg@freebsd.org, jlemon@flugsvamp.com, smp@freebsd.org Subject: Re: SMP safe interface queues Message-ID: <20001109123357.F72943@prism.flugsvamp.com> References: <20001110023223E.kjc@csl.sony.co.jp> <200011091808.eA9I83a89553@aslan.scsiguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200011091808.eA9I83a89553@aslan.scsiguy.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Nov 09, 2000 at 11:08:03AM -0700, Justin T. Gibbs wrote: > > > >Jonathan Lemon wrote: > >> I understand that this is a problem for ALTQ. However, for my > >> purposes, making the interface queues SMP safe, it is not a problem. > >> The queueing discipline remains FIFO at this time, and each driver > >> instance has its own ifq. So the driver can safely peek at the > >> front of the queue, and place packets back using PREPEND() without > >> a problem. (assuming, of course, that the rx or tx routine of the > >> driver is single-threaded). > >> > >> I agree that moving forward it probably will be beneficial to hide > >> the internal queueing details, but it is not needed initially. > > > >How about calling IF_DRAIN() or IF_PREPEND() outside of the interrupt > >context? > >Although it might be unlikely in practice, the point is that a locking > >system needs the design of a self-contained operation model. > >(defined operations should work when the lock is properly held.) > >I doubt that it can be done without modifying the existing drivers. > > There was some discussion about this very issue at USENIX. I > believe the outcome was that all mutex operations should be > made explicit in each driver. Chuck, David, and Jason were > more involved in this discussion than I was, so perhaps they > can chime in here. Hmm. I regrettably missed that, something to do with me not having a watch. :-( However, I'm not sure that this is needed; while each driver still has the option of explicitly performing a locking operation, it would seem to be a better fit for most of the locking to be implicit, since that is the way most operations are performed. The macros I have are not the same as the BSD/OS ones, so there is no confusion of the lock/unlock operation being split across different macro calls, which might be what was discussed at the meeting. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Nov 9 12: 3:24 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id 797D837B479 for ; Thu, 9 Nov 2000 12:03:21 -0800 (PST) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.3) with ESMTP id OAA01957; Thu, 9 Nov 2000 14:03:18 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Thu, 9 Nov 2000 14:03:17 -0600 (CST) From: Chris Dillon To: KT Sin Cc: freebsd-smp@FreeBSD.ORG Subject: Re: via chipset and SMP In-Reply-To: <3A0A32AB.E4E3A8BA@acm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 9 Nov 2000, KT Sin wrote: > I am thinking of getting a dual coppermine board with VIA chipset. > Has anyone tried running FreeBSD SMP on such boards? Is the VIA's > SMP chipset any good? Even their non-SMP chipsets are crap. It blew my mind that they had the ability to create an SMP chipset at all, let alone make one that might work. -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64 and PowerPC under development. 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 Nov 9 12:11:22 2000 Delivered-To: freebsd-smp@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 7635B37B479 for ; Thu, 9 Nov 2000 12:11:16 -0800 (PST) Received: (qmail 98267 invoked by uid 1142); 9 Nov 2000 20:11:15 -0000 Date: 9 Nov 2000 12:11:15 -0800 Date: Thu, 9 Nov 2000 12:10:33 -0800 From: Jason Evans To: Jonathan Lemon Cc: "Justin T. Gibbs" , smp@freebsd.org Subject: Re: SMP safe interface queues Message-ID: <20001109121033.H477@canonware.com> References: <20001110023223E.kjc@csl.sony.co.jp> <200011091808.eA9I83a89553@aslan.scsiguy.com> <20001109123357.F72943@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001109123357.F72943@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Thu, Nov 09, 2000 at 12:33:57PM -0600 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Nov 09, 2000 at 12:33:57PM -0600, Jonathan Lemon wrote: > On Thu, Nov 09, 2000 at 11:08:03AM -0700, Justin T. Gibbs wrote: > > There was some discussion about this very issue at USENIX. I > > believe the outcome was that all mutex operations should be > > made explicit in each driver. Chuck, David, and Jason were > > more involved in this discussion than I was, so perhaps they > > can chime in here. > > Hmm. I regrettably missed that, something to do with me not having > a watch. :-( However, I'm not sure that this is needed; while each > driver still has the option of explicitly performing a locking > operation, it would seem to be a better fit for most of the locking > to be implicit, since that is the way most operations are performed. > > The macros I have are not the same as the BSD/OS ones, so there is > no confusion of the lock/unlock operation being split across different > macro calls, which might be what was discussed at the meeting. Yes, the main problem we had with how the BSD/OS macros work is that the mutex locks and unlocks are split across macros. I've looked at Jonathan's patches, and while they're not exactly what we discussed at the BoF (after all, Jonathan wasn't there =) ), I think the approach taken is satisfactory. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Nov 9 13: 5: 3 2000 Delivered-To: freebsd-smp@freebsd.org Received: from front2.grolier.fr (front2.grolier.fr [194.158.96.52]) by hub.freebsd.org (Postfix) with ESMTP id 48A3B37B479; Thu, 9 Nov 2000 13:04:52 -0800 (PST) Received: from nas15-167.vlt.club-internet.fr (nas15-167.vlt.club-internet.fr [195.36.165.167]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA23855; Thu, 9 Nov 2000 22:04:30 +0100 (MET) Date: Thu, 9 Nov 2000 21:04:56 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Paolo Tealdi Cc: freebsd-hardware@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: Compaq DL370 [long] In-Reply-To: <5.0.0.25.0.20001109083543.00a9a6a0@averroe.polito.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I don't know about SMP, but could you please let me know what driver is attaching your SYMBIOS controller. Could be either `sym' or `ncr', but they differ regarding parity checking handling. OTOH, are you sure it is a SCSI parity error that is reported. When using the `sym' driver, PCI parity errors are also reported. Now, if this PCI|SCSI parity error is a real parity error, you should, IMHO, check if NT would not be working for the reason it wouldn't care about SCSI|PCI parity checking being _actually_ enabled. It may be unbelievable that COMPAQ is selling hardware that fails parity, but this should be checked, in my opinion. Btw, the latest nasty parity problem I have had to work around in `sym' driver was a PCI parity problem that occurs on some systems using SYMBIOS PCI-SCSI chips. Latest `sym' driver in -RELENG4 and -current does detect that, WARN USER ABOUT, and disable PCI parity checking by the master. G=E9rard. On Thu, 9 Nov 2000, Paolo Tealdi wrote: > As i already asked in the list, i'm trying to understand if FreeBSD suppo= rt=20 > the hardware in subject. > I tried to install FreeBSD on a system at my vendor's home and i found so= me=20 > interesting (and funny) things. >=20 > The system was a > single / double processor 733 MHz > 128 MB memory > standard COMPAQ SCSI controller (symbios) > standard COMPAQ ETHERNET controller >=20 > S.O. : FBSD 4.1 RELEASE >=20 > 1) First, i tried to start booting directly from Fbsd CDROM. > The system seemed to start, system recognized the scsi controller, but=20 > when checked the hard disk suddendly presented an error (seemed a parity= =20 > error on SCSI, if i remember well )and the installation program aborted a= s=20 > it didn't find any disk. >=20 > 2)consequently I loaded the COMPAQ SYSTEM INSTALLATION CDROM, I configure= d=20 > the system for an "other operating system" and i tried again to start wit= h=20 > FreeBSD CDROM. This time all went OK. I installed the system, booted=20 > sometimes and all seemed well (also network controller was found). >=20 > 3) Unfortunately the hardware the vender gave me was a single processor b= ut=20 > i would like to buy a double processor system, so the vendor told me that= =20 > he managed to receive one more and continue the test.And so we did. >=20 > 4) Yesterday the vendor contacted me the processor was arrived and that i= =20 > could go to do the final testing, and so i did. >=20 > 5)The vendor told me that he didn't touched the original system (it is an= =20 > NT guru and doesn't know ANYTHING about *nix ) and we installed the secon= d=20 > processor. The system bootstrapped, all seemed to go well, FreeBSD seemed= =20 > to recognized the second processor (the last thing i did the first time w= as=20 > to rebuild the kernel with SMP support, and i did it only decommenting th= e=20 > option SMP , option APIC and default for NPROCS ... copying GENERIC=20 > configuration) but when it tried to load the root partition again i found= =20 > the original error (parity on SCSI bus). >=20 > 6) This time i suggested that there was an hardware problem, so we tried = to=20 > install NT4 .After one hour of installation (it's not so quick as FBSD) t= he=20 > NT4 server seemed to be installed OK, without any error ( :-(( ) . >=20 > 7) So i reinstalled FBSD, after server setup installation with two=20 > processor and again all seemed to go OK. I recompiled the kernel (again= =20 > decommenting only SMP options) and this time (for three consecutive time = )=20 > FBSD hung on boot after APIC check, one time messaging that it got an=20 > uninspected interrupt (43) (kernel config defaults are for 25 interrupts)= =20 > and the others two without any message. >=20 > 8) I stopped any kernel rebuilding, as i'm not so skilled with SMP=20 > installation. >=20 > After this (very long) story i'd like to ask : >=20 > a) All these things are normal for a double processor system ? > b) Must i continue to try changing parameters in kernel configurations ? > c) Can be an hardware problem ? > d) It's normal for COMPAQ hardware ? > e) There are significant change on 4.2 for SMP that can avoid this proble= ms ? > f) Anybody has found similar SCSI and double processor problems with Comp= aq=20 > or other vendors hardware ? >=20 > I installed FBSD on a variety of servers ( mostly compatible) but never= =20 > happened to me these things ... In any case i have never installed a doub= le=20 > processor system. >=20 > Sorry for the long story, and for my not so well english. ... >=20 > Best regards, Paolo Tealdi >=20 >=20 >=20 > Ing. Paolo Tealdi Library & News System Administrator > Politecnico Torino Phone : +39-11-5646714 , FAX : +39-11-5646799 > C.so D. degli Abruzzi, 24 - 10129 Torino - ITALY Email: tealdi@sb.polito= =2Eit >=20 >=20 >=20 > 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 Thu Nov 9 14:44:22 2000 Delivered-To: freebsd-smp@freebsd.org Received: from juice.shallow.net (node16229.a2000.nl [24.132.98.41]) by hub.freebsd.org (Postfix) with ESMTP id 2774C37B479; Thu, 9 Nov 2000 14:44:07 -0800 (PST) Received: from localhost (joshua@localhost) by juice.shallow.net (8.9.3/8.9.3) with ESMTP id XAA74829; Thu, 9 Nov 2000 23:43:35 +0100 (CET) (envelope-from joshua@roughtrade.net) Date: Thu, 9 Nov 2000 23:43:34 +0100 (CET) From: Joshua Goodall To: =?ISO-8859-1?Q?G=E9rard_Roudier?= Cc: adrian@freebsd.org, Paolo Tealdi , freebsd-hardware@freebsd.org, freebsd-smp@freebsd.org Subject: Re: Compaq DL370 [long] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org We had some trouble with frisbee on DL380's which Adrian Chadd sorted out for us... although not, I believe, working alone, so I'll let him reply to this . J On Thu, 9 Nov 2000, [ISO-8859-1] Gérard Roudier wrote: > > > I don't know about SMP, but could you please let me know what driver is > attaching your SYMBIOS controller. Could be either `sym' or `ncr', but > they differ regarding parity checking handling. > > OTOH, are you sure it is a SCSI parity error that is reported. When using > the `sym' driver, PCI parity errors are also reported. > > Now, if this PCI|SCSI parity error is a real parity error, you should, > IMHO, check if NT would not be working for the reason it wouldn't care > about SCSI|PCI parity checking being _actually_ enabled. It may be > unbelievable that COMPAQ is selling hardware that fails parity, but this > should be checked, in my opinion. > > Btw, the latest nasty parity problem I have had to work around in `sym' > driver was a PCI parity problem that occurs on some systems using SYMBIOS > PCI-SCSI chips. Latest `sym' driver in -RELENG4 and -current does detect > that, WARN USER ABOUT, and disable PCI parity checking by the master. > > Gérard. > > On Thu, 9 Nov 2000, Paolo Tealdi wrote: > > > As i already asked in the list, i'm trying to understand if FreeBSD support > > the hardware in subject. > > I tried to install FreeBSD on a system at my vendor's home and i found some > > interesting (and funny) things. > > > > The system was a > > single / double processor 733 MHz > > 128 MB memory > > standard COMPAQ SCSI controller (symbios) > > standard COMPAQ ETHERNET controller > > > > S.O. : FBSD 4.1 RELEASE > > > > 1) First, i tried to start booting directly from Fbsd CDROM. > > The system seemed to start, system recognized the scsi controller, but > > when checked the hard disk suddendly presented an error (seemed a parity > > error on SCSI, if i remember well )and the installation program aborted as > > it didn't find any disk. > > > > 2)consequently I loaded the COMPAQ SYSTEM INSTALLATION CDROM, I configured > > the system for an "other operating system" and i tried again to start with > > FreeBSD CDROM. This time all went OK. I installed the system, booted > > sometimes and all seemed well (also network controller was found). > > > > 3) Unfortunately the hardware the vender gave me was a single processor but > > i would like to buy a double processor system, so the vendor told me that > > he managed to receive one more and continue the test.And so we did. > > > > 4) Yesterday the vendor contacted me the processor was arrived and that i > > could go to do the final testing, and so i did. > > > > 5)The vendor told me that he didn't touched the original system (it is an > > NT guru and doesn't know ANYTHING about *nix ) and we installed the second > > processor. The system bootstrapped, all seemed to go well, FreeBSD seemed > > to recognized the second processor (the last thing i did the first time was > > to rebuild the kernel with SMP support, and i did it only decommenting the > > option SMP , option APIC and default for NPROCS ... copying GENERIC > > configuration) but when it tried to load the root partition again i found > > the original error (parity on SCSI bus). > > > > 6) This time i suggested that there was an hardware problem, so we tried to > > install NT4 .After one hour of installation (it's not so quick as FBSD) the > > NT4 server seemed to be installed OK, without any error ( :-(( ) . > > > > 7) So i reinstalled FBSD, after server setup installation with two > > processor and again all seemed to go OK. I recompiled the kernel (again > > decommenting only SMP options) and this time (for three consecutive time ) > > FBSD hung on boot after APIC check, one time messaging that it got an > > uninspected interrupt (43) (kernel config defaults are for 25 interrupts) > > and the others two without any message. > > > > 8) I stopped any kernel rebuilding, as i'm not so skilled with SMP > > installation. > > > > After this (very long) story i'd like to ask : > > > > a) All these things are normal for a double processor system ? > > b) Must i continue to try changing parameters in kernel configurations ? > > c) Can be an hardware problem ? > > d) It's normal for COMPAQ hardware ? > > e) There are significant change on 4.2 for SMP that can avoid this problems ? > > f) Anybody has found similar SCSI and double processor problems with Compaq > > or other vendors hardware ? > > > > I installed FBSD on a variety of servers ( mostly compatible) but never > > happened to me these things ... In any case i have never installed a double > > processor system. > > > > Sorry for the long story, and for my not so well english. ... > > > > Best regards, Paolo Tealdi > > > > > > > > Ing. Paolo Tealdi Library & News System Administrator > > Politecnico Torino Phone : +39-11-5646714 , FAX : +39-11-5646799 > > C.so D. degli Abruzzi, 24 - 10129 Torino - ITALY Email: tealdi@sb.polito.it > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-smp" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hardware" 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 Thu Nov 9 17:13:20 2000 Delivered-To: freebsd-smp@freebsd.org Received: from femail2.sdc1.sfba.home.com (femail2.sdc1.sfba.home.com [24.0.95.82]) by hub.freebsd.org (Postfix) with ESMTP id 7449437B479 for ; Thu, 9 Nov 2000 17:13:18 -0800 (PST) Received: from cx443070b ([24.0.36.170]) by femail2.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001110011306.ZKTC19780.femail2.sdc1.sfba.home.com@cx443070b>; Thu, 9 Nov 2000 17:13:06 -0800 Message-ID: <006301c04ab3$b70121c0$aa240018@cx443070b> From: "Jeremiah Gowdy" To: "Chris Dillon" , "KT Sin" Cc: References: Subject: Re: via chipset and SMP Date: Thu, 9 Nov 2000 17:15:29 -0800 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 am thinking of getting a dual coppermine board with VIA chipset. > > Has anyone tried running FreeBSD SMP on such boards? Is the VIA's > > SMP chipset any good? > > Even their non-SMP chipsets are crap. It blew my mind that they had > the ability to create an SMP chipset at all, let alone make one that > might work. My counter opinion would simply be, I have ran FreeBSD on my Tyan Tiger 133A motherboard which uses the Via Apollo Pro 133A chipset with Dual Pentium III 450s. They aren't the best performing boards out there, however, they are pretty stable in my experience, both Athlon and PIII. Add that to the fact that they support the latest tech like AGP4X and UDMA100. Their chipsets do lack a little performance, but not so much as to make me wish I had another board. Dual Pentium IIIs are still Dual Pentium IIIs. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Nov 10 2:46:25 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mailhost.tue.nl (mailhost.tue.nl [131.155.2.5]) by hub.freebsd.org (Postfix) with ESMTP id 5CD9137B4C5 for ; Fri, 10 Nov 2000 02:46:22 -0800 (PST) Received: from wop5.wop.wtb.tue.nl (wop5.wop.wtb.tue.nl [131.155.56.55]) by mailhost.tue.nl (8.11.0/8.11.0) with ESMTP id eAAAkJN15666; Fri, 10 Nov 2000 11:46:20 +0100 (MET) Received: from tue.nl (wop24.wop.wtb.tue.nl [131.155.56.116]) by wop5.wop.wtb.tue.nl (8.11.1/8.11.1) with ESMTP id eAAAkJY13742; Fri, 10 Nov 2000 11:46:19 +0100 (MET) Message-ID: <3A0BD201.70E5D8C4@tue.nl> Date: Fri, 10 Nov 2000 11:46:25 +0100 From: Koen Schreel Organization: Eindhoven University of Technology X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-BETA i386) X-Accept-Language: en MIME-Version: 1.0 To: KT Sin Cc: freebsd-smp@FreeBSD.ORG Subject: Re: via chipset and SMP References: <3A0A32AB.E4E3A8BA@acm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org KT Sin wrote: > I am thinking of getting a dual coppermine board with VIA chipset. > Has anyone tried running FreeBSD SMP on such boards? Is the VIA's > SMP chipset any good? I'm running an MSI 694D-pro now pretty stable with two PIII-800's. Had some problems with memory initially, but now it runs OK for some time. Not the highest performing chipset, but it has a reasonable price/performance ratio. Koen. -- Dr. K.R.A.M. Schreel | Eindhoven University of Technology | Faculty of Mechanical Engineering Combustion Research | Section Energy Technology | Tel: +31-40-2472117 Fax: +31-40-2433445 K.R.A.M.Schreel@tue.nl | P.O. Box 513 5600 MB Eindhoven, The Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Nov 10 9: 7:30 2000 Delivered-To: freebsd-smp@freebsd.org Received: from roaming.cacheboy.net (roaming.cacheboy.net [203.56.168.69]) by hub.freebsd.org (Postfix) with ESMTP id 52D8637B4C5; Fri, 10 Nov 2000 09:07:25 -0800 (PST) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.0/8.11.0) id eAAH74U30105; Fri, 10 Nov 2000 18:07:04 +0100 (CET) (envelope-from adrian) Date: Fri, 10 Nov 2000 18:07:04 +0100 From: Adrian Chadd To: Joshua Goodall Cc: =?iso-8859-1?Q?G=E9rard_Roudier?= , Paolo Tealdi , freebsd-hardware@freebsd.org, freebsd-smp@freebsd.org Subject: Re: Compaq DL370 [long] Message-ID: <20001110180703.A30058@roaming.cacheboy.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from joshua@roughtrade.net on Thu, Nov 09, 2000 at 11:43:34PM +0100 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Nov 09, 2000, Joshua Goodall wrote: > > We had some trouble with frisbee on DL380's which Adrian Chadd sorted out > for us... although not, I believe, working alone, so I'll let him reply to > this . > > J I suggest you try a single CPU in the DL380. I installed 4.2-RC1 on a DL380 (euro, I believe the euro and US versions are different!) without any trouble. It has an "ida" raid controller, not a straight symbios card. I haven't tried it in SMP yet, but I've heard bad things about SMP on the DL series (and the lack of extra CPU/rectifier might prevent me trying :) I'll email you a dmesg on Monday if you'd like. (thanks for dobbing me in josh :) adrian -- Adrian Chadd "Programming is like sex: One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Nov 10 11:29:20 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id 0380E37B4FE for ; Fri, 10 Nov 2000 11:29:10 -0800 (PST) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.3) with ESMTP id NAA18016; Fri, 10 Nov 2000 13:28:47 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Fri, 10 Nov 2000 13:28:47 -0600 (CST) From: Chris Dillon To: Jeremiah Gowdy Cc: KT Sin , freebsd-smp@FreeBSD.ORG Subject: Re: via chipset and SMP In-Reply-To: <006301c04ab3$b70121c0$aa240018@cx443070b> 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, 9 Nov 2000, Jeremiah Gowdy wrote: > > > I am thinking of getting a dual coppermine board with VIA chipset. > > > Has anyone tried running FreeBSD SMP on such boards? Is the VIA's > > > SMP chipset any good? > > > > Even their non-SMP chipsets are crap. It blew my mind that they had > > the ability to create an SMP chipset at all, let alone make one that > > might work. > > My counter opinion would simply be, I have ran FreeBSD on my Tyan > Tiger 133A motherboard which uses the Via Apollo Pro 133A chipset > with Dual Pentium III 450s. They aren't the best performing > boards out there, however, they are pretty stable in my > experience, both Athlon and PIII. Add that to the fact that they > support the latest tech like AGP4X and UDMA100. Their chipsets do > lack a little performance, but not so much as to make me wish I > had another board. Dual Pentium IIIs are still Dual Pentium IIIs. Sure, the chipsets do work. Sometimes. Maybe. If you hold your toungue just right. The problem is not usually reliability so much as compatibility. I can't count how many times I've read README files for Windows drivers that point out some particular quirk that X product or driver has with this or that VIA or SiS or ALi chipset. I rarely ever see those types of "quirks" for Intel chipsets (or AMD's yet, for that matter, even though they only have the 750 and just recently the 760 to speak of). Even some of our (FreeBSD's) own driver writers have kvetched about how VIA or insert-other-lowball-chipset-maker-here has not followed this or that PCI spec or things of that nature. Intel apparently puts quite a bit more compatibility testing into their chipsets, and follows specifications closely (usually). I'm not sure if VIA, SiS, or ALi's inability to create decent chipsets is because of a lack of access to important standards information, lack of engineering ability, or for other reasons (like, they're low-end, low-price chipsets, and you get what you pay for). -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64 and PowerPC under development. 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 Nov 10 14:17:49 2000 Delivered-To: freebsd-smp@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id A9B2B37B479 for ; Fri, 10 Nov 2000 14:17:45 -0800 (PST) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id PAA04339; Fri, 10 Nov 2000 15:13:50 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpdAAAJLaWlS; Fri Nov 10 14:45:58 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id OAA00930; Fri, 10 Nov 2000 14:49:45 -0700 (MST) From: Terry Lambert Message-Id: <200011102149.OAA00930@usr08.primenet.com> Subject: Re: via chipset and SMP To: cdillon@wolves.k12.mo.us (Chris Dillon) Date: Fri, 10 Nov 2000 21:49:44 +0000 (GMT) Cc: jgowdy@home.com (Jeremiah Gowdy), ktsin@acm.org (KT Sin), freebsd-smp@FreeBSD.ORG In-Reply-To: from "Chris Dillon" at Nov 10, 2000 01:28:47 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ ... VIA chipsets ... ] > Sure, the chipsets do work. Sometimes. Maybe. If you hold your > toungue just right. The problem is not usually reliability so much as > compatibility. I can't count how many times I've read README files > for Windows drivers that point out some particular quirk that X > product or driver has with this or that VIA or SiS or ALi chipset. I > rarely ever see those types of "quirks" for Intel chipsets (or AMD's > yet, for that matter, even though they only have the 750 and just > recently the 760 to speak of). Intel has only recently, in the lifetime of PCI, proven itself capable of producing chipsets able to support more than 2 PCI bus master devices simultaneously. My personal experience with SiS chipsets has been very positive; at the time I got my first EISA system, the SiS machines were the only ones capable of running without 4-3-3 or worse, in terms of wait states (the one I have runs 2-1-1). Yes, you occasionally have bad chipsets, but I argue that Mercury, Neptune, and Natoma chipsets all have well recognized bugs. Let us also not forget the large number of Intel 8259 compatability hadrware bugs, their floppy controller bugs, the RZ1000 bug (it recently rose from the dead), the F00F bug, and the famous floating point bug. SMP adds stepping incompatability issues, which were otherwise invisible until you plugged in the second processor. I think you could probably point at any given manufacturer and find bad chips under their covers (e.g. the Cyrix 5520 and 5530, and the MOPSW instruction not being priviledged on the 68000, and the instruction restart after fault errors that Motorolla has had). Rather than tarring all products from a given manufacturer with a wide brush, it's much more useful to document what _does_ work, and list what _doesn't_ work only if you include very detailed information. Otherwise any experience, positive or negative, will not be repeatable by someone who goes out buying hardware. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Nov 10 15:51:19 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id BF57837B479 for ; Fri, 10 Nov 2000 15:51:12 -0800 (PST) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.3) with ESMTP id RAA21206; Fri, 10 Nov 2000 17:50:57 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Fri, 10 Nov 2000 17:50:57 -0600 (CST) From: Chris Dillon To: Terry Lambert Cc: Jeremiah Gowdy , KT Sin , freebsd-smp@FreeBSD.ORG Subject: Re: via chipset and SMP In-Reply-To: <200011102149.OAA00930@usr08.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 10 Nov 2000, Terry Lambert wrote: > [ ... VIA chipsets ... ] > > > Sure, the chipsets do work. Sometimes. Maybe. If you hold your > > toungue just right. The problem is not usually reliability so much as > > compatibility. I can't count how many times I've read README files > > for Windows drivers that point out some particular quirk that X > > product or driver has with this or that VIA or SiS or ALi chipset. I > > rarely ever see those types of "quirks" for Intel chipsets (or AMD's > > yet, for that matter, even though they only have the 750 and just > > recently the 760 to speak of). > > Intel has only recently, in the lifetime of PCI, proven itself > capable of producing chipsets able to support more than 2 PCI bus > master devices simultaneously. Apparently I've never used more than one busmaster device at a time (not a common situation, I presume). Could you elaborate on that a bit? Are more than one busmaster device capable of being present in the system, just not in use concurrently? And which chipsets from Intel are doing this correctly now? > My personal experience with SiS chipsets has been very positive; > at the time I got my first EISA system, the SiS machines were the > only ones capable of running without 4-3-3 or worse, in terms of > wait states (the one I have runs 2-1-1). My general feeling about the companies I've mentioned mostly applies to fairly recent generations of systems, Pentium and above. I have used many 286, 386, and 486 systems with no-name chipsets and only sometimes had compatibility problems. Things were much simpler back then. :-) > Yes, you occasionally have bad chipsets, but I argue that Mercury, > Neptune, and Natoma chipsets all have well recognized bugs. Let > us also not forget the large number of Intel 8259 compatability > hadrware bugs, their floppy controller bugs, the RZ1000 bug (it > recently rose from the dead), the F00F bug, and the famous > floating point bug. SMP adds stepping incompatability issues, > which were otherwise invisible until you plugged in the second > processor. Yeah, I'm aware of the bugs in those chipsets, as well as many others that Intel has made (except for the RZ1000 bug... never heard of that one). I submit, though, that in general Intel has fewer problems than the others I've mentioned. Stuff like the F00F and floating-point bugs are strictly processor-related, anyway, not chipset. Intel certainly has its share of chipset bugs, even recently (the i820+MTH is a good example, but that was a bad electrical engineering decision on their part, not a hardware or software compatibility problem). > I think you could probably point at any given manufacturer and > find bad chips under their covers (e.g. the Cyrix 5520 and 5530, > and the MOPSW instruction not being priviledged on the 68000, and > the instruction restart after fault errors that Motorolla has > had). Most definately, but we're moving away from the "support chipset" area of discussion. :-) > Rather than tarring all products from a given manufacturer with a > wide brush, it's much more useful to document what _does_ work, > and list what _doesn't_ work only if you include very detailed > information. Otherwise any experience, positive or negative, will > not be repeatable by someone who goes out buying hardware. I based it entirely on my own experience, which in general has not been good from said companies. A lot of it is based on "I put the card in this VIA-based system, it doesn't work. I put it in this Intel-based system, and it works fine. Grunt. Snort." Granted, I'm not using the newer Intel stuff -- the latest chipset from Intel that we're using around here is still the good old i440BX, though I would probably trust the recent i815 as much. I find it rather funny, though, that with so much experience riding on the shoulders of all of these companies, that they can have something working in one chipset and then break it in the next one. It seems to be getting better in some areas and worse in others. I'm waiting to see wether AMD's 760 will prove to be reliable and compatible, at which point we'll start buying Athlon processors and motherboards using that chipset. Since I can't buy any Athlons right now without putting them on a board with a VIA chipset (the AMD 750 isn't an option), we don't use them. -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64 and PowerPC under development. 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 Sat Nov 11 19:13:48 2000 Delivered-To: freebsd-smp@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id ED4BB37B479; Sat, 11 Nov 2000 19:13:39 -0800 (PST) Received: from opal (cs.binghamton.edu [128.226.123.101]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with ESMTP id WAA02111; Sat, 11 Nov 2000 22:13:36 -0500 (EST) Date: Sat, 11 Nov 2000 22:12:35 -0500 (EST) From: Zhiui Zhang X-Sender: zzhang@opal To: freebsd-hackers@freebsd.org, freebsd-smp@freebsd.org Subject: simple lock and the lost wakeup problem 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 I am new to SMP subject and have some questions to ask: Is the simplelock() really needed since FreeBSD is using the big giant lock and the kernel is non preemptive? Or has FreeBSD changed the big giant lock and made kernel thread preemptive? Uresha Vahalia talks about Lost Wakeup Problem (page 196), the test of the resource and sleep() has to be done atomically. Which correct mechanism should I use on FreeBSD to achieve this (avoid the lost-wakeup problem)? Any help is appreciated. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message