From owner-freebsd-smp Sun Apr 30 3:29:45 2000 Delivered-To: freebsd-smp@freebsd.org Received: from relativity.student.utwente.nl (wit389306.student.utwente.nl [130.89.234.166]) by hub.freebsd.org (Postfix) with ESMTP id 43C6F37BC68 for ; Sun, 30 Apr 2000 03:29:39 -0700 (PDT) (envelope-from djb@wit389306.student.utwente.nl) Received: by relativity.student.utwente.nl (Postfix, from userid 1000) id 631655DEE; Sun, 30 Apr 2000 12:29:43 +0200 (CEST) Date: Sun, 30 Apr 2000 12:29:43 +0200 From: Dave Boers To: Steve Passe Cc: smp@FreeBSD.ORG Subject: Re: hlt instructions and temperature issues Message-ID: <20000430122943.A52481@relativity.student.utwente.nl> Reply-To: djb@ifa.au.dk References: <200004300350.VAA13194@Ilsa.StevesCafe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004300350.VAA13194@Ilsa.StevesCafe.com>; from smp@csn.net on Sat, Apr 29, 2000 at 09:50:47PM -0600 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Apr 29, 2000 at 09:50:47PM -0600, Steve Passe wrote: > > In <200004291445.IAA09070@Ilsa.StevesCafe.com> Steve Passe wrote: > > > Did you use the version that had the explicit instruction between the sti > > > and hlt: > > > I would like to repeat your experiment. > > > Yes, I used Luoqi Chen's original patch, no modifications. > > This is very weird, my times improved with the hlt instruction in place: > http://people.FreeBSD.org/~fsmp/SMP/hltbenches.html That agrees with my experience. Seems to have only bright sides, that hlt instruction ;-) With the apic instruction between sti and hlt I did notice a few stray irq 7's in my logfiles, however. I will now go do a different kind of testing (one I usually use to test new memory DIMM's: large matrix inversion in double precision). I will do some benchmarking with and without the hlt instruction. You'll all hear from me shortly. Regards, Dave. -- djb@ifa.au.dk d.j.boers@tn.utwente.nl PGP key: ftp://relativity.student.utwente.nl:/pub/pgpkeys/djb.asc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Apr 30 6:23:44 2000 Delivered-To: freebsd-smp@freebsd.org Received: from relativity.student.utwente.nl (wit389306.student.utwente.nl [130.89.234.166]) by hub.freebsd.org (Postfix) with ESMTP id C28DF37B7F3 for ; Sun, 30 Apr 2000 06:23:40 -0700 (PDT) (envelope-from djb@wit389306.student.utwente.nl) Received: by relativity.student.utwente.nl (Postfix, from userid 1000) id 90BE75DEE; Sun, 30 Apr 2000 15:23:39 +0200 (CEST) Date: Sun, 30 Apr 2000 15:23:39 +0200 From: Dave Boers To: Steve Passe Cc: smp@FreeBSD.ORG Subject: Re: hlt instructions and temperature issues Message-ID: <20000430152339.A453@relativity.student.utwente.nl> Reply-To: djb@ifa.au.dk References: <200004300350.VAA13194@Ilsa.StevesCafe.com> <20000430122943.A52481@relativity.student.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000430122943.A52481@relativity.student.utwente.nl>; from djb@ifa.au.dk on Sun, Apr 30, 2000 at 12:29:43PM +0200 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Apr 30, 2000 at 12:29:43PM +0200, Dave Boers wrote: > I will now go do a different kind of testing (one I usually use to test > new memory DIMM's: large matrix inversion in double precision). I will do > some benchmarking with and without the hlt instruction. > > You'll all hear from me shortly. The test consists of filling a large (n x n) real-valued double precision matrix with random double's between 0 and 1 (I used srandomdev()) and adding the unit matrix to that, so that the matrix becomes diagonally dominant, which will ensure that it's invertible. This matrix is inverted using LU factorization and the inverted result is multiplied with the original. Then a test is performed to determine the maximum difference between the result and the unit matrix. This is a test I usually use to check memory integrity. This test uses a lot of memory very intensively and memory errors will hopefully trigger errors in the result that are bigger than the standard numerical noise (which is of the order of 1e12 for n = 2400). The system tested is an Abit BP6 dual celeron, not overclocked, 400 Mhz. There is 256 Mb RAM in the system and n = 2400 is about the maximum I can do without paging. The calculation is a single program, so effectively this uses about half the system's processing power. The program and the meschach matrix library used are in C and the optimization level used for both is simply -O. I removed the apic line (and the #define's for that matter) from swtch.s so that I now use exactly the same modifications as you, Steve. Here are the results: Unmodified kernel Matrix size: Output from time command: T: T/n**3: ----------------------------------------------------------------------- n = 2400 1323.063u 2.476s 22:06.53 99.9% 1325.539 s. 9.5887e-8 n = 1500 326.161u 0.757s 5:27.16 99.9% 326.918 s. 9.6865e-8 n = 500 12.438u 0.070s 0:12.53 99.7% 12.508 s. 1.0006e-7 Average CPU temperature during calculations: 50 degrees Celcius. Modified kernel Matrix size: Output from time command: T: T/n**3: ----------------------------------------------------------------------- n = 2400 1381.708u 2.250s 23:04.52 99.9% 1383.958 s. 1.0011e-7 n = 1500 342.293u 0.781s 5:43.37 99.9% 343.074 s. 1.0165e-7 n = 500 12.982u 0.124s 0:13.12 99.8% 13.106 s. 1.0485e-7 Average CPU temperature during calculations: 45 degrees Celcius. It can be seen from the last column that the calculations roughly scale with n**3, as they should because matrix inversion and multiplication are n**3 algorithms. Differences Matrix size: Relative difference: (T_modified/T_unmodified)*100-100 % ----------------------------------------------------------------------- n = 2400 + 4.41 % n = 1500 + 4.94 % n = 500 + 4.78 % Conclusion: the modifications have made matrix inversion and multiplication less than 5 % slower. Comparing this to your results, Steve, for which we have (36.9 / 38.7 minutes) * 100 - 100 % = - 4.65 % I think we can draw the conclusion that for NCPU in the order of 2 to 4, the hlt modifications have a plus or minus 5% impact on system performance, depending on the application and system specifications. Note that the temperature even during full load is 10 % lower with the modifications than without. Of course temperature results will vary widely. I personally wouldn't worry about 5% performance difference, and go for the lower temperature and increased stability. But others may have different opinions. My proposal is therefore to make the hlt instruction a kernel option for SMP systems. That way everyone can experiment for themselves and possible problems may be detected. My system appears perfectly stable and since I removed the apic lines from swtch.s I haven't seen a single stray irq 7 anymore. Regards, Dave Boers. -- djb@ifa.au.dk d.j.boers@tn.utwente.nl PGP key: ftp://relativity.student.utwente.nl:/pub/pgpkeys/djb.asc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Apr 30 7:23:16 2000 Delivered-To: freebsd-smp@freebsd.org Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (Postfix) with ESMTP id 6253237B54C for ; Sun, 30 Apr 2000 07:23:02 -0700 (PDT) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.10.0/8.10.0/Kp) with ESMTP id e3UESgC44580; Sun, 30 Apr 2000 15:28:42 +0100 (BST) Message-ID: <390C4185.5C07088A@tdx.co.uk> Date: Sun, 30 Apr 2000 15:21:57 +0100 From: Karl Pielorz Organization: TDX - The Digital eXchange X-Mailer: Mozilla 4.7 [en-gb] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: djb@ifa.au.dk Cc: Steve Passe , smp@FreeBSD.ORG Subject: Re: hlt instructions and temperature issues References: <200004300350.VAA13194@Ilsa.StevesCafe.com> <20000430122943.A52481@relativity.student.utwente.nl> <20000430152339.A453@relativity.student.utwente.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I personally wouldn't worry about 5% performance difference, and go for the > lower temperature and increased stability. But others may have different > opinions. My proposal is therefore to make the hlt instruction a kernel > option for SMP systems. That way everyone can experiment for themselves and > possible problems may be detected. Everyone, This thread has been a fascinating walk through CPU temperatures under SMP - but surely, no one should be designing a system that relies on the 'thermal characteristics of the software running' to ensure safe operation? - If the spec says you need to dissipate 32 Watts of heat from the CPU, you design a system to dissipate 32 Watts (probably a bit more for 'safety'? :)... Taking it to an extreme, it would be like building a system that falls over when it 'happens to be busy' one day, 'cause someone ran something computationally intensive? - I know for a fact these systems do exist, but we don't really want to be helping sweep the cause under the rug do we? I don't like the 5% speed decrease either - our SMP systems are SMP because we need the speed. They are built to handle the thermals - so the thought of dropping 5% in speed isn't appealing... At the very worst can this be made a 'default off' option? :-) And, I wasn't be funny - the thread _really_ was interesting... :) -Karl's $.02 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Apr 30 7:31:42 2000 Delivered-To: freebsd-smp@freebsd.org Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (Postfix) with ESMTP id 70DE737B749 for ; Sun, 30 Apr 2000 07:31:39 -0700 (PDT) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.10.0/8.10.0/Kp) with ESMTP id e3UEbUX44695 for ; Sun, 30 Apr 2000 15:37:30 +0100 (BST) Message-ID: <390C4394.D9E57E54@tdx.co.uk> Date: Sun, 30 Apr 2000 15:30:44 +0100 From: Karl Pielorz Organization: TDX - The Digital eXchange X-Mailer: Mozilla 4.7 [en-gb] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-smp@freebsd.org Subject: APIC workarounds for ahc Drivers under 4.0-Stable / 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 All, Being as there's been a lot of chat in -SMP recently, maybe someone can please help me with this problem? I recently upgraded a Dual P-Pro system from 3.2 to 4.0-Stable. The upgrade went fine, I rebuilt the world, followed someone's helpful 'going from 3.2 to 4.0' guide, fixed up /etc., got a new Kernel compiled up - and rebooted the machine... That's when my problems start... From peoples various comments - it looks like the APIC workarounds that were previously in the SMP / ahc-driver code [I'm not too sure where] have been removed in the move from 3.2 to 4.0, probably due to other architectural changes in 4.0 This used to result in my 3.2 system saying things like "Warning: broken APIC routing on xxxx installing an additional handler for PCI xxxxxx" [I forget the exact terms I'm afraid - I think I posted them before] - but it did actually work. As far as I can figure out this enabled the system to run it's three AHA 2940UW's correctly on my system, as they were effectively 'sharing' an IRQ (due to the buggy APIC on the board), and all three ahc drivers had to have a handler installed for that IRQ [humour me if this is way off track]. When booting 4.0-Stable/SMP I get no such kernel messages now, and the ahc adapters die horribly with loads of "time-out" and other nasty messages - apparently as only the first driver is seeing interrupts generated by the second, and third cards (which assume the ahc their connected to has gone south, due to the lack of interrupts). If anyone knows whether these have been put back in, or which files I should keep an eye on, I'd be very grateful for the info... The systems running a SuperMicro P6DNF, w 2xP-Pro 200's, and 256Mb of RAM. Thanks for your time, -Karl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Apr 30 7:38:29 2000 Delivered-To: freebsd-smp@freebsd.org Received: from relativity.student.utwente.nl (wit389306.student.utwente.nl [130.89.234.166]) by hub.freebsd.org (Postfix) with ESMTP id 2E42C37BCA0 for ; Sun, 30 Apr 2000 07:38:26 -0700 (PDT) (envelope-from djb@wit389306.student.utwente.nl) Received: by relativity.student.utwente.nl (Postfix, from userid 1000) id BF1725DEF; Sun, 30 Apr 2000 16:38:24 +0200 (CEST) Date: Sun, 30 Apr 2000 16:38:24 +0200 From: Dave Boers To: Karl Pielorz Cc: Steve Passe , smp@FreeBSD.ORG Subject: Re: hlt instructions and temperature issues Message-ID: <20000430163824.A1093@relativity.student.utwente.nl> Reply-To: djb@ifa.au.dk References: <200004300350.VAA13194@Ilsa.StevesCafe.com> <20000430122943.A52481@relativity.student.utwente.nl> <20000430152339.A453@relativity.student.utwente.nl> <390C4185.5C07088A@tdx.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <390C4185.5C07088A@tdx.co.uk>; from kpielorz@tdx.co.uk on Sun, Apr 30, 2000 at 03:21:57PM +0100 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Apr 30, 2000 at 03:21:57PM +0100, Karl Pielorz wrote: > > I personally wouldn't worry about 5% performance difference, and go for the > > lower temperature and increased stability. But others may have different > > opinions. My proposal is therefore to make the hlt instruction a kernel > > option for SMP systems. That way everyone can experiment for themselves and > > possible problems may be detected. > > Everyone, > > This thread has been a fascinating walk through CPU temperatures under SMP - > but surely, no one should be designing a system that relies on the 'thermal > characteristics of the software running' to ensure safe operation? - If the > spec says you need to dissipate 32 Watts of heat from the CPU, you design a > system to dissipate 32 Watts (probably a bit more for 'safety'? :)... Agreed. However, I can think of a number of reasons why it would be sometimes preferable to have the system cooler on average even though it should be designed to handle all the heat even at full load, and surely you can as well. So I think it is nice to have the hlt's as an option. > Taking it to an extreme, it would be like building a system that falls over > when it 'happens to be busy' one day, 'cause someone ran something > computationally intensive? - I know for a fact these systems do exist, but we > don't really want to be helping sweep the cause under the rug do we? No. I don't. > I don't like the 5% speed decrease either - our SMP systems are SMP because we > need the speed. They are built to handle the thermals - so the thought of > dropping 5% in speed isn't appealing... A matter of choice. And there isn't just a speed decrease, there can be an increase also, as it was shown by Steve. It merely means that different tasks will run at different speeds, some lower, some higher. > At the very worst can this be made a 'default off' option? :-) I'd go for that, yes. > And, I wasn't be funny - the thread _really_ was interesting... :) I still is. :-) Dave. -- djb@ifa.au.dk d.j.boers@tn.utwente.nl PGP key: ftp://relativity.student.utwente.nl:/pub/pgpkeys/djb.asc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Apr 30 8:11:23 2000 Delivered-To: freebsd-smp@freebsd.org Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [206.168.13.65]) by hub.freebsd.org (Postfix) with ESMTP id 1C48437B7F3 for ; Sun, 30 Apr 2000 08:11:20 -0700 (PDT) (envelope-from fbsd@Ilsa.StevesCafe.com) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.9.3/8.9.3) with ESMTP id JAA16392; Sun, 30 Apr 2000 09:11:12 -0600 (MDT) (envelope-from fbsd@Ilsa.StevesCafe.com) Message-Id: <200004301511.JAA16392@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0.2 2/24/98 From: Steve Passe To: djb@ifa.au.dk Cc: Karl Pielorz , smp@FreeBSD.ORG Subject: Re: hlt instructions and temperature issues In-reply-to: Your message of "Sun, 30 Apr 2000 16:38:24 +0200." <20000430163824.A1093@relativity.student.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 30 Apr 2000 09:11:12 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, > > > I personally wouldn't worry about 5% performance difference, and go for the > > > lower temperature and increased stability. But others may have different > > > opinions. My proposal is therefore to make the hlt instruction a kernel > > > option for SMP systems. That way everyone can experiment for themselves Some with experience in this area should make a sysctl that changes the value of _hlt_vector, one that has the hlt, another that doesn't: .globl _hlt_vector #ifdef SMP _hlt_vector: .long _no_halt /* pointer to halt routine */ #else _hlt_vector: .long _real_halt /* pointer to halt routine */ #endif ENTRY(no_halt) sti ret ENTRY(real_halt) sti hlt ret ... call *_hlt_vector /* wait for interrupt */ --- > > I don't like the 5% speed decrease either - our SMP systems are SMP because we > > need the speed. They are built to handle the thermals - so the thought of > > dropping 5% in speed isn't appealing... > > A matter of choice. And there isn't just a speed decrease, there can be an > increase also, as it was shown by Steve. As I said before, its "weird". I'm not ready to believe there is any speed increase yet... I expected a decrease, I was just trying to determine how much... Look at: http://people.FreeBSD.org/~fsmp/SMP/rbenches.html These are some baseline figures I took last week (indeed, the non-hlt, 4way numbers on the hlt graph are actually stolen from there). Notice that the 3way/j16 is actually faster than any 4way build. I attribute this to the BGL, ie, past 3 CPUs we actually loose ground competing for the lock and other such housekeeping. I'm thinking that the hlt instruction might be wasting CPU cycles by keeping CPUs hlt'd when there is useful work to do, but that this helps as there "isn't enough room in the kernel" for 4 CPUs anyway. I will run similar tests with a 3way kernel monday. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Apr 30 18:43:54 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mail.rdc2.bc.home.com (ha1.rdc2.bc.wave.home.com [24.2.10.68]) by hub.freebsd.org (Postfix) with ESMTP id 1E75737C09A for ; Sun, 30 Apr 2000 18:43:49 -0700 (PDT) (envelope-from dr@dursec.com) Received: from kyxbot.zorg ([24.113.134.64]) by mail.rdc2.bc.home.com (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20000501014348.PXRO22959.mail.rdc2.bc.home.com@kyxbot.zorg>; Sun, 30 Apr 2000 18:43:48 -0700 From: Dragos Ruiu Organization: kyx.net To: Karl Pielorz , djb@ifa.au.dk Subject: Re: hlt instructions and temperature issues Date: Sun, 30 Apr 2000 18:36:46 -0700 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain Cc: Steve Passe , smp@FreeBSD.ORG References: <200004300350.VAA13194@Ilsa.StevesCafe.com> <20000430152339.A453@relativity.student.utwente.nl> <390C4185.5C07088A@tdx.co.uk> In-Reply-To: <390C4185.5C07088A@tdx.co.uk> MIME-Version: 1.0 Message-Id: <00043018413807.18195@kyxbot.zorg> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 30 Apr 2000, Karl Pielorz wrote: > Taking it to an extreme, it would be like building a system that falls over > when it 'happens to be busy' one day, 'cause someone ran something > computationally intensive? - I know for a fact these systems do exist, but we > don't really want to be helping sweep the cause under the rug do we? > Tell that to IBM... one of the famous stories from classic computing history is the mainframe they built with the HCF opcode. Halt and Catch Fire. It turned out that for this model you could lock up into a tight one instruction loop and the CPU core would overheat and literally smoke. It's documented in the ancient back issues Mr. Neuman's old Risks usenet newsgroup in the early eighties. cheers, --dr -- dursec.com / kyx.net - we're from the future http://www.dursec.com learn kanga-foo from security experts: CanSecWest - May 10-12 Vancouver Speakers: Ron Gula/NSW, Ken Williams/E&Y, Marty Roesch/Hiverworld, Fyodor/insecure.org, RainForestPuppy/wiretrip.net, Theo de Raadt/OpenBSD Lance Spitzner/Sun, Fyodor Yarochkin/KALUG, Max Vision/whitehats.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Apr 30 20:10:30 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mail.rdc1.sdca.home.com (ha1.rdc1.sdca.home.com [24.0.3.66]) by hub.freebsd.org (Postfix) with ESMTP id 1082937B70F; Sun, 30 Apr 2000 20:10:26 -0700 (PDT) (envelope-from jgowdy@home.com) Received: from cx443070a ([24.4.93.90]) by mail.rdc1.sdca.home.com (InterMail vM.4.01.02.00 201-229-116) with SMTP id <20000501031023.EDBR13130.mail.rdc1.sdca.home.com@cx443070a>; Sun, 30 Apr 2000 20:10:23 -0700 Message-ID: <000901bfb31a$bcf8b240$5a5d0418@vista1.sdca.home.com> From: "Jeremiah Gowdy" To: , , Subject: Kernel Panic Date: Sun, 30 Apr 2000 20:10:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4132.1800 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4132.1800 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org panic: vrele: negative ref cnt mp_lock = 01000001; cpuid=1; lapic.id 01000000 boot() called on cpu#1 syncing disks... panic: rslock: cpu: 1, addr: 0xcee0c2ac, lock: 0x01000001 mp_lock = 01000001; cpuid=1; lapic.id 01000000 boot() called on cpu#1 This time it happened when I was accessing the FAT32 drive via Samba and also happens when I do the same type of operations under ProFTP. Any time I'm remotely accessing my FAT32 drive remotely, via ftp or smb, and I try to move or delete groups of files, my box eats it. I'm running 4.0 RELEASE, but I remember this happening via ftp under 3.4 STABLE. I am running under an SMP setup, Dual Pentium II 333s. The drive is a Maxtor 34 gig UDMA-66 running at UDMA-33. The drive is on it's own line on the controller, and I've never had problems with it (when it used to be in my windows box. I'm guessing this has something to do with the FAT32 file system code or perhaps SMP and the FAT32 together. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon May 1 7:16:34 2000 Delivered-To: freebsd-smp@freebsd.org Received: from relativity.student.utwente.nl (wit389306.student.utwente.nl [130.89.234.166]) by hub.freebsd.org (Postfix) with ESMTP id EEF3237B680 for ; Mon, 1 May 2000 07:16:28 -0700 (PDT) (envelope-from djb@wit389306.student.utwente.nl) Received: by relativity.student.utwente.nl (Postfix, from userid 1000) id B87275DF0; Mon, 1 May 2000 16:16:26 +0200 (CEST) Date: Mon, 1 May 2000 16:16:26 +0200 From: Dave Boers To: Steve Passe Cc: Karl Pielorz , smp@FreeBSD.ORG Subject: Re: hlt instructions and temperature issues Message-ID: <20000501161626.A4317@relativity.student.utwente.nl> Reply-To: djb@ifa.au.dk References: <20000430163824.A1093@relativity.student.utwente.nl> <200004301511.JAA16392@Ilsa.StevesCafe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004301511.JAA16392@Ilsa.StevesCafe.com>; from smp@csn.net on Sun, Apr 30, 2000 at 09:11:12AM -0600 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Apr 30, 2000 at 09:11:12AM -0600, Steve Passe wrote: > Some with experience in this area should make a sysctl that changes the value > of _hlt_vector, one that has the hlt, another that doesn't: > > .globl _hlt_vector > #ifdef SMP > _hlt_vector: .long _no_halt /* pointer to halt routine */ > #else > _hlt_vector: .long _real_halt /* pointer to halt routine */ > #endif > > ENTRY(no_halt) > sti > ret > > ENTRY(real_halt) > sti > hlt > ret > > ... > call *_hlt_vector /* wait for interrupt */ This looks like an excellent proposal. Does anyone have comments, or could someone with experience" in this area provide a patch? > As I said before, its "weird". I'm not ready to believe there is any speed > increase yet... I expected a decrease, I was just trying to determine how > much... Just came to my mind. There's another difference between your tests and mine: you're running 5.0-CURRENT while I have 4.0-STABLE. Regards, Dave. -- djb@ifa.au.dk d.j.boers@tn.utwente.nl PGP key: ftp://relativity.student.utwente.nl:/pub/pgpkeys/djb.asc In the land of the blind, the one-eyed man is murdered for heresy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon May 1 10:11:49 2000 Delivered-To: freebsd-smp@freebsd.org Received: from overcee.netplex.com.au (peter1.yahoo.com [208.48.107.4]) by hub.freebsd.org (Postfix) with ESMTP id 9219937BDC6 for ; Mon, 1 May 2000 10:11:46 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 04ADF1CD7; Mon, 1 May 2000 10:11:41 -0700 (PDT) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Karl Pielorz Cc: djb@ifa.au.dk, Steve Passe , smp@FreeBSD.ORG Subject: Re: hlt instructions and temperature issues In-Reply-To: Message from Karl Pielorz of "Sun, 30 Apr 2000 15:21:57 BST." <390C4185.5C07088A@tdx.co.uk> Date: Mon, 01 May 2000 10:11:40 -0700 From: Peter Wemm Message-Id: <20000501171141.04ADF1CD7@overcee.netplex.com.au> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Karl Pielorz wrote: > > I personally wouldn't worry about 5% performance difference, and go for the > > lower temperature and increased stability. But others may have different > > opinions. My proposal is therefore to make the hlt instruction a kernel > > option for SMP systems. That way everyone can experiment for themselves and > > possible problems may be detected. > > Everyone, > > This thread has been a fascinating walk through CPU temperatures under SMP - > but surely, no one should be designing a system that relies on the 'thermal > characteristics of the software running' to ensure safe operation? - If the > spec says you need to dissipate 32 Watts of heat from the CPU, you design a > system to dissipate 32 Watts (probably a bit more for 'safety'? :)... > > Taking it to an extreme, it would be like building a system that falls over > when it 'happens to be busy' one day, 'cause someone ran something > computationally intensive? - I know for a fact these systems do exist, but we > don't really want to be helping sweep the cause under the rug do we? For example, run a rc5des or something and see how good your heat dissipation is. It makes my laptop cooling system go berzerk, and makes the cpus run even hotter than the present idle loop under SMP. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon May 1 11:15:17 2000 Delivered-To: freebsd-smp@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id A632837CB84 for ; Mon, 1 May 2000 11:15:11 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id LAA01684; Mon, 1 May 2000 11:14:39 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200005011814.LAA01684@gndrsh.dnsmgr.net> Subject: Re: hlt instructions and temperature issues In-Reply-To: <00043018413807.18195@kyxbot.zorg> from Dragos Ruiu at "Apr 30, 2000 06:36:46 pm" To: dr@dursec.com (Dragos Ruiu) Date: Mon, 1 May 2000 11:14:39 -0700 (PDT) Cc: kpielorz@tdx.co.uk (Karl Pielorz), djb@ifa.au.dk, smp@csn.net (Steve Passe), smp@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 > On Sun, 30 Apr 2000, Karl Pielorz wrote: > > Taking it to an extreme, it would be like building a system that falls over > > when it 'happens to be busy' one day, 'cause someone ran something > > computationally intensive? - I know for a fact these systems do exist, but we > > don't really want to be helping sweep the cause under the rug do we? > > > > > Tell that to IBM... one of the famous stories from classic computing > history is the mainframe they built with the HCF opcode. > Halt and Catch Fire. It turned out that for this model > you could lock up into a tight one instruction loop and > the CPU core would overheat and literally smoke. > > It's documented in the ancient back issues Mr. Neuman's > old Risks usenet newsgroup in the early eighties. Right along with the chain breaking/hammer bank smoking code for the 1403 printers.... basically a very specific sequence of lines with very special character sequences could cause 1/3 of the hammer bank to fire every 14uS or so, do that for more than 10 cycles or so and you could litterly break the print character chain. De-optimize it for chain breaking and run it for 10 minutes and you would start smoking the hammer coils.... -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon May 1 15:34:25 2000 Delivered-To: freebsd-smp@freebsd.org Received: from freeway.dcfinc.com (cx74889-a.phnx3.az.home.com [24.1.193.157]) by hub.freebsd.org (Postfix) with ESMTP id A15C937B970 for ; Mon, 1 May 2000 15:34:18 -0700 (PDT) (envelope-from chad@freeway.dcfinc.com) Received: (from chad@localhost) by freeway.dcfinc.com (8.8.8/8.8.8) id PAA18008; Mon, 1 May 2000 15:33:58 -0700 (MST) (envelope-from chad) From: "Chad R. Larson" Message-Id: <200005012233.PAA18008@freeway.dcfinc.com> Subject: Re: hlt instructions and temperature issues In-Reply-To: <200005011814.LAA01684@gndrsh.dnsmgr.net> from "Rodney W. Grimes" at "May 1, 0 11:14:39 am" To: freebsd@gndrsh.dnsmgr.net (Rodney W. Grimes) Date: Mon, 1 May 2000 15:33:57 -0700 (MST) Cc: dr@dursec.com, kpielorz@tdx.co.uk, djb@ifa.au.dk, smp@csn.net, smp@FreeBSD.ORG Reply-To: chad@DCFinc.com X-Mailer: ELM [version 2.4ME+ PL40 (25)] 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 As I recall, Rodney W. Grimes wrote: > Right along with the chain breaking/hammer bank smoking code for the > 1403 printers.... basically a very specific sequence of lines with > very special character sequences could cause 1/3 of the hammer bank to > fire every 14uS or so, do that for more than 10 cycles or so and you > could litterly break the print character chain. De-optimize it for > chain breaking and run it for 10 minutes and you would start smoking > the hammer coils.... Ah, yes. I had one that would play "The Iowa Fight Song" (I was working for Collins Radio in Cedar Rapids at the time--circa 1969). Worked best with a single sheet of paper, and the paper thickness set for 6-part forms (very rattley). And the feed clutch open, so you could use "line feed" as a drum-beat. We had a printer controller (built by Collins, the 8401 I believe) that would allow you to gang printers, in case you needed more than 6 copies. Get five or six printers going and you could hear the song all over the building. I seem to remember one of my cow-workers wrote "On Wisconsin" as well. But shattering the chain was pretty spectacular. You'd want to be sure the covers were down or someone could get hurt. The IBM CEs loved us. Sometime I should tell you about making the Bryant disk drives walk across the floor... -crl -- Chad R. Larson (CRL15) 602-953-1392 Brother, can you paradigm? chad@dcfinc.com chad@larsons.org larson1@home.net DCF, Inc. - 14623 North 49th Place, Scottsdale, Arizona 85254-2207 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue May 2 2:35:55 2000 Delivered-To: freebsd-smp@freebsd.org Received: from hurgh.kancel.zoznam.sk (kancel.zoznam.sk [195.28.72.230]) by hub.freebsd.org (Postfix) with ESMTP id 69E6137BA90; Tue, 2 May 2000 02:35:30 -0700 (PDT) (envelope-from debnar@zoznam.sk) Received: from note (note.kancel.zoznam.sk [192.168.1.5]) by hurgh.kancel.zoznam.sk (8.9.3/8.9.3) with SMTP id LAA14786; Tue, 2 May 2000 11:34:02 +0200 (CEST) (envelope-from debnar@zoznam.sk) From: "=?iso-8859-2?Q?Ivan_Debn=E1r?=" To: , , Subject: Native threads and SMP Date: Tue, 2 May 2000 11:34:01 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0040_01BFB42A.5060A3C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Disposition-Notification-To: "=?iso-8859-2?Q?Ivan_Debn=E1r?=" Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0040_01BFB42A.5060A3C0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Is there a plan to support SMP in the native FreeBSD threads = implementation ? When using Linuxthreads from ports, trying to compile the aplications = (even provided examples) "static", it breaks with: It looks like it's not possible to link static applications with the = current linuxthreads from ports, complaining aboiu siglongjmp and longjmp. /usr/lib/libc.a(sigsetjmp.o): In function `siglongjmp': sigsetjmp.o(.text+0x94): multiple definition of `siglongjmp' /usr/local/lib/liblthread.a(ptlongjmp.o):/usr/ports/devel/linuxthreads/wo= rk/linuxthreads-2.1.2/ptlongjmp.c:39: first defined here /usr/lib/libc.a(setjmp.o): In function `__longjmp': setjmp.o(.text+0x88): multiple definition of `longjmp' /usr/local/lib/liblthread.a(ptlongjmp.o)(.text+0xc0):/usr/ports/devel/lin= uxthreads/work/linuxthreads-2.1.2/ptlongjmp.c: first defined here Any workarounds ? When compiling dynamicaly, it works (examples, but not mysqld - core = dumps imediately). Is it safe to use Linuxthreads and has anyone = succeded with runnig MySQL compiled with them ? Help with any info = please. Ivan Debn=E1r Zoznam s.r.o. http://www.zoznam.sk/ tel.:// 088 4146721 fax:// 088 4147212 ------=_NextPart_000_0040_01BFB42A.5060A3C0 Content-Type: text/x-vcard; name="=?iso-8859-2?Q?Ivan_Debn=E1r.vcf?=" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="=?iso-8859-2?Q?Ivan_Debn=E1r.vcf?=" BEGIN:VCARD VERSION:2.1 N:Debn=E1r;Ivan FN:Ivan Debn=E1r ORG:Zoznam s.r.o. TEL;WORK;VOICE:+421 (88) 4142231 TEL;HOME;VOICE:+421 (88) 4171223 TEL;CELL;VOICE:+421 (903) 506197 TEL;WORK;FAX:+421 (88) 4142207 ADR;WORK:;;Skuteck=E9ho 39;Bansk=E1 Bystrica;;974 01;Slovak Republic LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Skuteck=3DE9ho = 39=3D0D=3D0ABansk=3DE1 Bystrica 974 01=3D0D=3D0ASlovak Republic URL: URL:http://www.zoznam.sk EMAIL;PREF;INTERNET:debnar@zoznam.sk REV:20000124T135137Z END:VCARD ------=_NextPart_000_0040_01BFB42A.5060A3C0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue May 2 3:32: 4 2000 Delivered-To: freebsd-smp@freebsd.org Received: from hotmail.com (f4.law8.hotmail.com [216.33.241.4]) by hub.freebsd.org (Postfix) with SMTP id 654F237B610 for ; Tue, 2 May 2000 03:31:57 -0700 (PDT) (envelope-from the_hermit665@hotmail.com) Received: (qmail 83517 invoked by uid 0); 2 May 2000 10:31:56 -0000 Message-ID: <20000502103156.83516.qmail@hotmail.com> Received: from 63.226.227.73 by www.hotmail.com with HTTP; Tue, 02 May 2000 03:31:56 PDT X-Originating-IP: [63.226.227.73] Reply-To: the_hermit665@hotmail.com From: "Cosmic 665" To: jgowdy@home.com, questions@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG, bugs@freebsd.org Subject: Re: Kernel Panic Date: Tue, 02 May 2000 03:31:56 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org sounds like an SMP issue. do an mptable and make sure your kernel matches the SMP specs that the mptable program provides.. If they do.. then the only other issue would maybe be the fat32 driver. I've noticed that FreeBSD doesn't process Mircosoft filessystems all that well (In other words, FreeBSD can stand Bull#@@%%!! :P). good luck -Cosmic-665 >panic: vrele: negative ref cnt >mp_lock = 01000001; cpuid=1; lapic.id 01000000 >boot() called on cpu#1 > >syncing disks... panic: rslock: cpu: 1, addr: 0xcee0c2ac, lock: 0x01000001 >mp_lock = 01000001; cpuid=1; lapic.id 01000000 >boot() called on cpu#1 > >This time it happened when I was accessing the FAT32 drive via Samba and >also happens when I do the same type of operations under ProFTP. Any time >I'm remotely accessing my FAT32 drive remotely, via ftp or smb, and I try >to >move or delete groups of files, my box eats it. I'm running 4.0 RELEASE, >but I remember this happening via ftp under 3.4 STABLE. I am running under >an SMP setup, Dual Pentium II 333s. The drive is a Maxtor 34 gig UDMA-66 >running at UDMA-33. The drive is on it's own line on the controller, and >I've never had problems with it (when it used to be in my windows box. I'm >guessing this has something to do with the FAT32 file system code or >perhaps >SMP and the FAT32 together. > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-smp" in the body of the message ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue May 2 4:36:19 2000 Delivered-To: freebsd-smp@freebsd.org Received: from test.tar.com (test.tar.com [204.95.187.4]) by hub.freebsd.org (Postfix) with ESMTP id 4D66737B641 for ; Tue, 2 May 2000 04:36:14 -0700 (PDT) (envelope-from dick@test.tar.com) Received: (from dick@localhost) by test.tar.com (8.9.3/8.9.3) id GAA29505; Tue, 2 May 2000 06:36:02 -0500 (CDT) (envelope-from dick) Date: Tue, 2 May 2000 06:36:02 -0500 From: "Richard Seaman, Jr." To: =?iso-8859-1?Q?Ivan_Debn=E1r?= Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Native threads and SMP Message-ID: <20000502063602.B61185@seaman.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0.1i In-Reply-To: ; from debnar@zoznam.sk on Tue, May 02, 2000 at 11:34:01AM +0200 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, May 02, 2000 at 11:34:01AM +0200, Ivan Debnár wrote: > Is there a plan to support SMP in the native FreeBSD threads implementation ? If Jason Evans is still working on it, then yes. Otherwise, I'm not aware of anyone else working on it. > When using Linuxthreads from ports, trying to compile the aplications >(even provided examples) "static", it breaks with: Yes, static linking has been broken for many months. Jason Evans made some changes to siglongjmp and longjmp that broke static linking. He was made aware of the problem, but has (so far) chosen to ignore the problem. >When compiling dynamicaly, it works (examples, but not mysqld - core dumps imediately). >Is it safe to use Linuxthreads and has anyone succeded with runnig MySQL >compiled with them ? Help with any info please. I've not tried MySQL with linuxthreads. However, one thing that will surely cause problems is getting the FreeBSD pthreads header files included in your compilation. As a double check you might consider temporarily moving the pthread.h that is in /usr/include somewhere else, or rename it, to make sure you're getting the right pthread headers included in your MySQL compilation. If you still get a core dump, and if you send me the stack trace on the dump (compile linuxthreads with the debug options switched on in the file /usr/ports/devel/linuxthreads/work/linuxthreads-2.1.2/Makefile -- they're not on by default), I'll take a look at it. -- Richard Seaman, Jr. email: dick@seaman.org 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue May 2 8:46:54 2000 Delivered-To: freebsd-smp@freebsd.org Received: from macs.mxim.com (ip112.gte2.rb1.pdx.nwlink.com [207.202.206.112]) by hub.freebsd.org (Postfix) with ESMTP id 16B7E37BD39 for ; Tue, 2 May 2000 08:46:50 -0700 (PDT) (envelope-from michaele@mxim.com) Received: from node112 (node112 [198.145.56.112]) by macs.mxim.com (8.7/8.6.9) with SMTP id IAA14847 for ; Tue, 2 May 2000 08:46:48 -0700 (PDT) Message-ID: <004801bfb44d$a8301c70$703891c6@mxim.com> From: "Michael Enkelis" To: References: <200005012233.PAA18008@freeway.dcfinc.com> Subject: Networking: bridgeing Date: Tue, 2 May 2000 08:47:00 -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.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At which version of FreeBSD was bridging enabled? Or do I need a "bridge" daemon? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue May 2 9:39:20 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mail.targetnet.com (mail.targetnet.com [207.245.246.3]) by hub.freebsd.org (Postfix) with ESMTP id D541437B5B6; Tue, 2 May 2000 09:39:14 -0700 (PDT) (envelope-from james@targetnet.com) Received: from james by mail.targetnet.com with local (Exim 3.02 #1) id 12mfhW-000Hid-00; Tue, 02 May 2000 12:39:10 -0400 Date: Tue, 2 May 2000 12:39:10 -0400 From: James FitzGibbon To: freebsd-hackers@freebsd.org, freebsd-smp@freebsd.org Subject: Panics when using Mylex RAID with SMP under RELENG_4 Message-ID: <20000502123910.C29330@targetnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre1i Organization: Targetnet.com Inc. Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am trying to run a Mylex Acceleraid 1100 in a Dell Poweredge 2450. When running rawio against the mylex partition, the system panics within 2 minutes, always with a trap #29. I have kernel dumps for four panics, but kgdb doesn't show any similarities between the panics (other than that they are all #29). This is using RELENG_4 cvsupped recently, and the APIC patch is in. I've tried using a kernel both with and without Matt Dillon's experimental SMP patch, but both cause problems. If I boot this machine with kernel.GENERIC (no SMP), then rawio completes successfully. If I run the test on a single SCSI drive not attached to the Mylex, it completes without error regardless of whether I am using kernel.GENERIC or my SMP-enabled kernel. I'm wondering if anyone can help debug this problem. I can make the box accessible on the net and give an account to anyone with sufficient knowledge to help; I can also send the kernel dumps to anyone who is interested. I've looked over the CVS repository to see if there have been changes to the driver in -CURRENT, and there do appear to be changes, but I'm not sure if they might fix this problem. If they might, I'll install the latest current snapshot and give it a shot, but if that avenue won't do any good I'd rather not bother. Any info along those lines is also appreciated. The traps almost always look like this in kgdb: (kgdb) where #0 boot (howto=256) at ../../kern/kern_shutdown.c:304 #1 0xc014b574 in poweroff_wait (junk=0xc0216039, howto=0) at ../../kern/kern_shutdown.c:554 #2 0xc01e587e in trap_fatal (frame=0xff806fbc, eva=0) at ../../i386/i386/trap.c:926 #3 0xc01e5242 in trap (frame={tf_fs = 24, tf_es = -1071448048, tf_ds = 16, tf_edi = -1, tf_esi = 0, tf_ebp = 0, tf_isp = -8359960, tf_ebx = 0, tf_edx = 160165, tf_ecx = 1, tf_eax = 0, tf_trapno = 29, tf_err = 0, tf_eip = -1071757093, tf_cs = 8, tf_eflags = 582, tf_esp = 0, tf_ss = -8359936}) at ../../i386/i386/trap.c:586 (kgdb) Any help appreciated. Those with sufficient skill and contract hopes are invited to contact me directly. TIA. -- j. James FitzGibbon james@targetnet.com Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue May 2 10:25: 7 2000 Delivered-To: freebsd-smp@freebsd.org Received: from chopper.Poohsticks.ORG (chopper.poohsticks.org [63.227.60.73]) by hub.freebsd.org (Postfix) with SMTP id 32A7037B64D; Tue, 2 May 2000 10:24:59 -0700 (PDT) (envelope-from drew@chopper.Poohsticks.ORG) Received: from chopper.Poohsticks.ORG (localhost.poohsticks.org [127.0.0.1]) by chopper.Poohsticks.ORG (8.6.12/8.6.6) with ESMTP id LAA21159; Tue, 2 May 2000 11:24:48 -0600 Message-Id: <200005021724.LAA21159@chopper.Poohsticks.ORG> To: James FitzGibbon Cc: freebsd-hackers@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: Panics when using Mylex RAID with SMP under RELENG_4 In-reply-to: Your message of "Tue, 02 May 2000 12:39:10 EDT." <20000502123910.C29330@targetnet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21156.957288288.1@chopper.Poohsticks.ORG> Date: Tue, 02 May 2000 11:24:48 -0600 From: Drew Eckhardt Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <20000502123910.C29330@targetnet.com>, james@targetnet.com writes: >I am trying to run a Mylex Acceleraid 1100 in a Dell Poweredge 2450. What is a Dell Poweredge 2450, in terms of chipset and processors? >When >running rawio against the mylex partition, the system panics within 2 >minutes, always with a trap #29. I have kernel dumps for four panics, but >kgdb doesn't show any similarities between the panics (other than that they >are all #29). To add another datapoint: I just swapped the 350MHz PII in my Super Micro P6DGS (your generic 440GX dual slot-1 board) for a pair of PIII600Es. Since then, I have been getting panics under both 4.0 and 5.0 current from trap 29 that seem correlated to IDE disk I/O load. The first crash dump I grabbed showed that the faulting address was idle_loop + 64, which is at the cli instruction. Trap 29 could come from processor fault 19 (SIMD), an APIC, or PIC. Since cli isn't a SIMD instruction, I suspect the APICs or PICs but have yet to instrument and test this hypothesis. > tf_eip = -1071757093, tf_cs = 8, tf_eflags = 582, tf_esp = 0, > tf_ss = -8359936}) at ../../i386/i386/trap.c:586 >(kgdb) What do you get when you feed kgdb frame 3 info line * (void *)frame->tf_eip ? -- Home Page For those who do, no explanation is necessary. For those who don't, no explanation is possible. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue May 2 10:58: 8 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mail.targetnet.com (mail.targetnet.com [207.245.246.3]) by hub.freebsd.org (Postfix) with ESMTP id 645E137B7D1; Tue, 2 May 2000 10:57:57 -0700 (PDT) (envelope-from james@targetnet.com) Received: from james by mail.targetnet.com with local (Exim 3.02 #1) id 12mgvN-000Dlw-00; Tue, 02 May 2000 13:57:33 -0400 Date: Tue, 2 May 2000 13:57:33 -0400 From: James FitzGibbon To: Drew Eckhardt Cc: freebsd-hackers@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: Panics when using Mylex RAID with SMP under RELENG_4 Message-ID: <20000502135733.F29330@targetnet.com> References: <20000502123910.C29330@targetnet.com> <200005021724.LAA21159@chopper.Poohsticks.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre1i In-Reply-To: <200005021724.LAA21159@chopper.Poohsticks.ORG> Organization: Targetnet.com Inc. Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Drew Eckhardt (drew@Poohsticks.Org) [000502 13:24]: > In message <20000502123910.C29330@targetnet.com>, james@targetnet.com writes: > >I am trying to run a Mylex Acceleraid 1100 in a Dell Poweredge 2450. > > What is a Dell Poweredge 2450, in terms of chipset and processors? Dual 600 PIII, 256k cache. 512mb PC133 RAM. Serverworks RCC LE chipset. Adaptec 7899 Ultra160 SCSI controller. > To add another datapoint: > > I just swapped the 350MHz PII in my Super Micro P6DGS (your generic > 440GX dual slot-1 board) for a pair of PIII600Es. Since then, I have been > getting panics under both 4.0 and 5.0 current from trap 29 that seem > correlated to IDE disk I/O load. > > The first crash dump I grabbed showed that the faulting address was > idle_loop + 64, which is at the cli instruction. > > Trap 29 could come from processor fault 19 (SIMD), an APIC, or PIC. Since > cli isn't a SIMD instruction, I suspect the APICs or PICs but have yet to > instrument and test this hypothesis. > > > tf_eip = -1071757093, tf_cs = 8, tf_eflags = 582, tf_esp = 0, > > tf_ss = -8359936}) at ../../i386/i386/trap.c:586 > >(kgdb) > > What do you get when you feed kgdb > > frame 3 > info line * (void *)frame->tf_eip (kgdb) info line * (void *)frame->tf_eip No line number information available for address 0xc01e48db (kgdb) Well, at least that matches it to your problem. -- j. James FitzGibbon james@targetnet.com Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue May 2 11:31:23 2000 Delivered-To: freebsd-smp@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 1417E37B585 for ; Tue, 2 May 2000 11:31:16 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id LAA16510; Tue, 2 May 2000 11:29:15 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp04.primenet.com, id smtpdAAA9daaKF; Tue May 2 11:28:25 2000 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id LAA21651; Tue, 2 May 2000 11:28:31 -0700 (MST) From: Terry Lambert Message-Id: <200005021828.LAA21651@usr01.primenet.com> Subject: Re: hlt instructions and temperature issues To: smp@csn.net (Steve Passe) Date: Tue, 2 May 2000 18:28:31 +0000 (GMT) Cc: djb@ifa.au.dk, kpielorz@tdx.co.uk (Karl Pielorz), smp@FreeBSD.ORG In-Reply-To: <200004301511.JAA16392@Ilsa.StevesCafe.com> from "Steve Passe" at Apr 30, 2000 09:11:12 AM 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 > > A matter of choice. And there isn't just a speed decrease, there can be an > > increase also, as it was shown by Steve. > > As I said before, its "weird". I'm not ready to believe there is any speed > increase yet... I expected a decrease, I was just trying to determine how > much... IMO, there is still the stalling issue, unless IPI code is brought in. Someone should take Peter up on his "offer" to write the trivial IPI code, and test that, as well. Personally, I think restarting another CPU is worth the 6uS that Matt thinks it will take. We are talking latency here; we have worse latency as a result of context switching anyway, IMO. I personally don't believe that there will be 5% overhead to this, and attribute the observed behaviour to stalling with a CPU coming idle with nothing in the ready-to-run. Whether there is stuff in the ready-to-run is the gating factor, I believe, between your benchmarks results. Also note that there is some minor destruction of affinity, and that a small affinity patch would probably be a heck of a lot more relevent. You wouldn't need to IPI, except when leaving the scheduler with the choice to migrate processes to another CPU's scheduler queue. This would be a significant win, and take only a minor amount of code, at the same time making the need for the BGL to go away for most scheduler operations (you would only need to grab the BGL when a lck cmpexchg resulted in a conflict). 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 Tue May 2 11:32:44 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 CBBFC37B524 for ; Tue, 2 May 2000 11:32:39 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id LAA26882; Tue, 2 May 2000 11:32:15 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp02.primenet.com, id smtpdAAALja4u0; Tue May 2 11:32:03 2000 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id LAA21819; Tue, 2 May 2000 11:32:19 -0700 (MST) From: Terry Lambert Message-Id: <200005021832.LAA21819@usr01.primenet.com> Subject: Re: hlt instructions and temperature issues To: djb@ifa.au.dk Date: Tue, 2 May 2000 18:32:18 +0000 (GMT) Cc: smp@csn.net (Steve Passe), kpielorz@tdx.co.uk (Karl Pielorz), smp@FreeBSD.ORG In-Reply-To: <20000501161626.A4317@relativity.student.utwente.nl> from "Dave Boers" at May 01, 2000 04:16:26 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 [ ... sysctl ... ] > This looks like an excellent proposal. Does anyone have comments, or could > someone with experience" in this area provide a patch? As an experiment to convince people, this is OK. As a permanent change, it's wrong. Without handling the stalling case, the code is incorrect, and _will_ result in poorer performance on the first idle/resource wait. As an alternative, I suggest someone run multiple programs that can get I/O bound, and then swap the vector out from under the processors, thus enabling the hlt. This should stall all but one processor, as handling the interrupt requires the BGL, and the BGL will be held by a single CPU most of the time as a result of an I/O bound program. Basically, this means that everything but one CPU will hlt, and that it will hlt too, with only one CPU waking up when an interrupt happens on the I/O completion. 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 Tue May 2 11:40:44 2000 Delivered-To: freebsd-smp@freebsd.org Received: from frond.minions.com (adsl-63-192-211-186.dsl.snfc21.pacbell.net [63.192.211.186]) by hub.freebsd.org (Postfix) with ESMTP id 62A7C37B7BC for ; Tue, 2 May 2000 11:40:40 -0700 (PDT) (envelope-from bifrost@minions.com) Received: from localhost.minions.com (localhost.minions.com [127.0.0.1]) by frond.minions.com (8.9.3/8.9.3) with ESMTP id LAA70934; Tue, 2 May 2000 11:39:34 -0700 (PDT) (envelope-from bifrost@minions.com) Date: Tue, 2 May 2000 11:39:34 -0700 (PDT) From: Tom To: Michael Enkelis Cc: smp@FreeBSD.ORG Subject: Re: Networking: bridgeing In-Reply-To: <004801bfb44d$a8301c70$703891c6@mxim.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 > At which version of FreeBSD was bridging enabled? Or do I need a "bridge" > daemon? I believe its been in there since 2.2.8 I've used it in 3.2-3.4 and it worked pretty well. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue May 2 12:11:11 2000 Delivered-To: freebsd-smp@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 5661F37BCEC for ; Tue, 2 May 2000 12:10:58 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id LAA08760; Tue, 2 May 2000 11:52:31 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp01.primenet.com, id smtpdAAALGaqpq; Tue May 2 11:51:44 2000 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id LAA22601; Tue, 2 May 2000 11:51:23 -0700 (MST) From: Terry Lambert Message-Id: <200005021851.LAA22601@usr01.primenet.com> Subject: Re: hlt instructions and temperature issues To: BHechinger@half.com (Brian Hechinger) Date: Tue, 2 May 2000 18:51:23 +0000 (GMT) Cc: tlambert@primenet.com ('Terry Lambert'), BHechinger@half.com (Brian Hechinger), dillon@apollo.backplane.com, jgowdy@home.com, smp@csn.net, jim@thehousleys.net, freebsd-smp@FreeBSD.ORG In-Reply-To: from "Brian Hechinger" at Apr 28, 2000 11:45:43 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 > >No. The point is that the CPUs run hotter, which means shorter > >batter life, more power consumption, higher cooling requirements, > >and limitations on installtion in close space, as a result. > > so there is no super-critical need for CPU idling. Not unless you have power or heat dissipation issues for a particular use case. For the vast majority of users, it's meaningless, unless they have philosophical instead of technical reasons (e.g. they are environmentalists, etc.). > >about a six instruction latency overall, counting the code in > >the scheduler and the halt and wakeup overhead. This will vary > >from processor to processor, based on the voodoo necessary to > >make it work. > > but very acceptable for the gains. If the gains are purely thermal, perhaps not. It does introduce an additional context switch latency, when leaving the scheduler, for the CPU that is running -- this means that it penalizes the IPI sending CPU to wake up the receiving CPU. But I think that if this is done correctly, this will be practically unmeasurable. > >> would there be a significant increase in speed if we could > >> avoid this? > > > >Hotter processors run fractionally slower. All in all, it's > >about a wash, in terms of processor effectiveness. The real > >wins are heat dissipation and power consumption. > > so those super-cryo CPU cooling units are hype. :) Not if they actually cool the CPU. > so no "real" usefulness for such a beast, only overly comlicated code? IMO, the utility is more in the ability to prepare the kernel for further change in the direction of per CPU run queues. This will require an interlock and IPI for process migration from CPU #1's run queue to CPU #N's run queue. The benefit to doing this is processor affinity for processes. Right now, if a CPU comes into the scheduler, the process at the top of the run queue gets the CPU. This results in cache busting. Consider that in an 8 processor system, there is only a 12.5% probability of getting the same CPU you were using last time, and thus there is an 87.5% probability of a cache bust. People who don't know any better commonly claim that the SMP scalaing on shared memory multiprocessor architectures is limited to about 4 processors before you hit a wall of diminishing returns for additional processors. This is not true, unless you are doing a lot of interprocessor communication; this will not commonly happen in practice, unless you do the wrong things and let it happen through bad design. If all of your engines are work-to-do engines, then they are practically identical, except for cache contents, and there is little or no need to communicate between them. For example, there's little reason that an HTTP server with 8 engines can not run one engine per processor, keep persistant connections (HTTP 1.1 spec.), and operate almost wholly independantly from one another. 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 Tue May 2 13:30:34 2000 Delivered-To: freebsd-smp@freebsd.org Received: from timingpdc.timing.com (timingpdc.timing.com [206.168.13.194]) by hub.freebsd.org (Postfix) with ESMTP id 22A2237B52B for ; Tue, 2 May 2000 13:30:29 -0700 (PDT) (envelope-from smp@timing.com) Received: from RoadRunner.timing.com ([206.168.13.190]) by timingpdc.timing.com (Post.Office MTA v3.1.2 release (PO205-101c) ID# 103-49575U100L2S100) with ESMTP id AAA442; Tue, 2 May 2000 14:31:00 -0600 Received: from RoadRunner.timing.com (localhost [127.0.0.1]) by RoadRunner.timing.com (8.9.3/8.9.3) with ESMTP id OAA13797; Tue, 2 May 2000 14:30:15 -0600 (MDT) (envelope-from smp@RoadRunner.timing.com) Message-Id: <200005022030.OAA13797@RoadRunner.timing.com> X-Mailer: exmh version 2.0.2 2/24/98 From: Steve Passe To: freebsd-smp@FreeBSD.ORG Cc: tlambert@primenet.com ('Terry Lambert'), BHechinger@half.com (Brian Hechinger), dillon@apollo.backplane.com, jgowdy@home.com, smp@timing.com, jim@thehousleys.net Subject: Re: hlt instructions and temperature issues Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 May 2000 14:30:14 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, > The benefit to doing this is processor affinity for processes. > > Right now, if a CPU comes into the scheduler, the process at > the top of the run queue gets the CPU. This results in cache > busting. Not exactly true, there is CPU affinity code in kern_switch.c: /* * chooseproc() selects the next process to run. Ideally, cpu_switch() * would have determined that there is a process available before calling * this, but it is not a requirement. The selected process is removed * from it's queue, and the queue busy bit is cleared if it becomes empty. * This must be called at splhigh(). * * For SMP, trivial affinity is implemented by locating the first process * on the queue that has a matching lastcpu id. Since normal priorities * are mapped four priority levels per queue, this may allow the cpu to * choose a slightly lower priority process in order to preserve the cpu * caches. */ struct proc * chooseproc(void) -- Steve Passe | powered by smp@timing.com | Symmetric MultiProcessor FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue May 2 14:17:50 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 0A1CA37B705 for ; Tue, 2 May 2000 14:17:38 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id OAA04341; Tue, 2 May 2000 14:16:43 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpdAAAPwaaoi; Tue May 2 14:16:35 2000 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id OAA00637; Tue, 2 May 2000 14:16:48 -0700 (MST) From: Terry Lambert Message-Id: <200005022116.OAA00637@usr02.primenet.com> Subject: Re: hlt instructions and temperature issues To: smp@timing.com (Steve Passe) Date: Tue, 2 May 2000 21:16:47 +0000 (GMT) Cc: freebsd-smp@FreeBSD.ORG, tlambert@primenet.com ('Terry Lambert'), BHechinger@half.com (Brian Hechinger), dillon@apollo.backplane.com, jgowdy@home.com, smp@timing.com, jim@thehousleys.net In-Reply-To: <200005022030.OAA13797@RoadRunner.timing.com> from "Steve Passe" at May 02, 2000 02:30:14 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 > > The benefit to doing this is processor affinity for processes. > > > > Right now, if a CPU comes into the scheduler, the process at > > the top of the run queue gets the CPU. This results in cache > > busting. > > Not exactly true, there is CPU affinity code in kern_switch.c: > > /* > * chooseproc() selects the next process to run. Ideally, cpu_switch() > * would have determined that there is a process available before calling > * this, but it is not a requirement. The selected process is removed > * from it's queue, and the queue busy bit is cleared if it becomes empty. > * This must be called at splhigh(). > * > * For SMP, trivial affinity is implemented by locating the first process > * on the queue that has a matching lastcpu id. Since normal priorities > * are mapped four priority levels per queue, this may allow the cpu to > * choose a slightly lower priority process in order to preserve the cpu > * caches. > */ > struct proc * > chooseproc(void) The code calls itself trivial. I mentioned this when it was first proposed, and then again when it went in, but it is the CPU affinity equivalent of adopting SVR3 shared library technology back in 1993 when that code was provided, but not adopted, by the then patchkit project, because it would have been one step forward, but required two steps back before it could go forward again (this time on the correct path). I'm talking affinity of the order where you can in fact bind a process to a processor, and damn the migration preferences of the scheduler, when it has no other work it can do without a migration event. This should probably be the default case, with a potential for a load based override policy for migration. It's a policy issue. This boils down to per CPU run queues that don't require holding the BGL in order to run, and use a simple spinlock to grab their own queue (said lock will always be granted, unless there is a processor in the process of migrating something from its run queue to tht of the CPU in question. The ability to scale well to a large number of processors is a function of reducing the amount of communication which has to occur between processors, and thus the contention. The real problem, I perceive, is that people are getting blinded by the idea that kernel threads are the end-all and be-all of programming Nirvana, and that they are not considering the much more common cases of normal processes running on SMP systems. Even in the threads case, there are strong arguments for locking threads to processors, unless there is a lot of IPC, in which case you probably should have designed the code to do the job in a single address/affinity/cache space, since the overhead of doing otherwise will exceed the benefit of having multiple CPUs on the job. The simple affinity that is currently implemented is deleterious, in that it can hold the BGL for longer, resulting in a stall of the other processors waiting to acquire the BGL for their own entry into the scheduler, a fault handler, or otherwise get into the kernel. Everyone fighting for access to a system wide queue is not a nice thing. We should remember that on CPU bound tasks, the CPUs will stay in user space for almost the entirety of the quantum, whereas for I/O or memory bound processes, there will be significant thrashing if one does not code against it. This is one of the primary reasons that using kernel threads to handle interrupts is a bad idea: it increases contention, with the dubious benefit that 2nd year CS students will be able to follow the code without an architecture document (which should be written, instead) in their hand. Really, SMP wants to be able to treat each CPU as running in its own machine, with contention only occurring on IP or access to shared resources. This includes per processor resource pools, and the ability to fill/drain these from system-wide resources, as well as for the system to request resources back in low resource conditions, including perhaps lowering the low water mark at which a refill occurs, or the high water mark at which a CPU will return resources to the system pool. Some of this is antithetical to a SLAB allocator; the Dynix model is probably to be preferred in this case. There are also retention time issues, which can be worked around by grading the persistance of an allocation (high/medium/low), and using seperate zones for these allocations. This applies to resources other than memory or access to the ready-to-run queues. For example, it's likely to be a significant win to be able to ensure that no single CPU is monopolizing the tagged command queues in the disk subsystem, etc.. It all starts with the scheduler. Another example might be dividing the process table into per CPU zones, and then only write-locking a single zone at a time, so that readers can concurrently access the remaining zones to iterate processes, etc.. For the purpose of waking up a hlt'ed CPU, it could be done when whichever CPU handles the interrupt for completion which results in something coming alive on its ready-to-run queue, by way of a wakeup IPI; although ideally, the interrupt would be routed to the waiter, one could concieve of multiple waiters (e.g. loading the index.html into cache for the top level page of a web site) where that wouldn't be possible. It seems to me that there are circumstances where it is more desirable to hlt a CPU than it is to give it other work which would result in a cache bust. 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 Wed May 3 1: 7:17 2000 Delivered-To: freebsd-smp@freebsd.org Received: from pollux.sdata.de (pollux.sdata.de [193.30.133.37]) by hub.freebsd.org (Postfix) with ESMTP id D40F237B9B1 for ; Wed, 3 May 2000 01:06:59 -0700 (PDT) (envelope-from cs@sdata.de) Received: from sdata.de (vega.sdata.de [193.30.133.36]) by pollux.sdata.de (8.9.3/8.9.3) with ESMTP id KAA10780; Wed, 3 May 2000 10:05:41 +0200 (CEST) (envelope-from cs@sdata.de) Message-ID: <390FDDD5.41EC0293@sdata.de> Date: Wed, 03 May 2000 10:05:41 +0200 From: Christoph Splittgerber Organization: sdata - C. Splittgerber Datentechnik X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 3.4-STABLE i386) X-Accept-Language: de, en MIME-Version: 1.0 To: Terry Lambert Cc: Brian Hechinger , dillon@apollo.backplane.com, jgowdy@home.com, smp@csn.net, jim@thehousleys.net, freebsd-smp@FreeBSD.ORG Subject: Re: hlt instructions and temperature issues References: <200005021851.LAA22601@usr01.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Terry Lambert wrote: > [] > If the gains are purely thermal, perhaps not. It does introduce > an additional context switch latency, when leaving the scheduler, > for the CPU that is running -- this means that it penalizes the > IPI sending CPU to wake up the receiving CPU. But I think that > if this is done correctly, this will be practically unmeasurable. > But isn't this discussion useless anyway, since we have seti@home ? :-) :-) Christoph To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed May 3 6:17:42 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by hub.freebsd.org (Postfix) with ESMTP id D46CB37BB81; Wed, 3 May 2000 06:17:30 -0700 (PDT) (envelope-from stefan@syprix.se) Received: from d1o49.telia.com (d1o49.telia.com [195.198.194.241]) by mailg.telia.com (8.9.3/8.9.3) with ESMTP id PAA17499; Wed, 3 May 2000 15:17:25 +0200 (CEST) Received: from prutten (t2o79p112.telia.com [62.20.200.232]) by d1o49.telia.com (8.8.8/8.8.8) with SMTP id PAA18430; Wed, 3 May 2000 15:17:24 +0200 (CEST) Message-ID: <001101bfb503$1201cb20$070ba8c0@syprix.com> From: "Stefan Lindgren" To: Cc: , Subject: Epox Dual MB... Date: Wed, 3 May 2000 15:25:37 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01BFB513.D4FB2C60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_000E_01BFB513.D4FB2C60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Does anybody have experience with this Epox MB? http://www.epox.com/html/english/products/motherboard/ep-bxb-s.htm 1 GB Ram 2 Pentium III Slot 1 650 MHz Matrox Mill G400 360 Ramdac UW SCSI I'm planning to run 4.0-RELEASE. Also, if anybody have experience with FBSD and a Raid(HW) solution for 300 - 500 GB I should be delighted to share his/hers toughts e t c. It's going to run a Web hotel with *all* fancy stuff... Regards /Stefan ------=_NextPart_000_000E_01BFB513.D4FB2C60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
Does anybody have experience with this = Epox=20 MB?
http://www.epox.com/html/english/products/motherboard/ep-bxb-s.htm=
 
1 GB Ram
2 Pentium III Slot 1 650 = MHz
Matrox Mill G400 360 = Ramdac
UW SCSI
 
I'm planning to run = 4.0-RELEASE.
 
Also, if anybody have experience with = FBSD and a=20 Raid(HW) solution for
300 - 500 GB I should be delighted to = share=20 his/hers toughts e t c.
 
It's going to run a Web hotel with = *all* fancy=20 stuff...
 
 
Regards
 
 
/Stefan
------=_NextPart_000_000E_01BFB513.D4FB2C60-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed May 3 11:38:17 2000 Delivered-To: freebsd-smp@freebsd.org Received: from relativity.student.utwente.nl (wit389306.student.utwente.nl [130.89.234.166]) by hub.freebsd.org (Postfix) with ESMTP id 3595937BADE for ; Wed, 3 May 2000 11:38:15 -0700 (PDT) (envelope-from djb@wit389306.student.utwente.nl) Received: by relativity.student.utwente.nl (Postfix, from userid 1000) id B13BD5DF0; Wed, 3 May 2000 20:38:24 +0200 (CEST) Date: Wed, 3 May 2000 20:38:24 +0200 From: Dave Boers To: Terry Lambert Cc: Steve Passe , Karl Pielorz , smp@FreeBSD.ORG Subject: Re: hlt instructions and temperature issues Message-ID: <20000503203824.A36383@relativity.student.utwente.nl> Reply-To: djb@ifa.au.dk References: <200004301511.JAA16392@Ilsa.StevesCafe.com> <200005021828.LAA21651@usr01.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200005021828.LAA21651@usr01.primenet.com>; from tlambert@primenet.com on Tue, May 02, 2000 at 06:28:31PM +0000 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, May 02, 2000 at 06:28:31PM +0000, Terry Lambert wrote: > Someone should take Peter up on his "offer" to write the trivial > IPI code, and test that, as well. I'm willing to test. Bring on the patches. Regards, Dave. -- djb@ifa.au.dk d.j.boers@tn.utwente.nl PGP key: ftp://relativity.student.utwente.nl:/pub/pgpkeys/djb.asc In the land of the blind, the one-eyed man is murdered for heresy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed May 3 17:24:31 2000 Delivered-To: freebsd-smp@freebsd.org Received: from canonware.com (canonware.com [199.181.107.39]) by hub.freebsd.org (Postfix) with SMTP id 6CD6837BA2F for ; Wed, 3 May 2000 17:24:29 -0700 (PDT) (envelope-from jasone@canonware.com) Received: (qmail 77990 invoked by uid 1001); 4 May 2000 00:14:20 -0000 Date: Wed, 3 May 2000 17:14:20 -0700 From: Jason Evans To: "Richard Seaman, Jr." Cc: =?iso-8859-1?Q?Ivan_Debn=E1r?= , freebsd-smp@FreeBSD.ORG Subject: Re: Native threads and SMP Message-ID: <20000503171420.H65569@sturm.canonware.com> References: <20000502063602.B61185@seaman.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0.1i In-Reply-To: <20000502063602.B61185@seaman.org>; from dick@seaman.org on Tue, May 02, 2000 at 06:36:02AM -0500 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, May 02, 2000 at 06:36:02AM -0500, Richard Seaman, Jr. wrote: > On Tue, May 02, 2000 at 11:34:01AM +0200, Ivan Debnár wrote: > > Is there a plan to support SMP in the native FreeBSD threads implementation ? > > If Jason Evans is still working on it, then yes. Otherwise, I'm not aware > of anyone else working on it. Actually, libc_r has just gotten to the point where I can mainly concentrate on the new threads implementation, so I'm starting to work on it now. > > When using Linuxthreads from ports, trying to compile the aplications > >(even provided examples) "static", it breaks with: > > Yes, static linking has been broken for many months. Jason Evans made some > changes to siglongjmp and longjmp that broke static linking. He was made > aware of the problem, but has (so far) chosen to ignore the problem. *That's* why I have those diffs in my source tree! I think I have had fixes for this for a long time, but I totally forgot there was a problem. I'll look into it this week. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed May 3 18: 5:31 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 C744037B56E for ; Wed, 3 May 2000 18:05:24 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id SAA18594; Wed, 3 May 2000 18:05:03 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp02.primenet.com, id smtpdAAAyMaqrK; Wed May 3 18:04:54 2000 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id SAA01849; Wed, 3 May 2000 18:05:11 -0700 (MST) From: Terry Lambert Message-Id: <200005040105.SAA01849@usr01.primenet.com> Subject: Re: hlt instructions and temperature issues To: BHechinger@half.com (Brian Hechinger) Date: Thu, 4 May 2000 01:05:11 +0000 (GMT) Cc: tlambert@primenet.com ('Terry Lambert'), BHechinger@half.com (Brian Hechinger), dillon@apollo.backplane.com, jgowdy@home.com, smp@csn.net, jim@thehousleys.net, freebsd-smp@FreeBSD.ORG In-Reply-To: from "Brian Hechinger" at May 02, 2000 05:24:28 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 > > This message is in MIME format. Since your mail reader does not understand > this format, some or all of this message may not be legible. > > ------_=_NextPart_001_01BFB47C.CC2E8B50 > Content-Type: text/plain; > charset="iso-8859-1" > > >> so there is no super-critical need for CPU idling. > > > >Not unless you have power or heat dissipation issues for a > >particular use case. For the vast majority of users, it's > >meaningless, unless they have philosophical instead of > >technical reasons (e.g. they are environmentalists, etc.). > > so, poorly design cases and tree huggers aside, we shouldn't see any > problems if this doesn't work. > > >> but very acceptable for the gains. > > > >If the gains are purely thermal, perhaps not. It does introduce > >an additional context switch latency, when leaving the scheduler, > >for the CPU that is running -- this means that it penalizes the > >IPI sending CPU to wake up the receiving CPU. But I think that > >if this is done correctly, this will be practically unmeasurable. > > i tried sending mail to the list, but the list doesn't like my mail server > all of a sudden, and i said (which applies here i believe): > > so if the giant spin-lock is broken down to CPU level spin-locks, would that > facilitate us doing this correctly? > > >> so those super-cryo CPU cooling units are hype. :) > > > >Not if they actually cool the CPU. > > but to what benefit. if a simple fan can do the job of keeping the CPU cool > enough, does over-cooling the CPU make things better, or does it not really > affect anything (besides cooling too much which is also bad from what i > understand) > > >> so no "real" usefulness for such a beast, only overly comlicated code? > > > >IMO, the utility is more in the ability to prepare the kernel > >for further change in the direction of per CPU run queues. This > >will require an interlock and IPI for process migration from > >CPU #1's run queue to CPU #N's run queue. > > so the HLT issue may belong to something bigger and it wouldn't hurt to look > into it. > > >The benefit to doing this is processor affinity for processes. > > > >Right now, if a CPU comes into the scheduler, the process at > >the top of the run queue gets the CPU. This results in cache > >busting. Consider that in an 8 processor system, there is only > >a 12.5% probability of getting the same CPU you were using last > >time, and thus there is an 87.5% probability of a cache bust. > > but this can be controlled because we can tell which CPU the process last > ran on? > > >People who don't know any better commonly claim that the SMP > >scalaing on shared memory multiprocessor architectures is > >limited to about 4 processors before you hit a wall of diminishing > >returns for additional processors. This is not true, unless you > >are doing a lot of interprocessor communication; this will not > >commonly happen in practice, unless you do the wrong things and > >let it happen through bad design. If all of your engines are > >work-to-do engines, then they are practically identical, except > >for cache contents, and there is little or no need to communicate > >between them. > > the usual if it's done right in the first place mantra. :) > > but doesn't SUN use shared memory MP arch? if so, they put as many as 64 > CPUs in a single box. i tend to believe that SUN knows what they are doing > considering how long they have been doing it. :) > > >For example, there's little reason that an HTTP server with 8 > >engines can not run one engine per processor, keep persistant > >connections (HTTP 1.1 spec.), and operate almost wholly > >independantly from one another. > > or something like SETI@home, which never has to talk to the other clients > (and in fact doesn't even know they exist) > > so again i see us falling back to if it's written right in the first > place..... > > cheers, > > -brian > ps: thanks for trying to get me to understand this. i appreciate it. > > ------_=_NextPart_001_01BFB47C.CC2E8B50 > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > > > charset=3Diso-8859-1"> > 5.5.2651.75"> > RE: hlt instructions and temperature issues > > > >

>> so there is no super-critical need for CPU = > idling. >
> >
>Not unless you have power or heat dissipation = > issues for a >
>particular use case.  For the vast majority = > of users, it's >
>meaningless, unless they have philosophical = > instead of >
>technical reasons (e.g. they are = > environmentalists, etc.). >

> >

so, poorly design cases and tree huggers aside, we = > shouldn't see any problems if this doesn't work. >

> >

>> but very acceptable for the gains. >
> >
>If the gains are purely thermal, perhaps = > not.  It does introduce >
>an additional context switch latency, when = > leaving the scheduler, >
>for the CPU that is running -- this means that = > it penalizes the >
>IPI sending CPU to wake up the receiving = > CPU.  But I think that >
>if this is done correctly, this will be = > practically unmeasurable. >

> >

i tried sending mail to the list, but the list = > doesn't like my mail server all of a sudden, and i said (which applies = > here i believe):

> >

so if the giant spin-lock is broken down to CPU level = > spin-locks, would that facilitate us doing this correctly? >

> >

>> so those super-cryo CPU cooling units are = > hype. :) >
> >
>Not if they actually cool the CPU. >

