From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 12 04:19:52 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF8CD16A4C1 for ; Sun, 12 Oct 2003 04:19:52 -0700 (PDT) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08A9243FB1 for ; Sun, 12 Oct 2003 04:19:51 -0700 (PDT) (envelope-from des@des.no) Received: from smtp.des.no (37.80-203-228.nextgentel.com [80.203.228.37]) by mail.broadpark.no (Postfix) with ESMTP id 78E0F790D8; Sun, 12 Oct 2003 13:19:49 +0200 (MEST) Received: by smtp.des.no (Pony Express, from userid 666) id 14B329C2BF; Sun, 12 Oct 2003 13:19:49 +0200 (CEST) Received: from dwp.des.no (dwp.des.no [10.0.0.4]) by smtp.des.no (Pony Express) with ESMTP id 0026B9C0B9; Sun, 12 Oct 2003 13:19:44 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id CBDEFB825; Sun, 12 Oct 2003 13:19:44 +0200 (CEST) To: ticso@cicely.de References: <200310101417.h9AEHb4n025071@www.kukulies.org> <20031011050618.GB61302@freebsd1.cimlogic.com.au> <20031011222942.GM13791@cicely12.cicely.de> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Sun, 12 Oct 2003 13:19:44 +0200 In-Reply-To: <20031011222942.GM13791@cicely12.cicely.de> (Bernd Walter's message of "Sun, 12 Oct 2003 00:29:43 +0200") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on dsa.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 cc: "C. Kukulies" cc: hackers@freebsd.org Subject: Re: smallest piece of hardware that runs *BSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2003 11:19:53 -0000 Bernd Walter writes: > On Sat, Oct 11, 2003 at 03:06:18PM +1000, John Birrell wrote: > > Here's one the size of a credit card: . > > It's a lot bigger than a 'bump in a cable', but it runs FreeBSD. > Leaves the question how much of the data on that page is correct. > The elan chip is 486 class as we all know from soekris systems. >From www.amd.com: The =C9lan[tm] SC520 microcontroller combines a 32-bit, low-voltage Am5x86 CPU with a complete set of integrated peripherals suitable for both real-time and PC/AT-compatible embedded applications. The device also features a 32-bit PCI bus, a high-performance, 32-bit SDRAM interface and a full-featured, high-performance in-circuit emulation capability, known as the AMDebug[tm] technology. so it's not incorrect, though they might get in trouble with Intel over the use of the Pentium trademark in promotional material for a product based on an AMD microcontroller. Regarding the "computer in an ethernet jack" devices mentioned elsewhere in this thread: good luck trying to run FreeBSD on a 16-bit microcontroller with no MMU or FPU, 256 kB SRAM and 512 kB DRAM... DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 12 04:49:59 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E35C016A4B3 for ; Sun, 12 Oct 2003 04:49:59 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FD3943F93 for ; Sun, 12 Oct 2003 04:49:58 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) h9CBnct2057509 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 12 Oct 2003 13:49:40 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id h9CBnaS8088074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Oct 2003 13:49:36 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.10/8.12.10) with ESMTP id h9CBnZ2u056928; Sun, 12 Oct 2003 13:49:35 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.10/8.12.10/Submit) id h9CBnZA6056927; Sun, 12 Oct 2003 13:49:35 +0200 (CEST) (envelope-from ticso) Date: Sun, 12 Oct 2003 13:49:35 +0200 From: Bernd Walter To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20031012114934.GN13791@cicely12.cicely.de> References: <200310101417.h9AEHb4n025071@www.kukulies.org> <20031011050618.GB61302@freebsd1.cimlogic.com.au> <20031011222942.GM13791@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD cicely12.cicely.de 5.1-CURRENT alpha User-Agent: Mutt/1.5.4i cc: "C. Kukulies" cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: smallest piece of hardware that runs *BSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2003 11:50:00 -0000 On Sun, Oct 12, 2003 at 01:19:44PM +0200, Dag-Erling Smørgrav wrote: > Bernd Walter writes: > > On Sat, Oct 11, 2003 at 03:06:18PM +1000, John Birrell wrote: > > > Here's one the size of a credit card: . > > > It's a lot bigger than a 'bump in a cable', but it runs FreeBSD. > > Leaves the question how much of the data on that page is correct. > > The elan chip is 486 class as we all know from soekris systems. > > From www.amd.com: > > The Élan[tm] SC520 microcontroller combines a 32-bit, low-voltage > Am5x86 CPU with a complete set of integrated peripherals suitable > for both real-time and PC/AT-compatible embedded applications. The > device also features a 32-bit PCI bus, a high-performance, 32-bit > SDRAM interface and a full-featured, high-performance in-circuit > emulation capability, known as the AMDebug[tm] technology. Am5x86 != 586 class. This is what FreeBSD thinks about the SC520: CPU: AMD Enhanced Am486DX4/Am5x86 Write-Back (486-class CPU) Origin = "AuthenticAMD" Id = 0x494 Stepping = 4 Features=0x1 -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 12 05:01:53 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E58C16A4B3 for ; Sun, 12 Oct 2003 05:01:53 -0700 (PDT) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CDD643FAF for ; Sun, 12 Oct 2003 05:01:52 -0700 (PDT) (envelope-from des@des.no) Received: from smtp.des.no (37.80-203-228.nextgentel.com [80.203.228.37]) by mail.broadpark.no (Postfix) with ESMTP id BF742785A1 for ; Sun, 12 Oct 2003 14:01:51 +0200 (MEST) Received: by smtp.des.no (Pony Express, from userid 666) id 8BDB69C2BF; Sun, 12 Oct 2003 14:01:51 +0200 (CEST) Received: from dwp.des.no (dwp.des.no [10.0.0.4]) by smtp.des.no (Pony Express) with ESMTP id CFB299C0B9 for ; Sun, 12 Oct 2003 14:01:47 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id C8ED1B823; Sun, 12 Oct 2003 14:01:47 +0200 (CEST) To: hackers@freebsd.org From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Sun, 12 Oct 2003 14:01:47 +0200 Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on dsa.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: real vs. avail memory X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2003 12:01:53 -0000 I've gotten used to the fact that there is a small discrepancy between real and available memory, but I was surprised to see the following in dmesg on a new P4 system: real memory =3D 1073676288 (1023 MB) avail memory =3D 1037799424 (989 MB) That's a full 40 MB difference... where does that memory go? is it used for page maps or something like that? DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 12 07:10:00 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D11316A4B3 for ; Sun, 12 Oct 2003 07:10:00 -0700 (PDT) Received: from wonkity.com (wonkity.com [65.173.111.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4411C43FA3 for ; Sun, 12 Oct 2003 07:09:59 -0700 (PDT) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.12.9/8.12.9) with ESMTP id h9CE9tYM031891; Sun, 12 Oct 2003 08:09:55 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.12.9/8.12.9/Submit) with ESMTP id h9CE9sDN031888; Sun, 12 Oct 2003 08:09:55 -0600 (MDT) Date: Sun, 12 Oct 2003 08:09:54 -0600 (MDT) From: Warren Block To: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= In-Reply-To: Message-ID: <20031012080314.E31832@wonkity.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: hackers@freebsd.org Subject: Re: real vs. avail memory X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2003 14:10:00 -0000 On Sun, 12 Oct 2003, Dag-Erling [iso-8859-1] Sm=F8rgrav wrote: > dmesg on a new P4 system: > > real memory =3D 1073676288 (1023 MB) > avail memory =3D 1037799424 (989 MB) > > That's a full 40 MB difference... where does that memory go? is it > used for page maps or something like that? 34M, as I figure it. Is this an Intel motherboard, or other motherboard with integrated video adapter? That could be "shared" memory used for the video. -Warren Block * Rapid City, South Dakota USA From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 12 08:27:41 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECC5416A4BF for ; Sun, 12 Oct 2003 08:27:41 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id D460A43FBD for ; Sun, 12 Oct 2003 08:27:40 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9p2/8.12.9) with ESMTP id h9CFRUE7033920; Sun, 12 Oct 2003 09:27:30 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 12 Oct 2003 09:26:08 -0600 (MDT) Message-Id: <20031012.092608.31505263.imp@bsdimp.com> To: des@des.no From: "M. Warner Losh" In-Reply-To: References: <20031011050618.GB61302@freebsd1.cimlogic.com.au> <20031011222942.GM13791@cicely12.cicely.de> X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: kuku@www.kukulies.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: smallest piece of hardware that runs *BSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2003 15:27:42 -0000 In message: des@des.no (Dag-Erling Sm=F8rgrav) writes: : Bernd Walter writes: : > On Sat, Oct 11, 2003 at 03:06:18PM +1000, John Birrell wrote: : > > Here's one the size of a credit card: . : > > It's a lot bigger than a 'bump in a cable', but it runs FreeBSD. : > Leaves the question how much of the data on that page is correct. : > The elan chip is 486 class as we all know from soekris systems. : = : >From www.amd.com: : = : The =C9lan[tm] SC520 microcontroller combines a 32-bit, low-voltage= : Am5x86 CPU with a complete set of integrated peripherals suitable : for both real-time and PC/AT-compatible embedded applications. The : device also features a 32-bit PCI bus, a high-performance, 32-bit : SDRAM interface and a full-featured, high-performance in-circuit : emulation capability, known as the AMDebug[tm] technology. : = : so it's not incorrect, though they might get in trouble with Intel : over the use of the Pentium trademark in promotional material for a : product based on an AMD microcontroller. I'm not sure what you are saying here. However the Am5x86 core is a 486 class machine... Warner From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 12 08:50:35 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4573316A4B3 for ; Sun, 12 Oct 2003 08:50:35 -0700 (PDT) Received: from tx0.oucs.ox.ac.uk (tx0.oucs.ox.ac.uk [129.67.1.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9FFF43F85 for ; Sun, 12 Oct 2003 08:50:33 -0700 (PDT) (envelope-from colin.percival@wadham.ox.ac.uk) Received: from scan0.oucs.ox.ac.uk ([129.67.1.162] helo=localhost) by tx0.oucs.ox.ac.uk with esmtp (Exim 4.20) id 1A8iUK-0005od-Fz for hackers@freebsd.org; Sun, 12 Oct 2003 16:50:32 +0100 Received: from rx0.oucs.ox.ac.uk ([129.67.1.161]) by localhost (scan0.oucs.ox.ac.uk [129.67.1.162]) (amavisd-new, port 25) with ESMTP id 22074-07 for ; Sun, 12 Oct 2003 16:50:32 +0100 (BST) Received: from gateway.wadham.ox.ac.uk ([163.1.161.253]) by rx0.oucs.ox.ac.uk with smtp (Exim 4.20) id 1A8iUK-0005oa-2f for hackers@freebsd.org; Sun, 12 Oct 2003 16:50:32 +0100 Received: (qmail 24485 invoked by uid 0); 12 Oct 2003 15:50:32 -0000 Received: from colin.percival@wadham.ox.ac.uk by gateway by uid 71 with qmail-scanner-1.16 (sweep: 2.14/3.71. spamassassin: 2.53. Clear:. Processed in 2.835386 secs); 12 Oct 2003 15:50:32 -0000 X-Qmail-Scanner-Mail-From: colin.percival@wadham.ox.ac.uk via gateway X-Qmail-Scanner: 1.16 (Clear:. Processed in 2.835386 secs) Received: from dhcp1131.wadham.ox.ac.uk (HELO piii600.wadham.ox.ac.uk) (163.1.161.131) by gateway.wadham.ox.ac.uk with SMTP; 12 Oct 2003 15:50:28 -0000 Message-Id: <5.0.2.1.1.20031012164431.031a4f90@popserver.sfu.ca> X-Sender: cperciva@popserver.sfu.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 12 Oct 2003 16:50:26 +0100 To: hackers@freebsd.org From: Colin Percival Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: md5(1) exit code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2003 15:50:35 -0000 Or rather, lack thereof. I was rather astonished to find that `md5 /nonexistant` printed an error message but still returned an exit code of zero; this is, of course, due to the use of warn() instead of err() in response to a receiving a NULL pointer returned from MD5File(3). Is there any reason for this behaviour? Colin Percival From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 12 09:17:20 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CC8C16A4B3; Sun, 12 Oct 2003 09:17:20 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2582343FBD; Sun, 12 Oct 2003 09:17:18 -0700 (PDT) (envelope-from se@freebsd.org) Received: from [212.227.126.206] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1A8iuD-0000BS-00; Sun, 12 Oct 2003 18:17:17 +0200 Received: from [80.132.234.134] (helo=Gatekeeper.FreeBSD.org) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1A8iuC-0003Fv-00; Sun, 12 Oct 2003 18:17:16 +0200 Received: from StefanEsser.FreeBSD.org (StefanEsser [10.0.0.1]) by Gatekeeper.FreeBSD.org (Postfix) with ESMTP id 4D1D35F18; Sun, 12 Oct 2003 18:17:14 +0200 (CEST) Received: by StefanEsser.FreeBSD.org (Postfix, from userid 200) id 908601E41; Sun, 12 Oct 2003 18:17:13 +0200 (CEST) Date: Sun, 12 Oct 2003 18:17:11 +0200 From: Stefan =?iso-8859-1?Q?E=DFer?= To: Colin Percival Message-ID: <20031012161711.GA20748@StefanEsser.FreeBSD.org> Mail-Followup-To: Stefan =?iso-8859-1?Q?E=DFer?= , Colin Percival , hackers@freebsd.org References: <5.0.2.1.1.20031012164431.031a4f90@popserver.sfu.ca> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: <5.0.2.1.1.20031012164431.031a4f90@popserver.sfu.ca> User-Agent: Mutt/1.5.4i X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: hackers@freebsd.org Subject: Re: md5(1) exit code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2003 16:17:20 -0000 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On 2003-10-12 16:50 +0100, Colin Percival wrote: > Or rather, lack thereof. I was rather astonished to find that `md5 > /nonexistant` printed an error message but still returned an exit code of > zero; this is, of course, due to the use of warn() instead of err() in > response to a receiving a NULL pointer returned from MD5File(3). > Is there any reason for this behaviour? Don't think so, and I fixed it many years ago (much earlier than the dates in the diff seem to indicate) on my system. Patch attached ... Regards, STefan PS: Guess I should just commit this change to -current ... Index: md5.1 =================================================================== RCS file: /usr/cvs/src/sbin/md5/md5.1,v retrieving revision 1.18 diff -u -r1.18 md5.1 --- md5.1 19 Apr 2002 23:05:25 -0000 1.18 +++ md5.1 21 Jun 2002 12:53:47 -0000 @@ -67,6 +67,10 @@ .It Fl x Run a built-in test script. .El +.Sh DIAGNOSTICS +The +.Nm +program exits 0 on success, and 1 if at least one of the input files could not be read. .Sh SEE ALSO .Xr cksum 1 .Rs Index: md5.c =================================================================== RCS file: /usr/cvs/src/sbin/md5/md5.c,v retrieving revision 1.30 diff -u -r1.30 md5.c --- md5.c 3 May 2003 18:41:58 -0000 1.30 +++ md5.c 4 May 2003 13:11:55 -0000 @@ -62,7 +62,9 @@ int ch; char *p; char buf[33]; + int failed; + failed = 0; while ((ch = getopt(argc, argv, "pqrs:tx")) != -1) switch (ch) { case 'p': @@ -93,19 +95,24 @@ if (*argv) { do { p = MD5File(*argv, buf); - if (!p) + if (!p) { warn("%s", *argv); - else + failed++; + } else { if (qflag) printf("%s\n", p); else if (rflag) printf("%s %s\n", p, *argv); else printf("MD5 (%s) = %s\n", *argv, p); + } } while (*++argv); } else if (!sflag && (optind == 1 || qflag || rflag)) MDFilter(0); + if (failed != 0) + return (1); + return (0); } /* --UlVJffcvxoiEqYs2-- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 12 11:58:05 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5ADB516A4B3 for ; Sun, 12 Oct 2003 11:58:05 -0700 (PDT) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FB1943F3F for ; Sun, 12 Oct 2003 11:58:04 -0700 (PDT) (envelope-from andrei@andruxa.sytes.net) Received: from h-68-164-30-157.snvacaid.dynamic.covad.net ([68.164.30.157] helo=andruxa.sytes.net) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1A8lPn-0001g2-00 for freebsd-hackers@freebsd.org; Sun, 12 Oct 2003 11:58:03 -0700 Received: from andruxa.sytes.net (localhost [127.0.0.1]) by andruxa.sytes.net (8.12.9p2/8.12.9) with ESMTP id h9CIvXRl000631 for ; Sun, 12 Oct 2003 11:57:33 -0700 (PDT) (envelope-from andrei@andruxa.sytes.net) Received: (from andrei@localhost) by andruxa.sytes.net (8.12.9p2/8.12.9/Submit) id h9CIvSq3000630 for freebsd-hackers@freebsd.org; Sun, 12 Oct 2003 11:57:28 -0700 (PDT) (envelope-from andrei) Date: Sun, 12 Oct 2003 11:57:27 -0700 From: Andrew Konstantinov To: freebsd-hackers@freebsd.org Message-ID: <20031012185727.GA595@andruxa.sytes.net> Mail-Followup-To: Andrew Konstantinov , freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: return-rst does not work for ipv6 in ipfilter X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2003 18:58:05 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi guys, The 'return-rst' option in ipfilter does not work for ipv6. I sent a problem report and just in case decided to send this patch here too. That option saves a lot of headache and it would be very nice to have it work properly. The patch was originally written by Peter Postma. I edited it a little so it can be applied without problems. I am not really a code guru, so if someone could review this patch, it would be great! Thanks in advance, Andrew Konstantinov --- ip_fil.c.orig Fri Dec 6 12:45:45 2002 +++ ip_fil.c Tue Mar 25 17:05:09 2003 @@ -1937,24 +1937,24 @@ struct route_in6 ip6route; struct sockaddr_in6 *dst6; struct route_in6 *ro; - struct ifnet *ifp; + struct ifnet *ifp = (fdp != NULL) ? fdp->fd_ifp : fin->fin_ifp; frentry_t *fr; #if defined(OpenBSD) && (OpenBSD >= 200211) struct route_in6 *ro_pmtu = NULL; struct in6_addr finaldst; - ip6_t *ip6; #endif + ip6_t *ip6; u_long mtu; int error; - ifp = NULL; ro = &ip6route; + ip6 = mtod(m0, struct ip6_t *); fr = fin->fin_fr; bzero((caddr_t)ro, sizeof(*ro)); dst6 = (struct sockaddr_in6 *)&ro->ro_dst; dst6->sin6_family = AF_INET6; dst6->sin6_len = sizeof(struct sockaddr_in6); - dst6->sin6_addr = fin->fin_fi.fi_src.in6; + dst6->sin6_addr = ip6->ip6_dst; if (fdp != NULL) ifp = fdp->fd_ifp; --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/iaQXttaE8kbpwrARApY+AJ9thsk67bVwakC0WLR2uQ1wk54V+wCeJDEb AwyoPZ9ZMISRatyfX1lW9K8= =VRTA -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 12 12:05:19 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8587916A4B3 for ; Sun, 12 Oct 2003 12:05:19 -0700 (PDT) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7228C43FD7 for ; Sun, 12 Oct 2003 12:05:15 -0700 (PDT) (envelope-from des@des.no) Received: from smtp.des.no (37.80-203-228.nextgentel.com [80.203.228.37]) by mail.broadpark.no (Postfix) with ESMTP id 16FD57968B; Sun, 12 Oct 2003 21:04:37 +0200 (MEST) Received: by smtp.des.no (Pony Express, from userid 666) id B5C019B531; Sun, 12 Oct 2003 21:04:36 +0200 (CEST) Received: from dwp.des.no (dwp.des.no [10.0.0.4]) by smtp.des.no (Pony Express) with ESMTP id 913EC95F46; Sun, 12 Oct 2003 21:04:32 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 77BC3B823; Sun, 12 Oct 2003 21:04:32 +0200 (CEST) To: Warren Block References: <20031012080314.E31832@wonkity.com> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Sun, 12 Oct 2003 21:04:32 +0200 In-Reply-To: <20031012080314.E31832@wonkity.com> (Warren Block's message of "Sun, 12 Oct 2003 08:09:54 -0600 (MDT)") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on dsa.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 cc: hackers@freebsd.org Subject: Re: real vs. avail memory X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2003 19:05:19 -0000 Warren Block writes: > On Sun, 12 Oct 2003, Dag-Erling [iso-8859-1] Sm=F8rgrav wrote: > > That's a full 40 MB difference... where does that memory go? is it > > used for page maps or something like that? > 34M, as I figure it. Is this an Intel motherboard, or other motherboard > with integrated video adapter? That could be "shared" memory used for > the video. It is a Gigabyte motherboard with an Intel ICH4 chipset, but it has no onboard video. I have an ATI Radeon 7500 with 128 MB in the AGP slot. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 12 12:58:03 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACF1D16A4B3 for ; Sun, 12 Oct 2003 12:58:03 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AF4143F3F for ; Sun, 12 Oct 2003 12:58:01 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 6F4406542A; Sun, 12 Oct 2003 20:58:00 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07496-01-2; Sun, 12 Oct 2003 20:57:59 +0100 (BST) Received: from saboteur.dek.spc.org (82-147-18-81.dsl.uk.rapidplay.com [82.147.18.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id E9B0A653AC; Sun, 12 Oct 2003 20:57:53 +0100 (BST) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 1C9DE55; Sun, 12 Oct 2003 20:57:52 +0100 (BST) Date: Sun, 12 Oct 2003 20:57:52 +0100 From: Bruce M Simpson To: Peter Jeremy , Andrew Gallatin , freebsd-hackers@freebsd.org Message-ID: <20031012195752.GE2996@saboteur.dek.spc.org> Mail-Followup-To: Peter Jeremy , Andrew Gallatin , freebsd-hackers@freebsd.org References: <20031010103640.6F5A216A4BF@hub.freebsd.org> <20031010134400.GE803@saboteur.dek.spc.org> <16263.1019.939450.708832@grasshopper.cs.duke.edu> <20031011035827.GD75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> <20031011082711.GB679@saboteur.dek.spc.org> <20031011101231.GH75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> <20031011140651.GA1739@saboteur.dek.spc.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: <20031011140651.GA1739@saboteur.dek.spc.org> Subject: Re: Determining CPU features / cache organization from userland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2003 19:58:03 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline All, I came up with the attached text file today to summarize some of my findings, after looking at various open source trees to see how they handle run-time cache geometry detection. Many will find it ironic that i386 is the easiest platform to deal with. [ Andrew: Perhaps you can shed some light on how the necessary information can be gathered on Alpha? My search was incomplete and I could not find a reliable source for DEC's development manuals. ] Jeff Roberson suggested I adopt NetBSD's API, however, on further examination it's clear that NetBSD's approach isn't consistent across all platforms. Darwin takes a similar approach, but it is perhaps too PowerPC-centric. sysctl is a good interface for retrieving this information as it doesn't change during the lifetime of the kernel, and it is small. sysctl is already invoked from within libc to retrieve information in this way. glibc's approach to dealing with situations where knowledge of the cache line size is needed is a bit fractious - it retrieves the information from an 'aux vector' passed to glibc at startup. I think threading libraries should seriously consider becoming consumers of the API once it's finalized. Mutex alignment on cache line boundaries is desirable for userland applications too. However, phk malloc would need to be changed in order to support this specific form of aligned allocation. Perhaps a separate pool or zone could be used for this kind of allocation? This becomes more important and timely when one considers the I/O alignment restrictions we've encountered. Some applications may need to align their buffers on arbitrary boundaries to suit devices, too. BMS --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="cacheplan.txt" all --- NetBSD cache information API(s) are not consistent across platforms. alpha ----- Cache discovery? Static. 21064, 21064A, 21066, 21066A, 21164 all have line sizes of 32-bytes. The 21264 has a 64-byte line size. 21364: L1 split, 64KB each, 2-way set-associative, Virtual caches can be implemented using PALcode, but this is probably more of a curiosity than anything else. ia64 ---- Cache discovery? Call PAL_CACHE_INFO, I think. No documentation on how to do this at this time. I have emailed marcel@freebsd.org asking for advice. i386 pc98 amd64 --------------- Cache discovery? CPUID. Earlier chips which don't support it probably don't have a cache, or aren't worth supporting. General rule for x86: split L1, unified L2, optional unified L3. General rule for Intel P5: 2-way, 32 bytes/line General rule for Intel MMX and up: 4-way, 32 bytes/line PPro doesn't have L3. The newer cores have different cache geometry. powerpc ------- Cache line discovery? Static. Many core variants. I have not seen any runtime code for this. The POWER clcs instruction is obsolete. OpenDarwin assumes 32-bytes. It has hooks for discovering the cache geometry at runtime but these are not used. NetBSD statically initializes this information according to the discovered CPU model in use, which is the way to go. NetBSD tells uvm to recolor the page queues if required. Linux uses static #define's from IBM people, except in the case of ppc64, which is strikingly similar to the OpenDarwin code except it actually talks to the open firmware. Open Firmware on CHRP should however provide the following for each cpu device node configured in the system: i-cache-size i-cache-sets i-cache-block-size d-cache-size d-cache-sets d-cache-block-size tlb-size tlb-sets l2-cache All are integers except for l2-cache which is the address of an l2-cache device node if the system found one. mips ---- The NetBSD MIPS code for dealing with cache geometry was recently updated. MIPS caches may be split/unified at L1/L2 and unified at L3. Cache detection code is quite voluminous. Swipe NetBSD's if FreeBSD/mips ever kicks off. Many, many core variants. sparc64 ------- Cache line discovery? Performed by Open Firmware. Open Firmware property names used are ever so slightly different from Apple's. icache-size icache-line-size icache-associativity dcache-size dcache-line-size dcache-associativity ecache-size ecache-line-size ecache-associativity Already handled within cache.c, but assembly stubs *expect* this information in a certain format. Specifically they need to see the data cache/instruction cache sizes and line sizes. General rule: Split L1, Unified L2. Cores: Spitfire/Blackbird/Cheetah --gBBFr7Ir9EOA20Yy-- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 13 00:07:26 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FD9B16A4BF for ; Mon, 13 Oct 2003 00:07:26 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F7B143FAF for ; Mon, 13 Oct 2003 00:07:24 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h9D76f311546; Mon, 13 Oct 2003 09:06:41 +0200 (MEST) Date: Mon, 13 Oct 2003 09:06:41 +0200 (CEST) From: Harti Brandt To: Tim Kientzle In-Reply-To: <3F8663AA.4010707@acm.org> Message-ID: <20031013090323.P45269@beagle.fokus.fraunhofer.de> References: <20031009194644.50B9116A4BF@hub.freebsd.org> <20031010091003.Q95881@beagle.fokus.fraunhofer.de> <3F8663AA.4010707@acm.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2003 07:07:26 -0000 On Fri, 10 Oct 2003, Tim Kientzle wrote: TK>Harti Brandt wrote: TK>> Yes. When I read the C standard TK>> foo = data & mask; TK>> wouldn't also help, because there is no sequence point in this statement TK>> except at the ;. TK> TK>Before anyone takes this particular line of reasoning seriously, TK>I feel compelled to point out that sequence points have nothing to TK>do with this. TK> TK>a) Sequence points are an "as if" requirement. The TK> program must produce the same results "as if" it TK> strictly obeyed sequence points. It doesn't have TK> to really operate that way. (And, in fact, well-optimized TK> programs running on modern processors rarely do.) And that means, that at the semicolon the value of foo should be "as if" the compiler really compiled the expression as written. This does not mean, that he has to and this does mean, that while executing this expression "foo" can have any value. TK>b) Sequence points say NOTHING about how multiple TK> threads or processors interact. TK> TK>Sorry, but the C standard doesn't help here. The TK>C standard does not address multi-threading at all. But it addresses signal handling which suffers from the same problem of atomic access to variables. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 13 02:47:34 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EE1316A4B3 for ; Mon, 13 Oct 2003 02:47:34 -0700 (PDT) Received: from c211-28-27-130.belrs2.nsw.optusnet.com.au (c211-28-27-130.belrs2.nsw.optusnet.com.au [211.28.27.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81CEB43FB1 for ; Mon, 13 Oct 2003 02:47:32 -0700 (PDT) (envelope-from peterjeremy@optushome.com.au) Received: from server.c211-28-27-130.belrs2.nsw.optusnet.com.au (localhost.c211-28-27-130.belrs2.nsw.optusnet.com.au [127.0.0.1]) ESMTP id h9D9lHdb076321; Mon, 13 Oct 2003 19:47:17 +1000 (EST) peter@server.c211-28-27-130.belrs2.nsw.optusnet.com.au) Received: (from peter@localhost) (8.12.9p1/8.12.9/Submit) id h9D9lG1U076320; Mon, 13 Oct 2003 19:47:16 +1000 (EST) (envelope-from peter) Date: Mon, 13 Oct 2003 19:47:16 +1000 From: Peter Jeremy To: Andrew Gallatin , freebsd-hackers@freebsd.org Message-ID: <20031013094715.GA75662@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> References: <20031010103640.6F5A216A4BF@hub.freebsd.org> <20031010134400.GE803@saboteur.dek.spc.org> <16263.1019.939450.708832@grasshopper.cs.duke.edu> <20031011035827.GD75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> <20031011082711.GB679@saboteur.dek.spc.org> <20031011101231.GH75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> <20031011140651.GA1739@saboteur.dek.spc.org> <20031012195752.GE2996@saboteur.dek.spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031012195752.GE2996@saboteur.dek.spc.org> User-Agent: Mutt/1.4.1i Subject: Re: Determining CPU features / cache organization from userland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2003 09:47:34 -0000 On Sun, Oct 12, 2003 at 08:57:52PM +0100, Bruce M Simpson wrote: >[ Andrew: Perhaps you can shed some light on how the necessary information >can be gathered on Alpha? My search was incomplete and I could not find >a reliable source for DEC's development manuals. ] L1 cache information is in the CPU datasheets. I don't know of a summary across the whole Alpha family. The datasheets can be (nominally) found at: http://h18000.www1.hp.com/products/software/alpha-tools/documentation/current/chip-docs.html Last time I went digging, some of the links didn't work but if you look at the links and rummage around the FTP site, the information was all there (and other material that wasn't referenced in the HTML pages). >sysctl is a good interface for retrieving this information as it doesn't >change during the lifetime of the kernel, and it is small. sysctl is already >invoked from within libc to retrieve information in this way. I agree. sysctl would appear to be the best interface. >alpha >----- >Cache discovery? Static. AFAIK, there's no PALcode interface, unfortunately. >i386 pc98 amd64 >--------------- >Cache discovery? CPUID. >Earlier chips which don't support it probably don't have a cache, >or aren't worth supporting. 80386 has no on-chip cache. Intel i486 has 8KB _unified_ 4-way, 16 bytes/line L1. Cache alignment has a significant effect and gcc defaults to 16-byte alignment on -m486. ports/benchmarks/lmbench includes tools that can experimentally determine the cache configuration - though not quickly/efficiently enough to form part of the boot. Peter From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 13 08:11:44 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 599E416A4B3 for ; Mon, 13 Oct 2003 08:11:44 -0700 (PDT) Received: from www.kjkoster.org (213-84-106-195.adsl.xs4all.nl [213.84.106.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B99E43F75 for ; Mon, 13 Oct 2003 08:11:41 -0700 (PDT) (envelope-from kjkoster@kjkoster.org) Received: from kjkoster.org (LikeEver [192.168.0.1]) by www.kjkoster.org (8.12.9p2/8.12.9) with ESMTP id h9DFBduO005328; Mon, 13 Oct 2003 17:11:39 +0200 (CEST) (envelope-from kjkoster@kjkoster.org) Sender: kjkoster@www.kjkoster.org Message-ID: <3F8AC0AB.77589A79@kjkoster.org> Date: Mon, 13 Oct 2003 17:11:39 +0200 From: Kees Jan Koster X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: FreeBSD Hackers mailing list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: kjkoster@kjkoster.org Subject: On-board Promise controller is not detected X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2003 15:11:44 -0000 Dear FreeBSD hackers, I have posted this question to FreeBSD-questions earlier, but got no reply. So I try here. I'm having trouble getting my on-board Promise controller to work. I can use atacontrol to build an array, but sysinstall won't detect the disk pack. Could this be a problem with the fact that I use 2x80GB (Western Digital) disk? Are they perhaps too large for the controller to understand? LikeEver# uname -a FreeBSD LikeEver.kjkoster.org 4.9-RC FreeBSD 4.9-RC #51: Fri Oct 3 23:13:50 CEST 2003 kjkoster@LikeEver.kjkoster.org:/usr/obj/usr/src/sys/LIKEEVER i386 LikeEver# dmesg | egrep -i "ata|ad[0-9]" Preloaded splash_image_data "/boot/splash.bmp" at 0xc03f2190. atapci0: port 0xdc00-0xdc3f,0xe000-0xe003,0xe400-0xe407,0xe800-0xe803,0xec00-0xec07 mem 0xdffe0000-0xdfffffff irq 10 at device 12.0 on pci0 ata2: at 0xec00 on atapci0 ata3: at 0xe400 on atapci0 atapci1: port 0xfc00-0xfc0f at device 17.1 on pci0 ata0: at 0x1f0 irq 14 on atapci1 ata1: at 0x170 irq 15 on atapci1 ad0: 14655MB [29777/16/63] at ata0-master UDMA66 ad2: 14655MB [29777/16/63] at ata1-master UDMA66 ar0: 76293MB [9726/255/63] status: READY subdisks: 0 READY ad4: 76319MB [155061/16/63] at ata2-master UDMA100 1 READY ad6: 76319MB [155061/16/63] at ata3-master UDMA100 Mounting root from ufs:/dev/ad0s1a LikeEver# atacontrol delete 0 LikeEver# atacontrol create stripe 512 ad4 ad6 ar0 created LikeEver# atacontrol status 0 ar0: ATA RAID0 subdisks: ad4 ad6 status: READY LikeEver# _ Unfortunately, sysinstall won't see the disk pack at all. It just gives me ad0 and ad2. Building the disk array from the (rather useless) BIOS utility does not help. This is where I get lost. Anything I have missed? The mainboard is an MSI K7T266 Pro2. Thank you in advance, Kees Jan --------------------------------------------------------------- Kees Jan Koster e-mail: kjkoster "at" kjkoster.org www: http://www.kjkoster.org/ --------------------------------------------------------------- Life is uncertain; eat dessert first. From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 13 08:20:43 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E32A16A4B3 for ; Mon, 13 Oct 2003 08:20:43 -0700 (PDT) Received: from mizar.origin-it.net (mizar.origin-it.net [194.8.96.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0BA343FA3 for ; Mon, 13 Oct 2003 08:20:40 -0700 (PDT) (envelope-from helge.oldach@atosorigin.com) Received: from matar.hbg.de.int.atosorigin.com (dehsfw3e.origin-it.net [194.8.96.68])h9DFKaT9032440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2003 17:20:36 +0200 (CEST) (envelope-from helge.oldach@atosorigin.com) Received: from galaxy.hbg.de.ao-srv.com (galaxy.hbg.de.ao-srv.com [161.89.20.4])ESMTP id h9DFKZno079859; Mon, 13 Oct 2003 17:20:35 +0200 (CEST) (envelope-from helge.oldach@atosorigin.com) Received: (from hmo@localhost) by galaxy.hbg.de.ao-srv.com (8.9.3p2/8.9.3/hmo30mar03) id RAA04960; Mon, 13 Oct 2003 17:20:32 +0200 (MET DST) Message-Id: <200310131520.RAA04960@galaxy.hbg.de.ao-srv.com> In-Reply-To: <20031006120920.GC31567@saboteur.dek.spc.org> from Bruce M Simpson at "Oct 6, 2003 2: 9:20 pm" To: bms@spc.org (Bruce M Simpson) Date: Mon, 13 Oct 2003 17:20:31 +0200 (MET DST) From: Helge Oldach X-Address: Atos Origin GmbH, Friesenstraße 13, D-20097 Hamburg, Germany X-Phone: +49 40 7886 7464, Fax: +49 40 7886 9464, Mobile: +49 160 4782517 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org cc: chuck@NetBSD.org cc: matt@domsch.com Subject: Re: afaapps port committed to FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2003 15:20:43 -0000 Hi, I may sound ignorant, but what is wrong with the FreeBSD-native aaccli utility that can be downloaded from Adaptec (5400s_fbsd_cli_v10.zip)? I have been using this for some time now with success. May I suggest to make a port out of this as well? Helge Bruce M Simpson: >Hi, > >I'm a FreeBSD src committer who deals with Dell hardware a lot. I've just >committed a port of afaapps to FreeBSD. I should be grateful if you could >add this to your extremely useful list of resources. > >Please pass on my sincere thanks to your colleagues at Dell for providing us >with these tools. > >I've tested the tools with Scott Long's aac(4) driver. This has a >passthrough >for the ioctls which the afacli tool uses. Version 2.7 of the tools, with a >PowerEdge 2400 chassis' Dell PERC 2/Si running firmware 2.1, work perfectly >under Linux emulation in FreeBSD 4.9-RC. > >I understand that Dell do not officially support FreeBSD; members of the >Project certainly hope that will change in future, as the forthcoming 5.2 >release is looking very promising. I also understand that distribution >restrictions exist on Dell software, therefore the port has been marked >RESTRICTED (binaries will not be distributed as part of FreeBSD releases), >in accordance with Dell's wishes. > >Kind regards, >Bruce M. Simpson <---> bms@spc.org / bms@FreeBSD.org / vm/net hacker > From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 13 09:25:53 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 334F916A4BF for ; Mon, 13 Oct 2003 09:25:53 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5CA843FE9 for ; Mon, 13 Oct 2003 09:25:46 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 6D3BA654B7; Mon, 13 Oct 2003 17:25:45 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17510-02-2; Mon, 13 Oct 2003 17:25:45 +0100 (BST) Received: from saboteur.dek.spc.org (82-147-18-81.dsl.uk.rapidplay.com [82.147.18.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 81651653D4; Mon, 13 Oct 2003 17:25:43 +0100 (BST) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 4F57B28; Mon, 13 Oct 2003 17:25:39 +0100 (BST) Date: Mon, 13 Oct 2003 17:25:39 +0100 From: Bruce M Simpson To: Helge Oldach Message-ID: <20031013162539.GQ23068@saboteur.dek.spc.org> References: <20031006120920.GC31567@saboteur.dek.spc.org> <200310131520.RAA04960@galaxy.hbg.de.ao-srv.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/i8j2F0k9BYX4qLc" Content-Disposition: inline In-Reply-To: <200310131520.RAA04960@galaxy.hbg.de.ao-srv.com> cc: hackers@freebsd.org cc: matt@domsch.com Subject: Re: afaapps port committed to FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2003 16:25:53 -0000 --/i8j2F0k9BYX4qLc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 13, 2003 at 05:20:31PM +0200, Helge Oldach wrote: > I may sound ignorant, but what is wrong with the FreeBSD-native aaccli > utility that can be downloaded from Adaptec (5400s_fbsd_cli_v10.zip)? > I have been using this for some time now with success. >=20 > May I suggest to make a port out of this as well? Already did. Didn't realize til after scottl@ told me the next day. Check cvs-ports@. :-) BMS --/i8j2F0k9BYX4qLc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQE/itICueUpAYYNtTsRAoNCAJ4kr0wKrZ32Ezz+csEvJrT7winadgCgouiq dD4LG/tBtJEhSjtfI/b+d1Q= =9Uti -----END PGP SIGNATURE----- --/i8j2F0k9BYX4qLc-- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 13 09:46:43 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 59B4316A4B3 for ; Mon, 13 Oct 2003 09:46:43 -0700 (PDT) Received: from visi.gothic.net.au (visi.gothic.net.au [202.182.69.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C07F43FBF for ; Mon, 13 Oct 2003 09:46:39 -0700 (PDT) (envelope-from sean@gothic.net.au) Received: from localhost (localhost [127.0.0.1]) by visi.gothic.net.au (Postfix) with ESMTP id E962B2844A; Tue, 14 Oct 2003 02:46:35 +1000 (EST) Received: from gothic.net.au (pvc.gothic.net.au [202.182.90.7]) by visi.gothic.net.au (Postfix) with ESMTP id 4F3C12700C; Tue, 14 Oct 2003 02:46:29 +1000 (EST) Message-ID: <3F8AD6DB.4050107@gothic.net.au> Date: Tue, 14 Oct 2003 02:46:19 +1000 From: Sean Winn User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Jeremy References: <20031010103640.6F5A216A4BF@hub.freebsd.org> <20031010134400.GE803@saboteur.dek.spc.org> <16263.1019.939450.708832@grasshopper.cs.duke.edu> <20031011035827.GD75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> <20031011082711.GB679@saboteur.dek.spc.org> <20031011101231.GH75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> <20031011140651.GA1739@saboteur.dek.spc.org> <20031012195752.GE2996@saboteur.dek.spc.org> <20031013094715.GA75662@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> In-Reply-To: <20031013094715.GA75662@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.60-rc3 (1.202-2003-08-29-exp) on visi.gothic.net.au X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60-rc3 X-Virus-Scanned: by amavisd 0.1 cc: freebsd-hackers@freebsd.org Subject: Re: Determining CPU features / cache organization from userland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2003 16:46:43 -0000 Peter Jeremy wrote: > On Sun, Oct 12, 2003 at 08:57:52PM +0100, Bruce M Simpson wrote: > >>[ Andrew: Perhaps you can shed some light on how the necessary information >>can be gathered on Alpha? My search was incomplete and I could not find >>a reliable source for DEC's development manuals. ] > > > L1 cache information is in the CPU datasheets. I don't know of a > summary across the whole Alpha family. The datasheets can be > (nominally) found at: > http://h18000.www1.hp.com/products/software/alpha-tools/documentation/current/chip-docs.html > > Last time I went digging, some of the links didn't work but if you > look at the links and rummage around the FTP site, the information was > all there (and other material that wasn't referenced in the HTML pages). > > >>sysctl is a good interface for retrieving this information as it doesn't >>change during the lifetime of the kernel, and it is small. sysctl is already >>invoked from within libc to retrieve information in this way. > > > I agree. sysctl would appear to be the best interface. > > >>alpha >>----- >>Cache discovery? Static. > > > AFAIK, there's no PALcode interface, unfortunately. > > >>i386 pc98 amd64 >>--------------- >>Cache discovery? CPUID. >>Earlier chips which don't support it probably don't have a cache, >>or aren't worth supporting. > > > 80386 has no on-chip cache. > Intel i486 has 8KB _unified_ 4-way, 16 bytes/line L1. Cache alignment has > a significant effect and gcc defaults to 16-byte alignment on -m486. Only the DX, SX, DX2, SX2 and GX - DX4 has a 16kB one, and it may be write through or write back. However, I believe the DX4s have CPUID so detecting them should be simple. > > ports/benchmarks/lmbench includes tools that can experimentally > determine the cache configuration - though not quickly/efficiently > enough to form part of the boot. > > Peter > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 13 12:33:09 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3CE816A4B3 for ; Mon, 13 Oct 2003 12:33:08 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AC4043FA3 for ; Mon, 13 Oct 2003 12:33:06 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id F2FA0653B5 for ; Mon, 13 Oct 2003 20:33:04 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19228-02 for ; Mon, 13 Oct 2003 20:33:04 +0100 (BST) Received: from saboteur.dek.spc.org (82-147-18-81.dsl.uk.rapidplay.com [82.147.18.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 8DB8D65322 for ; Mon, 13 Oct 2003 20:33:03 +0100 (BST) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id ECB42C0; Mon, 13 Oct 2003 20:32:58 +0100 (BST) Date: Mon, 13 Oct 2003 20:32:58 +0100 From: Bruce M Simpson To: freebsd-hackers@freebsd.org Message-ID: <20031013193258.GB25160@saboteur.dek.spc.org> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20031010103640.6F5A216A4BF@hub.freebsd.org> <20031010134400.GE803@saboteur.dek.spc.org> <16263.1019.939450.708832@grasshopper.cs.duke.edu> <20031011035827.GD75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> <20031011082711.GB679@saboteur.dek.spc.org> <20031011101231.GH75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> <20031011140651.GA1739@saboteur.dek.spc.org> <20031012195752.GE2996@saboteur.dek.spc.org> <20031013094715.GA75662@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> <3F8AD6DB.4050107@gothic.net.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DKU6Jbt7q3WqK7+M" Content-Disposition: inline In-Reply-To: <3F8AD6DB.4050107@gothic.net.au> Subject: Re: Determining CPU features / cache organization from userland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2003 19:33:09 -0000 --DKU6Jbt7q3WqK7+M Content-Type: multipart/mixed; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline All, Here are detailed design documents for determining cache and TLB geometry across our currently supported processor architectures, with recommendations outlined for implementation. What I haven't addressed yet is how indirect consumers of the API might use it, e.g. mutex consumers vs. UMA, in the context of allocating cache-aligned mutexes from a mutex pool. Please let me know your thoughts. BMS --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="cacheinfo.txt" Detailed design for cache/tlb geometry discovery ------------------------------------------------ all --- Review NetBSD's uvm_page_recolor() viz applicability to FreeBSD VM/UMA. alpha ----- Action: Add code to machdep.c in identifycpu() to fill out hw_cacheinfo. Cache discovery: Static tables keyed on specific CPU model. TLB discovery: Static tables keyed on specific CPU model. Cache heuristic: 8Kb L1 Split Direct Mapped (21064) 2MB L2 Unified Direct Mapped (21064) All CPUs below 21264 have a 32-byte L1 line size. 21264 (EV6) has a 64-byte L1 line size. Optional L3 cache. TLB heuristic: ITLB 8KB page 8 lines, 4MB page 4 lines (21064) DTLB 32 lines, all page sizes, fully associative. (21064) ia64 ---- Action: Add code to machdep.c in identifycpu() to fill out hw_cacheinfo. Review Linux's pal.h and palinfo.c. files. Cache discovery: Call the platform functions PAL_CACHE_SUMMARY and PAL_CACHE_INFO to get this information. TLB discovery: Static tables keyed on specific CPU model. Cache heuristic: L1 typically split 4-way set-associative 16KB, L2 256KB unified, L3 3MB-6MB unified. Line size isn't defined by the architecture. TLB heuristic: L1 TLB, split, data/instruction 32 entries each, fully associative L2 TLB, split, data/instruction 128 entries each, fully associative i386 pc98 amd64 --------------- Action: Add code to identcpu.c to fill out hw_cacheinfo. Cache discovery: Extended CPUID. Static tables if 486-class machine. No cache on 386. TLB discovery: Extended CPUID. Static tables if 486-class machine. No cache on 386. Cache heuristic (Intel): L1: 4-way, 32 bytes/line Cache heuristic (AMD): L2: 8-way, 64 bytes/line TLB heuristic (Intel): 4KB Code: 32 entries, 4-way, LRU 4MB Code: 2 entries, Fully associative, LRU 4KB Data: 64 entries, 4-way, LRU 4MB Data: 8 entries, 4-way, LRU TLB heuristic (AMD): 4KB L1 Code: 16 entries, Fully associative, LRU 4MB/2MB L1 Code: 8 entries, Fully associative, LRU 4KB L1 Data: 24/32 entries, Fully associative, LRU 4MB/2MB L1 Data: 8 entries, 4-way, LRU 4KB L2 Code: 256 entries, 4-way, LRU 4KB L2 Data: 256 entries, 4-way, LRU (That's 6 distinct TLBs to deal with on AMD-based i386 architectures). powerpc ------- Action: Adapt from NetBSD as appropriate. Cache discovery: Open Firmware on CHRP if available. Static tables keyed on specific CPU model. TLB discovery: Open Firmware on CHRP if available. Static tables keyed on specific CPU model. Cache heuristic: L1 line size: 32 bytes across family. Pre-G5: 32KB/32KB Split, 8-way G5: 64KB/32KB Split, 1-way L2 line size: 32/64/128 bytes, TLB heuristic: PPC 601e: 4KB Instruction TLB, 4 entries, most recently used translations UTLB, 256 entries, 2-way set associative, software selectable block size OFW properties: i-cache-size i-cache-sets i-cache-block-size d-cache-size d-cache-sets d-cache-block-size tlb-size tlb-sets l2-cache [*] CHRP only mips ---- Action: Adapt from NetBSD as appropriate. Cache discovery: Static tables keyed on specific CPU model. TLB discovery: MIPS32/MIPS64 Privileged Resource Architecture registers Cache heuristic: Split/unified L1/L2, unified L3. TLB heuristic: 16KB page size, 64 entries, fully associative (R10000) sparc64 ------- Action: Adapt existing code in cache.c to fill out and use hw_cacheinfo. Review assembly code, particularly that which abuses the TLB. Work closely with jake@ to avoid code churn. Cache discovery: Open Firmware. TLB discovery: Open Firmware. Cache heuristic: Split L1, Unified L2. TLB heuristic: Split L1 TLB. Fully Associative. NLU. 64 lines each. OFW properties: icache-size icache-line-size icache-associativity dcache-size dcache-line-size dcache-associativity ecache-size ecache-line-size ecache-associativity #dtlb-entries #itlb-entries --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="cacheplan.txt" Maintain information about cache and TLB geometry in an MI structure. The abstraction is intended to reflect current and future machine architectures. It is expected that the contents of these structures may not change over the lifetime of the kernel. Keeping this information in a structure doesn't significantly increase the cost of retrieving it from userland anyway. Userland consumers such as thread libraries and memory allocators should take a copy of this structure upon initialization. Kernel consumers may feel free to cache the information in local variables as they like. TLBs are 'caches' for virtual address lookups. Like data and instruction caches, they may employ set associativity to reduce the risk of unnecessary cache flushes/misses in multiprogramming environments. Some architectures segregate their TLBs according to page size. If this is the case, set the segsize member accordingly. These segregated TLBs are counted as seperate TLBs. If this particular TLB has a software-programmable page size, set pagesize to PAGESIZE_PROG. At an extreme, it's possible to detect cache/TLB properties of a machine at runtime using algorithms such as those used by Stefan Manegold's 'Calibrator' program (although this isn't suitable for boot-time kernel use): ---------------------------------------------------------------------------- /* * Per-cache information structure. * * Properties of the cache may be determined using the * simple macros below. Where a unified cache exists, consumers should check * the 'code' member first, as the 'data' member shall be used for * CACHE_OTHER members. */ struct hw_cache { u_int16_t type; u_int16_t linesize; u_int32_t nsets; u_int32_t nlines; } __packed; #define CACHE_ISDISABLED(_c) ((_c)->nsets == 0) #define CACHE_ISDIRECTMAPPED(_c) ((_c)->nsets == 1) #define CACHE_ISFULLYASSOC(_c) ((_c)->nsets == (_c)->nlines) #define CACHE_SIZE(_c) ((_c)->nsets * (_c)->nlines) /* definitions for type member */ #define CACHE_NONE 0 /* does not exist */ #define CACHE_UNIFIED 1 /* is unified */ #define CACHE_CODE 2 /* is for instructions only */ #define CACHE_DATA 3 /* is for data only */ #define CACHE_OTHER 4 /* is something different */ /* * Per-TLB information structure. * * There can be up to MAX_TLB distinct TLBs present in current architectures. * By the rules above, AMD Athlon processors have approx. 6 TLBs. * * The properties of a TLB must be represented and referenced using the * same CACHE_* macros above. */ struct hw_tlb { u_int32_t type; u_int32_t pagesize; u_int32_t nsets; u_int32_t nlines; } __packed; #define PAGESIZE_PROG 0UL #define MAX_TLB 8 /* * Maintain information about all caches and TLBs in the system. Assume that * this information is consistent across all CPUs in an SMP system. * * Export this structure to userland via a sysctl. * * XXX TODO: Make it easy for assembly language routines to use this * structure. */ struct hw_cacheinfo { struct { struct hw_cache icache; struct hw_cache dcache; } l1, l2, l3; struct hw_tlb tlb[MAX_TLB]; } __packed; ---------------------------------------------------------------------------- --Nq2Wo0NMKNjxTN9z-- --DKU6Jbt7q3WqK7+M Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQE/iv3queUpAYYNtTsRAhF7AJ0UVwBDhiJ4lF5igBtNZQqKmEnZdQCdHGxi HiHfl/3Qw/XJw3b9ESX8bsk= =Myma -----END PGP SIGNATURE----- --DKU6Jbt7q3WqK7+M-- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 13 13:11:02 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 992DD16A4C0 for ; Mon, 13 Oct 2003 13:11:02 -0700 (PDT) Received: from gidgate.gid.co.uk (gid.co.uk [194.32.164.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A43043FA3 for ; Mon, 13 Oct 2003 13:11:00 -0700 (PDT) (envelope-from rb@gid.co.uk) Received: (from rb@localhost) by gidgate.gid.co.uk (8.11.7/8.11.6) id h9DKAwY44350; Mon, 13 Oct 2003 21:10:58 +0100 (BST) (envelope-from rb) Message-Id: <4.3.2.7.2.20031013210610.02dc0028@gid.co.uk> X-Sender: rbmail@gid.co.uk X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 Oct 2003 21:10:56 +0100 To: Bruce M Simpson , freebsd-hackers@freebsd.org From: Bob Bishop In-Reply-To: <20031013193258.GB25160@saboteur.dek.spc.org> References: <3F8AD6DB.4050107@gothic.net.au> <20031010103640.6F5A216A4BF@hub.freebsd.org> <20031010134400.GE803@saboteur.dek.spc.org> <16263.1019.939450.708832@grasshopper.cs.duke.edu> <20031011035827.GD75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> <20031011082711.GB679@saboteur.dek.spc.org> <20031011101231.GH75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> <20031011140651.GA1739@saboteur.dek.spc.org> <20031012195752.GE2996@saboteur.dek.spc.org> <20031013094715.GA75662@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> <3F8AD6DB.4050107@gothic.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: Determining CPU features / cache organization from userland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2003 20:11:02 -0000 Hi, ISTR that AMD 486 had different cache arrangements from Intel. Just threw one out - I'll see if I can find another around here. -- Bob Bishop +44 (0)118 977 4017 rb@gid.co.uk fax +44 (0)118 989 4254 From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 14 01:38:18 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DE0916A4B3 for ; Tue, 14 Oct 2003 01:38:18 -0700 (PDT) Received: from c210-49-151-50.thorn1.nsw.optusnet.com.au (c210-49-151-50.thorn1.nsw.optusnet.com.au [210.49.151.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6900643F93 for ; Tue, 14 Oct 2003 01:38:17 -0700 (PDT) (envelope-from tonymaher@optushome.com.au) Received: from dt.home (localhost [127.0.0.1])ESMTP id h9E8cFDw001142 for ; Tue, 14 Oct 2003 18:38:15 +1000 (EST) (envelope-from tonym@dt.home) Received: (from tonym@localhost) by dt.home (8.12.9p2/8.12.9/Submit) id h9E8cAWe001066 for hackers@freebsd.org; Tue, 14 Oct 2003 18:38:10 +1000 (EST) (envelope-from tonym) Date: Tue, 14 Oct 2003 18:38:10 +1000 (EST) From: Tony Maher Message-Id: <200310140838.h9E8cAWe001066@dt.home> To: hackers@freebsd.org Subject: default route curiosity X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2003 08:38:18 -0000 Hello, this is just for my own curiosity. On the weekend at work, the comms guys rebuilt a router and our freebsd boxes could not talk to database server in a different subnet for a few hours. The router upgrade failed so upgrade was backed out and routes eventually re-established. All seemed well, could ssh into the freebsd boxes from different subnets but the freebsd boxes could not talk to the database server in one particular subnet (or indeed contact the box on that subnet vi any protocol except ping [icmp]). Other subnet could be reached. sockstat showed there were existing connections to database. The router changed its mac address back and forth during upgrade so did 'arp -ad' but this did not help. Flushing all routes and re-establishing default route and everything immediately worked. The routing table before and after the flushing were identical (and of course default route worked to other subnets before flushing). I assume it was because of the existing database connections there was some bad routing 'info' held in the sytem somewhere. Anyone have any further insight into this. just curious -- tonym From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 14 05:44:44 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C29C16A4B3; Tue, 14 Oct 2003 05:44:44 -0700 (PDT) Received: from milla.ask33.net (milla.ask33.net [217.197.166.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD2C243F75; Tue, 14 Oct 2003 05:44:42 -0700 (PDT) (envelope-from nick@milla.ask33.net) Received: by milla.ask33.net (Postfix, from userid 1001) id 2C49A3ABB35; Tue, 14 Oct 2003 14:47:47 +0200 (CEST) Date: Tue, 14 Oct 2003 14:47:47 +0200 From: Pawel Jakub Dawidek To: freebsd-hackers@freebsd.org Message-ID: <20031014124747.GQ520@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="V1B6tgkYnQOXc079" Content-Disposition: inline X-PGP-Key-URL: http://garage.freebsd.pl/jules.asc X-OS: FreeBSD 4.8-RELEASE-p9 i386 X-URL: http://garage.freebsd.pl User-Agent: Mutt/1.5.1i cc: phk@phk.freebsd.dk cc: freebsd-current@freebsd.org Subject: GEOM Gate. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2003 12:44:44 -0000 --V1B6tgkYnQOXc079 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello hackers... Ok, GEOM Gate is ready for testing. For those who don't know what it is, they can read README: http://garage.freebsd.pl/geom_gate.README and presentation from WIP/BSDCon03 session: http://garage.freebsd.pl/GEOM_Gate.pdf After compliation (cd geom_gate; make; make install) you should run regression tests: # regression/runtests.sh If everything will went ok you can play with GEOM Gate and report any bugs. I've spend some time to made GEOM Gate force-remove-safe so using '-f' option with ggc(8) should be always safe. Ah! Four manual pages are added, so feel free to read them first (gg(4), geom_gate(4), ggc(8), ggd(8)) http://garage.freebsd.pl/geom_gate.tbz Enjoy! --=20 Pawel Jakub Dawidek pawel@dawidek.net UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net --V1B6tgkYnQOXc079 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iQCVAwUBP4vwcz/PhmMH/Mf1AQEj/wP/Uz8KvtmlPmNVu0EbZuNt+gJcFvDeGJne XYdAZBxW9VqQSNf+k5B9RoPDoBwuJYOteoUSNpSdNJV2o+C1/aUMdGoLCggcBSpZ f41E0CY5WqqUtlFQtEHqGInRn1ImbjT8FON46d0A1K5MVcpdkr2IiBLzfUxAtICf 3pjqz8MlOPc= =/82a -----END PGP SIGNATURE----- --V1B6tgkYnQOXc079-- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 14 06:51:34 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 331F516A4BF for ; Tue, 14 Oct 2003 06:51:34 -0700 (PDT) Received: from sana.init-main.com (104.194.138.210.bn.2iij.net [210.138.194.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D1F543FA3 for ; Tue, 14 Oct 2003 06:51:30 -0700 (PDT) (envelope-from takawata@init-main.com) Received: from init-main.com (localhost [127.0.0.1]) by sana.init-main.com (8.12.10/8.12.9) with ESMTP id h9EDlQUN000769; Tue, 14 Oct 2003 22:47:26 +0900 (JST) (envelope-from takawata@init-main.com) Message-Id: <200310141347.h9EDlQUN000769@sana.init-main.com> To: rizzo@icir.org Date: Tue, 14 Oct 2003 22:47:26 +0900 From: Takanori Watanabe cc: freebsd-hackers@freebsd.org cc: takawata@sana.init-main.com Subject: #ifdef IPDIVERT in sys/netinet/ip_fw2.c? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2003 13:51:34 -0000 Do we need #ifdef IPDIVERT in sys/ne I don't think it is needed, because ip_fw2 always accepts DIVERT packet and the option is only used for print out if IPDIVERT option is enabled or not. I tried to run natd in kernel with IPDIVERT enabled and IPFW not enabled, with ipfw kernel module. And it workes. % dmesg ... ipfw2 initialized, divert disabled, rule-based forwarding enabled, default to de ny, logging disabled acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0% ... % kldstat Id Refs Address Size Name 1 41 0xc0400000 2de980 kernel 2 2 0xc06df000 1d634 linux.ko 3 1 0xc06fd000 9310 ipfw.ko 4 1 0xc0707000 b3ec if_fxp.ko 5 3 0xc0713000 1c174 miibus.ko 6 1 0xc0730000 8080 if_rl.ko 7 1 0xc0739000 7988 ng_pppoe.ko 8 2 0xc0741000 49f0 ng_ether.ko 9 8 0xc0746000 14b2c netgraph.ko 10 1 0xc075b000 59b8 snd_cmi.ko 11 2 0xc0761000 1e678 snd_pcm.ko 12 9 0xc0780000 13088 agp.ko 13 1 0xc0794000 1f3c bktr_mem.ko 14 1 0xc0796000 31c4 joy.ko 15 1 0xc079a000 7e1c fdc.ko 16 1 0xc07a2000 1af2c4 nvidia.ko 17 1 0xc0952000 4ce2c acpi.ko 18 1 0xc63ab000 5000 ip6fw.ko 19 1 0xc63d6000 1b000 nfsserver.ko 20 1 0xc6422000 3000 daemon_saver.ko 21 1 0xc643d000 4000 ng_socket.ko 22 1 0xc6441000 4000 ng_iface.ko 23 1 0xc6447000 8000 ng_ppp.ko 24 1 0xc646d000 4000 ng_bpf.ko 25 1 0xc6471000 5000 ng_vjc.ko % ps auxwww|grep natd root 211 0.0 0.0 804 348 ?? Is 10:04PM 0:00.06 /sbin/natd -dynamic -n ng0 '#ifdef' should be avoided as possible, because Do you need the message to indicate IPDIVERT is enabled? If it is not needed so much, just change the message to dike the #ifdef. --- /sys/netinet/ip_fw2.c Fri Sep 26 19:14:22 2003 +++ ip_fw2.c Tue Oct 14 22:45:41 2003 @@ -2928,13 +2928,8 @@ } ip_fw_default_rule = layer3_chain.rules; - printf("ipfw2 initialized, divert %s, " + printf("ipfw2 initialized, " "rule-based forwarding enabled, default to %s, logging ", -#ifdef IPDIVERT - "enabled", -#else - "disabled", -#endif default_rule.cmd[0].opcode == O_ACCEPT ? "accept" : "deny"); If you still need it, this should be converted to a reference to global variable. How do you think about it? From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 14 09:15:03 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8710316A4B3 for ; Tue, 14 Oct 2003 09:15:03 -0700 (PDT) Received: from mail.speakeasy.net (mail9.speakeasy.net [216.254.0.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E03843FBD for ; Tue, 14 Oct 2003 09:15:02 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 31354 invoked from network); 14 Oct 2003 16:15:01 -0000 Received: from unknown (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail9.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 14 Oct 2003 16:15:01 -0000 Received: from hydrogen.funkthat.com (tuhktg@localhost.funkthat.com [127.0.0.1])h9EGF1Ce006637 for ; Tue, 14 Oct 2003 09:15:01 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id h9EGF1Xl006633 for freebsd-hackers@freebsd.org; Tue, 14 Oct 2003 09:15:01 -0700 (PDT) Date: Tue, 14 Oct 2003 09:15:01 -0700 From: John-Mark Gurney To: freebsd-hackers@freebsd.org Message-ID: <20031014161501.GS533@funkthat.com> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20031010134400.GE803@saboteur.dek.spc.org> <16263.1019.939450.708832@grasshopper.cs.duke.edu> <20031011035827.GD75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> <20031011082711.GB679@saboteur.dek.spc.org> <20031011101231.GH75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> <20031011140651.GA1739@saboteur.dek.spc.org> <20031012195752.GE2996@saboteur.dek.spc.org> <20031013094715.GA75662@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> <3F8AD6DB.4050107@gothic.net.au> <20031013193258.GB25160@saboteur.dek.spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031013193258.GB25160@saboteur.dek.spc.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: Re: Determining CPU features / cache organization from userland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2003 16:15:03 -0000 Bruce M Simpson wrote this message on Mon, Oct 13, 2003 at 20:32 +0100: > i386 pc98 amd64 > --------------- > Action: Add code to identcpu.c to fill out hw_cacheinfo. > > Cache discovery: Extended CPUID. > Static tables if 486-class machine. No cache on 386. > TLB discovery: Extended CPUID. > Static tables if 486-class machine. No cache on 386. not to be a stick, but I do have a Am386DX-40 that has 128kb of cache on the mother board. It's the same style SRAMs that most 486's have on their board. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 14 09:56:23 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D59516A4B3; Tue, 14 Oct 2003 09:56:23 -0700 (PDT) Received: from rhymer.cogsci.ed.ac.uk (rhymer.cogsci.ed.ac.uk [129.215.144.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 725B143FA3; Tue, 14 Oct 2003 09:56:21 -0700 (PDT) (envelope-from richard@cogsci.ed.ac.uk) Received: (from richard@localhost) by rhymer.cogsci.ed.ac.uk (8.9.3p2/8.9.3) id RAA28657; Tue, 14 Oct 2003 17:56:20 +0100 (BST) Date: Tue, 14 Oct 2003 17:56:20 +0100 (BST) Message-Id: <200310141656.RAA28657@rhymer.cogsci.ed.ac.uk> From: Richard Tobin To: freebsd-hackers@freebsd.org In-Reply-To: Pawel Jakub Dawidek's message of Tue, 14 Oct 2003 14:47:47 +0200 Organization: just say no cc: freebsd-current@freebsd.org Subject: Re: GEOM Gate. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2003 16:56:23 -0000 > Ok, GEOM Gate is ready for testing. > For those who don't know what it is, they can read README: Aaargh! It's the return of nd(4) from SunOS. (Sorry about that.) -- Richard From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 14 13:33:08 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F53D16A4B3; Tue, 14 Oct 2003 13:33:08 -0700 (PDT) Received: from mailrtr03.ntelos.net (mailrtr03.ntelos.net [216.12.0.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFE7A43F3F; Tue, 14 Oct 2003 13:33:06 -0700 (PDT) (envelope-from wer@cstone.net) Received: from cstone.net (bill.eng.cstone.net [209.145.66.27]) by mailrtr03.ntelos.net (8.11.7/8.11.7) with ESMTP id h9EKX4B13310; Tue, 14 Oct 2003 16:33:04 -0400 Message-ID: <3F8C5D80.2070706@cstone.net> Date: Tue, 14 Oct 2003 16:33:04 -0400 From: Bill Reid User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: conrads@cox.net References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-multimedia@FreeBSD.ORG cc: freebsd-hackers@FreeBSD.ORG cc: John Utz Subject: Re: midi on FreeBSD 4.5: good progress! i now have a midi.ko bas X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2003 20:33:08 -0000 I second that. Thanks John. -=Bill Conrad Sabatier wrote: >John, > >Please keep us informed as to your progress. I'm sure I'm not the only one >who would be *very* happy to see your work come to fruition! > >If I can help in any way (testing or whatever), let me know. > > > From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 14 13:44:24 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8CD116A4B3; Tue, 14 Oct 2003 13:44:24 -0700 (PDT) Received: from mizar.origin-it.net (mizar.origin-it.net [194.8.96.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E80043F75; Tue, 14 Oct 2003 13:44:21 -0700 (PDT) (envelope-from Helge.Oldach@atosorigin.com) Received: from matar.hbg.de.int.atosorigin.com (dehsfw3e.origin-it.net [194.8.96.68])h9EKiFT9003234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2003 22:44:16 +0200 (CEST) (envelope-from Helge.Oldach@atosorigin.com) Received: from dehhx004.hbg.de.int.atosorigin.com (dehhx004.hbg.de.int.atosorigin.com [161.90.164.40]) ESMTP id h9EKiFno049923; Tue, 14 Oct 2003 22:44:15 +0200 (CEST) (envelope-from Helge.Oldach@atosorigin.com) Received: by dehhx004.hbg.de.int.atosorigin.com with Internet Mail Service (5.5.2653.19) id <4CPL9R8R>; Tue, 14 Oct 2003 22:44:15 +0200 Message-ID: From: "Oldach, Helge" To: "'Richard Tobin'" , freebsd-hackers@freebsd.org Date: Tue, 14 Oct 2003 22:44:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" cc: freebsd-current@freebsd.org Subject: RE: GEOM Gate. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2003 20:44:24 -0000 From: Richard Tobin [mailto:richard@cogsci.ed.ac.uk] > > Ok, GEOM Gate is ready for testing. > > For those who don't know what it is, they can read README: > > Aaargh! It's the return of nd(4) from SunOS. Excuse me? # uname -a SunOS galaxy 4.1.4 18 sun4m # man nd No manual entry for nd. # Helge From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 14 14:05:27 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FDBE16A5ED; Tue, 14 Oct 2003 14:05:27 -0700 (PDT) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5753D43FBF; Tue, 14 Oct 2003 14:05:26 -0700 (PDT) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtpzilla3.xs4all.nl (8.12.9/8.12.9) with ESMTP id h9EL5MRe060459; Tue, 14 Oct 2003 23:05:22 +0200 (CEST) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.9p1/8.12.9) with ESMTP id h9EL5MPq057737; Tue, 14 Oct 2003 23:05:22 +0200 (CEST) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.9p1/8.12.9/Submit) id h9EL5MeK057736; Tue, 14 Oct 2003 23:05:22 +0200 (CEST) (envelope-from wkb) Date: Tue, 14 Oct 2003 23:05:22 +0200 From: Wilko Bulte To: "Oldach, Helge" Message-ID: <20031014210522.GA57718@freebie.xs4all.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-OS: FreeBSD 4.9-PRERELEASE X-PGP: finger wilko@freebsd.org cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org cc: 'Richard Tobin' Subject: Re: GEOM Gate. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2003 21:05:27 -0000 On Tue, Oct 14, 2003 at 10:44:14PM +0200, Oldach, Helge wrote: > From: Richard Tobin [mailto:richard@cogsci.ed.ac.uk] > > > Ok, GEOM Gate is ready for testing. > > > For those who don't know what it is, they can read README: > > > > Aaargh! It's the return of nd(4) from SunOS. > > Excuse me? > > # uname -a > SunOS galaxy 4.1.4 18 sun4m Too new.. > # man nd > No manual entry for nd. > # -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 15 00:28:57 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0E0316A4B3; Wed, 15 Oct 2003 00:28:57 -0700 (PDT) Received: from razorbill.mail.pas.earthlink.net (razorbill.mail.pas.earthlink.net [207.217.121.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EBC043FAF; Wed, 15 Oct 2003 00:28:57 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfnc7.dialup.mindspring.com ([165.247.221.135] helo=mindspring.com) by razorbill.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1A9g5W-00041m-00; Wed, 15 Oct 2003 00:28:54 -0700 Message-ID: <3F8CF70C.4CF8B00A@mindspring.com> Date: Wed, 15 Oct 2003 00:28:12 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Wilko Bulte References: <20031014210522.GA57718@freebie.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a40b3bd6996f196cc36ff3a4ccf9e725a7387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: "Oldach, Helge" cc: freebsd-current@freebsd.org Subject: Re: GEOM Gate. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2003 07:28:58 -0000 Wilko Bulte wrote: > On Tue, Oct 14, 2003 at 10:44:14PM +0200, Oldach, Helge wrote: > > From: Richard Tobin [mailto:richard@cogsci.ed.ac.uk] > > > > Ok, GEOM Gate is ready for testing. > > > > For those who don't know what it is, they can read README: > > > > > > Aaargh! It's the return of nd(4) from SunOS. > > > > Excuse me? > > > > # uname -a > > SunOS galaxy 4.1.4 18 sun4m > > Too new.. Yeah... Think Sun2 systems.... http://www.netbsd.org/Documentation/network/netboot/nd.html -- Terry From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 15 01:04:01 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 483F216A4B3; Wed, 15 Oct 2003 01:04:01 -0700 (PDT) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22AB843FAF; Wed, 15 Oct 2003 01:03:59 -0700 (PDT) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtpzilla1.xs4all.nl (8.12.9/8.12.9) with ESMTP id h9F83ujo001999; Wed, 15 Oct 2003 10:03:56 +0200 (CEST) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.9p1/8.12.9) with ESMTP id h9F83uPq093524; Wed, 15 Oct 2003 10:03:56 +0200 (CEST) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.9p1/8.12.9/Submit) id h9F83u4K093523; Wed, 15 Oct 2003 10:03:56 +0200 (CEST) (envelope-from wkb) Date: Wed, 15 Oct 2003 10:03:56 +0200 From: Wilko Bulte To: Terry Lambert Message-ID: <20031015080356.GA93493@freebie.xs4all.nl> References: <20031014210522.GA57718@freebie.xs4all.nl> <3F8CF70C.4CF8B00A@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F8CF70C.4CF8B00A@mindspring.com> User-Agent: Mutt/1.4.1i X-OS: FreeBSD 4.9-PRERELEASE X-PGP: finger wilko@freebsd.org cc: freebsd-hackers@freebsd.org cc: "Oldach, Helge" cc: freebsd-current@freebsd.org Subject: Re: GEOM Gate. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2003 08:04:01 -0000 On Wed, Oct 15, 2003 at 12:28:12AM -0700, Terry Lambert wrote: > Wilko Bulte wrote: > > On Tue, Oct 14, 2003 at 10:44:14PM +0200, Oldach, Helge wrote: > > > From: Richard Tobin [mailto:richard@cogsci.ed.ac.uk] > > > > > Ok, GEOM Gate is ready for testing. > > > > > For those who don't know what it is, they can read README: > > > > > > > > Aaargh! It's the return of nd(4) from SunOS. > > > > > > Excuse me? > > > > > > # uname -a > > > SunOS galaxy 4.1.4 18 sun4m > > > > Too new.. > > Yeah... Think Sun2 systems.... > > http://www.netbsd.org/Documentation/network/netboot/nd.html /me fondly remembers the hacked-up backplane in the Sun2/170 to allow it to use 7 1MB RAM cards.. -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 15 01:55:02 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 729) id 6FF5416A4BF; Wed, 15 Oct 2003 01:55:02 -0700 (PDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Bruce M Simpson In-Reply-To: Your message of "Mon, 13 Oct 2003 20:32:58 +0100." <20031013193258.GB25160@saboteur.dek.spc.org> Mime-Version: 1.0 Content-Type: text/plain Message-Id: <20031015085502.6FF5416A4BF@hub.freebsd.org> Date: Wed, 15 Oct 2003 01:55:02 -0700 (PDT) From: jkoshy@FreeBSD.ORG (Joseph Koshy) cc: freebsd-hackers@freebsd.org Subject: Re: Determining CPU features / cache organization from userland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2003 08:55:02 -0000 Hi Bruce, A few thoughts on your API: 1) Rather than naming the struct's as "l1", "l2" etc, it may be more orthogonal to use an array of cache entries like so struct entry { ... } entries[MAX_ENTRIES]; where MAX_ENTRIES would be say, 8. 2) We could pass information back about whether the cache is write-back or write-through and whether it uses write-allocate. In some CPUs (e.g. the AMD K6-2) this aspect of the cache is programmable at boot time. 3) Have a bit indicating whether the cache is indexed virtually or physically. This allows us to describe TLBs and caches using the same descriptor; the MIPS R4K used virtually addressed L1 caches, IIRC. 4) For caches and TLBs that support variable line/page sizes, we would be reporting the currently programmed size (the kernel knows this information) I guess? The 'type' field of the cache descriptor could be an `u_int32_t' or `u_int16_t', allocated out as follows: kind: tlb/cache/other 2 bits addressing: virtual/physical/unknown 2 bits mode: data/instruction/both/unknown 2 bits distance: L0/L1/L2/whatever 3 bits on-write-hit: write-back/write-thru/unknown 2 bits on-write-miss: write-allocate/unknown 2 bits Another suggestion I have is that the sysctl return: int n_entries; struct entry entries[n_entries]; since it isn't clear how many levels of cache and how many kinds of TLBs are going to be used in the systems of tomorrow. Regards, Koshy From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 15 02:59:29 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52AC616A4B3; Wed, 15 Oct 2003 02:59:29 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A64D43FA3; Wed, 15 Oct 2003 02:59:28 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 7EDC42ED43C; Wed, 15 Oct 2003 02:59:28 -0700 (PDT) Date: Wed, 15 Oct 2003 02:59:28 -0700 From: Alfred Perlstein To: hackers@freebsd.org Message-ID: <20031015095928.GC99943@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i cc: yokota@freebsd.org Subject: [patch] psm hacks for kvm problems. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2003 09:59:29 -0000 I was getting fustrated with the effect my KVM was having on my PS/2 mouse, basically after switching to the FreeBSD box I was getting random mouse movement for a second or two including button clicks as the kvm "settled". Windows doesn't have this problem. I have some hacks here that get me close to a solution but not all the way there. This change signifigantly reduces the "jitter" by detecting when we get out of sync and just dropping data for two seconds (tunable via sysctl). I also tried to get the mouse status if there has been no activity for more than two seconds however this doesn't seem to work. I still get an initial jitter. Does anyone have any suggestions how I could ask the mouse "are you ok" from within the context of the interrupt routine? If I could do that reliably (check to make sure mouse is sane) then I could get rid of the jitter entirely. thank you. Index: psm.c =================================================================== RCS file: /home/ncvs/src/sys/isa/psm.c,v retrieving revision 1.61 diff -u -r1.61 psm.c --- psm.c 12 Jul 2003 18:36:04 -0000 1.61 +++ psm.c 15 Oct 2003 09:43:58 -0000 @@ -74,6 +74,7 @@ #include #include #include +#include #include #include @@ -99,7 +100,7 @@ #endif #ifndef PSM_INPUT_TIMEOUT -#define PSM_INPUT_TIMEOUT 2000000 /* 2 sec */ +#define PSM_INPUT_TIMEOUT 500000 /* .5 sec */ #endif /* end of driver specific options */ @@ -158,7 +159,9 @@ int xold; /* previous absolute X position */ int yold; /* previous absolute Y position */ int syncerrors; - struct timeval inputtimeout; + struct timeval inputtimeout; /* max delay between bytes per packet */ + struct timeval syncholdtime; /* how long to backoff when sync error */ + struct timeval lastvalid; /* last valid packet time */ int watchdog; /* watchdog timer flag */ struct callout_handle callout; /* watchdog timer call out */ dev_t dev; @@ -1951,6 +1954,15 @@ sc->callout = timeout(psmtimeout, (void *)(uintptr_t)sc, hz); } +static int syncholdtime = 2; +static int lastvalidthresh = 2; + +SYSCTL_NODE(_hw, OID_AUTO, psm, CTLFLAG_RD, 0, "ps/2 mouse"); +SYSCTL_INT(_hw_psm, OID_AUTO, syncholdtime, CTLFLAG_RW, &syncholdtime, 0, + "block mouse input when out of sync for this long."); +SYSCTL_INT(_hw_psm, OID_AUTO, lastvalidthresh, CTLFLAG_RW, &lastvalidthresh, 0, + "time between packets to check for status."); + static void psmintr(void *arg) { @@ -1980,11 +1992,12 @@ }; register struct psm_softc *sc = arg; mousestatus_t ms; - struct timeval tv; + struct timeval tv, tv2; int x, y, z; int c; int l; int x0, y0; + int stat[3]; /* read until there is nothing to read */ while((c = read_aux_data_no_wait(sc->kbdc)) != -1) { @@ -2018,6 +2031,14 @@ if ((c & sc->mode.syncmask[0]) != sc->mode.syncmask[1]) { log(LOG_DEBUG, "psmintr: out of sync (%04x != %04x).\n", c & sc->mode.syncmask[0], sc->mode.syncmask[1]); + /* + * When we get out of sync record when it happened so that + * we can temporarily turn off data until we're back in sync + * for 'syncholdtime' seconds. + */ + sc->syncholdtime.tv_sec = syncholdtime; + sc->syncholdtime.tv_usec = 0; + timevaladd(&sc->syncholdtime, &tv); ++sc->syncerrors; if (sc->syncerrors < sc->mode.packetsize) { log(LOG_DEBUG, "psmintr: discard a byte (%d).\n", sc->syncerrors); @@ -2038,6 +2059,28 @@ } continue; } + + /* + * Are we still possibly resyncing? + */ + if (timevalcmp(&tv, &sc->syncholdtime, <)) { + sc->inputbytes = 0; + continue; + } + /* If more than 2 seconds have gone by since the last packet + * then make sure our mouse is alright. + */ + tv2.tv_sec = lastvalidthresh; + tv2.tv_usec = 0; + timevaladd(&tv2, &sc->lastvalid); + if (timevalcmp(&tv2, &tv, <) && + get_mouse_status(sc->kbdc, stat, 0, 3) < 3) { + log(LOG_DEBUG, "psm%d: failed to get status (psmintr).\n", + sc->unit); + sc->inputbytes = 0; + continue; + } + sc->lastvalid = tv; /* * A kludge for Kensington device! -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684 From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 15 05:47:13 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3A2A16A4B3 for ; Wed, 15 Oct 2003 05:47:13 -0700 (PDT) Received: from www.kjkoster.org (213-84-106-195.adsl.xs4all.nl [213.84.106.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 650E243F3F for ; Wed, 15 Oct 2003 05:47:11 -0700 (PDT) (envelope-from kjkoster@kjkoster.org) Received: from kjkoster.org (LikeEver [192.168.0.1]) by www.kjkoster.org (8.12.9p2/8.12.9) with ESMTP id h9FCl7uO008948; Wed, 15 Oct 2003 14:47:07 +0200 (CEST) (envelope-from kjkoster@kjkoster.org) Sender: kjkoster@www.kjkoster.org Message-ID: <3F8D41CB.F4309999@kjkoster.org> Date: Wed, 15 Oct 2003 14:47:07 +0200 From: Kees Jan Koster X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: FreeBSD Hackers mailing list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: kjkoster@kjkoster.org Subject: Crash 4.9-RC during heavy I/O, crashdump available. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2003 12:47:13 -0000 Dear All, My workstation went down today. Thanks to Michael Lucas' article I was prepared and could get you guys a crash dump. You will find it inline just after my signature. My system goes down like this occasionally (about once a month) and it is always during heavy I/O. This time I was rebuilding some code in a personal project and doing a port rebuild for the JDK 1.4 port. Both lean quite hard on the disks. As extra datapoint: the raid set and disks (ar0, ad4 and ad6) are not used at the moment, so they have not contributed to this panic. Also interesting to notice that my mainboard does not reset its memory, so that I have a dmesg for the entire day, not just for this session. If you'd like more information on this crash, please feel free to ask. Yours, Kees Jan --------------------------------------------------------------- Kees Jan Koster e-mail: kjkoster "at" kjkoster.org www: http://www.kjkoster.org/ --------------------------------------------------------------- Life is uncertain; eat dessert first. Script started on Wed Oct 15 14:32:53 2003 LikeEver# gdb -k kernel.debug.20031004 vmcore.1 GNU gdb 4.18 (FreeBSD) Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 2627 in elfstab_build_psymtabs Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 933 in fill_symbuf IdlePTD at phsyical address 0x00411000 initial pcb at physical address 0x0031e8e0 panicstr: ffs_write: dir write panic messages: --- panic: ffs_write: dir write syncing disks... 230 107 84 77 44 37 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 giving up on 3 buffers Uptime: 1h44m18s dumping to dev #ad/0x40011, offset 7077764 dump ata1: resetting devices .. done 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 258 257 25 6 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 487 if (dumping++) { (kgdb) where #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 #1 0xc0164a73 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316 #2 0xc0164eb1 in panic (fmt=0xc02b7ae2 "%s: dir write") at /usr/src/sys/kern/kern_shutdown.c:595 #3 0xc0209857 in ffs_write (ap=0xd7857d94) at /usr/src/sys/ufs/ufs/ufs_readwrite.c:449 #4 0xc021fd73 in vnode_pager_generic_putpages (vp=0xd606b6c0, m=0xd7857ea4, bytecount=4096, flags=0, rtvals=0xd7857e38) at vnode_if.h:363 #5 0xc020a126 in ffs_putpages (ap=0xd7857dfc) at /usr/src/sys/ufs/ufs/ufs_readwrite.c:755 #6 0xc021fb96 in vnode_pager_putpages (object=0xd62ea170, m=0xd7857ea4, count=1, sync=0, rtvals=0xd7857e38) at vnode_if.h:1147 #7 0xc021cb14 in vm_pageout_flush (mc=0xd7857ea4, count=1, flags=0) at /usr/src/sys/vm/vm_pager.h:147 #8 0xc021ca7c in vm_pageout_clean (m=0xc0e70dc8) at /usr/src/sys/vm/vm_pageout.c:342 #9 0xc021d3d4 in vm_pageout_scan (pass=0) at /usr/src/sys/vm/vm_pageout.c:936 #10 0xc021dcf7 in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:1405 (kgdb) ^D LikeEver# uname -a FreeBSD LikeEver.kjkoster.org 4.9-RC FreeBSD 4.9-RC #51: Fri Oct 3 23:13:50 CEST 2003 kjkoster@LikeEver.kjkoster.org:/usr/obj/usr/src/sys/LIKEEVER i386 LikeEver# dmesg Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.9-RC #51: Fri Oct 3 23:13:50 CEST 2003 kjkoster@LikeEver.kjkoster.org:/usr/obj/usr/src/sys/LIKEEVER Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 1538815339 Hz CPU: AMD Athlon(tm) XP 1800+ (1538.82-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc0480000 real memory = 536805376 (524224K bytes) avail memory = 518283264 (506136K bytes) Preloaded elf kernel "kernel" at 0xc03f2000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc03f209c. Preloaded elf module "splash_bmp.ko" at 0xc03f20ec. Preloaded splash_image_data "/boot/splash.bmp" at 0xc03f2190. VESA: v3.0, 16128k memory, flags:0x1, mode table:0xc0334fc2 (1000022) VESA: NVidia Pentium Pro MTRR support enabled Using $PIR table, 10 entries at 0xc00f7ea0 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 irq 11 ncr0: port 0xd800-0xd8ff mem 0xdffcff00-0xdffcffff irq 10 at device 6.0 on pci0 fxp0: port 0xd400-0xd41f mem 0xdfe00000-0xdfefffff,0xdd9ff000-0xdd9fffff irq 5 at device 8.0 on pci0 fxp0: Ethernet address 00:e0:18:00:2f:22 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ohci0: mem 0xdffcd000-0xdffcdfff irq 11 at device 11.0 on pci0 usb0: OHCI version 1.0 usb0: on ohci0 usb0: USB revision 1.0 uhub0: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xdffce000-0xdffcefff irq 10 at device 11.1 on pci0 usb1: OHCI version 1.0 usb1: on ohci1 usb1: USB revision 1.0 uhub1: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: at 11.2 irq 10 atapci0: port 0xdc00-0xdc3f,0xe000-0xe003,0xe400-0xe407,0xe800-0xe803,0xec00-0xec07 mem 0xdffe0000-0xdfffffff irq 10 at device 12.0 on pci0 ata2: at 0xec00 on atapci0 ata3: at 0xe400 on atapci0 isab0: at device 17.0 on pci0 isa0: on isab0 atapci1: port 0xfc00-0xfc0f at device 17.1 on pci0 ata0: at 0x1f0 irq 14 on atapci1 ata1: at 0x170 irq 15 on atapci1 pcm0: port 0xd000-0xd0ff irq 10 at device 17.5 on pci0 pcm0: isa0: too many memory ranges orm0: