From owner-freebsd-smp Mon Aug 20 5:59:58 2001 Delivered-To: freebsd-smp@freebsd.org Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by hub.freebsd.org (Postfix) with ESMTP id 10A5037B40F for ; Mon, 20 Aug 2001 05:59:51 -0700 (PDT) (envelope-from watchman@ludd.luth.se) Received: from d1o907.telia.com (d1o907.telia.com [195.252.38.241]) by mailb.telia.com (8.9.3/8.9.3) with ESMTP id OAA29015 for ; Mon, 20 Aug 2001 14:58:40 +0200 (CEST) Received: from ludd.luth.se (h125n2fls21o907.telia.com [213.66.203.125]) by d1o907.telia.com (8.8.8/8.8.8) with ESMTP id OAA06706 for ; Mon, 20 Aug 2001 14:58:35 +0200 (CEST) Message-ID: <3B81097B.6090201@ludd.luth.se> Date: Mon, 20 Aug 2001 14:58:35 +0200 From: Joachim =?ISO-8859-1?Q?Str=F6mbergson?= Organization: Acne User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.3) Gecko/20010819 X-Accept-Language: en-US MIME-Version: 1.0 To: freebsd-smp@FreeBSD.ORG Subject: Bye bye dear SMP-system Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Aloha! Ok, I belive I'm experiencing a HW failure but would just like to check with you guys. I have been a very happy owner of a FreeBSD SMP system. The machine runs on dual Celeron 533 CPUs on the ABIT BP6 MB. It has been a very stable and nice system even though it might not have the straight line, single process speed. Lately however I have experienced hard lockups that forces me to hit reset. I've survived so far (thanks to Soft updates I pressume). One of the big SW changes have been the move to XFree86 4.1.0. Also, I have probably let kernel and system come out of sync [1]. Checking this I therefore dropped out of X and made a buildworld, single user installworld and mergemaster. Suddenly I got a lock in while merging. Since /etc hadn't been updates no major harm was done. I noticed however that Win98 worked smoothly and semed to be more stable that the SMP-system. (No, I'm not trolling ;-). This sounds seriously wrong. This got me thinking in terms of SMP vs UP. I therefore compiled a new kernel with the only difference compared to the SMP kernel was that SMP was turned off. I have now been running on this kernel for 8 hours in X with mozilla (another suspect since I recently started using it). So far everything seems fine. So, a few questions: (1) Is late 4.3-STABLE and 4.4-RC unstable in SMP mode? I suspect not, (2) How to go about catching the lock? Console doesn't show anything, the machines simply freezes over, (3) Any BP6-user with similar experience that have any ideas? I'm not running overclocked or anything like that. I've included the latest dmesg. (It's the UP dmesg). Any help and pointers would be very helpful. [1] I guess I'm not the only one tracks stable on a weekly basis, and then once in a while realises that a new driver or thingy needs to be changed in the kernel and therefore simply rebuilds and installs a new kernel while not building && installing world everytime. Yes I hang my head in shame. -- Med vänlig hälsning, Cheers! Joachim Strömbergson ============================================================================ Joachim Strömbergson - ASIC designer, nice to *cute* animals. snail: phone: mail & web: Sävenäsgatan 5A +46 31 - 27 98 47 watchman@ludd.luth.se 416 72 Göteborg +46 733 75 97 02 www.ludd.luth.se/~watchman ============================================================================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Aug 20 7: 6: 2 2001 Delivered-To: freebsd-smp@freebsd.org Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by hub.freebsd.org (Postfix) with ESMTP id 58CE337B410 for ; Mon, 20 Aug 2001 07:05:56 -0700 (PDT) (envelope-from watchman@ludd.luth.se) Received: from d1o907.telia.com (d1o907.telia.com [195.252.38.241]) by mailc.telia.com (8.11.2/8.11.0) with ESMTP id f7KE5s729846 for ; Mon, 20 Aug 2001 16:05:54 +0200 (CEST) Received: from ludd.luth.se (h125n2fls21o907.telia.com [213.66.203.125]) by d1o907.telia.com (8.8.8/8.8.8) with ESMTP id QAA01139 for ; Mon, 20 Aug 2001 16:05:53 +0200 (CEST) Message-ID: <3B811940.10807@ludd.luth.se> Date: Mon, 20 Aug 2001 16:05:52 +0200 From: Joachim =?ISO-8859-1?Q?Str=F6mbergson?= Organization: Acne User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.3) Gecko/20010819 X-Accept-Language: en-US MIME-Version: 1.0 To: smp@freebsd.org Subject: Bye bye dear SMP system Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Aloha! Ok, I belive I'm experiencing a HW failure but would just like to check with you guys. I have been a very happy owner of a FreeBSD SMP system. The machine runs on dual Celeron 533 CPUs on the ABIT BP6 MB. It has been a very stable and nice system even though it might not have the straight line, single process speed. Lately however I have experienced hard lockups that forces me to hit reset. I've survived so far (thanks to Soft updates I pressume). One of the big SW changes have been the move to XFree86 4.1.0. Also, I have probably let kernel and system come out of sync [1]. Checking this I therefore dropped out of X and made a buildworld, single user installworld and mergemaster. Suddenly I got a lock in while merging. Since /etc hadn't been updates no major harm was done. I noticed however that Win98 worked smoothly and semed to be more stable that the SMP-system. (No, I'm not trolling [;-)] . This sounds seriously wrong. This got me thinking in terms of SMP vs UP. I therefore compiled a new kernel with the only difference compared to the SMP kernel was that SMP was turned off. I have now been running on this kernel for 8 hours in X with mozilla (another suspect since I recently started using it). So far everything seems fine. So, a few questions: (1) Is late 4.3-STABLE and 4.4-RC unstable in SMP mode? I suspect not, (2) How to go about catching the lock? Console doesn't show anything, the machines simply freezes over, (3) Any BP6-user with similar experience that have any ideas? I'm not running overclocked or anything like that. I've included the latest dmesg. (It's the UP dmesg). Any help and pointers would be very helpful. [1] I guess I'm not the only one tracks stable on a weekly basis, and then once in a while realises that a new driver or thingy needs to be changed in the kernel and therefore simply rebuilds and installs a new kernel while not building && installing world everytime. Yes I hang my head in shame. -- Med vänlig hälsning, Cheers! Joachim Strömbergson ============================================================================ Joachim Strömbergson - ASIC designer, nice to *cute* animals. snail: phone: mail & web: Sävenäsgatan 5A +46 31 - 27 98 47 watchman@ludd.luth.se 416 72 Göteborg +46 733 75 97 02 www.ludd.luth.se/~watchman ============================================================================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Aug 20 7:54:20 2001 Delivered-To: freebsd-smp@freebsd.org Received: from webpimps.net (lgb-DSL71-cust207.mpowercom.net [208.57.71.207]) by hub.freebsd.org (Postfix) with ESMTP id B11DD37B415 for ; Mon, 20 Aug 2001 07:54:13 -0700 (PDT) (envelope-from click46@webpimps.net) Received: from WorldClient [127.0.0.1] by webpimps.net [127.0.0.1] with SMTP (MDaemon.v3.1.2.R) for ; Mon, 20 Aug 2001 07:51:52 -0700 Date: Mon, 20 Aug 2001 07:51:52 -0700 From: "Aaron" To: "Joachim =?iso-8859-1?Q?Str=F6mbergson?=" Cc: freebsd-smp@freebsd.org Subject: Re: Bye bye dear SMP-system MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Mailer: WorldClient Standard 3.1.2 In-Reply-To: <3B81097B.6090201@ludd.luth.se> X-MDRcpt-To: freebsd-smp@freebsd.org X-MDRemoteIP: 127.0.0.1 X-Return-Path: click46@webpimps.net X-MDaemon-Deliver-To: freebsd-smp@freebsd.org Message-Id: <20010820145413.B11DD37B415@hub.freebsd.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Joachim Strömbergson, I too own an Abit BP6, only with two 433 celerons. I have had on three random occasions 4.3-RELEASE spontaneously reboot. Only once was I present when the system rebooted itself and the error message was quite perplexing. This machine does not run X and, oddly enough, had nothing but standard daemons running at the time. I still have yet to find the *exact* cause but a BIOS flash to the latest non-beta version and removing an older 64Mb Pc100 Siemens quickly ridded my machine of any SMP unstability (in both Win2K and FreeBSD). Being a long time BP6 user and overclocker, I've seen many stories quite similar to yours. How long have you had the board? Has any trouble like this happend before in any operating system? Any changes hardware wise that might perhaps raise system temp? Lastly, what revision is your BP6? Regards, - aaron --------------------------------------------- click46[wp] - AIM the click46 - ICQ 43450396 webpimps.net | bsdatwork.com | nerdserve.net moderator - o/c cooling forum @ hardforum.com -----Original Message----- From: Joachim Strömbergson To: freebsd-smp@FreeBSD.ORG Date: Mon, 20 Aug 2001 14:58:35 +0200 Subject: Bye bye dear SMP-system > Aloha! > > Ok, I belive I'm experiencing a HW failure but would just like to check > with you guys. > > I have been a very happy owner of a FreeBSD SMP system. The machine > runs > on dual Celeron 533 CPUs on the ABIT BP6 MB. It has been a very stable > and nice system even though it might not have the straight line, single > process speed. > > Lately however I have experienced hard lockups that forces me to hit > reset. I've survived so far (thanks to Soft updates I pressume). One of > the big SW changes have been the move to XFree86 4.1.0. Also, I have > probably let kernel and system come out of sync [1]. > > Checking this I therefore dropped out of X and made a buildworld, > single > user installworld and mergemaster. Suddenly I got a lock in while > merging. Since /etc hadn't been updates no major harm was done. > > I noticed however that Win98 worked smoothly and semed to be more > stable > that the SMP-system. (No, I'm not trolling ;-). This sounds seriously > wrong. This got me thinking in terms of SMP vs UP. > > I therefore compiled a new kernel with the only difference compared to > the SMP kernel was that SMP was turned off. I have now been running on > this kernel for 8 hours in X with mozilla (another suspect since I > recently started using it). So far everything seems fine. > > So, a few questions: > (1) Is late 4.3-STABLE and 4.4-RC unstable in SMP mode? I suspect not, > > (2) How to go about catching the lock? Console doesn't show anything, > the machines simply freezes over, > > (3) Any BP6-user with similar experience that have any ideas? > > I'm not running overclocked or anything like that. > > I've included the latest dmesg. (It's the UP dmesg). > > Any help and pointers would be very helpful. > > > [1] I guess I'm not the only one tracks stable on a weekly basis, and > then once in a while realises that a new driver or thingy needs to be > changed in the kernel and therefore simply rebuilds and installs a new > kernel while not building && installing world everytime. Yes I hang my > head in shame. > > -- > Med vänlig hälsning, Cheers! > > Joachim Strömbergson > ======================================================================= > ===== > Joachim Strömbergson - ASIC designer, nice to *cute* animals. > snail: phone: mail & web: > Sävenäsgatan 5A +46 31 - 27 98 47 watchman@ludd.luth.se > 416 72 Göteborg +46 733 75 97 02 > www.ludd.luth.se/~watchman > ======================================================================= > ===== > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Aug 20 8:30:22 2001 Delivered-To: freebsd-smp@freebsd.org Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by hub.freebsd.org (Postfix) with ESMTP id 8EC2A37B417 for ; Mon, 20 Aug 2001 08:30:06 -0700 (PDT) (envelope-from barney@tp.databus.com) Received: (from barney@localhost) by tp.databus.com (8.11.4/8.11.4) id f7KFU1804524; Mon, 20 Aug 2001 11:30:01 -0400 (EDT) (envelope-from barney) Date: Mon, 20 Aug 2001 11:29:57 -0400 From: Barney Wolff Cc: =?iso-8859-1?Q?Joachim_Str=F6mbergson?= , freebsd-smp@FreeBSD.ORG Subject: Re: Bye bye dear SMP-system Message-ID: <20010820112957.A4506@tp.databus.com> References: <3B81097B.6090201@ludd.luth.se> <20010820145413.B11DD37B415@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <20010820145413.B11DD37B415@hub.freebsd.org>; from click46@webpimps.net on Mon, Aug 20, 2001 at 07:51:52AM -0700 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I know it sounds stupid, but have you checked the fan on the 2nd cpu? Win98 is not smp. Barney Wolff On Mon, Aug 20, 2001 at 07:51:52AM -0700, Aaron wrote: > Joachim Strömbergson, > > I too own an Abit BP6, only with two 433 celerons. I have had on three > random occasions 4.3-RELEASE spontaneously reboot. Only once was I > present when the system rebooted itself and the error message was quite > perplexing. This machine does not run X and, oddly enough, had nothing > but standard daemons running at the time. > I still have yet to find the *exact* cause but a BIOS flash to the > latest non-beta version and removing an older 64Mb Pc100 Siemens quickly > ridded my machine of any SMP unstability (in both Win2K and FreeBSD). > Being a long time BP6 user and overclocker, I've seen many stories > quite similar to yours. How long have you had the board? Has any trouble > like this happend before in any operating system? Any changes hardware > wise that might perhaps raise system temp? Lastly, what revision is your > BP6? > > Regards, > - aaron > > --------------------------------------------- > click46[wp] - AIM the click46 - ICQ 43450396 > webpimps.net | bsdatwork.com | nerdserve.net > moderator - o/c cooling forum @ hardforum.com > > > -----Original Message----- > From: Joachim Strömbergson > To: freebsd-smp@FreeBSD.ORG > Date: Mon, 20 Aug 2001 14:58:35 +0200 > Subject: Bye bye dear SMP-system > > > Aloha! > > > > Ok, I belive I'm experiencing a HW failure but would just like to check > > with you guys. > > > > I have been a very happy owner of a FreeBSD SMP system. The machine > > runs > > on dual Celeron 533 CPUs on the ABIT BP6 MB. It has been a very stable > > and nice system even though it might not have the straight line, single > > process speed. > > > > Lately however I have experienced hard lockups that forces me to hit > > reset. I've survived so far (thanks to Soft updates I pressume). One of > > the big SW changes have been the move to XFree86 4.1.0. Also, I have > > probably let kernel and system come out of sync [1]. > > > > Checking this I therefore dropped out of X and made a buildworld, > > single > > user installworld and mergemaster. Suddenly I got a lock in while > > merging. Since /etc hadn't been updates no major harm was done. > > > > I noticed however that Win98 worked smoothly and semed to be more > > stable > > that the SMP-system. (No, I'm not trolling ;-). This sounds seriously > > wrong. This got me thinking in terms of SMP vs UP. > > > > I therefore compiled a new kernel with the only difference compared to > > the SMP kernel was that SMP was turned off. I have now been running on > > this kernel for 8 hours in X with mozilla (another suspect since I > > recently started using it). So far everything seems fine. > > > > So, a few questions: > > (1) Is late 4.3-STABLE and 4.4-RC unstable in SMP mode? I suspect not, > > > > (2) How to go about catching the lock? Console doesn't show anything, > > the machines simply freezes over, > > > > (3) Any BP6-user with similar experience that have any ideas? > > > > I'm not running overclocked or anything like that. > > > > I've included the latest dmesg. (It's the UP dmesg). > > > > Any help and pointers would be very helpful. > > > > > > [1] I guess I'm not the only one tracks stable on a weekly basis, and > > then once in a while realises that a new driver or thingy needs to be > > changed in the kernel and therefore simply rebuilds and installs a new > > kernel while not building && installing world everytime. Yes I hang my > > head in shame. > > > > -- > > Med vänlig hälsning, Cheers! > > > > Joachim Strömbergson > > ======================================================================= > > ===== > > Joachim Strömbergson - ASIC designer, nice to *cute* animals. > > snail: phone: mail & web: > > Sävenäsgatan 5A +46 31 - 27 98 47 watchman@ludd.luth.se > > 416 72 Göteborg +46 733 75 97 02 > > www.ludd.luth.se/~watchman > > ======================================================================= > > ===== > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-smp" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Aug 20 9:18:30 2001 Delivered-To: freebsd-smp@freebsd.org Received: from c017.sfo.cp.net (c017-h007.c017.sfo.cp.net [209.228.12.221]) by hub.freebsd.org (Postfix) with SMTP id 89F4B37B407 for ; Mon, 20 Aug 2001 09:18:25 -0700 (PDT) (envelope-from noackjr@compgeek.com) Received: (cpmta 1909 invoked from network); 20 Aug 2001 09:18:25 -0700 Date: 20 Aug 2001 09:18:25 -0700 Message-ID: <20010820161825.1908.cpmta@c017.sfo.cp.net> X-Sent: 20 Aug 2001 16:18:25 GMT Received: from [64.1.99.131] by mail.compgeek.com with HTTP; 20 Aug 2001 09:18:25 PDT Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: freebsd-smp@FreeBSD.org From: Jon Noack X-Mailer: Web Mail 3.9.3.5 X-Sent-From: noackjr@compgeek.com Subject: Re: Bye bye dear SMP-system Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have 2 machines running dual Celeron 500s on BP6s. The only problems I have come across have had to do with the HPT366 controller. I use IBM 75GXP hard drives in the machines and enabled tagged queuing (using the 'hw.ata.tags="1"' line in /boot/loader.conf). Under heavy reads (but not heavy writes - weird), the kernel would post an "ad0: READ command timeout resetting" error followed by an "ad0: invalidating queued requests" error. That was shortly followed by a hard lock. I tried 'hw.ata.wc="1"' instead and have had no problems (except if and when the UPS dies). I could reproduce the error by cvsuping my source tree to RELENG_4_3. The first time was fine, as there was some writing because several items were being updated (from 4.3-release). Later attempts (which were almost solely reads) always resulted in a hard lock. Jon On Mon, 20 August 2001, Joachim Strömbergson wrote: > So, a few questions: > (1) Is late 4.3-STABLE and 4.4-RC unstable in SMP mode? I suspect not, > > (2) How to go about catching the lock? Console doesn't show anything, > the machines simply freezes over, > > (3) Any BP6-user with similar experience that have any ideas? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Aug 20 11:42:39 2001 Delivered-To: freebsd-smp@freebsd.org Received: from c017.sfo.cp.net (c017-h012.c017.sfo.cp.net [209.228.12.226]) by hub.freebsd.org (Postfix) with SMTP id 5689337B407 for ; Mon, 20 Aug 2001 11:42:37 -0700 (PDT) (envelope-from noackjr@compgeek.com) Received: (cpmta 12541 invoked from network); 20 Aug 2001 11:42:36 -0700 Date: 20 Aug 2001 11:42:36 -0700 Message-ID: <20010820184236.12540.cpmta@c017.sfo.cp.net> X-Sent: 20 Aug 2001 18:42:36 GMT Received: from [64.1.99.131] by mail.compgeek.com with HTTP; 20 Aug 2001 11:42:36 PDT Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: freebsd-smp@FreeBSD.org From: Jon Noack X-Mailer: Web Mail 3.9.3.5 X-Sent-From: noackjr@compgeek.com Subject: tuning ata disks (was Re: Bye bye dear SMP-system) Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org To check what is currently enabled for disks, "sysctl -a | grep hw.ata" For more info on what can be set and how to set it, "man ata" "man loader.conf" Jon On Mon, 20 August 2001, "Aaron" wrote: This may be off topic, but where did you learn of these attributes for loader.conf? Is there a list of some sort? I've seen many of them for tuning effects and memory management. Now for disk drives! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Aug 20 12:21:25 2001 Delivered-To: freebsd-smp@freebsd.org Received: from freebsd.dk (fw-rl0.freebsd.dk [212.242.86.114]) by hub.freebsd.org (Postfix) with ESMTP id 47C0B37B411 for ; Mon, 20 Aug 2001 12:21:22 -0700 (PDT) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.11.3/8.11.3) id f7KJLcA87034; Mon, 20 Aug 2001 21:21:38 +0200 (CEST) (envelope-from sos) From: Søren Schmidt Message-Id: <200108201921.f7KJLcA87034@freebsd.dk> Subject: Re: Bye bye dear SMP-system In-Reply-To: <20010820161825.1908.cpmta@c017.sfo.cp.net> "from Jon Noack at Aug 20, 2001 09:18:25 am" To: Jon Noack Date: Mon, 20 Aug 2001 21:21:38 +0200 (CEST) Cc: freebsd-smp@FreeBSD.ORG Reply-To: sos@freebsd.dk X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org It seems Jon Noack wrote: > I have 2 machines running dual Celeron 500s on BP6s. The only problems > I have come across have had to do with the HPT366 controller. I use IBM > 75GXP hard drives in the machines and enabled tagged queuing (using the > 'hw.ata.tags="1"' line in /boot/loader.conf). Under heavy reads (but not > heavy writes - weird), the kernel would post an "ad0: READ command timeout > resetting" error followed by an "ad0: invalidating queued requests" > error. That was shortly followed by a hard lock. I tried 'hw.ata.wc="1"' > instead and have had no problems (except if and when the UPS dies). I > could reproduce the error by cvsuping my source tree to RELENG_4_3. The > first time was fine, as there was some writing because several items were > being updated (from 4.3-release). Later attempts (which were almost > solely reads) always resulted in a hard lock. The HPT366 has HW issues with some of the fast disk, I havn't been able to find a solution to that, nor has HPT as far as I'm informed.. -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Aug 20 13:49:24 2001 Delivered-To: freebsd-smp@freebsd.org Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by hub.freebsd.org (Postfix) with ESMTP id 3191237B409 for ; Mon, 20 Aug 2001 13:49:21 -0700 (PDT) (envelope-from watchman@ludd.luth.se) Received: from d1o907.telia.com (d1o907.telia.com [195.252.38.241]) by maile.telia.com (8.11.2/8.11.0) with ESMTP id f7KKmi128592; Mon, 20 Aug 2001 22:48:44 +0200 (CEST) Received: from ludd.luth.se (h125n2fls21o907.telia.com [213.66.203.125]) by d1o907.telia.com (8.8.8/8.8.8) with ESMTP id WAA14747; Mon, 20 Aug 2001 22:48:43 +0200 (CEST) Message-ID: <3B8177A5.6070607@ludd.luth.se> Date: Mon, 20 Aug 2001 22:48:37 +0200 From: Joachim =?ISO-8859-1?Q?Str=F6mbergson?= Organization: Acne User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.3) Gecko/20010819 X-Accept-Language: en-US MIME-Version: 1.0 To: Barney Wolff Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Bye bye dear SMP-system References: <3B81097B.6090201@ludd.luth.se> <20010820145413.B11DD37B415@hub.freebsd.org> <20010820112957.A4506@tp.databus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Aloha! Barney Wolff wrote: > I know it sounds stupid, but have you checked the fan on the 2nd cpu? Yes, it spins nicely and the temp sensor shows that it's about the same temp as CPU1 > Win98 is not smp. Yes. That's was the reason why I realised that it might be CPU2 to be the culprit. -- Med vänlig hälsning, Cheers! Joachim Strömbergson ============================================================================ Joachim Strömbergson - ASIC designer, nice to *cute* animals. snail: phone: mail & web: Sävenäsgatan 5A +46 31 - 27 98 47 watchman@ludd.luth.se 416 72 Göteborg +46 733 75 97 02 www.ludd.luth.se/~watchman ============================================================================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Aug 20 16:40:35 2001 Delivered-To: freebsd-smp@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 75AE937B401; Mon, 20 Aug 2001 16:40:08 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7KNe8l58236; Mon, 20 Aug 2001 16:40:08 -0700 (PDT) (envelope-from dillon) Date: Mon, 20 Aug 2001 16:40:08 -0700 (PDT) From: Matt Dillon Message-Id: <200108202340.f7KNe8l58236@earth.backplane.com> To: John Baldwin Cc: freebsd-smp@FreeBSD.org, freebsd-alpha@FreeBSD.org Subject: Preliminary proposed rollup of kernel submap initialization code Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is what I was thinking in regards to rolling up the submap initialization code, moving out of the MD section into the MI section. This is for -current only and has not yet been tested, do not patch this in. I'm looking mainly for feedback on things like the location of the procedures, structure declarations, externs, and so forth. This patch includes the rollup for i386 and alpha. platforms that haven't been rolled up will still compile just fine the old way (we can roll things up piecemeal). -Matt Index: vm/vm.h =================================================================== RCS file: /home/ncvs/src/sys/vm/vm.h,v retrieving revision 1.18 diff -u -r1.18 vm.h --- vm/vm.h 2001/07/04 16:20:27 1.18 +++ vm/vm.h 2001/08/20 23:35:44 @@ -113,4 +113,21 @@ typedef struct vm_page *vm_page_t; #endif +/* + * Information passed from the machine-independant VM initialization code + * for use by machine-dependant code (mainly for MMU support) + */ +struct kva_md_info { + vm_offset_t buffer_sva; + vm_offset_t buffer_eva; + vm_offset_t clean_sva; + vm_offset_t clean_eva; + vm_offset_t pager_sva; + vm_offset_t pager_eva; +}; + +extern struct kva_md_info kmi; +extern void vm_ksubmap_init(struct kva_md_info *kmi); + #endif /* VM_H */ + Index: vm/vm_init.c =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_init.c,v retrieving revision 1.28 diff -u -r1.28 vm_init.c --- vm/vm_init.c 2001/07/04 16:20:27 1.28 +++ vm/vm_init.c 2001/08/20 23:34:35 @@ -74,8 +74,12 @@ #include #include #include +#include +#include #include +#include +#include #include #include #include @@ -119,3 +123,154 @@ pmap_init(avail_start, avail_end); vm_pager_init(); } + +void +vm_ksubmap_init(struct kva_md_info *kmi) +{ + vm_offset_t firstaddr; + caddr_t v; + vm_size_t size = 0; + int physmem_est; + vm_offset_t minaddr; + vm_offset_t maxaddr; + unsigned int i; + + /* + * Calculate callout wheel size + */ + for (callwheelsize = 1, callwheelbits = 0; + callwheelsize < ncallout; + callwheelsize <<= 1, ++callwheelbits) + ; + callwheelmask = callwheelsize - 1; + + /* + * Allocate space for system data structures. + * The first available kernel virtual address is in "v". + * As pages of kernel virtual memory are allocated, "v" is incremented. + * As pages of memory are allocated and cleared, + * "firstaddr" is incremented. + * An index into the kernel page table corresponding to the + * virtual memory address maintained in "v" is kept in "mapaddr". + */ + + /* + * Make two passes. The first pass calculates how much memory is + * needed and allocates it. The second pass assigns virtual + * addresses to the various data structures. + */ + firstaddr = 0; +again: + v = (caddr_t)firstaddr; + +#define valloc(name, type, num) \ + (name) = (type *)v; v = (caddr_t)((name)+(num)) +#define valloclim(name, type, num, lim) \ + (name) = (type *)v; v = (caddr_t)((lim) = ((name)+(num))) + + valloc(callout, struct callout, ncallout); + valloc(callwheel, struct callout_tailq, callwheelsize); + + /* + * Discount the physical memory larger than the size of kernel_map + * to avoid eating up all of KVA space. + */ + if (kernel_map->first_free == NULL) { + printf("Warning: no free entries in kernel_map.\n"); + physmem_est = physmem; + } else { + physmem_est = min(physmem, kernel_map->max_offset - + kernel_map->min_offset); + } + + /* + * The nominal buffer size (and minimum KVA allocation) is BKVASIZE. + * For the first 64MB of ram nominally allocate sufficient buffers to + * cover 1/4 of our ram. Beyond the first 64MB allocate additional + * buffers to cover 1/20 of our ram over 64MB. When auto-sizing + * the buffer cache we limit the eventual kva reservation to + * maxbcache bytes. + * + * factor represents the 1/4 x ram conversion. + */ + if (nbuf == 0) { + int factor = 4 * BKVASIZE / PAGE_SIZE; + + nbuf = 50; + if (physmem_est > 1024) + nbuf += min((physmem_est - 1024) / factor, + 16384 / factor); + if (physmem_est > 16384) + nbuf += (physmem_est - 16384) * 2 / (factor * 5); + + if (maxbcache && nbuf > physmem_est / BKVASIZE) + nbuf = maxbcache / BKVASIZE; + } + + /* + * Do not allow the buffer_map to be more then 1/2 the size of the + * kernel_map. + */ + if (nbuf > (kernel_map->max_offset - kernel_map->min_offset) / + (BKVASIZE * 2)) { + nbuf = (kernel_map->max_offset - kernel_map->min_offset) / + (BKVASIZE * 2); + printf("Warning: nbufs capped at %d\n", nbuf); + } + + nswbuf = max(min(nbuf/4, 256), 16); + + valloc(swbuf, struct buf, nswbuf); + valloc(buf, struct buf, nbuf); + v = bufhashinit(v); + + /* + * End of first pass, size has been calculated so allocate memory + */ + if (firstaddr == 0) { + size = (vm_size_t)((char *)v - firstaddr); + firstaddr = kmem_alloc(kernel_map, round_page(size)); + if (firstaddr == 0) + panic("startup: no room for tables"); + goto again; + } + + /* + * End of second pass, addresses have been assigned + */ + if ((vm_size_t)((char *)v - firstaddr) != size) + panic("startup: table size inconsistency"); + + clean_map = kmem_suballoc(kernel_map, &kmi->clean_sva, &kmi->clean_eva, + (nbuf*BKVASIZE) + (nswbuf*MAXPHYS) + pager_map_size); + buffer_map = kmem_suballoc(clean_map, &kmi->buffer_sva, + &kmi->buffer_eva, (nbuf*BKVASIZE)); + buffer_map->system_map = 1; + pager_map = kmem_suballoc(clean_map, &kmi->pager_sva, &kmi->pager_eva, + (nswbuf*MAXPHYS) + pager_map_size); + pager_map->system_map = 1; + exec_map = kmem_suballoc(kernel_map, &minaddr, &maxaddr, + (16*(ARG_MAX+(PAGE_SIZE*3)))); + + /* + * XXX: Mbuf system machine-specific initializations should + * go here, if anywhere. + */ + + /* + * Initialize callouts + */ + SLIST_INIT(&callfree); + for (i = 0; i < ncallout; i++) { + callout_init(&callout[i], 0); + callout[i].c_flags = CALLOUT_LOCAL_ALLOC; + SLIST_INSERT_HEAD(&callfree, &callout[i], c_links.sle); + } + + for (i = 0; i < callwheelsize; i++) { + TAILQ_INIT(&callwheel[i]); + } + + mtx_init(&callout_lock, "callout", MTX_SPIN | MTX_RECURSE); +} + Index: i386/i386/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v retrieving revision 1.470 diff -u -r1.470 machdep.c --- i386/i386/machdep.c 2001/08/20 00:41:11 1.470 +++ i386/i386/machdep.c 2001/08/20 23:36:28 @@ -196,9 +196,8 @@ /* must be 2 less so 0 0 can signal end of chunks */ #define PHYS_AVAIL_ARRAY_END ((sizeof(phys_avail) / sizeof(vm_offset_t)) - 2) -static vm_offset_t buffer_sva, buffer_eva; -vm_offset_t clean_sva, clean_eva; -static vm_offset_t pager_sva, pager_eva; +struct kva_md_info kmi; + static struct trapframe proc0_tf; #ifndef SMP static struct globaldata __globaldata; @@ -211,14 +210,6 @@ cpu_startup(dummy) void *dummy; { - register unsigned i; - register caddr_t v; - vm_offset_t maxaddr; - vm_size_t size = 0; - int firstaddr; - vm_offset_t minaddr; - int physmem_est; - /* * Good {morning,afternoon,evening,night}. */ @@ -248,6 +239,9 @@ } } + vm_ksubmap_init(&kmi); + +#if 0 /* * Calculate callout wheel size */ @@ -384,6 +378,7 @@ } mtx_init(&callout_lock, "callout", MTX_SPIN | MTX_RECURSE); +#endif #if defined(USERCONFIG) userconfig(); Index: i386/i386/pmap.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/pmap.c,v retrieving revision 1.284 diff -u -r1.284 pmap.c --- i386/i386/pmap.c 2001/07/27 01:08:59 1.284 +++ i386/i386/pmap.c 2001/08/20 23:10:49 @@ -546,7 +546,7 @@ static PMAP_INLINE int pmap_track_modified(vm_offset_t va) { - if ((va < clean_sva) || (va >= clean_eva)) + if ((va < kmi.clean_sva) || (va >= kmi.clean_eva)) return 1; else return 0; Index: alpha/alpha/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/machdep.c,v retrieving revision 1.138 diff -u -r1.138 machdep.c --- alpha/alpha/machdep.c 2001/08/13 22:41:14 1.138 +++ alpha/alpha/machdep.c 2001/08/20 23:39:42 @@ -228,9 +228,7 @@ static void identifycpu __P((void)); -static vm_offset_t buffer_sva, buffer_eva; -vm_offset_t clean_sva, clean_eva; -static vm_offset_t pager_sva, pager_eva; +struct kva_md_info kmi; /* * Hooked into the shutdown chain; if the system is to be halted, @@ -248,13 +246,6 @@ cpu_startup(dummy) void *dummy; { - register unsigned i; - register caddr_t v; - vm_offset_t maxaddr; - vm_size_t size = 0; - vm_offset_t firstaddr; - vm_offset_t minaddr; - /* * Good {morning,afternoon,evening,night}. */ @@ -281,6 +272,9 @@ } } + vm_ksubmap_init(&kmi); + +#if 0 /* * Calculate callout wheel size */ @@ -387,6 +381,7 @@ } mtx_init(&callout_lock, "callout", MTX_SPIN | MTX_RECURSE); +#endif #if defined(USERCONFIG) #if defined(USERCONFIG_BOOT) Index: alpha/alpha/pmap.c =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/pmap.c,v retrieving revision 1.62 diff -u -r1.62 pmap.c --- alpha/alpha/pmap.c 2001/07/27 01:08:59 1.62 +++ alpha/alpha/pmap.c 2001/08/20 23:23:56 @@ -774,7 +774,7 @@ static PMAP_INLINE int pmap_track_modified(vm_offset_t va) { - if ((va < clean_sva) || (va >= clean_eva)) + if ((va < kmi.clean_sva) || (va >= kmi.clean_eva)) return 1; else return 0; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Aug 20 18:57:53 2001 Delivered-To: freebsd-smp@freebsd.org Received: from k7.locore.ca (k7.locore.ca [198.96.117.169]) by hub.freebsd.org (Postfix) with ESMTP id A1F2637B407; Mon, 20 Aug 2001 18:57:16 -0700 (PDT) (envelope-from jake@k7.locore.ca) Received: from k7.locore.ca (localhost [127.0.0.1]) by k7.locore.ca (8.11.4/8.11.4) with ESMTP id f7L1vAh10384; Mon, 20 Aug 2001 21:57:10 -0400 (EDT) (envelope-from jake@k7.locore.ca) Message-Id: <200108210157.f7L1vAh10384@k7.locore.ca> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Matt Dillon Cc: John Baldwin , freebsd-smp@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: Preliminary proposed rollup of kernel submap initialization code In-Reply-To: Message from Matt Dillon of "Mon, 20 Aug 2001 16:40:08 PDT." <200108202340.f7KNe8l58236@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Aug 2001 21:57:10 -0400 From: Jake Burkholder Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > This is what I was thinking in regards to rolling up the submap > initialization code, moving out of the MD section into the MI section. > This is for -current only and has not yet been tested, do not patch this > in. I'm looking mainly for feedback on things like the location of the > procedures, structure declarations, externs, and so forth. > > This patch includes the rollup for i386 and alpha. platforms that > haven't been rolled up will still compile just fine the old way (we > can roll things up piecemeal). > > -Matt > > Yay! I was just about to do almost exactly the same thing! Looks ok to me. I'll take care of the sparc64 changes. You might want to move some of the callout initialization to kern_timeout.c. > Index: vm/vm.h > =================================================================== > RCS file: /home/ncvs/src/sys/vm/vm.h,v > retrieving revision 1.18 > diff -u -r1.18 vm.h > --- vm/vm.h 2001/07/04 16:20:27 1.18 > +++ vm/vm.h 2001/08/20 23:35:44 > @@ -113,4 +113,21 @@ > typedef struct vm_page *vm_page_t; > #endif > > +/* > + * Information passed from the machine-independant VM initialization code > + * for use by machine-dependant code (mainly for MMU support) > + */ > +struct kva_md_info { > + vm_offset_t buffer_sva; > + vm_offset_t buffer_eva; > + vm_offset_t clean_sva; > + vm_offset_t clean_eva; > + vm_offset_t pager_sva; > + vm_offset_t pager_eva; > +}; > + > +extern struct kva_md_info kmi; > +extern void vm_ksubmap_init(struct kva_md_info *kmi); > + > #endif /* VM_H */ > + > Index: vm/vm_init.c > =================================================================== > RCS file: /home/ncvs/src/sys/vm/vm_init.c,v > retrieving revision 1.28 > diff -u -r1.28 vm_init.c > --- vm/vm_init.c 2001/07/04 16:20:27 1.28 > +++ vm/vm_init.c 2001/08/20 23:34:35 > @@ -74,8 +74,12 @@ > #include > #include > #include > +#include > +#include > > #include > +#include > +#include > #include > #include > #include > @@ -119,3 +123,154 @@ > pmap_init(avail_start, avail_end); > vm_pager_init(); > } > + > +void > +vm_ksubmap_init(struct kva_md_info *kmi) > +{ > + vm_offset_t firstaddr; > + caddr_t v; > + vm_size_t size = 0; > + int physmem_est; > + vm_offset_t minaddr; > + vm_offset_t maxaddr; > + unsigned int i; > + > + /* > + * Calculate callout wheel size > + */ > + for (callwheelsize = 1, callwheelbits = 0; > + callwheelsize < ncallout; > + callwheelsize <<= 1, ++callwheelbits) > + ; > + callwheelmask = callwheelsize - 1; > + > + /* > + * Allocate space for system data structures. > + * The first available kernel virtual address is in "v". > + * As pages of kernel virtual memory are allocated, "v" is incremented. > + * As pages of memory are allocated and cleared, > + * "firstaddr" is incremented. > + * An index into the kernel page table corresponding to the > + * virtual memory address maintained in "v" is kept in "mapaddr". > + */ > + > + /* > + * Make two passes. The first pass calculates how much memory is > + * needed and allocates it. The second pass assigns virtual > + * addresses to the various data structures. > + */ > + firstaddr = 0; > +again: > + v = (caddr_t)firstaddr; > + > +#define valloc(name, type, num) \ > + (name) = (type *)v; v = (caddr_t)((name)+(num)) > +#define valloclim(name, type, num, lim) \ > + (name) = (type *)v; v = (caddr_t)((lim) = ((name)+(num))) > + > + valloc(callout, struct callout, ncallout); > + valloc(callwheel, struct callout_tailq, callwheelsize); > + > + /* > + * Discount the physical memory larger than the size of kernel_map > + * to avoid eating up all of KVA space. > + */ > + if (kernel_map->first_free == NULL) { > + printf("Warning: no free entries in kernel_map.\n"); > + physmem_est = physmem; > + } else { > + physmem_est = min(physmem, kernel_map->max_offset - > + kernel_map->min_offset); > + } > + > + /* > + * The nominal buffer size (and minimum KVA allocation) is BKVASIZE. > + * For the first 64MB of ram nominally allocate sufficient buffers to > + * cover 1/4 of our ram. Beyond the first 64MB allocate additional > + * buffers to cover 1/20 of our ram over 64MB. When auto-sizing > + * the buffer cache we limit the eventual kva reservation to > + * maxbcache bytes. > + * > + * factor represents the 1/4 x ram conversion. > + */ > + if (nbuf == 0) { > + int factor = 4 * BKVASIZE / PAGE_SIZE; > + > + nbuf = 50; > + if (physmem_est > 1024) > + nbuf += min((physmem_est - 1024) / factor, > + 16384 / factor); > + if (physmem_est > 16384) > + nbuf += (physmem_est - 16384) * 2 / (factor * 5); > + > + if (maxbcache && nbuf > physmem_est / BKVASIZE) > + nbuf = maxbcache / BKVASIZE; > + } > + > + /* > + * Do not allow the buffer_map to be more then 1/2 the size of the > + * kernel_map. > + */ > + if (nbuf > (kernel_map->max_offset - kernel_map->min_offset) / > + (BKVASIZE * 2)) { > + nbuf = (kernel_map->max_offset - kernel_map->min_offset) / > + (BKVASIZE * 2); > + printf("Warning: nbufs capped at %d\n", nbuf); > + } > + > + nswbuf = max(min(nbuf/4, 256), 16); > + > + valloc(swbuf, struct buf, nswbuf); > + valloc(buf, struct buf, nbuf); > + v = bufhashinit(v); > + > + /* > + * End of first pass, size has been calculated so allocate memory > + */ > + if (firstaddr == 0) { > + size = (vm_size_t)((char *)v - firstaddr); > + firstaddr = kmem_alloc(kernel_map, round_page(size)); > + if (firstaddr == 0) > + panic("startup: no room for tables"); > + goto again; > + } > + > + /* > + * End of second pass, addresses have been assigned > + */ > + if ((vm_size_t)((char *)v - firstaddr) != size) > + panic("startup: table size inconsistency"); > + > + clean_map = kmem_suballoc(kernel_map, &kmi->clean_sva, &kmi->clean_eva, > + (nbuf*BKVASIZE) + (nswbuf*MAXPHYS) + pager_map_size); > + buffer_map = kmem_suballoc(clean_map, &kmi->buffer_sva, > + &kmi->buffer_eva, (nbuf*BKVASIZE)); > + buffer_map->system_map = 1; > + pager_map = kmem_suballoc(clean_map, &kmi->pager_sva, &kmi->pager_eva, > + (nswbuf*MAXPHYS) + pager_map_size); > + pager_map->system_map = 1; > + exec_map = kmem_suballoc(kernel_map, &minaddr, &maxaddr, > + (16*(ARG_MAX+(PAGE_SIZE*3)))); > + > + /* > + * XXX: Mbuf system machine-specific initializations should > + * go here, if anywhere. > + */ > + > + /* > + * Initialize callouts > + */ > + SLIST_INIT(&callfree); > + for (i = 0; i < ncallout; i++) { > + callout_init(&callout[i], 0); > + callout[i].c_flags = CALLOUT_LOCAL_ALLOC; > + SLIST_INSERT_HEAD(&callfree, &callout[i], c_links.sle); > + } > + > + for (i = 0; i < callwheelsize; i++) { > + TAILQ_INIT(&callwheel[i]); > + } > + > + mtx_init(&callout_lock, "callout", MTX_SPIN | MTX_RECURSE); > +} > + > Index: i386/i386/machdep.c > =================================================================== > RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v > retrieving revision 1.470 > diff -u -r1.470 machdep.c > --- i386/i386/machdep.c 2001/08/20 00:41:11 1.470 > +++ i386/i386/machdep.c 2001/08/20 23:36:28 > @@ -196,9 +196,8 @@ > /* must be 2 less so 0 0 can signal end of chunks */ > #define PHYS_AVAIL_ARRAY_END ((sizeof(phys_avail) / sizeof(vm_offset_t)) - 2) > > -static vm_offset_t buffer_sva, buffer_eva; > -vm_offset_t clean_sva, clean_eva; > -static vm_offset_t pager_sva, pager_eva; > +struct kva_md_info kmi; > + > static struct trapframe proc0_tf; > #ifndef SMP > static struct globaldata __globaldata; > @@ -211,14 +210,6 @@ > cpu_startup(dummy) > void *dummy; > { > - register unsigned i; > - register caddr_t v; > - vm_offset_t maxaddr; > - vm_size_t size = 0; > - int firstaddr; > - vm_offset_t minaddr; > - int physmem_est; > - > /* > * Good {morning,afternoon,evening,night}. > */ > @@ -248,6 +239,9 @@ > } > } > > + vm_ksubmap_init(&kmi); > + > +#if 0 > /* > * Calculate callout wheel size > */ > @@ -384,6 +378,7 @@ > } > > mtx_init(&callout_lock, "callout", MTX_SPIN | MTX_RECURSE); > +#endif > > #if defined(USERCONFIG) > userconfig(); > Index: i386/i386/pmap.c > =================================================================== > RCS file: /home/ncvs/src/sys/i386/i386/pmap.c,v > retrieving revision 1.284 > diff -u -r1.284 pmap.c > --- i386/i386/pmap.c 2001/07/27 01:08:59 1.284 > +++ i386/i386/pmap.c 2001/08/20 23:10:49 > @@ -546,7 +546,7 @@ > static PMAP_INLINE int > pmap_track_modified(vm_offset_t va) > { > - if ((va < clean_sva) || (va >= clean_eva)) > + if ((va < kmi.clean_sva) || (va >= kmi.clean_eva)) > return 1; > else > return 0; > Index: alpha/alpha/machdep.c > =================================================================== > RCS file: /home/ncvs/src/sys/alpha/alpha/machdep.c,v > retrieving revision 1.138 > diff -u -r1.138 machdep.c > --- alpha/alpha/machdep.c 2001/08/13 22:41:14 1.138 > +++ alpha/alpha/machdep.c 2001/08/20 23:39:42 > @@ -228,9 +228,7 @@ > > static void identifycpu __P((void)); > > -static vm_offset_t buffer_sva, buffer_eva; > -vm_offset_t clean_sva, clean_eva; > -static vm_offset_t pager_sva, pager_eva; > +struct kva_md_info kmi; > > /* > * Hooked into the shutdown chain; if the system is to be halted, > @@ -248,13 +246,6 @@ > cpu_startup(dummy) > void *dummy; > { > - register unsigned i; > - register caddr_t v; > - vm_offset_t maxaddr; > - vm_size_t size = 0; > - vm_offset_t firstaddr; > - vm_offset_t minaddr; > - > /* > * Good {morning,afternoon,evening,night}. > */ > @@ -281,6 +272,9 @@ > } > } > > + vm_ksubmap_init(&kmi); > + > +#if 0 > /* > * Calculate callout wheel size > */ > @@ -387,6 +381,7 @@ > } > > mtx_init(&callout_lock, "callout", MTX_SPIN | MTX_RECURSE); > +#endif > > #if defined(USERCONFIG) > #if defined(USERCONFIG_BOOT) > Index: alpha/alpha/pmap.c > =================================================================== > RCS file: /home/ncvs/src/sys/alpha/alpha/pmap.c,v > retrieving revision 1.62 > diff -u -r1.62 pmap.c > --- alpha/alpha/pmap.c 2001/07/27 01:08:59 1.62 > +++ alpha/alpha/pmap.c 2001/08/20 23:23:56 > @@ -774,7 +774,7 @@ > static PMAP_INLINE int > pmap_track_modified(vm_offset_t va) > { > - if ((va < clean_sva) || (va >= clean_eva)) > + if ((va < kmi.clean_sva) || (va >= kmi.clean_eva)) > return 1; > else > return 0; > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Aug 21 0:24:14 2001 Delivered-To: freebsd-smp@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id D54F737B415; Tue, 21 Aug 2001 00:24:10 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7L7O4E61056; Tue, 21 Aug 2001 00:24:04 -0700 (PDT) (envelope-from dillon) Date: Tue, 21 Aug 2001 00:24:04 -0700 (PDT) From: Matt Dillon Message-Id: <200108210724.f7L7O4E61056@earth.backplane.com> To: Jake Burkholder Cc: John Baldwin , freebsd-smp@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: Preliminary proposed rollup of kernel submap initialization code References: <200108210157.f7L1vAh10384@k7.locore.ca> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org :Yay! I was just about to do almost exactly the same thing! : :Looks ok to me. I'll take care of the sparc64 changes. : :You might want to move some of the callout initialization to :kern_timeout.c. Ok, will do. I'll make the modifications, add the fixes as per Bruce, get the timeout init into kern_timeout.c, test, and commit it all tomorrow night. I ran out of time tonight. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Aug 21 1:16:30 2001 Delivered-To: freebsd-smp@freebsd.org Received: from zen.estpak.ee (zen.estpak.ee [194.126.101.100]) by hub.freebsd.org (Postfix) with ESMTP id 1A7F037B41B for ; Tue, 21 Aug 2001 01:16:27 -0700 (PDT) (envelope-from kalts@estpak.ee) Received: from myhakas.estpak.ee (myhakas.estpak.ee [194.126.115.54]) by zen.estpak.ee (Postfix) with ESMTP id BFEC839B143; Tue, 21 Aug 2001 10:16:25 +0200 (EET) Received: (from vallo@localhost) by myhakas.estpak.ee (8.11.5/8.11.5) id f7L8GOT02747; Tue, 21 Aug 2001 10:16:24 +0200 (EET) (envelope-from vallo) Date: Tue, 21 Aug 2001 10:16:24 +0200 From: Vallo Kallaste To: =?utf-8?Q?S=F8ren?= Schmidt Cc: Jon Noack , freebsd-smp@FreeBSD.ORG Subject: Re: Bye bye dear SMP-system Message-ID: <20010821101624.A2632@myhakas.estpak.ee> Reply-To: kalts@estpak.ee Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200108201921.f7KJLcA87034@freebsd.dk> User-Agent: Mutt/1.3.18i-ja0 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Aug 20, 2001 at 09:21:38PM +0200, S�ren Schmidt wrote: > > I have come across have had to do with the HPT366 controller. I use IBM > > 75GXP hard drives in the machines and enabled tagged queuing (using the > > 'hw.ata.tags="1"' line in /boot/loader.conf). Under heavy reads (but not > > heavy writes - weird), the kernel would post an "ad0: READ command timeout > > resetting" error followed by an "ad0: invalidating queued requests" > > error. That was shortly followed by a hard lock. I tried 'hw.ata.wc="1"' > > instead and have had no problems (except if and when the UPS dies). I > > could reproduce the error by cvsuping my source tree to RELENG_4_3. The > > first time was fine, as there was some writing because several items were > > being updated (from 4.3-release). Later attempts (which were almost > > solely reads) always resulted in a hard lock. > > The HPT366 has HW issues with some of the fast disk, I havn't been able > to find a solution to that, nor has HPT as far as I'm informed.. Oh no, with Promise one can't use tagged queing at all, with HPT there's another problem... Are there any combinations of controller (such as Promise, HPT), disks and driver which works successfully under load? The whole ATA scene seems totally hopeless. -- Vallo Kallaste kalts@estpak.ee To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Aug 21 2:17:24 2001 Delivered-To: freebsd-smp@freebsd.org Received: from freebsd.dk (fw-rl0.freebsd.dk [212.242.86.114]) by hub.freebsd.org (Postfix) with ESMTP id 3CDF237B407 for ; Tue, 21 Aug 2001 02:17:19 -0700 (PDT) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.11.3/8.11.3) id f7L9HVM77882; Tue, 21 Aug 2001 11:17:31 +0200 (CEST) (envelope-from sos) From: Søren Schmidt Message-Id: <200108210917.f7L9HVM77882@freebsd.dk> Subject: Re: Bye bye dear SMP-system In-Reply-To: <20010821101624.A2632@myhakas.estpak.ee> "from Vallo Kallaste at Aug 21, 2001 10:16:24 am" To: kalts@estpak.ee Date: Tue, 21 Aug 2001 11:17:31 +0200 (CEST) Cc: Jon Noack , freebsd-smp@FreeBSD.ORG Reply-To: sos@freebsd.dk X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org It seems Vallo Kallaste wrote: > > > > The HPT366 has HW issues with some of the fast disk, I havn't been able > > to find a solution to that, nor has HPT as far as I'm informed.. > > Oh no, with Promise one can't use tagged queing at all, with HPT > there's another problem... Are there any combinations of controller > (such as Promise, HPT), disks and driver which works successfully > under load? The whole ATA scene seems totally hopeless. I dont think you can buy the HPT366 anymore, the current HPT370 works just dandy, in fact its my recommendation any time... On the Promise front I need to get ahold of one of their newer controller and see if they've fixed their DMA engine to support tagged queing, anybody got a spare Promise ctrl, prefarably the newest "TX2" based one ?? -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Aug 21 8:48:43 2001 Delivered-To: freebsd-smp@freebsd.org Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by hub.freebsd.org (Postfix) with ESMTP id 2317637B401; Tue, 21 Aug 2001 08:48:36 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@[147.11.46.201]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA05161; Tue, 21 Aug 2001 08:48:29 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200108202340.f7KNe8l58236@earth.backplane.com> Date: Tue, 21 Aug 2001 08:48:35 -0700 (PDT) From: John Baldwin To: Matt Dillon Subject: RE: Preliminary proposed rollup of kernel submap initialization Cc: freebsd-alpha@FreeBSD.org, freebsd-smp@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 20-Aug-01 Matt Dillon wrote: > This is what I was thinking in regards to rolling up the submap > initialization code, moving out of the MD section into the MI section. > This is for -current only and has not yet been tested, do not patch this > in. I'm looking mainly for feedback on things like the location of the > procedures, structure declarations, externs, and so forth. > > This patch includes the rollup for i386 and alpha. platforms that > haven't been rolled up will still compile just fine the old way (we > can roll things up piecemeal). Looks great! I've been wanting to do the same type of thing for a while. There's way too much MI code buried in sys/MACHINE/MACHINE still IMO. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Aug 21 9:33:16 2001 Delivered-To: freebsd-smp@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 2DEB337B409; Tue, 21 Aug 2001 09:33:10 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7LGX9463853; Tue, 21 Aug 2001 09:33:09 -0700 (PDT) (envelope-from dillon) Date: Tue, 21 Aug 2001 09:33:09 -0700 (PDT) From: Matt Dillon Message-Id: <200108211633.f7LGX9463853@earth.backplane.com> To: John Baldwin Cc: freebsd-alpha@FreeBSD.org, freebsd-smp@FreeBSD.org Subject: Re: RE: Preliminary proposed rollup of kernel submap initialization References: Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org : : :On 20-Aug-01 Matt Dillon wrote: :> This is what I was thinking in regards to rolling up the submap :> initialization code, moving out of the MD section into the MI section. :> This is for -current only and has not yet been tested, do not patch this :> in. I'm looking mainly for feedback on things like the location of the :> procedures, structure declarations, externs, and so forth. :> :> This patch includes the rollup for i386 and alpha. platforms that :> haven't been rolled up will still compile just fine the old way (we :> can roll things up piecemeal). : :Looks great! I've been wanting to do the same type of thing for a while. :There's way too much MI code buried in sys/MACHINE/MACHINE still IMO. : :-- : :John Baldwin -- http://www.FreeBSD.org/~jhb/ :PGP Key: http://www.baldwin.cx/~john/pgpkey.asc :"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ Maybe I'll take a pass at the MD/MI stuff in general before I try to get the VM mutexes working. Those are turning into a real bear - my roadmap is sound but I haven't had the time to really push into it. It may indeed not be complete until after 5.0 (what you or Jake thought would happen at the usenix kernel meeting). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Aug 21 9:56:34 2001 Delivered-To: freebsd-smp@freebsd.org Received: from mail.fpsn.net (mail.fpsn.net [63.224.69.57]) by hub.freebsd.org (Postfix) with ESMTP id 9694537B40B for ; Tue, 21 Aug 2001 09:56:28 -0700 (PDT) (envelope-from cfaber@fpsn.net) Received: from fpsn.net (control.fpsn.net [63.224.69.60]) by mail.fpsn.net (8.9.3/8.9.3) with ESMTP id KAA30880; Tue, 21 Aug 2001 10:54:28 -0600 (MDT) (envelope-from cfaber@fpsn.net) Message-ID: <3B82924F.1BC53557@fpsn.net> Date: Tue, 21 Aug 2001 10:54:39 -0600 From: Colin Faber Reply-To: cfaber@fpsn.net Organization: fpsn.net, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sos@freebsd.dk Cc: kalts@estpak.ee, Jon Noack , freebsd-smp@FreeBSD.ORG Subject: Re: Bye bye dear SMP-system References: <200108210917.f7L9HVM77882@freebsd.dk> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I do, and its totally unused, Would you like me to mail it? `Promise TX2 Ultra100' "Søren Schmidt" wrote: > > It seems Vallo Kallaste wrote: > > > > > > The HPT366 has HW issues with some of the fast disk, I havn't been able > > > to find a solution to that, nor has HPT as far as I'm informed.. > > > > Oh no, with Promise one can't use tagged queing at all, with HPT > > there's another problem... Are there any combinations of controller > > (such as Promise, HPT), disks and driver which works successfully > > under load? The whole ATA scene seems totally hopeless. > > I dont think you can buy the HPT366 anymore, the current HPT370 > works just dandy, in fact its my recommendation any time... > > On the Promise front I need to get ahold of one of their newer > controller and see if they've fixed their DMA engine to > support tagged queing, anybody got a spare Promise ctrl, > prefarably the newest "TX2" based one ?? > > -Søren > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Aug 21 10:37:54 2001 Delivered-To: freebsd-smp@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id D071937B401; Tue, 21 Aug 2001 10:36:52 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7LHaoC64628; Tue, 21 Aug 2001 10:36:50 -0700 (PDT) (envelope-from dillon) Date: Tue, 21 Aug 2001 10:36:50 -0700 (PDT) From: Matt Dillon Message-Id: <200108211736.f7LHaoC64628@earth.backplane.com> To: Jake Burkholder Cc: John Baldwin , freebsd-smp@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: Preliminary proposed rollup of kernel submap initialization code References: <200108210157.f7L1vAh10384@k7.locore.ca> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org :Yay! I was just about to do almost exactly the same thing! : :Looks ok to me. I'll take care of the sparc64 changes. : :You might want to move some of the callout initialization to :kern_timeout.c. Ok, here is an adjusted patch. This compiles clean (for i386 anyway), but has NOT been tested yet. Specifically, I rearranged the caddr_t v address manipulation a bit. I'll be able to test and commit it to -current this evening. -Matt Index: alpha/alpha/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/machdep.c,v retrieving revision 1.138 diff -u -r1.138 machdep.c --- alpha/alpha/machdep.c 2001/08/13 22:41:14 1.138 +++ alpha/alpha/machdep.c 2001/08/20 23:39:42 @@ -228,9 +228,7 @@ static void identifycpu __P((void)); -static vm_offset_t buffer_sva, buffer_eva; -vm_offset_t clean_sva, clean_eva; -static vm_offset_t pager_sva, pager_eva; +struct kva_md_info kmi; /* * Hooked into the shutdown chain; if the system is to be halted, @@ -248,13 +246,6 @@ cpu_startup(dummy) void *dummy; { - register unsigned i; - register caddr_t v; - vm_offset_t maxaddr; - vm_size_t size = 0; - vm_offset_t firstaddr; - vm_offset_t minaddr; - /* * Good {morning,afternoon,evening,night}. */ @@ -281,6 +272,9 @@ } } + vm_ksubmap_init(&kmi); + +#if 0 /* * Calculate callout wheel size */ @@ -387,6 +381,7 @@ } mtx_init(&callout_lock, "callout", MTX_SPIN | MTX_RECURSE); +#endif #if defined(USERCONFIG) #if defined(USERCONFIG_BOOT) Index: alpha/alpha/pmap.c =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/pmap.c,v retrieving revision 1.62 diff -u -r1.62 pmap.c --- alpha/alpha/pmap.c 2001/07/27 01:08:59 1.62 +++ alpha/alpha/pmap.c 2001/08/20 23:23:56 @@ -774,7 +774,7 @@ static PMAP_INLINE int pmap_track_modified(vm_offset_t va) { - if ((va < clean_sva) || (va >= clean_eva)) + if ((va < kmi.clean_sva) || (va >= kmi.clean_eva)) return 1; else return 0; Index: i386/i386/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v retrieving revision 1.472 diff -u -r1.472 machdep.c --- i386/i386/machdep.c 2001/08/21 07:20:06 1.472 +++ i386/i386/machdep.c 2001/08/21 07:21:52 @@ -198,9 +198,8 @@ /* must be 2 less so 0 0 can signal end of chunks */ #define PHYS_AVAIL_ARRAY_END ((sizeof(phys_avail) / sizeof(vm_offset_t)) - 2) -static vm_offset_t buffer_sva, buffer_eva; -vm_offset_t clean_sva, clean_eva; -static vm_offset_t pager_sva, pager_eva; +struct kva_md_info kmi; + static struct trapframe proc0_tf; #ifndef SMP static struct globaldata __globaldata; @@ -213,14 +212,6 @@ cpu_startup(dummy) void *dummy; { - register unsigned i; - register caddr_t v; - vm_offset_t maxaddr; - vm_size_t size = 0; - int firstaddr; - vm_offset_t minaddr; - int physmem_est; /* in pages */ - /* * Good {morning,afternoon,evening,night}. */ @@ -250,6 +241,9 @@ } } + vm_ksubmap_init(&kmi); + +#if 0 /* * Calculate callout wheel size */ @@ -387,6 +381,7 @@ } mtx_init(&callout_lock, "callout", MTX_SPIN | MTX_RECURSE); +#endif #if defined(USERCONFIG) userconfig(); Index: i386/i386/pmap.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/pmap.c,v retrieving revision 1.284 diff -u -r1.284 pmap.c --- i386/i386/pmap.c 2001/07/27 01:08:59 1.284 +++ i386/i386/pmap.c 2001/08/20 23:10:49 @@ -546,7 +546,7 @@ static PMAP_INLINE int pmap_track_modified(vm_offset_t va) { - if ((va < clean_sva) || (va >= clean_eva)) + if ((va < kmi.clean_sva) || (va >= kmi.clean_eva)) return 1; else return 0; Index: kern/kern_timeout.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_timeout.c,v retrieving revision 1.69 diff -u -r1.69 kern_timeout.c --- kern/kern_timeout.c 2001/08/10 21:06:59 1.69 +++ kern/kern_timeout.c 2001/08/21 17:10:20 @@ -62,6 +62,55 @@ static struct callout *nextsoftcheck; /* Next callout to be checked. */ /* + * kern_timeout_callwheel_alloc() - kernel low level callwheel initialization + * + * This code is called very early in the kernel initialization sequence, + * and may be called more then once. + */ +caddr_t +kern_timeout_callwheel_alloc(caddr_t v) +{ + /* + * Calculate callout wheel size + */ + for (callwheelsize = 1, callwheelbits = 0; + callwheelsize < ncallout; + callwheelsize <<= 1, ++callwheelbits) + ; + callwheelmask = callwheelsize - 1; + + callout = (struct callout *)v; + v = (caddr_t)(callout + ncallout); + callwheel = (struct callout_tailq *)v; + v = (caddr_t)(callwheel + callwheelsize); + return(v); +} + +/* + * kern_timeout_callwheel_init() - initialize previously reserved callwheel + * space. + * + * This code is called just once, after the space reserved for the + * callout wheel has been finalized. + */ +void +kern_timeout_callwheel_init(void) +{ + int i; + + SLIST_INIT(&callfree); + for (i = 0; i < ncallout; i++) { + callout_init(&callout[i], 0); + callout[i].c_flags = CALLOUT_LOCAL_ALLOC; + SLIST_INSERT_HEAD(&callfree, &callout[i], c_links.sle); + } + for (i = 0; i < callwheelsize; i++) { + TAILQ_INIT(&callwheel[i]); + } + mtx_init(&callout_lock, "callout", MTX_SPIN | MTX_RECURSE); +} + +/* * The callout mechanism is based on the work of Adam M. Costello and * George Varghese, published in a technical report entitled "Redesigning * the BSD Callout and Timer Facilities" and modified slightly for inclusion Index: kern/vfs_bio.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v retrieving revision 1.285 diff -u -r1.285 vfs_bio.c --- kern/vfs_bio.c 2001/07/27 15:57:17 1.285 +++ kern/vfs_bio.c 2001/08/21 17:26:53 @@ -319,19 +319,73 @@ } /* - * Initialize buffer headers and related structures. + * Calculating buffer cache scaling values and reserve space for buffer + * headers. This is called during low level kernel initialization and + * may be called more then once. We CANNOT write to the memory area + * being reserved at this time. */ - caddr_t -bufhashinit(caddr_t vaddr) +kern_vfs_bio_buffer_alloc(caddr_t v, int physmem_est) { - /* first, make a null hash table */ + /* + * The nominal buffer size (and minimum KVA allocation) is BKVASIZE. + * For the first 64MB of ram nominally allocate sufficient buffers to + * cover 1/4 of our ram. Beyond the first 64MB allocate additional + * buffers to cover 1/20 of our ram over 64MB. When auto-sizing + * the buffer cache we limit the eventual kva reservation to + * maxbcache bytes. + * + * factor represents the 1/4 x ram conversion. + */ + if (nbuf == 0) { + int factor = 4 * BKVASIZE / PAGE_SIZE; + + nbuf = 50; + if (physmem_est > 1024) + nbuf += min((physmem_est - 1024) / factor, + 16384 / factor); + if (physmem_est > 16384) + nbuf += (physmem_est - 16384) * 2 / (factor * 5); + + if (maxbcache && nbuf > maxbcache / BKVASIZE) + nbuf = maxbcache / BKVASIZE; + } + + /* + * Do not allow the buffer_map to be more then 1/2 the size of the + * kernel_map. + */ + if (nbuf > (kernel_map->max_offset - kernel_map->min_offset) / + (BKVASIZE * 2)) { + nbuf = (kernel_map->max_offset - kernel_map->min_offset) / + (BKVASIZE * 2); + printf("Warning: nbufs capped at %d\n", nbuf); + } + + /* + * swbufs are used as temporary holders for I/O, such as paging I/O. + * We have no less then 16 and no more then 256. + */ + nswbuf = max(min(nbuf/4, 256), 16); + + /* + * Reserve space for the buffer cache buffers + */ + swbuf = (void *)v; + v = (caddr_t)(swbuf + nswbuf); + buf = (void *)v; + v = (caddr_t)(buf + nbuf); + + /* + * Calculate the hash table size and reserve space + */ for (bufhashmask = 8; bufhashmask < nbuf / 4; bufhashmask <<= 1) ; - bufhashtbl = (void *)vaddr; - vaddr = vaddr + sizeof(*bufhashtbl) * bufhashmask; + bufhashtbl = (void *)v; + v = (caddr_t)(bufhashtbl + bufhashmask); --bufhashmask; - return(vaddr); + + return(v); } void Index: sys/buf.h =================================================================== RCS file: /home/ncvs/src/sys/sys/buf.h,v retrieving revision 1.119 diff -u -r1.119 buf.h --- sys/buf.h 2001/08/20 00:41:12 1.119 +++ sys/buf.h 2001/08/21 17:25:30 @@ -513,7 +513,7 @@ struct uio; -caddr_t bufhashinit __P((caddr_t)); +caddr_t kern_vfs_bio_buffer_alloc __P((caddr_t v, int physmem_est)); void bufinit __P((void)); void bwillwrite __P((void)); int buf_dirty_count_severe __P((void)); Index: sys/systm.h =================================================================== RCS file: /home/ncvs/src/sys/sys/systm.h,v retrieving revision 1.148 diff -u -r1.148 systm.h --- sys/systm.h 2001/08/10 06:37:04 1.148 +++ sys/systm.h 2001/08/21 17:25:20 @@ -208,6 +208,8 @@ void callout_handle_init __P((struct callout_handle *)); struct callout_handle timeout __P((timeout_t *, void *, int)); void untimeout __P((timeout_t *, void *, struct callout_handle)); +caddr_t kern_timeout_callwheel_alloc __P((caddr_t v)); +void kern_timeout_callwheel_init __P((void)); /* Stubs for obsolete functions that used to be for interrupt management */ static __inline void spl0(void) { return; } Index: vm/vm.h =================================================================== RCS file: /home/ncvs/src/sys/vm/vm.h,v retrieving revision 1.18 diff -u -r1.18 vm.h --- vm/vm.h 2001/07/04 16:20:27 1.18 +++ vm/vm.h 2001/08/20 23:35:44 @@ -113,4 +113,21 @@ typedef struct vm_page *vm_page_t; #endif +/* + * Information passed from the machine-independant VM initialization code + * for use by machine-dependant code (mainly for MMU support) + */ +struct kva_md_info { + vm_offset_t buffer_sva; + vm_offset_t buffer_eva; + vm_offset_t clean_sva; + vm_offset_t clean_eva; + vm_offset_t pager_sva; + vm_offset_t pager_eva; +}; + +extern struct kva_md_info kmi; +extern void vm_ksubmap_init(struct kva_md_info *kmi); + #endif /* VM_H */ + Index: vm/vm_init.c =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_init.c,v retrieving revision 1.28 diff -u -r1.28 vm_init.c --- vm/vm_init.c 2001/07/04 16:20:27 1.28 +++ vm/vm_init.c 2001/08/21 17:33:48 @@ -74,8 +74,12 @@ #include #include #include +#include +#include #include +#include +#include #include #include #include @@ -119,3 +123,88 @@ pmap_init(avail_start, avail_end); vm_pager_init(); } + +void +vm_ksubmap_init(struct kva_md_info *kmi) +{ + vm_offset_t firstaddr; + caddr_t v; + vm_size_t size = 0; + int physmem_est; + vm_offset_t minaddr; + vm_offset_t maxaddr; + + /* + * Allocate space for system data structures. + * The first available kernel virtual address is in "v". + * As pages of kernel virtual memory are allocated, "v" is incremented. + * As pages of memory are allocated and cleared, + * "firstaddr" is incremented. + * An index into the kernel page table corresponding to the + * virtual memory address maintained in "v" is kept in "mapaddr". + */ + + /* + * Make two passes. The first pass calculates how much memory is + * needed and allocates it. The second pass assigns virtual + * addresses to the various data structures. + */ + firstaddr = 0; +again: + v = (caddr_t)firstaddr; + + v = kern_timeout_callwheel_alloc(v); + + /* + * Discount the physical memory larger than the size of kernel_map + * to avoid eating up all of KVA space. + */ + if (kernel_map->first_free == NULL) { + printf("Warning: no free entries in kernel_map.\n"); + physmem_est = physmem; + } else { + physmem_est = min(physmem, btoc(kernel_map->max_offset - + kernel_map->min_offset)); + } + + v = kern_vfs_bio_buffer_alloc(v, physmem_est); + + /* + * End of first pass, size has been calculated so allocate memory + */ + if (firstaddr == 0) { + size = (vm_size_t)((char *)v - firstaddr); + firstaddr = kmem_alloc(kernel_map, round_page(size)); + if (firstaddr == 0) + panic("startup: no room for tables"); + goto again; + } + + /* + * End of second pass, addresses have been assigned + */ + if ((vm_size_t)((char *)v - firstaddr) != size) + panic("startup: table size inconsistency"); + + clean_map = kmem_suballoc(kernel_map, &kmi->clean_sva, &kmi->clean_eva, + (nbuf*BKVASIZE) + (nswbuf*MAXPHYS) + pager_map_size); + buffer_map = kmem_suballoc(clean_map, &kmi->buffer_sva, + &kmi->buffer_eva, (nbuf*BKVASIZE)); + buffer_map->system_map = 1; + pager_map = kmem_suballoc(clean_map, &kmi->pager_sva, &kmi->pager_eva, + (nswbuf*MAXPHYS) + pager_map_size); + pager_map->system_map = 1; + exec_map = kmem_suballoc(kernel_map, &minaddr, &maxaddr, + (16*(ARG_MAX+(PAGE_SIZE*3)))); + + /* + * XXX: Mbuf system machine-specific initializations should + * go here, if anywhere. + */ + + /* + * Initialize the callouts we just allocated. + */ + kern_timeout_callwheel_init(); +} + To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Aug 21 12: 3:14 2001 Delivered-To: freebsd-smp@freebsd.org Received: from webpimps.net (lgb-DSL71-cust207.mpowercom.net [208.57.71.207]) by hub.freebsd.org (Postfix) with ESMTP id 1FFC237B407 for ; Tue, 21 Aug 2001 12:03:11 -0700 (PDT) (envelope-from click46@webpimps.net) Received: from WorldClient [127.0.0.1] by webpimps.net [127.0.0.1] with SMTP (MDaemon.v3.1.2.R) for ; Tue, 21 Aug 2001 12:00:17 -0700 Date: Tue, 21 Aug 2001 12:00:17 -0700 From: "Aaron" To: "Colin Faber" Cc: kalts@estpak.ee, noackjr@compgeek.com, freebsd-smp@FreeBSD.ORG Subject: Promise TX2 Ultra100 [was Re: Bye bye dear SMP-system] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Mailer: WorldClient Standard 3.1.2 In-Reply-To: <3B82924F.1BC53557@fpsn.net> X-MDRcpt-To: freebsd-smp@FreeBSD.ORG X-MDRemoteIP: 127.0.0.1 X-Return-Path: click46@webpimps.net X-MDaemon-Deliver-To: freebsd-smp@FreeBSD.ORG Message-Id: <20010821190311.1FFC237B407@hub.freebsd.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I was under the impression that support for TX2 based Promise cards is non-existant due to Promise's lack of sharing needed information. Is this still true? Or has someone been able to get working drivers for this series of cards? If so, thats another one to chalk up for review ;) - aaron --------------------------------------------- click46[wp] - AIM the click46 - ICQ 43450396 webpimps.net | bsdatwork.com | nerdserve.net moderator - o/c cooling forum @ hardforum.com -----Original Message----- From: Colin Faber To: sos@freebsd.dk Date: Tue, 21 Aug 2001 10:54:39 -0600 Subject: Re: Bye bye dear SMP-system > I do, and its totally unused, > > Would you like me to mail it? > > > `Promise TX2 Ultra100' > > "Søren Schmidt" wrote: > > > > It seems Vallo Kallaste wrote: > > > > > > > > The HPT366 has HW issues with some of the fast disk, I havn't > been able > > > > to find a solution to that, nor has HPT as far as I'm informed.. > > > > > > Oh no, with Promise one can't use tagged queing at all, with HPT > > > there's another problem... Are there any combinations of controller > > > (such as Promise, HPT), disks and driver which works successfully > > > under load? The whole ATA scene seems totally hopeless. > > > > I dont think you can buy the HPT366 anymore, the current HPT370 > > works just dandy, in fact its my recommendation any time... > > > > On the Promise front I need to get ahold of one of their newer > > controller and see if they've fixed their DMA engine to > > support tagged queing, anybody got a spare Promise ctrl, > > prefarably the newest "TX2" based one ?? > > > > -Søren > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-smp" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Aug 21 12:22:51 2001 Delivered-To: freebsd-smp@freebsd.org Received: from freebsd.dk (fw-rl0.freebsd.dk [212.242.86.114]) by hub.freebsd.org (Postfix) with ESMTP id 73B2837B401 for ; Tue, 21 Aug 2001 12:22:46 -0700 (PDT) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.11.3/8.11.3) id f7LJMpW14318; Tue, 21 Aug 2001 21:22:51 +0200 (CEST) (envelope-from sos) From: Søren Schmidt Message-Id: <200108211922.f7LJMpW14318@freebsd.dk> Subject: Re: Promise TX2 Ultra100 [was Re: Bye bye dear SMP-system] In-Reply-To: <20010821190311.1FFC237B407@hub.freebsd.org> "from Aaron at Aug 21, 2001 12:00:17 pm" To: Aaron Date: Tue, 21 Aug 2001 21:22:50 +0200 (CEST) Cc: Colin Faber , kalts@estpak.ee, noackjr@compgeek.com, freebsd-smp@FreeBSD.ORG Reply-To: sos@freebsd.dk X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org It seems Aaron wrote: > I was under the impression that support for TX2 based Promise cards is > non-existant due to Promise's lack of sharing needed information. Is this > still true? Or has someone been able to get working drivers for this > series of cards? It has been supported for a while in -current, since today the v2 of the chip as well... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Aug 21 12:53:54 2001 Delivered-To: freebsd-smp@freebsd.org Received: from mail.fpsn.net (mail.fpsn.net [63.224.69.57]) by hub.freebsd.org (Postfix) with ESMTP id 140D237B40F for ; Tue, 21 Aug 2001 12:51:44 -0700 (PDT) (envelope-from cfaber@fpsn.net) Received: from fpsn.net (control.fpsn.net [63.224.69.60]) by mail.fpsn.net (8.9.3/8.9.3) with ESMTP id NAA32065; Tue, 21 Aug 2001 13:51:16 -0600 (MDT) (envelope-from cfaber@fpsn.net) Message-ID: <3B82BBBF.9131C949@fpsn.net> Date: Tue, 21 Aug 2001 13:51:27 -0600 From: Colin Faber Reply-To: cfaber@fpsn.net Organization: fpsn.net, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Aaron Cc: kalts@estpak.ee, noackjr@compgeek.com, freebsd-smp@FreeBSD.ORG Subject: Re: Promise TX2 Ultra100 [was Re: Bye bye dear SMP-system] References: <20010821190311.1FFC237B407@hub.freebsd.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm not so sure on that. I know that there was an entry into ata-pci.c committed to -CURRENT through im not sure who committed it. Aaron wrote: > > I was under the impression that support for TX2 based Promise cards is > non-existant due to Promise's lack of sharing needed information. Is this > still true? Or has someone been able to get working drivers for this > series of cards? > > If so, thats another one to chalk up for review ;) > > - aaron > > --------------------------------------------- > click46[wp] - AIM the click46 - ICQ 43450396 > webpimps.net | bsdatwork.com | nerdserve.net > moderator - o/c cooling forum @ hardforum.com > > -----Original Message----- > From: Colin Faber > To: sos@freebsd.dk > Date: Tue, 21 Aug 2001 10:54:39 -0600 > Subject: Re: Bye bye dear SMP-system > > > I do, and its totally unused, > > > > Would you like me to mail it? > > > > > > `Promise TX2 Ultra100' > > > > "Søren Schmidt" wrote: > > > > > > It seems Vallo Kallaste wrote: > > > > > > > > > > The HPT366 has HW issues with some of the fast disk, I havn't > > been able > > > > > to find a solution to that, nor has HPT as far as I'm informed.. > > > > > > > > Oh no, with Promise one can't use tagged queing at all, with HPT > > > > there's another problem... Are there any combinations of controller > > > > (such as Promise, HPT), disks and driver which works successfully > > > > under load? The whole ATA scene seems totally hopeless. > > > > > > I dont think you can buy the HPT366 anymore, the current HPT370 > > > works just dandy, in fact its my recommendation any time... > > > > > > On the Promise front I need to get ahold of one of their newer > > > controller and see if they've fixed their DMA engine to > > > support tagged queing, anybody got a spare Promise ctrl, > > > prefarably the newest "TX2" based one ?? > > > > > > -Søren > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-smp" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-smp" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Aug 21 13:26:54 2001 Delivered-To: freebsd-smp@freebsd.org Received: from freebsd.dk (fw-rl0.freebsd.dk [212.242.86.114]) by hub.freebsd.org (Postfix) with ESMTP id 93E5B37B407 for ; Tue, 21 Aug 2001 13:26:51 -0700 (PDT) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.11.3/8.11.3) id f7LKR0Q28865; Tue, 21 Aug 2001 22:27:00 +0200 (CEST) (envelope-from sos) From: Søren Schmidt Message-Id: <200108212027.f7LKR0Q28865@freebsd.dk> Subject: Re: Promise TX2 Ultra100 [was Re: Bye bye dear SMP-system] In-Reply-To: <3B82BBBF.9131C949@fpsn.net> "from Colin Faber at Aug 21, 2001 01:51:27 pm" To: cfaber@fpsn.net Date: Tue, 21 Aug 2001 22:27:00 +0200 (CEST) Cc: Aaron , kalts@estpak.ee, noackjr@compgeek.com, freebsd-smp@FreeBSD.ORG Reply-To: sos@freebsd.dk X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org It seems Colin Faber wrote: > I'm not so sure on that. > > I know that there was an entry into ata-pci.c committed to -CURRENT > through im not sure who committed it. I did, and I have reports that it works... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Aug 21 21: 9:19 2001 Delivered-To: freebsd-smp@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id D73B337B414; Tue, 21 Aug 2001 21:09:09 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7M498e71398; Tue, 21 Aug 2001 21:09:08 -0700 (PDT) (envelope-from dillon) Date: Tue, 21 Aug 2001 21:09:08 -0700 (PDT) From: Matt Dillon Message-Id: <200108220409.f7M498e71398@earth.backplane.com> To: Jake Burkholder Cc: John Baldwin , freebsd-smp@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: Preliminary proposed rollup of kernel submap initialization code References: <200108210157.f7L1vAh10384@k7.locore.ca> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I did some simple testing and comitted the rollup to -current. You should be good to go for the sparc, Jake. I didn't compile-test alpha but it should be fine. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Aug 22 0:30:47 2001 Delivered-To: freebsd-smp@freebsd.org Received: from dragon.nuxi.com (dsl092-013-169.sfo1.dsl.speakeasy.net [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id B1B8B37B40A; Wed, 22 Aug 2001 00:30:42 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.5/8.11.1) id f7M7UTo65341; Wed, 22 Aug 2001 00:30:29 -0700 (PDT) (envelope-from obrien) Date: Wed, 22 Aug 2001 00:30:29 -0700 From: "David O'Brien" To: Matt Dillon Cc: Jake Burkholder , John Baldwin , freebsd-smp@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: Preliminary proposed rollup of kernel submap initialization code Message-ID: <20010822003029.A65089@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200108210157.f7L1vAh10384@k7.locore.ca> <200108220409.f7M498e71398@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108220409.f7M498e71398@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Aug 21, 2001 at 09:09:08PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Aug 21, 2001 at 09:09:08PM -0700, Matt Dillon wrote: > I didn't compile-test alpha > but it should be fine. Is beast.freebsd.org down? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Aug 22 0:41:17 2001 Delivered-To: freebsd-smp@freebsd.org Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 2F7F937B406; Wed, 22 Aug 2001 00:41:10 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.135.228.Dial1.SanJose1.Level3.net [209.245.135.228]) by snipe.mail.pas.earthlink.net (8.11.5/8.9.3) with ESMTP id f7M7f6h27454; Wed, 22 Aug 2001 00:41:06 -0700 (PDT) Message-ID: <3B83623D.9DC45B93@mindspring.com> Date: Wed, 22 Aug 2001 00:41:49 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matt Dillon Cc: Jake Burkholder , John Baldwin , freebsd-smp@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: Preliminary proposed rollup of kernel submap initialization code References: <200108210157.f7L1vAh10384@k7.locore.ca> <200108211736.f7LHaoC64628@earth.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Matt Dillon wrote: > -static vm_offset_t buffer_sva, buffer_eva; > -vm_offset_t clean_sva, clean_eva; > -static vm_offset_t pager_sva, pager_eva; > +struct kva_md_info kmi; You make this a non-static global... > + vm_ksubmap_init(&kmi); Then you pass it's address in... > +void > +vm_ksubmap_init(struct kva_md_info *kmi) > +{ And then use much more expensive pointer arithmatic... > + buffer_map = kmem_suballoc(clean_map, &kmi->buffer_sva, > + &kmi->buffer_eva, (nbuf*BKVASIZE)); I understand that this is called once, but doesn't this really obfuscate things? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Aug 22 7:57: 0 2001 Delivered-To: freebsd-smp@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 1DB1837B418; Wed, 22 Aug 2001 07:56:43 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7MEufD74609; Wed, 22 Aug 2001 07:56:41 -0700 (PDT) (envelope-from dillon) Date: Wed, 22 Aug 2001 07:56:41 -0700 (PDT) From: Matt Dillon Message-Id: <200108221456.f7MEufD74609@earth.backplane.com> To: Terry Lambert Cc: Jake Burkholder , John Baldwin , freebsd-smp@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: Preliminary proposed rollup of kernel submap initialization code References: <200108210157.f7L1vAh10384@k7.locore.ca> <200108211736.f7LHaoC64628@earth.backplane.com> <3B83623D.9DC45B93@mindspring.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org :Then you pass it's address in... : :> +void :> +vm_ksubmap_init(struct kva_md_info *kmi) :> +{ : :And then use much more expensive pointer arithmatic... : :> + buffer_map = kmem_suballoc(clean_map, &kmi->buffer_sva, :> + &kmi->buffer_eva, (nbuf*BKVASIZE)); : :I understand that this is called once, but doesn't this :really obfuscate things? : :-- Terry I don't follow. The argument passing and pointer arithmatic is not expensive at all - in fact, it is less expensive then the original MD code if you look at the assembly output! And who really gives a damn about a few nanoseconds during boot anyway? kmi is static in the MD sections because it allows the kernel to compile for all platforms without us having to 'fix' all platforms all at once. One could also argue that the mainline kernel code has no direct need to know about the contents of kmi but that wasn't the main reason for doing it that way. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Aug 22 8: 0:31 2001 Delivered-To: freebsd-smp@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 4B61037B41C; Wed, 22 Aug 2001 08:00:22 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7MF0Mj74650; Wed, 22 Aug 2001 08:00:22 -0700 (PDT) (envelope-from dillon) Date: Wed, 22 Aug 2001 08:00:22 -0700 (PDT) From: Matt Dillon Message-Id: <200108221500.f7MF0Mj74650@earth.backplane.com> To: "David O'Brien" Cc: Jake Burkholder , John Baldwin , freebsd-smp@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: Preliminary proposed rollup of kernel submap initialization code References: <200108210157.f7L1vAh10384@k7.locore.ca> <200108220409.f7M498e71398@earth.backplane.com> <20010822003029.A65089@dragon.nuxi.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org : :On Tue, Aug 21, 2001 at 09:09:08PM -0700, Matt Dillon wrote: :> I didn't compile-test alpha :> but it should be fine. : :Is beast.freebsd.org down? I'll have more time in the future to run parallel compiles but, generally speaking, compiling on beast (or on other platforms) is always going to be an afterthought to some degree. On the otherhand, if we could get some sort of official cross-compiling environment setup, I would be happy to do all of that on my local box. Then I wouldn't have to shove patchsets around. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Aug 22 12:24:23 2001 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 837EE37B43B; Wed, 22 Aug 2001 12:23:49 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id FAA19268; Thu, 23 Aug 2001 05:23:36 +1000 Date: Thu, 23 Aug 2001 05:23:30 +1000 (EST) From: Bruce Evans X-X-Sender: To: Matt Dillon Cc: Terry Lambert , Jake Burkholder , John Baldwin , , Subject: Re: Preliminary proposed rollup of kernel submap initialization code In-Reply-To: <200108221456.f7MEufD74609@earth.backplane.com> Message-ID: <20010823051540.U15063-100000@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 22 Aug 2001, Matt Dillon wrote: > :Then you pass it's address in... > : > :> +void > :> +vm_ksubmap_init(struct kva_md_info *kmi) > :> +{ > : > :And then use much more expensive pointer arithmatic... > : > :> + buffer_map = kmem_suballoc(clean_map, &kmi->buffer_sva, > :> + &kmi->buffer_eva, (nbuf*BKVASIZE)); > : > :I understand that this is called once, but doesn't this > :really obfuscate things? > : > :-- Terry > > I don't follow. The argument passing and pointer arithmatic is not > expensive at all - in fact, it is less expensive then the original MD > code if you look at the assembly output! And who really gives a damn > about a few nanoseconds during boot anyway? > > kmi is static in the MD sections because it allows the kernel to compile global > for all platforms without us having to 'fix' all platforms all at once. Make it global in an MI section and it automatically implements it in all platforms at once (platforms that haven't been "fixed" simply don't use it). > One could also argue that the mainline kernel code has no direct need to > know about the contents of kmi but that wasn't the main reason for doing > it that way. I prefer keeping the variables separate like they used to be. There is even less need for them to be combined in a struct than there used to be, since centralizing the their initializations ensures that they are the same for all arches. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Aug 22 12:54:57 2001 Delivered-To: freebsd-smp@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 322FC37B43F; Wed, 22 Aug 2001 12:54:41 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7MJsbd77448; Wed, 22 Aug 2001 12:54:37 -0700 (PDT) (envelope-from dillon) Date: Wed, 22 Aug 2001 12:54:37 -0700 (PDT) From: Matt Dillon Message-Id: <200108221954.f7MJsbd77448@earth.backplane.com> To: Bruce Evans Cc: Terry Lambert , Jake Burkholder , John Baldwin , , Subject: Re: Preliminary proposed rollup of kernel submap initialization code References: <20010823051540.U15063-100000@besplex.bde.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org :Make it global in an MI section and it automatically implements it in all :platforms at once (platforms that haven't been "fixed" simply don't use it). The danger of this is that down the line someone might assume in MI code that the globals are initialized when, potentially, not all platforms initialize them. This way the MI code has no access to the global data that MD code is initializing and misuse in MI code sections will result in a compile-time error. There's nothing wrong with having MI structures that can be applied to multiple platforms but which are only used by MD routines. :> One could also argue that the mainline kernel code has no direct need to :> know about the contents of kmi but that wasn't the main reason for doing :> it that way. : :I prefer keeping the variables separate like they used to be. There is :even less need for them to be combined in a struct than there used to be, :since centralizing the their initializations ensures that they are the same :for all arches. : :Bruce All the fields are related. They belong in a structure rather then as free globals or free statics. And it makes it easier for the MD code to call the MI code. My opinion, anyway. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Aug 22 13:23: 5 2001 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 226DD37B42B; Wed, 22 Aug 2001 13:22:53 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id GAA22126; Thu, 23 Aug 2001 06:22:41 +1000 Date: Thu, 23 Aug 2001 06:22:35 +1000 (EST) From: Bruce Evans X-X-Sender: To: Matt Dillon Cc: Terry Lambert , Jake Burkholder , John Baldwin , , Subject: Re: Preliminary proposed rollup of kernel submap initialization code In-Reply-To: <200108221954.f7MJsbd77448@earth.backplane.com> Message-ID: <20010823060618.M15348-100000@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 22 Aug 2001, Matt Dillon wrote: > :I prefer keeping the variables separate like they used to be. There is > :even less need for them to be combined in a struct than there used to be, > :since centralizing the their initializations ensures that they are the same > :for all arches. > > All the fields are related. They belong in a structure rather then > as free globals or free statics. And it makes it easier for the MD > code to call the MI code. My opinion, anyway. Actually, they are even less related than at first appearance. buffer_sva, buffer_eva, pager_sva and pager_eva aren't really used. They are just places for throwing away the values returned indirectly by kmem_suballoc(). clean_sva and clean_eva are used in one place in pmap.c. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Aug 22 13:39:49 2001 Delivered-To: freebsd-smp@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id B9C0B37B425; Wed, 22 Aug 2001 13:39:42 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7MKdeW78135; Wed, 22 Aug 2001 13:39:40 -0700 (PDT) (envelope-from dillon) Date: Wed, 22 Aug 2001 13:39:40 -0700 (PDT) From: Matt Dillon Message-Id: <200108222039.f7MKdeW78135@earth.backplane.com> To: Bruce Evans Cc: Terry Lambert , Jake Burkholder , John Baldwin , , Subject: Re: Preliminary proposed rollup of kernel submap initialization code References: <20010823060618.M15348-100000@besplex.bde.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org :> All the fields are related. They belong in a structure rather then :> as free globals or free statics. And it makes it easier for the MD :> code to call the MI code. My opinion, anyway. : :Actually, they are even less related than at first appearance. :buffer_sva, buffer_eva, pager_sva and pager_eva aren't really used. :They are just places for throwing away the values returned indirectly :by kmem_suballoc(). clean_sva and clean_eva are used in one place in :pmap.c. : :Bruce Look, I don't want to get into a big argument. It makes sense to keep them together because they are related, and even though our existing platforms do not appear to need them I can see that changing in the future as we add more platform ports to the system. For example, having the pager range accessible could be advantageous for platforms that take TLB faults. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Aug 22 23:19:26 2001 Delivered-To: freebsd-smp@freebsd.org Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 35C0B37B40C; Wed, 22 Aug 2001 23:19:20 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.134.55.Dial1.SanJose1.Level3.net [209.245.134.55]) by snipe.mail.pas.earthlink.net (8.11.5/8.9.3) with ESMTP id f7N6JFQ22355; Wed, 22 Aug 2001 23:19:16 -0700 (PDT) Message-ID: <3B84A08D.92864A27@mindspring.com> Date: Wed, 22 Aug 2001 23:19:57 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matt Dillon Cc: Jake Burkholder , John Baldwin , freebsd-smp@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: Preliminary proposed rollup of kernel submap initialization code References: <200108210157.f7L1vAh10384@k7.locore.ca> <200108211736.f7LHaoC64628@earth.backplane.com> <3B83623D.9DC45B93@mindspring.com> <200108221456.f7MEufD74609@earth.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Matt Dillon wrote: > I don't follow. The argument passing and pointer arithmatic is not > expensive at all - in fact, it is less expensive then the original MD > code if you look at the assembly output! And who really gives a damn > about a few nanoseconds during boot anyway? I was just thinking that, wherever possible, the reference should supply easy to understand C code that can be replaced by platform specific assembly versions, when necessary. The issue with the pointer pass is that it'll be a bit harder to code an assembly version on some platforms. I doubt we'll ever run on IBM big iron, where pointer arithmatic is nearly impossible, but you never know... > kmi is static in the MD sections because it allows the kernel to compile > for all platforms without us having to 'fix' all platforms all at once. > One could also argue that the mainline kernel code has no direct need to > know about the contents of kmi but that wasn't the main reason for doing > it that way. Uh, I complained that the declaration was _NOT_ static... that's what made the pointer reference to it so curious: it was already available as a global, so it didn't make sense why you were passing its address around, and then doing pointer math on it, instead of just referencing the elements directly. The use of descriptors in OpenSSL, particularly in the hardware acceleration code, and in the VFS (this latter could be made much simpler by sorting the VOP elements by descriptor order, and then using a direct dereference) are more expensive by far than a direct reference would be... if one were available. You can actually eliminate about 500 cycles out of the interface calls in OpenSSL by referencing the auto descriptor structure elements directly, instead of using the pointer to the descriptor substructure, to fill out the subcall specific descriptor fields, FWIW. Again, I don't expect this code to be used as often as the OpenSSL code is used (but the OpenSSL code could certainly stand fixing), but as a reference implementation it makes sense to keep it as simple as possible, while still getting the job done. Regards, -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Aug 22 23:37:28 2001 Delivered-To: freebsd-smp@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 0F20537B40A; Wed, 22 Aug 2001 23:37:22 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7N6bKs83608; Wed, 22 Aug 2001 23:37:20 -0700 (PDT) (envelope-from dillon) Date: Wed, 22 Aug 2001 23:37:20 -0700 (PDT) From: Matt Dillon Message-Id: <200108230637.f7N6bKs83608@earth.backplane.com> To: Terry Lambert Cc: Jake Burkholder , John Baldwin , freebsd-smp@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: Preliminary proposed rollup of kernel submap initialization code References: <200108210157.f7L1vAh10384@k7.locore.ca> <200108211736.f7LHaoC64628@earth.backplane.com> <3B83623D.9DC45B93@mindspring.com> <200108221456.f7MEufD74609@earth.backplane.com> <3B84A08D.92864A27@mindspring.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org : :Matt Dillon wrote: :> I don't follow. The argument passing and pointer arithmatic is not :> expensive at all - in fact, it is less expensive then the original MD :> code if you look at the assembly output! And who really gives a damn :> about a few nanoseconds during boot anyway? : :I was just thinking that, wherever possible, the reference should :supply easy to understand C code that can be replaced by platform :specific assembly versions, when necessary. The issue with the :pointer pass is that it'll be a bit harder to code an assembly :.. You lost me. This is one-time single-execution code. Unless you are planning on rewriting the entire FreeBSD OS in assembly there is no issue. :Uh, I complained that the declaration was _NOT_ static... that's :what made the pointer reference to it so curious: it was already :available as a global, so it didn't make sense why you were passing :its address around, and then doing pointer math on it, instead of :just referencing the elements directly. This isn't designed for general use. It's because there are two different source files in i386/i386 (blah/blah) that access the structure. Otherwise I would have happily made it static. I'm sure the extern is in the wrong place, but I believe Bruce is planning on fixing that. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Aug 22 23:38:53 2001 Delivered-To: freebsd-smp@freebsd.org Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 1791E37B40C; Wed, 22 Aug 2001 23:38:48 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.134.55.Dial1.SanJose1.Level3.net [209.245.134.55]) by falcon.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id XAA15482; Wed, 22 Aug 2001 23:38:40 -0700 (PDT) Message-ID: <3B84A51A.3BC5689F@mindspring.com> Date: Wed, 22 Aug 2001 23:39:22 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matt Dillon Cc: Bruce Evans , Jake Burkholder , John Baldwin , freebsd-smp@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: Preliminary proposed rollup of kernel submap initialization code References: <20010823060618.M15348-100000@besplex.bde.org> <200108222039.f7MKdeW78135@earth.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Matt Dillon wrote: > Look, I don't want to get into a big argument. It makes sense to > keep them together because they are related, and even though our > existing platforms do not appear to need them I can see that changing > in the future as we add more platform ports to the system. For example, > having the pager range accessible could be advantageous for platforms > that take TLB faults. For a MIPS or other processors where TLBs are done in software, using the pointer could get vastly more expensive than a global reference, if you had to look in there for every shootdown, and an LRU shootdown of at least one entry happened on nearly every context switch. As for keeping them together, I understand the desire to have them around for doing automatic limits calculations, but if that's going to happen, it should be that they are required to be initialized past a certain point on all platforms, or they are MD, and don't belong in an MI structure. I agree that they are related -- just that they are related by machine dependencies on a platform which isn't supported yet (I don't think we need to worry about Chris D. switching the Sibytes card away from NetBSD any time soon, for example 8-)). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Aug 22 23:53: 8 2001 Delivered-To: freebsd-smp@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 8E03E37B412; Wed, 22 Aug 2001 23:53:02 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7N6r0E83692; Wed, 22 Aug 2001 23:53:00 -0700 (PDT) (envelope-from dillon) Date: Wed, 22 Aug 2001 23:53:00 -0700 (PDT) From: Matt Dillon Message-Id: <200108230653.f7N6r0E83692@earth.backplane.com> To: Terry Lambert Cc: Bruce Evans , Jake Burkholder , John Baldwin , freebsd-smp@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: Preliminary proposed rollup of kernel submap initialization code References: <20010823060618.M15348-100000@besplex.bde.org> <200108222039.f7MKdeW78135@earth.backplane.com> <3B84A51A.3BC5689F@mindspring.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org : :Matt Dillon wrote: :> Look, I don't want to get into a big argument. It makes sense to :> keep them together because they are related, and even though our :> existing platforms do not appear to need them I can see that changing :> in the future as we add more platform ports to the system. For example, :> having the pager range accessible could be advantageous for platforms :> that take TLB faults. : :For a MIPS or other processors where TLBs are done in software, :using the pointer could get vastly more expensive than a global :reference, if you had to look in there for every shootdown, and :an LRU shootdown of at least one entry happened on nearly every :context switch. For the machine dependant code it IS a global reference, not that I think it matters much. Sure, on an R3000 with its 9-instruction TLB fault handler you might care, but on the later MIPS cpus with better hardware support for TLB miss handling? Not a big deal if the initial hash lookup fails. :that's going to happen, it should be that they are required to :be initialized past a certain point on all platforms, or they :are MD, and don't belong in an MI structure. Read the code. The MI portion of the system is making the information available to the MD portion of the system. There is no requirement or necessity that the MD portion of the system use all the available info, and no detriment either. And it makes no sense whatsoever to define the structure in MD code where it would have to be duplicated multiple times (some potentially with alterations if you are also trying to 'optimize' it), when defining it once as an MI structure makes the whole result easier to follow, understand, and document. I really don't give a damn if it eats 16 more bytes of bss for certain platforms. In short, the code is fine, and you complainer's need to take a bit more time to actually *read* it and think the problem through before making comments. In fact, so far, the only person who has taken the time to look at the code thoughly has been Bruce! -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Aug 23 2:42: 7 2001 Delivered-To: freebsd-smp@freebsd.org Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id B37B737B409; Thu, 23 Aug 2001 02:42:01 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.134.55.Dial1.SanJose1.Level3.net [209.245.134.55]) by snipe.mail.pas.earthlink.net (8.11.5/8.9.3) with ESMTP id f7N9fuQ18146; Thu, 23 Aug 2001 02:41:56 -0700 (PDT) Message-ID: <3B84D00C.AA0DDB5C@mindspring.com> Date: Thu, 23 Aug 2001 02:42:36 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matt Dillon Cc: Jake Burkholder , John Baldwin , freebsd-smp@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: Preliminary proposed rollup of kernel submap initialization code References: <200108210157.f7L1vAh10384@k7.locore.ca> <200108211736.f7LHaoC64628@earth.backplane.com> <3B83623D.9DC45B93@mindspring.com> <200108221456.f7MEufD74609@earth.backplane.com> <3B84A08D.92864A27@mindspring.com> <200108230637.f7N6bKs83608@earth.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Matt Dillon wrote: > :> I don't follow. The argument passing and pointer arithmatic is not > :> expensive at all - in fact, it is less expensive then the original MD > :> code if you look at the assembly output! And who really gives a damn > :> about a few nanoseconds during boot anyway? > : > :I was just thinking that, wherever possible, the reference should > :supply easy to understand C code that can be replaced by platform > :specific assembly versions, when necessary. The issue with the > :pointer pass is that it'll be a bit harder to code an assembly > :.. > > You lost me. This is one-time single-execution code. Unless you > are planning on rewriting the entire FreeBSD OS in assembly there > is no issue. It's a porting issue. There are several really nice things about the current FreeBSD when it comes to porting: 1) It can boot over the network, so you only need to get the network devices supported to get to single user mode. 2) It has devfs, which means that you can host the boot on a different machine if, like some machines, the machine is incapable of netbooting correctly from FreeBSD for some reason (without devfs, FreeBSD's use of additional bits in major/minor device numbers made it impossible to run over NFS or hosted on systems that didn't support creating device nodes on their local FS's with that many bots for the remote FreeBSD to use). 3) It's mostly not as arcane as a lot of systems (it has its strange moments during boot, though, particularly when bootstrapping the VM system and the console). Adding a fourth: 4) There are straight forward C equivalents for everything except what you _absolutely must_ do in assembly. Would be a terrifically nifty feature... Even if you're not interested in adding it, making it less straight forward to get to single user mode, even with C level performance suckage, is bad for getting new ports done. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Aug 23 11:33: 3 2001 Delivered-To: freebsd-smp@freebsd.org Received: from cod.progroup.com (cod.progroup.com [207.44.190.233]) by hub.freebsd.org (Postfix) with ESMTP id 32C7C37B414 for ; Thu, 23 Aug 2001 11:32:56 -0700 (PDT) (envelope-from craig@progroup.com) Received: from progroup.com (guppy.progroup.com [207.44.190.237]) by cod.progroup.com (8.9.2/8.9.2) with ESMTP id LAA16732; Thu, 23 Aug 2001 11:32:55 -0700 (PDT) (envelope-from craig@progroup.com) Message-ID: <3B855D1C.E2EDD580@progroup.com> Date: Thu, 23 Aug 2001 12:44:28 -0700 From: Craig Shaver Organization: Productivity Group, Inc. X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-smp@FreeBSD.ORG Subject: Re: unsubscribe freebsd-smp References: <20010823182718.D67F837B401@hub.freebsd.org> <3B855CAA.92196E4A@progroup.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org unsubscribe freebsd-hardware To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message