> >

but to what benefit.  if a simple fan can do the = > job of keeping the CPU cool enough, does over-cooling the CPU make = > things better, or does it not really affect anything (besides cooling = > too much which is also bad from what i understand)

> >

>> so no "real" usefulness for such a = > beast, only overly comlicated code? >
> >
>IMO, the utility is more in the ability to = > prepare the kernel >
>for further change in the direction of per CPU = > run queues.  This >
>will require an interlock and IPI for process = > migration from >
>CPU #1's run queue to CPU #N's run queue. >

> >

so the HLT issue may belong to something bigger and = > it wouldn't hurt to look into it. >

> >

>The benefit to doing this is processor affinity = > for processes. >
> >
>Right now, if a CPU comes into the scheduler, = > the process at >
>the top of the run queue gets the CPU.  = > This results in cache >
>busting.  Consider that in an 8 processor = > system, there is only >
>a 12.5% probability of getting the same CPU you = > were using last >
>time, and thus there is an 87.5% probability of = > a cache bust. >

> >

but this can be controlled because we can tell which = > CPU the process last ran on? >

> >

>People who don't know any better commonly claim = > that the SMP >
>scalaing on shared memory multiprocessor = > architectures is >
>limited to about 4 processors before you hit a = > wall of diminishing >
>returns for additional processors.  This is = > not true, unless you >
>are doing a lot of interprocessor communication; = > this will not >
>commonly happen in practice, unless you do the = > wrong things and >
>let it happen through bad design.  If all = > of your engines are >
>work-to-do engines, then they are practically = > identical, except >
>for cache contents, and there is little or no = > need to communicate >
>between them. >

> >

the usual if it's done right in the first place = > mantra. :) >

> >

but doesn't SUN use shared memory MP arch?  if = > so, they put as many as 64 CPUs in a single box.  i tend to = > believe that SUN knows what they are doing considering how long they = > have been doing it.  :)

> >

>For example, there's little reason that an HTTP = > server with 8 >
>engines can not run one engine per processor, = > keep persistant >
>connections (HTTP 1.1 spec.), and operate almost = > wholly >
>independantly from one another. >

> >

or something like SETI@home, which never has to talk = > to the other clients (and in fact doesn't even know they exist) >

> >

so again i see us falling back to if it's written = > right in the first place..... >

> >

cheers, >

> >

-brian >
ps: thanks for trying to get me to understand = > this.  i appreciate it. >

> > > > ------_=_NextPart_001_01BFB47C.CC2E8B50-- > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed May 3 18: 6:53 2000 Delivered-To: freebsd-smp@freebsd.org Received: from smtp09.phx.gblx.net (smtp09.phx.gblx.net [206.165.6.139]) by hub.freebsd.org (Postfix) with ESMTP id 6273D37B9DD for ; Wed, 3 May 2000 18:06:49 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp09.phx.gblx.net (8.9.3/8.9.3) id SAA11354; Wed, 3 May 2000 18:06:47 -0700 Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp09.phx.gblx.net, id smtpdc6lfya; Wed May 3 18:06:40 2000 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id SAA01922; Wed, 3 May 2000 18:06:38 -0700 (MST) From: Terry Lambert Message-Id: <200005040106.SAA01922@usr01.primenet.com> Subject: Re: hlt instructions and temperature issues To: cs@sdata.de (Christoph Splittgerber) Date: Thu, 4 May 2000 01:06:38 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), BHechinger@half.com (Brian Hechinger), dillon@apollo.backplane.com, jgowdy@home.com, smp@csn.net, jim@thehousleys.net, freebsd-smp@FreeBSD.ORG In-Reply-To: <390FDDD5.41EC0293@sdata.de> from "Christoph Splittgerber" at May 03, 2000 10:05:41 AM 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 > Terry Lambert wrote: > > If the gains are purely thermal, perhaps not. It does introduce > > an additional context switch latency, when leaving the scheduler, > > for the CPU that is running -- this means that it penalizes the > > IPI sending CPU to wake up the receiving CPU. But I think that > > if this is done correctly, this will be practically unmeasurable. > > But isn't this discussion useless anyway, since we have seti@home ? :-) :-) Depends on if it's ever in an I/O wait; if it is, the CPU can be halted until the interrupt occurs on the I/O completion. "What, seti@home in an I/O wait? Perish the thought!". 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 Wed May 3 19:23:18 2000 Delivered-To: freebsd-smp@freebsd.org Received: from freeway.dcfinc.com (cx74889-a.phnx3.az.home.com [24.1.193.157]) by hub.freebsd.org (Postfix) with ESMTP id E0A0137B9FD for ; Wed, 3 May 2000 19:23:14 -0700 (PDT) (envelope-from chad@freeway.dcfinc.com) Received: (from chad@localhost) by freeway.dcfinc.com (8.8.8/8.8.8) id TAA05907; Wed, 3 May 2000 19:22:06 -0700 (MST) (envelope-from chad) From: "Chad R. Larson" Message-Id: <200005040222.TAA05907@freeway.dcfinc.com> Subject: Re: hlt instructions and temperature issues In-Reply-To: <200005040106.SAA01922@usr01.primenet.com> from Terry Lambert at "May 4, 0 01:06:38 am" To: tlambert@primenet.com (Terry Lambert) Date: Wed, 3 May 2000 19:22:04 -0700 (MST) Cc: cs@sdata.de, tlambert@primenet.com, BHechinger@half.com, dillon@apollo.backplane.com, jgowdy@home.com, smp@csn.net, jim@thehousleys.net, freebsd-smp@FreeBSD.ORG Reply-To: chad@DCFinc.com X-Mailer: ELM [version 2.4ME+ PL40 (25)] 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 As I recall, Terry Lambert wrote: > > "What, seti@home in an I/O wait? Perish the thought!". It writes to the filesystem every second or so, updating its checkpoint file. -crl -- Chad R. Larson (CRL15) 602-953-1392 Brother, can you paradigm? chad@dcfinc.com chad@larsons.org larson1@home.net DCF, Inc. - 14623 North 49th Place, Scottsdale, Arizona 85254-2207 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed May 3 20:49:53 2000 Delivered-To: freebsd-smp@freebsd.org Received: from sharmas.dhs.org (c62443-a.frmt1.sfba.home.com [24.0.69.165]) by hub.freebsd.org (Postfix) with ESMTP id 66A8537B608 for ; Wed, 3 May 2000 20:49:51 -0700 (PDT) (envelope-from adsharma@sharmas.dhs.org) Received: (from adsharma@localhost) by sharmas.dhs.org (8.9.3/8.9.3) id UAA21083; Wed, 3 May 2000 20:49:25 -0700 Date: Wed, 3 May 2000 20:49:25 -0700 From: Arun Sharma Message-Id: <200005040349.UAA21083@sharmas.dhs.org> To: jasone@canonware.com, smp@freebsd.org Subject: Re: Native threads and SMP In-Reply-To: <20000503171420.H65569@sturm.canonware.com> References: <20000502063602.B61185@seaman.org> <20000503171420.H65569@sturm.canonware.com> Reply-To: adsharma@sharmas.dhs.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In muc.lists.freebsd.smp, you wrote: > > > > If Jason Evans is still working on it, then yes. Otherwise, I'm not aware > > of anyone else working on it. > > Actually, libc_r has just gotten to the point where I can mainly > concentrate on the new threads implementation, so I'm starting to work on > it now. Is this the scheduler activation based stuff, many-to-many or one-to-one ? Are you going to be doing this work on the -current tree ? -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed May 3 20:54:21 2000 Delivered-To: freebsd-smp@freebsd.org Received: from canonware.com (canonware.com [199.181.107.39]) by hub.freebsd.org (Postfix) with SMTP id C26CC37B608 for ; Wed, 3 May 2000 20:54:19 -0700 (PDT) (envelope-from jasone@canonware.com) Received: (qmail 78576 invoked by uid 1001); 4 May 2000 03:44:09 -0000 Date: Wed, 3 May 2000 20:44:09 -0700 From: Jason Evans To: Arun Sharma Cc: smp@freebsd.org Subject: Re: Native threads and SMP Message-ID: <20000503204408.J65569@sturm.canonware.com> References: <20000502063602.B61185@seaman.org> <20000503171420.H65569@sturm.canonware.com> <200005040349.UAA21083@sharmas.dhs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200005040349.UAA21083@sharmas.dhs.org>; from adsharma@sharmas.dhs.org on Wed, May 03, 2000 at 08:49:25PM -0700 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, May 03, 2000 at 08:49:25PM -0700, Arun Sharma wrote: > Is this the scheduler activation based stuff, many-to-many or one-to-one ? > Are you going to be doing this work on the -current tree ? The implementation will most closely resemble scheduler activations. Yes, the work is being done on -current. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu May 4 11:56:59 2000 Delivered-To: freebsd-smp@freebsd.org Received: from inc.net (mailhost.inc.net [204.95.160.26]) by hub.freebsd.org (Postfix) with ESMTP id A1A4437C256 for ; Thu, 4 May 2000 11:56:42 -0700 (PDT) (envelope-from steve@inc.net) Received: from inc.net (niki.pwke.twtelecom.net [207.250.66.46]) by inc.net (8.9.3/8.9.1) with ESMTP id NAA08748 for ; Thu, 4 May 2000 13:56:30 -0500 (CDT) Message-ID: <3911C746.AE662230@inc.net> Date: Thu, 04 May 2000 13:53:58 -0500 From: Steve Kaczkowski Organization: Time Warner Telecom - IDD X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-smp@freebsd.org Subject: General slowness with SMP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hey all! Here's my setup: Intel N440BX MB Dual P3 550Es @ 550 1 gig of RAM Using built in Symbios 875 SCSI Mylex DAC960SX External RAID controller Dual IBM 18ES (18 gig) UltraWide (Mirrored) Running 4.0 Current (Was Release, but didn't matter. See below) Cricket,RRDtool,ModPerl 5, Apache 1.3.9 Ok, here's the situation. This box is setup to be a statistics collector using Cricket and RRDtool to pool routers,other boxes,etc,etc. Running in dual mode we'd notice all sorts of sluggish behavior like: Compile times on the Cricket database (basically perl just parsing the config tree and making a DB file) would climb and climb. A 650 target database was taking about 70-80 seconds (Refer to Single mode down below for more detail). When using things like VI there would be pauses when initially opening the file for editing. We'd also see pauses in the middle of editing a file, moving around,tabbing,etc. Pauses when untarring Umm.. Overall memory usage is fine, have about 730megs free, no swap. Everything seems to be ok... One thing I noticed is that when I'm doing a database compile (didn't take note of other processes like VI) is that the tasks will keep swapping back and forth between processors, seems to me that in itself would cause some speed issues. Anyway, no thinking this could be some sorta of strange SMP issue and decided to compile a single processor kernel to test the theory. Low and behold everything is working like a charm! Database compiles take about 8 seconds instead of 60-80! NO VI pauses Untarring is fine Everything is looking peachy.. Oh, I also tried CVS'n to Current with an SMP kernel which yielded the same results.. So the question is, what gives? I'm thinking that having tasks swapping processors isn't good in itself, but is there something else going on like file locking or some lower level processor locking issue that I don't know about? From looking around the forums it seems that people are having really good luck with SMP boxes, so I must be doing something totally wrong!? This is pretty much my first dive into FreeBSD SMP so I'm really not sure where or what to look at to help track this down and fix it.. Looking for any and all info... Thanks in advance! -- Steve Kaczkowski Time Warner Telecom IDD steve@inc.net (414)908-9012 http://www.inc.net (603)737-9209 Fax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu May 4 16:30:12 2000 Delivered-To: freebsd-smp@freebsd.org Received: from sigbus.com (sigbus.com [207.211.10.110]) by hub.freebsd.org (Postfix) with ESMTP id 10FA337B863 for ; Thu, 4 May 2000 16:30:09 -0700 (PDT) (envelope-from henrich@sigbus.com) Received: (from henrich@localhost) by sigbus.com (8.9.3/8.9.3) id QAA89803 for freebsd-smp@freebsd.org; Thu, 4 May 2000 16:30:08 -0700 (PDT) (envelope-from henrich) Date: Thu, 4 May 2000 16:30:08 -0700 From: Charles Henrich To: freebsd-smp@freebsd.org Subject: i840 Tyan Thunder Message-ID: <20000504163008.B89733@sigbus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i X-Operating-System: FreeBSD 3.3-RELEASE X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org When I boot up 4.0-REL it just hangs after plip initialization. Has anyone seen anything like this? I have NAPIC=2 and NBUS=6 -Crh Charles Henrich Manex Visual Effects henrich@sigbus.com http://www.sigbus.com/~henrich To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu May 4 16:46:10 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.234]) by hub.freebsd.org (Postfix) with ESMTP id BBCC737B628 for ; Thu, 4 May 2000 16:46:06 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id QAA45318; Thu, 4 May 2000 16:54:20 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200005042354.QAA45318@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Charles Henrich Cc: freebsd-smp@freebsd.org Subject: Re: i840 Tyan Thunder In-reply-to: Your message of "Thu, 04 May 2000 16:30:08 PDT." <20000504163008.B89733@sigbus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 May 2000 16:54:20 -0700 From: Mike Smith Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > When I boot up 4.0-REL it just hangs after plip initialization. Has anyone > seen anything like this? I have NAPIC=2 and NBUS=6 You will need a recent 4.0-stable to run SMP on this system; there are bugs in 4.0-release related to multiple I/O APIC implementations. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu May 4 16:49:54 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mxr01.nyc01.dsl.net (ns2.dsl.net [209.87.79.232]) by hub.freebsd.org (Postfix) with ESMTP id DC56F37BB2A for ; Thu, 4 May 2000 16:49:49 -0700 (PDT) (envelope-from eric@cdc.net) Received: from garfield (216-175-151-207.client.dsl.net [216.175.151.207]) by mxr01.nyc01.dsl.net (8.9.3/8.9.3) with SMTP id TAA21516; Thu, 4 May 2000 19:49:40 -0400 From: "Duncan, Eric A." To: "Charles Henrich" , Subject: RE: i840 Tyan Thunder Date: Thu, 4 May 2000 18:49:07 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001F_01BFB5F9.6D3E3220" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20000504163008.B89733@sigbus.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_001F_01BFB5F9.6D3E3220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes. FreeBSD is broke when it comes to more then one APICs. This was first discovered a few weeks ago. Attached is the patch to patch 4.0-RELEASE to work with multiple APICs. Regards, Eric Duncan eric@cdc.net -----Original Message----- From: owner-freebsd-smp@FreeBSD.ORG [mailto:owner-freebsd-smp@FreeBSD.ORG]On Behalf Of Charles Henrich Sent: Thursday, May 04, 2000 6:30 PM To: freebsd-smp@freebsd.org Subject: i840 Tyan Thunder When I boot up 4.0-REL it just hangs after plip initialization. Has anyone seen anything like this? I have NAPIC=2 and NBUS=6 -Crh Charles Henrich Manex Visual Effects henrich@sigbus.com http://www.sigbus.com/~henrich To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message ------=_NextPart_000_001F_01BFB5F9.6D3E3220 Content-Type: application/octet-stream; name="smp.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="smp.patch" Index: pmap.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /usr/src/sys/i386/i386/pmap.c,v=0A= retrieving revision 1.252=0A= diff -u -r1.252 pmap.c=0A= --- pmap.c 2000/03/16 08:51:49 1.252=0A= +++ pmap.c 2000/04/20 03:14:48=0A= @@ -426,9 +426,10 @@=0A= for (j =3D 0; j < mp_napics; j++) {=0A= /* same page frame as a previous IO apic? */=0A= if (((vm_offset_t)SMPpt[NPTEPG-2-j] & PG_FRAME) =3D=3D=0A= - (io_apic_address[0] & PG_FRAME)) {=0A= + (io_apic_address[i] & PG_FRAME)) {=0A= ioapic[i] =3D (ioapic_t *)((u_int)SMP_prvspace=0A= - + (NPTEPG-2-j)*PAGE_SIZE);=0A= + + (NPTEPG-2-j)*PAGE_SIZE=0A= + + (io_apic_address[i] & PAGE_MASK));=0A= break;=0A= }=0A= /* use this slot if available */=0A= @@ -436,7 +437,8 @@=0A= SMPpt[NPTEPG-2-j] =3D (pt_entry_t)(PG_V | PG_RW |=0A= pgeflag | (io_apic_address[i] & PG_FRAME));=0A= ioapic[i] =3D (ioapic_t *)((u_int)SMP_prvspace=0A= - + (NPTEPG-2-j)*PAGE_SIZE);=0A= + + (NPTEPG-2-j)*PAGE_SIZE=0A= + + (io_apic_address[i] & PAGE_MASK));=0A= break;=0A= }=0A= }=0A= =0A= =0A= =0A= =0A= =0A= =0A= /* To issue this patch, type: patch -p0 < smp.patch=0A= ------=_NextPart_000_001F_01BFB5F9.6D3E3220-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu May 4 18:26: 1 2000 Delivered-To: freebsd-smp@freebsd.org Received: from sigbus.com (sigbus.com [207.211.10.110]) by hub.freebsd.org (Postfix) with ESMTP id 5C1F137B578 for ; Thu, 4 May 2000 18:25:58 -0700 (PDT) (envelope-from henrich@sigbus.com) Received: (from henrich@localhost) by sigbus.com (8.9.3/8.9.3) id SAA90068; Thu, 4 May 2000 18:25:55 -0700 (PDT) (envelope-from henrich) Date: Thu, 4 May 2000 18:25:55 -0700 From: Charles Henrich To: "Duncan, Eric A." Cc: freebsd-smp@freebsd.org Subject: Re: i840 Tyan Thunder Message-ID: <20000504182555.A90051@sigbus.com> References: <20000504163008.B89733@sigbus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: X-Operating-System: FreeBSD 3.3-RELEASE X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On the subject of RE: i840 Tyan Thunder, Duncan, Eric A. stated: Worked wonders, thanks! > Yes. FreeBSD is broke when it comes to more then one APICs. This was first > discovered a few weeks ago. Attached is the patch to patch 4.0-RELEASE to > work with multiple APICs. > > > Regards, Eric Duncan > > eric@cdc.net > > > > -----Original Message----- From: owner-freebsd-smp@FreeBSD.ORG > [mailto:owner-freebsd-smp@FreeBSD.ORG]On Behalf Of Charles Henrich Sent: > Thursday, May 04, 2000 6:30 PM To: freebsd-smp@freebsd.org Subject: i840 > Tyan Thunder > > > When I boot up 4.0-REL it just hangs after plip initialization. Has anyone > seen anything like this? I have NAPIC=2 and NBUS=6 > > -Crh > > Charles Henrich Manex Visual Effects henrich@sigbus.com > > http://www.sigbus.com/~henrich > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe > freebsd-smp" in the body of the message Charles Henrich Manex Visual Effects henrich@sigbus.com http://www.sigbus.com/~henrich To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu May 4 19:14: 1 2000 Delivered-To: freebsd-smp@freebsd.org Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [206.168.13.65]) by hub.freebsd.org (Postfix) with ESMTP id 3986D37B581 for ; Thu, 4 May 2000 19:13:54 -0700 (PDT) (envelope-from fbsd@Ilsa.StevesCafe.com) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.9.3/8.9.3) with ESMTP id UAA49217; Thu, 4 May 2000 20:13:47 -0600 (MDT) (envelope-from fbsd@Ilsa.StevesCafe.com) Message-Id: <200005050213.UAA49217@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0.2 2/24/98 From: Steve Passe To: Steve Kaczkowski Cc: freebsd-smp@FreeBSD.ORG Subject: Re: General slowness with SMP In-reply-to: Your message of "Thu, 04 May 2000 13:53:58 CDT." <3911C746.AE662230@inc.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 May 2000 20:13:47 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, > Hey all! > > Here's my setup: > ... > Running in dual mode we'd notice all sorts of sluggish behavior like: > > Compile times on the Cricket database (basically perl just parsing > the config tree and making a DB file) would climb and climb. A > 650 target database was taking about 70-80 seconds (Refer to Single > mode down below for more detail). > > When using things like VI there would be pauses when initially opening > the file for editing. We'd also see pauses in the middle of editing > a file, moving around,tabbing,etc. > > Pauses when untarring > > Umm.. Overall memory usage is fine, have about 730megs free, no swap. > Everything > seems to be ok... > ... > This is pretty much my first dive into FreeBSD SMP so I'm really not > sure > where or what to look at to help track this down and fix it.. > > Looking for any and all info... Easiest way to guage "normal" FBSD SMP response would be to do a buildworld both UP and SMP: UP: rm -rf /usr/obj/* && cd /usr/src && time make -j4 buildworld SMP: rm -rf /usr/obj/* && cd /usr/src && time make -j8 buildworld Give us these times and we can say a little more... -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri May 5 13: 7:37 2000 Delivered-To: freebsd-smp@freebsd.org Received: from chopper.Poohsticks.ORG (chopper.poohsticks.org [63.227.60.73]) by hub.freebsd.org (Postfix) with SMTP id A360637BC41 for ; Fri, 5 May 2000 13:07:34 -0700 (PDT) (envelope-from drew@chopper.Poohsticks.ORG) Received: from chopper.Poohsticks.ORG (localhost.poohsticks.org [127.0.0.1]) by chopper.Poohsticks.ORG (8.6.12/8.6.6) with ESMTP id OAA28764 for ; Fri, 5 May 2000 14:07:33 -0600 Message-Id: <200005052007.OAA28764@chopper.Poohsticks.ORG> To: freebsd-smp@freebsd.org Subject: T_RESERVED prevention kludge MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28761.957557253.1@chopper.Poohsticks.ORG> Date: Fri, 05 May 2000 14:07:33 -0600 From: Drew Eckhardt Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following is against 4.0 stable, and includes Tor.Egge@fast.no's mask unused APIC pins patch. Before, half the time I couldn't build a kernel before I paniced. Now, I can survive five make buildworld -j 5s. Index: mpapic.c =================================================================== RCS file: /usr/local/cvs/src/sys/i386/i386/mpapic.c,v retrieving revision 1.37 diff -u -r1.37 mpapic.c --- mpapic.c 1999/12/15 19:17:08 1.37 +++ mpapic.c 2000/05/05 19:08:45 @@ -168,6 +168,27 @@ for (pin = 0; pin < maxpin; ++pin) { int bus, bustype, irq; + select = pin * 2 + IOAPIC_REDTBL0; /* register */ + /* + * Always disable interrupts, and by default map + * pin X to IRQX because the disable doesn't stick + * and the uninitialize vector will get translated + * into a panic. + * + * This is correct for IRQs 1 and 3-15. In the other cases, + * any robust driver will handle the spurious interrupt, and + * the effective NOP beats a panic. + * + * A dedicated "bogus interrupt" entry in the IDT would + * be a nicer hack, although some one should find out + * why some systems are generating interrupts when they + * shouldn't and stop the carnage. + */ + vector = NRSVIDT + pin; /* IDT vec */ + io_apic_write(apic, select, + (io_apic_read(apic, select) & ~IOART_INTMASK + & ~0xff)|IOART_INTMSET|vector); + /* we only deal with vectored INTs here */ if (apic_int_type(apic, pin) != 0) continue; @@ -209,7 +230,6 @@ if (apic != 0 || pin != irq) printf("IOAPIC #%d intpin %d -> irq %d\n", apic, pin, irq); - select = pin * 2 + IOAPIC_REDTBL0; /* register */ vector = NRSVIDT + irq; /* IDT vec */ io_apic_write(apic, select, flags | vector); io_apic_write(apic, select + 1, target); -- Home Page For those who do, no explanation is necessary. For those who don't, no explanation is possible. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri May 5 18:26:41 2000 Delivered-To: freebsd-smp@freebsd.org Received: from inc.net (mailhost.inc.net [204.95.160.26]) by hub.freebsd.org (Postfix) with ESMTP id 6BF2837BDBE for ; Fri, 5 May 2000 18:26:37 -0700 (PDT) (envelope-from steve@inc.net) Received: from inc.net (niki.pwke.twtelecom.net [207.250.66.46]) by inc.net (8.9.3/8.9.1) with ESMTP id UAA19941; Fri, 5 May 2000 20:26:31 -0500 (CDT) Message-ID: <3913741B.AFE526F8@inc.net> Date: Fri, 05 May 2000 20:23:39 -0500 From: Steve Kaczkowski Organization: Time Warner Telecom - IDD X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: smp@csn.net, freebsd-smp@freebsd.org Subject: Re: General slowness with SMP References: <200005050213.UAA49217@Ilsa.StevesCafe.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ok, here's my numbers for the buildworlds, I'm not sure how this looked on Release since I CVS'd it before doing a buildworld. Something changed from Release to Stable though since now it looks and acts right. I guess I'll see if I'm still getting the pauses with things, but compile times look good.. This is the UP 4.0 STABLE kernel: 3321.344u 721.170s 1:49:22.16 61.6% 1381+1461k 27364+287916io 1423pf+0w Here's the SMP 4.0 STABLE kernel: 3281.858u 1503.289s 1:15:40.96 105.3% 1260+1339k 27723+287900io 1437pf+0w Looks right to me, now check this out: > ./compile [05-May-2000 20:20:15 ] Starting compile: Cricket version 0.72 ( Sun Jan 23 23:54:35 PST 2000 ) [05-May-2000 20:20:23 ] Processed 1267 nodes (in 740 files) in 9 seconds. That was the thing that was taking over a minute before, what gives ?? WOW, I'm happy that it's working right, but I'd really like to know how/why the only thing I did was CVS the box up to stable, was there some strange problem with the Release SMP ? What do you think ? Thanks again! -- Steve Kaczkowski Time Warner Telecom IDD steve@inc.net (414)908-9012 http://www.inc.net (603)737-9209 Fax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat May 6 13:49: 4 2000 Delivered-To: freebsd-smp@freebsd.org Received: from relativity.student.utwente.nl (wit389306.student.utwente.nl [130.89.234.166]) by hub.freebsd.org (Postfix) with ESMTP id 3340637BA78 for ; Sat, 6 May 2000 13:48:58 -0700 (PDT) (envelope-from djb@wit389306.student.utwente.nl) Received: by relativity.student.utwente.nl (Postfix, from userid 1000) id CEE1A5DF0; Sat, 6 May 2000 22:48:47 +0200 (CEST) Date: Sat, 6 May 2000 22:48:47 +0200 From: Dave Boers To: Terry Lambert Cc: Steve Passe , Karl Pielorz , smp@FreeBSD.ORG Subject: Re: hlt instructions and temperature issues Message-ID: <20000506224847.A753@relativity.student.utwente.nl> Reply-To: djb@ifa.au.dk References: <20000501161626.A4317@relativity.student.utwente.nl> <200005021832.LAA21819@usr01.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200005021832.LAA21819@usr01.primenet.com>; from tlambert@primenet.com on Tue, May 02, 2000 at 06:32:18PM +0000 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, May 02, 2000 at 06:32:18PM +0000, Terry Lambert wrote: > [ ... sysctl ... ] > > > This looks like an excellent proposal. Does anyone have comments, or could > > someone with experience" in this area provide a patch? > > As an experiment to convince people, this is OK. As a permanent > change, it's wrong. > > Without handling the stalling case, the code is incorrect, and _will_ > result in poorer performance on the first idle/resource wait. Not only that, but (as I just found out) the stray irq 7's which I mentioned earlier in the tread are a real problem. My system just hanged during printer I/O. I still have only the hlt instruction in the kernel. When not using the printer, the system is fine. Dave. -- djb@ifa.au.dk d.j.boers@tn.utwente.nl PGP key: ftp://relativity.student.utwente.nl:/pub/pgpkeys/djb.asc In the land of the blind, the one-eyed man is murdered for heresy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat May 6 15:49: 3 2000 Delivered-To: freebsd-smp@freebsd.org Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [206.168.13.65]) by hub.freebsd.org (Postfix) with ESMTP id B0C9137BD45 for ; Sat, 6 May 2000 15:49:00 -0700 (PDT) (envelope-from smp@Ilsa.StevesCafe.com) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.9.3/8.9.3) with ESMTP id QAA78915; Sat, 6 May 2000 16:48:51 -0600 (MDT) (envelope-from smp@Ilsa.StevesCafe.com) Message-Id: <200005062248.QAA78915@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0.2 2/24/98 From: Steve Passe To: djb@ifa.au.dk Cc: smp@FreeBSD.ORG Subject: Re: hlt instructions and temperature issues In-reply-to: Your message of "Sat, 06 May 2000 22:48:47 +0200." <20000506224847.A753@relativity.student.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 06 May 2000 16:48:51 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Tue, May 02, 2000 at 06:32:18PM +0000, Terry Lambert wrote: > > [ ... sysctl ... ] ... > > Without handling the stalling case, the code is incorrect, and _will_ > > result in poorer performance on the first idle/resource wait. > > Not only that, but (as I just found out) the stray irq 7's which I > mentioned earlier in the tread are a real problem. My system just hanged > during printer I/O. > > I still have only the hlt instruction in the kernel. When not using the > printer, the system is fine. I think you have something else going on here, the hlt/nohlt issue should not cause stray irq7s. And using hlt should not hang your system during printing. My 4way has been running with hlt for a week or so now, with no hangs (although I admittedly have no printer on the pport). -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat May 6 16:38:56 2000 Delivered-To: freebsd-smp@freebsd.org Received: from relativity.student.utwente.nl (wit389306.student.utwente.nl [130.89.234.166]) by hub.freebsd.org (Postfix) with ESMTP id 28F5D37B8CB for ; Sat, 6 May 2000 16:38:52 -0700 (PDT) (envelope-from djb@wit389306.student.utwente.nl) Received: by relativity.student.utwente.nl (Postfix, from userid 1000) id 7F21E5DF0; Sun, 7 May 2000 01:38:50 +0200 (CEST) Date: Sun, 7 May 2000 01:38:50 +0200 From: Dave Boers To: Steve Passe Cc: djb@ifa.au.dk, smp@FreeBSD.ORG Subject: Re: hlt instructions and temperature issues Message-ID: <20000507013850.A1023@relativity.student.utwente.nl> Reply-To: djb@ifa.au.dk References: <20000506224847.A753@relativity.student.utwente.nl> <200005062248.QAA78915@Ilsa.StevesCafe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200005062248.QAA78915@Ilsa.StevesCafe.com>; from smp@csn.net on Sat, May 06, 2000 at 04:48:51PM -0600 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, May 06, 2000 at 04:48:51PM -0600, Steve Passe wrote: > I think you have something else going on here, the hlt/nohlt issue should > not cause stray irq7s. And using hlt should not hang your system during > printing. My 4way has been running with hlt for a week or so now, with > no hangs (although I admittedly have no printer on the pport). I have never had stray irq7's as long as the machine exists (which is exactly as long as it's running FreeBSD) until I put in the hlt instruction. They are definitely triggered by turning on the hlt instruction in the kernel. The hang may be a coincidence, however (albeit a damn lucky one if it is). I still haven't solved the random SMP related hang issue on my Abit BP6 system and I haven't even found its trigger after all this time (check the thread called "SMP and vn" for details). So the hang may be caused by something else but it's almost too much of a coincidence that it occurs during printing because I rarely print from that machine. It is not reproducible, however: I just finished printing some large documents for testing. I'll assume for now that you're right and that the hang isn't hlt-related (but the stray irq7 is). Then this must mean that the random hang issue is still unsolved. Because noone on this list could shed any light on it, I figured that it might be a hardware issue after all. After checking memory integrity and all that, the only thing I could come up with was the high core temperature. It may be that this hang just proved that it's not temperature related either. Testing is extremely difficult and slow because the hang only occasionally occurs. But I'm not giving in just yet. I still have one last trick up my sleeve; I'm going to switch the last remaining variable now. Regards, Dave. -- djb@ifa.au.dk d.j.boers@tn.utwente.nl PGP key: ftp://relativity.student.utwente.nl:/pub/pgpkeys/djb.asc In the land of the blind, the one-eyed man is murdered for heresy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat May 6 18:31:19 2000 Delivered-To: freebsd-smp@freebsd.org Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [206.168.13.65]) by hub.freebsd.org (Postfix) with ESMTP id 17CA237B8CB for ; Sat, 6 May 2000 18:31:15 -0700 (PDT) (envelope-from fbsd@Ilsa.StevesCafe.com) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.9.3/8.9.3) with ESMTP id TAA79722; Sat, 6 May 2000 19:31:09 -0600 (MDT) (envelope-from fbsd@Ilsa.StevesCafe.com) Message-Id: <200005070131.TAA79722@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0.2 2/24/98 From: Steve Passe To: djb@ifa.au.dk Cc: Steve Passe , smp@FreeBSD.ORG Subject: Re: hlt instructions and temperature issues In-reply-to: Your message of "Sun, 07 May 2000 01:38:50 +0200." <20000507013850.A1023@relativity.student.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 06 May 2000 19:31:09 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, > On Sat, May 06, 2000 at 04:48:51PM -0600, Steve Passe wrote: > > I think you have something else going on here, the hlt/nohlt issue should > > not cause stray irq7s. And using hlt should not hang your system during > > printing. My 4way has been running with hlt for a week or so now, with > > no hangs (although I admittedly have no printer on the pport). > > I have never had stray irq7's as long as the machine exists (which is > exactly as long as it's running FreeBSD) until I put in the hlt > instruction. They are definitely triggered by turning on the hlt > instruction in the kernel. > > The hang may be a coincidence, however (albeit a damn lucky one if it is). > I still haven't solved the random SMP related hang issue on my Abit BP6 > system and I haven't even found its trigger after all this time (check the > thread called "SMP and vn" for details). > > So the hang may be caused by something else but it's almost too much of a > coincidence that it occurs during printing because I rarely print from that > machine. It is not reproducible, however: I just finished printing some > large documents for testing. > > I'll assume for now that you're right and that the hang isn't hlt-related > (but the stray irq7 is). I need to clarify, I can't think of any way the hlt could cause a stray irq7, but in this business you can never say never... A "stray irq7" is what occurs when some piece of hardware causes an INT cycle on the PIC (in our case APIC) to begin, but when the PIC gets to the INTACK cycle the hardware is no longer asserting the INT. Thus the PIC has no way to build a vector to return on the bus, so it arbitrarily uses the irq7 vector (intel design decision). Usually the offending INT wasn't even asserted on the INT7 pin, but the hardware has no way of telling this... I believe its perfectly feasable that the stray irq7s are causing printer related hangs, as a stray irq7 happening in a race with real irq7s from the printer port could well cause problems. So in summary: I can't see how hlt could cause stray irq7s (but it might...) stray irq7s could well cause a hang if occurring during printing. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message