From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 26 22:55:22 2005 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 0CE4B16A4CE for ; Sat, 26 Mar 2005 22:55:22 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [83.167.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BF5143D46 for ; Sat, 26 Mar 2005 22:55:21 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 1D2D665211; Sat, 26 Mar 2005 22:52:14 +0000 (GMT) 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 44160-04-2; Sat, 26 Mar 2005 22:52:13 +0000 (GMT) Received: from empiric.dek.spc.org (66-117-149-249.rdsl.lmi.net [66.117.149.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id EC1BB651F7; Sat, 26 Mar 2005 22:52:09 +0000 (GMT) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 378AB6893; Sat, 26 Mar 2005 14:55:09 -0800 (PST) Date: Sat, 26 Mar 2005 14:55:09 -0800 From: Bruce M Simpson To: Bao Zhao Message-ID: <20050326225508.GA715@empiric.icir.org> Mail-Followup-To: Bao Zhao , freebsd-hackers References: <20050326174436.59757.qmail@web31701.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050326174436.59757.qmail@web31701.mail.mud.yahoo.com> cc: freebsd-hackers Subject: Re: relation between PQ_CACHESIZE and PQ_L2_SIZE 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: Sat, 26 Mar 2005 22:55:22 -0000 On Sat, Mar 26, 2005 at 09:44:36AM -0800, Bao Zhao wrote: > some think it is 4-way set associative,but I think it > is the page's size-4KB. > > If I'm right, How BSD deals with 8KB page size? Please search this list's archives as there's a thread on this from a few years back (I was one of the protagonists). BMS From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 02:12:29 2005 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 5C7E616A4CE for ; Sun, 27 Mar 2005 02:12:29 +0000 (GMT) Received: from web31710.mail.mud.yahoo.com (web31710.mail.mud.yahoo.com [68.142.201.190]) by mx1.FreeBSD.org (Postfix) with SMTP id EB5C643D48 for ; Sun, 27 Mar 2005 02:12:28 +0000 (GMT) (envelope-from baozhaolinuxer@yahoo.com) Received: (qmail 84360 invoked by uid 60001); 27 Mar 2005 02:12:28 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=n++2O2J/IAAiea3xKBcT/STtuD8UN2aYu6KBHJWwoM7M4Wu8csnWG+cpXyEO2wHh6w6b/9X8dGFAIBWJdz59MzBizT+NdtAB6XHCQ/uQwiDBkyTZr6/mmXJgKDZobZXN8B5L+ifi/q+XHwYbsucpFpj0DptzB3977HVJIcW5ojM= ; Message-ID: <20050327021228.84358.qmail@web31710.mail.mud.yahoo.com> Received: from [218.75.247.252] by web31710.mail.mud.yahoo.com via HTTP; Sat, 26 Mar 2005 18:12:28 PST Date: Sat, 26 Mar 2005 18:12:28 -0800 (PST) From: Bao Zhao To: Bruce M Simpson In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-hackers@freebsd.org Subject: Re: relation between PQ_CACHESIZE and PQ_L2_SIZE 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, 27 Mar 2005 02:12:29 -0000 --- Bruce M Simpson wrote: > On Sat, Mar 26, 2005 at 09:44:36AM -0800, Bao Zhao > wrote: > > some think it is 4-way set associative,but I think > it > > is the page's size-4KB. > > > > If I'm right, How BSD deals with 8KB page size? > > Please search this list's archives as there's a > thread on this from a > few years back (I was one of the protagonists). > > BMS > Yes, I have searched the archives before I asked the question.see below: http://lists.freebsd.org/mailman/htdig/freebsd-hackers/2003-June/001655.html But what puzzled me is : why not page size is a factor when calculating the number of colors? Best Regard Bao Zhao __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 03:08:36 2005 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 B4E2316A4CE for ; Sun, 27 Mar 2005 03:08:36 +0000 (GMT) Received: from f31.mail.ru (f31.mail.ru [194.67.57.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FA0943D39 for ; Sun, 27 Mar 2005 03:08:36 +0000 (GMT) (envelope-from shmukler@mail.ru) Received: from mail by f31.mail.ru with local id 1DFO8g-000CQA-00; Sun, 27 Mar 2005 07:08:34 +0400 Received: from [24.185.245.215] by win.mail.ru with HTTP; Sun, 27 Mar 2005 07:08:34 +0400 From: Igor Shmukler To: Bao Zhao Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [24.185.245.215] Date: Sun, 27 Mar 2005 07:08:34 +0400 In-Reply-To: <20050327021228.84358.qmail@web31710.mail.mud.yahoo.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: cc: freebsd-hackers@freebsd.org Subject: Re[2]: relation between PQ_CACHESIZE and PQ_L2_SIZE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Igor Shmukler List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2005 03:08:36 -0000 > http://lists.freebsd.org/mailman/htdig/freebsd-hackers/2003-June/001655.html > But what puzzled me is : why not page size is a > factor when calculating the number of colors? Page coloring in freebsd was implemented by John Dyson. It is needed to better utilize the cache. Depending on cache's implementation fully-associative vs. 4-way vs 2-way etc you might have problems. A subset of bits (low-bits) from the page frame's (physical) address tells us where can data be stored in processor cache. We want a relatively equal distribution of these "colors" so that we utilize as much of cache real estate as possible. Hence, we are interested in the size of a set, not size of a page. I am sure, there are whole bunch of articles written about this. I could give you some pointers offline. Igor. From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 05:23:52 2005 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 79E3E16A4CE for ; Sun, 27 Mar 2005 05:23:52 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2D7543D3F for ; Sun, 27 Mar 2005 05:23:51 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j2R5NPda059496; Sat, 26 Mar 2005 22:23:25 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 26 Mar 2005 22:23:56 -0700 (MST) Message-Id: <20050326.222356.39639083.imp@bsdimp.com> To: marks@ripe.net From: "M. Warner Losh" In-Reply-To: <20050326011351.GE659@laptop.santcroos.net> References: <20050326011351.GE659@laptop.santcroos.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: axe CPU_UPGRADE_HW_CACHE from i386 specific 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, 27 Mar 2005 05:23:52 -0000 In message: <20050326011351.GE659@laptop.santcroos.net> Mark Santcroos writes: : It looks like CPU_UPGRADE_HW_CACHE is only used in PC98, so it can be : removed from all I386 specific code. : : Any objections to the following patch? This does appear to be a pc98 only item. A grep of the tree shows this to be the clase. However, there's more opportunity here for cleanup. One can easily move nearly all the PC98 code out of initcpu. First, there's some redudant code: In initcput.c we see: static void init_bluelightning(void) { u_long eflags; #if defined(PC98) && !defined(CPU_UPGRADE_HW_CACHE) need_post_dma_flush = 1; #endif ... but we also see: #if defined(PC98) && !defined(CPU_UPGRADE_HW_CACHE) ... } else if (strcmp(cpu_vendor, "IBM") == 0) { need_post_dma_flush = 1; ... #endif So, we set it once in init_bluelightning, and again at the tail end of initialize cpu. So that code should be just eliminated, unless I've missed something subtle in my analysis of the code. In addition, one can easily add the CPU_I486_ON_386 tests to the same code at the end of initializecpu(). In fact, it may already be there, or there may be a bug: #ifdef CPU_I486_ON_386 case CPU_486: init_i486_on_386(); break; #endif vs case CPU_CY486DX: need_pre_dma_flush = 1; #ifdef CPU_I486_ON_386 need_post_dma_flush = 1; #endif break; Note that the comments say that this flushing is necessary for non-intel hardware only, yet CPU_486 is a true intel part. At the very least, the ifdef code in init_i486_on_386 can be eliminated, since it appears redudant with code later on: } else { #ifdef CPU_I486_ON_386 need_pre_dma_flush = 1; #endif This makes the code fairly well contained, and it could be convered to a function an placed somehere appropriate in pc98/pc98, maybe pc98_machine.c? This would localize the use of the need_{pre,post}_dma_flush variables to pc98/pc98 (well, and one instance in dev/ct, which doesn't call the standard DMA complete routines, but I've not investigated further). This would shrink the size of the ifdefs down to a single one-liner... Warner From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 26 17:27:06 2005 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 B24A016A4CE for ; Sat, 26 Mar 2005 17:27:06 +0000 (GMT) Received: from mailtest.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id 348AA43D46 for ; Sat, 26 Mar 2005 17:27:04 +0000 (GMT) (envelope-from fcash-ml@sd73.bc.ca) Received: from localhost (localhost [127.0.0.1]) by mailtest.sd73.bc.ca (Postfix) with ESMTP id 87EBCF2F9A; Sat, 26 Mar 2005 09:27:05 -0800 (PST) Received: from mailtest.sd73.bc.ca ([127.0.0.1]) by localhost (mailtest.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14505-01-54; Sat, 26 Mar 2005 09:27:04 -0800 (PST) Received: by mailtest.sd73.bc.ca (Postfix, from userid 80) id 6246AF2F99; Sat, 26 Mar 2005 09:27:04 -0800 (PST) Received: from 24.71.128.63 (SquirrelMail authenticated user fcash); by mailtest.sd73.bc.ca with HTTP; Sat, 26 Mar 2005 09:27:04 -0800 (PST) Message-ID: <61442.24.71.128.63.1111858024.squirrel@24.71.128.63> In-Reply-To: <200503260308.j2Q38w2D053744@localhost.cpsc.ucalgary.ca> References: <200503260308.j2Q38w2D053744@localhost.cpsc.ucalgary.ca> Date: Sat, 26 Mar 2005 09:27:04 -0800 (PST) From: "Freddie Cash" To: "Jie Gao" User-Agent: SquirrelMail/1.5.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new using ClamAV at sd73.bc.ca X-Mailman-Approved-At: Sun, 27 Mar 2005 12:55:18 +0000 cc: hackers@freebsd.org Subject: Re: Kpdf and -march=pentium4? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: fcash-ml@sd73.bc.ca List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2005 17:27:06 -0000 > I noticed that while making kdegraphics from ports, if > "-march=pentium4" is in the compiler flags, I will finally get a > non-working kpdf. It compiles fine but when I try to open a pdf > file, kdpf will core dupm. But a kpdf compiled without > "-march=pentium4" will work just fine. > For this reason, should we put something in kdegraphics3's Makefile > to prevent a bad kdpf? E.g. a patch like this: kdegraphics3 compiled with CPUTYPE=p4, CGLAGS=-Os -pipe -fno-strict-aliasing works fine here. Worked with KDE 3.3.x, and still works with KDE 3.4. I've tested it with small PDFs (2 or 3 pages) and large PDFs (30+ pages), and everything works fine for me. -- Freddie Cash, CCNT CCLP Helpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] fcash-ml@sd73.bc.ca From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 26 21:31:47 2005 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 D6BA416A4CE; Sat, 26 Mar 2005 21:31:47 +0000 (GMT) Received: from mail2.dreamscape.com (mail2.dreamscape.com [206.64.128.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CB4643D1D; Sat, 26 Mar 2005 21:31:47 +0000 (GMT) (envelope-from krentel@dreamscape.com) Received: from blue.mwk.domain (syr-mdm-03-216-171-177-59.dreamscape.com [216.171.177.59])j2QLVht7018736; Sat, 26 Mar 2005 16:31:45 -0500 (EST) Received: from blue.mwk.domain (localhost [127.0.0.1]) by blue.mwk.domain (8.13.1/8.13.1) with ESMTP id j2QLWuJo074028; Sat, 26 Mar 2005 16:33:00 -0500 (EST) (envelope-from krentel@blue.mwk.domain) Message-Id: <200503262133.j2QLWuJo074028@blue.mwk.domain> To: green@freebsd.org Date: Sat, 26 Mar 2005 16:32:56 -0500 From: "Mark W. Krentel" X-Mailman-Approved-At: Sun, 27 Mar 2005 12:55:18 +0000 cc: freebsd-hackers@freebsd.org Subject: Re: contributing to fbsd 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: Sat, 26 Mar 2005 21:31:48 -0000 > The VM map algorithms are the same as ever, though. They use linear > traversal along with a cached reference to the last lookup. There > are certainly some workloads that should benefit from this, so it > definitely could be something you could work on. Not any more. The first_free hint was replaced by an O(log n) algorithm built into the splay tree back in August 2004. See rev. 1.357 of vm_map.c. --Mark From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 26 22:46:41 2005 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 27CE116A4CE for ; Sat, 26 Mar 2005 22:46:41 +0000 (GMT) Received: from ensc.cpsc.ucalgary.ca (ensc.cpsc.ucalgary.ca [136.159.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B383143D2D for ; Sat, 26 Mar 2005 22:46:40 +0000 (GMT) (envelope-from gaoj@cpsc.ucalgary.ca) Received: from imgw1.cpsc.ucalgary.ca (imgw1 [136.159.5.9]) j2QMhOeM021979; Sat, 26 Mar 2005 15:43:24 -0700 Received: from localhost (localhost [127.0.0.1])j2QMhOJi000732; Sat, 26 Mar 2005 15:43:24 -0700 Received: from imgw1.cpsc.ucalgary.ca ([127.0.0.1]) by localhost (imgw1 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32728-05; Sat, 26 Mar 2005 15:43:24 -0700 (MST) Received: from aibsd (sana-sa [136.159.7.231])j2QMhK4l000726; Sat, 26 Mar 2005 15:43:20 -0700 From: Jie Gao Organization: University of Calgary To: fcash-ml@sd73.bc.ca Date: Sat, 26 Mar 2005 15:43:18 -0700 User-Agent: KMail/1.8 References: <200503260308.j2Q38w2D053744@localhost.cpsc.ucalgary.ca> <61442.24.71.128.63.1111858024.squirrel@24.71.128.63> In-Reply-To: <61442.24.71.128.63.1111858024.squirrel@24.71.128.63> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503261543.19723.gaoj@cpsc.ucalgary.ca> X-Virus-Scanned: by amavisd-new at cpsc.ucalgary.ca X-Spam-Status: No, hits=-1.2 required=6.8 X-Spam-Level: X-Mailman-Approved-At: Sun, 27 Mar 2005 12:55:18 +0000 cc: hackers@freebsd.org Subject: Re: Kpdf and -march=pentium4? 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: Sat, 26 Mar 2005 22:46:41 -0000 Well, I had -O2 with -march=pentium4. Maybe that's the reason of different results. On March 26, 2005 10:27 am, Freddie Cash wrote: > > kdegraphics3 compiled with CPUTYPE=p4, CGLAGS=-Os -pipe > -fno-strict-aliasing works fine here. Worked with KDE 3.3.x, and > still works with KDE 3.4. > > I've tested it with small PDFs (2 or 3 pages) and large PDFs (30+ > pages), and everything works fine for me. From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 11:31:03 2005 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 BB28016A4CE for ; Sun, 27 Mar 2005 11:31:03 +0000 (GMT) Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D45143D1F for ; Sun, 27 Mar 2005 11:31:03 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd31.aul.t-online.de by mailout01.sul.t-online.com with smtp id 1DFVyw-0002K3-01; Sun, 27 Mar 2005 13:31:02 +0200 Received: from Andro-Beta.Leidinger.net (rIFiH4ZBZeq2nXDnY5Oh4l1kJg03jW-ItokO-g0hmPzt6mPh1dbIUP@[217.229.215.79]) by fwd31.sul.t-online.de with esmtp id 1DFVyu-0IWbHk0; Sun, 27 Mar 2005 13:31:00 +0200 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) j2RBTckZ032444; Sun, 27 Mar 2005 13:29:38 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Sun, 27 Mar 2005 13:30:59 +0200 From: Alexander Leidinger To: Attila Nagy Message-ID: <20050327133059.3d68a78c@Magellan.Leidinger.net> In-Reply-To: <423C15C5.6040902@fsn.hu> References: <423C15C5.6040902@fsn.hu> X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: rIFiH4ZBZeq2nXDnY5Oh4l1kJg03jW-ItokO-g0hmPzt6mPh1dbIUP@t-dialin.net X-TOI-MSGID: cca4aa78-2afd-452f-a095-0cb35757ce05 X-Mailman-Approved-At: Sun, 27 Mar 2005 12:55:44 +0000 cc: hackers@freebsd.org Subject: Re: 5-STABLE kernel build with icc broken 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, 27 Mar 2005 11:31:03 -0000 On Sat, 19 Mar 2005 13:06:29 +0100 Attila Nagy wrote: > It seems to me that building kernel with icc is currently broken, at > least in 5-STABLE. Could somebody investigate this? I don't have a problem to compile it with a recent -current and a recent icc (-stable not tested), but the resulting kernel imediatly panics (page fault in _mtx_...()). Bye, Alexander. -- It's not a bug, it's tradition! http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 13:05:23 2005 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 17CF716A4CF; Sun, 27 Mar 2005 13:05:23 +0000 (GMT) Received: from f12.mail.ru (f12.mail.ru [194.67.57.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3B9543D31; Sun, 27 Mar 2005 13:05:22 +0000 (GMT) (envelope-from shmukler@mail.ru) Received: from mail by f12.mail.ru with local id 1DFXSH-000HDU-00; Sun, 27 Mar 2005 17:05:25 +0400 Received: from [24.185.245.215] by win.mail.ru with HTTP; Sun, 27 Mar 2005 17:05:25 +0400 From: Igor Shmukler To: Matthew Dillon Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [24.185.245.215] Date: Sun, 27 Mar 2005 17:05:25 +0400 In-Reply-To: <200502212147.j1LLlP7n010674@apollo.backplane.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: cc: hackers@freebsd.org cc: rwatson@freebsd.org Subject: name cache (was Re[4]: vn_fullpath()) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Igor Shmukler List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2005 13:05:23 -0000 Hi, Sorry for reopening an old thread. I am doing this because last time around I was unaware of some issues. There are more corner cases/issues with vn_fullpath() and possibly the name cache. Please correct me if I am wrong. Perhaps, I would even personally look into fixing these, but I would like to know everyone agrees that this is needed. 1. vn_fullpath() does not return names for VCHR vnodes. I think it would be handy if this was possible. 2. It appears that vn_fullpath() has problems with FD 0..2. [It even seems to happen regardless whether file descriptors were inherited or open via $foo >my.file] I am under the impression that Linux d_path() does these things. Is there an agreement that this a problem and it would be benefitial to have vn_fullpath() [and name cache] behave in a "proper" way? Where does dragonfly stand on this? Thank you, Igor > :I seem to recall that DragonFly keeps the intermediate nodes. > > There's no way to backport that, it would be hundreds of man hours of > work. DragonFly uses a totally different namecache topology now, one > that is mandatory and which guarentees the existance of intermediate > nodes. > > You'd have to implement something similar to libc's getcwd code. e.g. > ".." through and scan each directory to find the matching inode if > the namecache entry is not present. It actually wouldn't be too hard > to do. It wouldn't be efficient, but vn_fullpath() is rarely used > so it shouldn't be a problem. From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 13:40:48 2005 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 0256916A4CE for ; Sun, 27 Mar 2005 13:40:48 +0000 (GMT) Received: from keylime.silverwraith.com (keylime.silverwraith.com [69.55.228.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCC1B43D39 for ; Sun, 27 Mar 2005 13:40:47 +0000 (GMT) (envelope-from lists-freebsd@silverwraith.com) Received: from keylime.silverwraith.com ([69.55.228.10]) by keylime.silverwraith.com with esmtp (Exim 4.41 (FreeBSD)) id 1DFY0V-000Lxd-6x; Sun, 27 Mar 2005 05:40:47 -0800 Received: (from avleen@localhost)j2RDeiRg084408; Sun, 27 Mar 2005 05:40:44 -0800 (PST) (envelope-from lists-freebsd@silverwraith.com) X-Authentication-Warning: keylime.silverwraith.com: avleen set sender to lists-freebsd@silverwraith.com using -f Date: Sun, 27 Mar 2005 05:40:44 -0800 From: Avleen Vig To: Alexander Leidinger Message-ID: <20050327134044.GM78512@silverwraith.com> References: <423C15C5.6040902@fsn.hu> <20050327133059.3d68a78c@Magellan.Leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050327133059.3d68a78c@Magellan.Leidinger.net> User-Agent: Mutt/1.5.6i cc: hackers@freebsd.org Subject: Re: 5-STABLE kernel build with icc broken 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, 27 Mar 2005 13:40:48 -0000 On Sun, Mar 27, 2005 at 01:30:59PM +0200, Alexander Leidinger wrote: > > It seems to me that building kernel with icc is currently broken, at > > least in 5-STABLE. Could somebody investigate this? > > I don't have a problem to compile it with a recent -current and a recent > icc (-stable not tested), but the resulting kernel imediatly panics > (page fault in _mtx_...()). Without intending to start any compiler holy wars, what benefits does ICC provide over GCC for the end user? From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 13:53:48 2005 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 ADD0F16A4CE for ; Sun, 27 Mar 2005 13:53:48 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B16243D39 for ; Sun, 27 Mar 2005 13:53:48 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 6678C46B55; Sun, 27 Mar 2005 08:53:47 -0500 (EST) Date: Sun, 27 Mar 2005 13:50:41 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Igor Shmukler In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org Subject: Re: name cache (was Re[4]: vn_fullpath()) 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, 27 Mar 2005 13:53:48 -0000 On Sun, 27 Mar 2005, Igor Shmukler wrote: > Sorry for reopening an old thread. I am doing this because last time > around I was unaware of some issues. > > There are more corner cases/issues with vn_fullpath() and possibly the > name cache. Please correct me if I am wrong. Perhaps, I would even > personally look into fixing these, but I would like to know everyone > agrees that this is needed. > > 1. vn_fullpath() does not return names for VCHR vnodes. I think it would > be handy if this was possible. On FreeBSD, this occurs because devfs doesn't use the name cache. Two easy solutions are: - Use the name cache in devfs. This would have to be done carefully in the context of cloning, etc, but should work out. - Add a VOP/VFS operation to help figure out a pathname with the help of the file system, and implement it for devfs. This would avoid having to deal with cache invalidation issues in devfs. > 2. It appears that vn_fullpath() has problems with FD 0..2. [It even > seems to happen regardless whether file descriptors were inherited or > open via $foo >my.file] I'm not familiar with this issue specifically. Normally these descriptors point to tty's (unnamed due to devfs issues above) and pipes (no name), which would generally explain the issues. However, the >my.file case is a bit concerning. Could you confirm that the file descriptor in that case is definitely pointed at a vnode? > I am under the impression that Linux d_path() does these things. Is > there an agreement that this a problem and it would be benefitial to > have vn_fullpath() [and name cache] behave in a "proper" way? Linux does something a little different in how they maintain references to files -- their "struct inode" is logically equivilent to our "struct vnode", in that it's a virtualized inode. However, they have an additional structure named "struct dentry", which is a reference counted inode reference, but includes pointers into the name cache and a cached local name. The "struct file" in Linux references a dentry rather than a pure inode. This means that name information for inodes is usually immediately available to consumers, and the name cache is aware of the use of inodes and paths more explicitly. A dentry is not always present, though, but often will be when there's a process around acting explicitly on a file. Robert N M Watson > > Where does dragonfly stand on this? > > Thank you, > > Igor > > > :I seem to recall that DragonFly keeps the intermediate nodes. > > > > There's no way to backport that, it would be hundreds of man hours of > > work. DragonFly uses a totally different namecache topology now, one > > that is mandatory and which guarentees the existance of intermediate > > nodes. > > > > You'd have to implement something similar to libc's getcwd code. e.g. > > ".." through and scan each directory to find the matching inode if > > the namecache entry is not present. It actually wouldn't be too hard > > to do. It wouldn't be efficient, but vn_fullpath() is rarely used > > so it shouldn't be a problem. > > From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 14:13:01 2005 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 F27CF16A4CE for ; Sun, 27 Mar 2005 14:13:01 +0000 (GMT) Received: from vsmtp4.tin.it (vsmtp4.tin.it [212.216.176.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A5A543D5C for ; Sun, 27 Mar 2005 14:13:01 +0000 (GMT) (envelope-from gerarra@tin.it) Received: from ims3a.cp.tin.it (192.168.70.103) by vsmtp4.tin.it (7.0.027) id 423846490048D0FE for freebsd-hackers@freebsd.org; Sun, 27 Mar 2005 16:12:58 +0200 Received: from [192.168.70.227] by ims3a.cp.tin.it with HTTP; Sun, 27 Mar 2005 16:12:57 +0200 Date: Sun, 27 Mar 2005 15:12:57 +0100 Message-ID: <420008450006DC4F@ims3a.cp.tin.it> In-Reply-To: <20050327134044.GM78512@silverwraith.com> From: gerarra@tin.it To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable X-Originating-IP: 82.57.93.209 Subject: Re: 5-STABLE kernel build with icc broken 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, 27 Mar 2005 14:13:02 -0000 > >Without intending to start any compiler holy wars, what benefits does >ICC provide over GCC for the end user? > ICC would provide better low level code (remind: Intel C Compiler. It wou= ld mean better performance). rookie From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 15:31:43 2005 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 1572916A4CE; Sun, 27 Mar 2005 15:31:43 +0000 (GMT) Received: from f24.mail.ru (f24.mail.ru [194.67.57.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id A790A43D1D; Sun, 27 Mar 2005 15:31:42 +0000 (GMT) (envelope-from shmukler@mail.ru) Received: from mail by f24.mail.ru with local id 1DFZjp-000Fvk-00; Sun, 27 Mar 2005 19:31:41 +0400 Received: from [24.185.245.215] by win.mail.ru with HTTP; Sun, 27 Mar 2005 19:31:41 +0400 From: Igor Shmukler To: Robert Watson Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [24.185.245.215] Date: Sun, 27 Mar 2005 19:31:41 +0400 In-Reply-To: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: cc: hackers@freebsd.org Subject: Re[2]: name cache (was Re[4]: vn_fullpath()) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Igor Shmukler List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2005 15:31:43 -0000 > On FreeBSD, this occurs because devfs doesn't use the name cache. Two > easy solutions are: > > - Use the name cache in devfs. This would have to be done carefully in > the context of cloning, etc, but should work out. > > - Add a VOP/VFS operation to help figure out a pathname with the help of > the file system, and implement it for devfs. This would avoid having to > deal with cache invalidation issues in devfs. I would prefer whatever would be a lowest impact uniform (for different FSs) solution. I will start looking into this issue. > I'm not familiar with this issue specifically. Normally these descriptors > point to tty's (unnamed due to devfs issues above) and pipes (no name), > which would generally explain the issues. However, the >my.file case is a > bit concerning. Could you confirm that the file descriptor in that case > is definitely pointed at a vnode? I will do this. I would like to point out ( guess I was not clear the first time). That even if std[in/out/err] is VREG, not VCHR after child process inhereted this descriptor vn_fullpath() does not work. I understand that this sounds fishy, because fd simply points to vnode, but that the impression for now. If one closes a "standard" descriptor then opens a file, it does work, but seems not to survive through inheritance. I will follow-up with more information on this. Maybe, files issue for 0..2 is a just a product of imagination :) > Linux does something a little different in how they maintain references to I am aware that Linux dentry/inode/cache are different, but I was asking this for a simple (selfish) reason. If there is a concesus that d_path() like functionality [in a black-box way i.e. let's forget how it is implemented] would be very helpful, then I think if a patch was made it might be committed before 5.5 is out. In that case, I would try to work on this and/or even ask my colleagues to help with coding/testing. If this is viewed as an obscure feature that will not be included anytime soon, I would remove from my agenda for now. I thank you Robert and everyone else who spent time reading this thread and thinking about this whole issue. Thank you, Igor From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 16:09:38 2005 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 1433016A4CE for ; Sun, 27 Mar 2005 16:09:38 +0000 (GMT) Received: from web31712.mail.mud.yahoo.com (web31712.mail.mud.yahoo.com [68.142.201.192]) by mx1.FreeBSD.org (Postfix) with SMTP id A683343D1F for ; Sun, 27 Mar 2005 16:09:37 +0000 (GMT) (envelope-from baozhaolinuxer@yahoo.com) Received: (qmail 62242 invoked by uid 60001); 27 Mar 2005 16:09:37 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=vbJKzyG7QFZrI4sNRzuaInehhv2DATGz0skb1NhC5cqbNI4RPeNjS3ip7dh0YDXHEEI5BpgMgva34HlqvBNKzSPJjJ6WuFz1ocYnSSIecrtAL5SGTF3DD1QZst7/udrL/m2RZXP61qjI48s7uBMRmqMo0CyMwOtJxpWDuEcKrgk= ; Message-ID: <20050327160937.62240.qmail@web31712.mail.mud.yahoo.com> Received: from [218.75.247.252] by web31712.mail.mud.yahoo.com via HTTP; Sun, 27 Mar 2005 08:09:37 PST Date: Sun, 27 Mar 2005 08:09:37 -0800 (PST) From: Bao Zhao To: Igor Shmukler In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-hackers Subject: Re: Re[2]: relation between PQ_CACHESIZE and PQ_L2_SIZE 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, 27 Mar 2005 16:09:38 -0000 --- Igor Shmukler wrote: > > > http://lists.freebsd.org/mailman/htdig/freebsd-hackers/2003-June/001655.html > > But what puzzled me is : why not page size is > a > > factor when calculating the number of colors? > > Page coloring in freebsd was implemented by John > Dyson. It is needed to better utilize the > cache. Depending on cache's implementation > fully-associative vs. 4-way vs 2-way etc you might > have problems. > > A subset of bits (low-bits) from the page frame's > (physical) address tells us where can data be > stored in processor cache. We want a relatively > equal distribution of these "colors" so that we > utilize as much of cache real estate as possible. > Hence, we are interested in the size of a > set, not size of a page. > > I am sure, there are whole bunch of articles written > about this. I could give you some pointers > offline. > > Igor. > _______________________________________________ > 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" > I have read two papers. Both of them think page size impact the number of colorings. The first one: R.E.Kessler "page placement algorithms for large-indexed caches" excerpt from this paper , "Let N be the cache size in pages and B=N/A(A is associativity) be the number of bins" The second paper William L.Lynch "The Interaction Of Virtual Memory and Cache Memory" excerpt from this paper ,section 5.3 "The number of colors depends on the page size. As th page size increases, the number of colors decreases until the page size is equal to the cache size-per-degree-of-associative" and I find Alan Cox's post http://lists.freebsd.org/pipermail/freebsd-current/2004-June/028470.html quoted from the post "1. Cache size alone does not correctly determine the number of colors,except for direct map caches. The correct formula is (cache size in bytes / page size in bytes) / degree of cache associativity Thus, the comments would lead one to configure his/her system with too many colors. " I think Alan is right . What's you opinion? Thanks! Best Regards! Bao Zhao __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 16:40:05 2005 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 0932616A4CE; Sun, 27 Mar 2005 16:40:05 +0000 (GMT) Received: from mx3.uidaho.edu (mx3.uidaho.edu [129.101.155.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id 250C143D3F; Sun, 27 Mar 2005 16:40:04 +0000 (GMT) (envelope-from andrewr@uidaho.edu) Received: from mailA.its.uidaho.edu (mailA.its.uidaho.edu [129.101.155.252]) by mx3.uidaho.edu (8.13.1/8.13.1) with ESMTP id j2RGe3Bu004920; Sun, 27 Mar 2005 08:40:03 -0800 Received: from uidaho.edu (mailA [129.101.155.252]) by mailA.its.uidaho.edu (Go Vandals!) with ESMTP id <0IE00063WRMRS6@mailA.its.uidaho.edu>; Sun, 27 Mar 2005 08:40:03 -0800 (PST) Received: from [68.67.22.85] by mailA.its.uidaho.edu (mshttpd); Sun, 27 Mar 2005 08:40:03 -0800 Date: Sun, 27 Mar 2005 08:40:03 -0800 From: Andrew Robinson To: des@des.no (=?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=) Message-id: <11397e10fc35.10fc3511397e@uidaho.edu> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.21 (built Sep 8 2003) Content-type: text/plain; charset=iso-8859-1 Content-language: en Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: en Priority: normal X-SpamDetails: rule=notspam policy= score=0 mlx=0 adultscore=0 adjust=0 engine=2.5.0-05032500 definitions=2.5.0-05032601 X-SpamScore: 0 cc: "Kevin G. Eliuk" cc: Kevin Kinsey cc: hackers@freebsd.org cc: freebsd-hackers@freebsd.org cc: jason henson Subject: Re: NIC detected, but won't DHCP or configure 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, 27 Mar 2005 16:40:05 -0000 Thanks VERY much=2E The card works just fine now=2E Andrew ----- Original Message ----- From=3A des=40des=2Eno (Dag-Erling Sm=F8rgrav) Date=3A Wednesday=2C March 23=2C 2005 9=3A42 am Subject=3A Re=3A NIC detected=2C but won=27t DHCP or configure =3E Andrew Robinson =3Candrewr=40uidaho=2Eedu=3E writes=3A =3E =3E re=5Fprobe()=3A vid 10ec did 8169 hwrev 10000000 =3E = =3E That=27s an 8169SB=2C which is supported in -CURRENT=2E Try the atta= ched =3E patch=2E I=27ll try to get it merged before 5=2E4-RELEASE=2E =3E = =3E DES =3E -- = =3E Dag-Erling Sm=F8rgrav - des=40des=2Eno =3E = =3E From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 16:40:05 2005 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 0932616A4CE; Sun, 27 Mar 2005 16:40:05 +0000 (GMT) Received: from mx3.uidaho.edu (mx3.uidaho.edu [129.101.155.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id 250C143D3F; Sun, 27 Mar 2005 16:40:04 +0000 (GMT) (envelope-from andrewr@uidaho.edu) Received: from mailA.its.uidaho.edu (mailA.its.uidaho.edu [129.101.155.252]) by mx3.uidaho.edu (8.13.1/8.13.1) with ESMTP id j2RGe3Bu004920; Sun, 27 Mar 2005 08:40:03 -0800 Received: from uidaho.edu (mailA [129.101.155.252]) by mailA.its.uidaho.edu (Go Vandals!) with ESMTP id <0IE00063WRMRS6@mailA.its.uidaho.edu>; Sun, 27 Mar 2005 08:40:03 -0800 (PST) Received: from [68.67.22.85] by mailA.its.uidaho.edu (mshttpd); Sun, 27 Mar 2005 08:40:03 -0800 Date: Sun, 27 Mar 2005 08:40:03 -0800 From: Andrew Robinson To: des@des.no (=?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=) Message-id: <11397e10fc35.10fc3511397e@uidaho.edu> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.21 (built Sep 8 2003) Content-type: text/plain; charset=iso-8859-1 Content-language: en Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: en Priority: normal X-SpamDetails: rule=notspam policy= score=0 mlx=0 adultscore=0 adjust=0 engine=2.5.0-05032500 definitions=2.5.0-05032601 X-SpamScore: 0 cc: "Kevin G. Eliuk" cc: Kevin Kinsey cc: hackers@freebsd.org cc: freebsd-hackers@freebsd.org cc: jason henson Subject: Re: NIC detected, but won't DHCP or configure 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, 27 Mar 2005 16:40:05 -0000 Thanks VERY much=2E The card works just fine now=2E Andrew ----- Original Message ----- From=3A des=40des=2Eno (Dag-Erling Sm=F8rgrav) Date=3A Wednesday=2C March 23=2C 2005 9=3A42 am Subject=3A Re=3A NIC detected=2C but won=27t DHCP or configure =3E Andrew Robinson =3Candrewr=40uidaho=2Eedu=3E writes=3A =3E =3E re=5Fprobe()=3A vid 10ec did 8169 hwrev 10000000 =3E = =3E That=27s an 8169SB=2C which is supported in -CURRENT=2E Try the atta= ched =3E patch=2E I=27ll try to get it merged before 5=2E4-RELEASE=2E =3E = =3E DES =3E -- = =3E Dag-Erling Sm=F8rgrav - des=40des=2Eno =3E = =3E From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 19:26:28 2005 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 B89CB16A4CE for ; Sun, 27 Mar 2005 19:26:28 +0000 (GMT) Received: from mxsf13.cluster1.charter.net (mxsf13.cluster1.charter.net [209.225.28.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C7D043D2F for ; Sun, 27 Mar 2005 19:26:28 +0000 (GMT) (envelope-from c0ldbyte@myrealbox.com) Received: from mxip14.cluster1.charter.net (mxip14a.cluster1.charter.net [209.225.28.144])j2RJQRZf013213 for ; Sun, 27 Mar 2005 14:26:27 -0500 Received: from 24.247.253.134.gha.mi.chartermi.net (HELO eleanor.us1.wmi.uvac.net) (24.247.253.134) by mxip14.cluster1.charter.net with ESMTP; 27 Mar 2005 14:26:23 -0500 X-Ironport-AV: i="3.91,127,1110171600"; d="scan'208"; a="101979072:sNHT4618058464" Date: Sun, 27 Mar 2005 14:26:21 -0500 (EST) From: c0ldbyte To: gerarra@tin.it In-Reply-To: <420008450006DC4F@ims3a.cp.tin.it> Message-ID: <20050327142324.D15693@eleanor.us1.wmi.uvac.net> References: <420008450006DC4F@ims3a.cp.tin.it> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-hackers@freebsd.org Subject: Re: 5-STABLE kernel build with icc broken 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, 27 Mar 2005 19:26:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 27 Mar 2005 gerarra@tin.it wrote: >> >> Without intending to start any compiler holy wars, what benefits does >> ICC provide over GCC for the end user? >> > > ICC would provide better low level code (remind: Intel C Compiler. It would > mean better performance). > > rookie > If any, still produces not all that much of a difference of code between the newer gcc34 and as much performance differance as your going to get isnt going to even be noticeable in the long run. Your just setting your self up for failure with something that isnt really going to give you the desired effects. - -- Best regards, --c0ldbyte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xF7DF979F iD8DBQFCRwjgsmFQuvffl58RAoqKAJ44D4TFVVaHgK2bP7rrKV0cLHBGlQCeJauB ajI0mxvPps7e/l9dU14DMMU= =73/q -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 19:28:35 2005 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 CDEB316A4CE for ; Sun, 27 Mar 2005 19:28:35 +0000 (GMT) Received: from mxsf36.cluster1.charter.net (mxsf36.cluster1.charter.net [209.225.28.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4623543D3F for ; Sun, 27 Mar 2005 19:28:35 +0000 (GMT) (envelope-from c0ldbyte@myrealbox.com) Received: from mxip20.cluster1.charter.net (mxip20a.cluster1.charter.net [209.225.28.150])j2RJSY1p012560 for ; Sun, 27 Mar 2005 14:28:34 -0500 Received: from 24.247.253.134.gha.mi.chartermi.net (HELO eleanor.us1.wmi.uvac.net) (24.247.253.134) by mxip20.cluster1.charter.net with ESMTP; 27 Mar 2005 14:28:33 -0500 X-Ironport-AV: i="3.91,127,1110171600"; d="scan'208"; a="827966830:sNHT12903040" Date: Sun, 27 Mar 2005 14:28:31 -0500 (EST) From: c0ldbyte To: gerarra@tin.it In-Reply-To: <20050327142324.D15693@eleanor.us1.wmi.uvac.net> Message-ID: <20050327142720.V15720@eleanor.us1.wmi.uvac.net> References: <420008450006DC4F@ims3a.cp.tin.it> <20050327142324.D15693@eleanor.us1.wmi.uvac.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-hackers@freebsd.org Subject: Re: 5-STABLE kernel build with icc broken 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, 27 Mar 2005 19:28:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 27 Mar 2005, c0ldbyte wrote: > On Sun, 27 Mar 2005 gerarra@tin.it wrote: > >>> >>> Without intending to start any compiler holy wars, what benefits does >>> ICC provide over GCC for the end user? >>> >> >> ICC would provide better low level code (remind: Intel C Compiler. It would >> mean better performance). >> >> rookie >> > > If any, still produces not all that much of a difference of code between > the newer gcc34 and as much performance differance as your going to get > isnt going to even be noticeable in the long run. Your just setting your > self up for failure with something that isnt really going to give you > the desired effects. > > -- > Best regards, > --c0ldbyte > PS: There is coders from Intel that do work on some of the code for gcc34. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xF7DF979F iD8DBQFCRwlhsmFQuvffl58RAq83AJsGKYklfVtdxeT8UcIcJ21TaqAmiQCfY6Fz JhQgmTHP66gd6ySeo0zueHc= =RrMC -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 20:43:43 2005 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 AD30A16A4CE for ; Sun, 27 Mar 2005 20:43:43 +0000 (GMT) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0DAE43D5A for ; Sun, 27 Mar 2005 20:43:40 +0000 (GMT) (envelope-from bra@fsn.hu) Received: from localhost (localhost [127.0.0.1]) by people.fsn.hu (Postfix) with ESMTP id AC5A084408; Sun, 27 Mar 2005 22:43:38 +0200 (CEST) Received: from people.fsn.hu ([127.0.0.1]) by localhost (people.fsn.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05567-04-2; Sun, 27 Mar 2005 22:43:31 +0200 (CEST) Received: from [192.168.0.101] (fw.axelero.hu [195.228.243.120]) by people.fsn.hu (Postfix) with ESMTP id AD6AB84425; Sun, 27 Mar 2005 22:43:31 +0200 (CEST) Message-ID: <42471AEC.1030602@fsn.hu> Date: Sun, 27 Mar 2005 22:43:24 +0200 From: Attila Nagy User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: c0ldbyte References: <420008450006DC4F@ims3a.cp.tin.it> <20050327142324.D15693@eleanor.us1.wmi.uvac.net> In-Reply-To: <20050327142324.D15693@eleanor.us1.wmi.uvac.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at fsn.hu cc: freebsd-hackers@freebsd.org cc: gerarra@tin.it Subject: Re: 5-STABLE kernel build with icc broken 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, 27 Mar 2005 20:43:43 -0000 c0ldbyte wrote: > If any, still produces not all that much of a difference of code between > the newer gcc34 and as much performance differance as your going to get > isnt going to even be noticeable in the long run. Your just setting your > self up for failure with something that isnt really going to give you > the desired effects. You don't have to use it, but it is good if you *can*. I guess besides that having a cleaner code base which compiles not only with exactly one compiler it is always good to have the ability to try something else out. BTW, on my humble Pentium II server I noticed significant speedups, compared to the system compiler. But that's purely empirical. -- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone @work: +361 371 3536 ISOs: http://www.fsn.hu/?f=download cell.: +3630 306 6758 From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 20:49:15 2005 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 CECB216A4CE for ; Sun, 27 Mar 2005 20:49:15 +0000 (GMT) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FDEC43D3F for ; Sun, 27 Mar 2005 20:49:15 +0000 (GMT) (envelope-from bra@fsn.hu) Received: from localhost (localhost [127.0.0.1]) by people.fsn.hu (Postfix) with ESMTP id AB07584425; Sun, 27 Mar 2005 22:49:13 +0200 (CEST) Received: from people.fsn.hu ([127.0.0.1]) by localhost (people.fsn.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06571-03-8; Sun, 27 Mar 2005 22:49:08 +0200 (CEST) Received: from [192.168.0.101] (fw.axelero.hu [195.228.243.120]) by people.fsn.hu (Postfix) with ESMTP id 2481784408; Sun, 27 Mar 2005 22:49:08 +0200 (CEST) Message-ID: <42471C41.3090406@fsn.hu> Date: Sun, 27 Mar 2005 22:49:05 +0200 From: Attila Nagy User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: c0ldbyte References: <420008450006DC4F@ims3a.cp.tin.it> <20050327142324.D15693@eleanor.us1.wmi.uvac.net> <20050327142720.V15720@eleanor.us1.wmi.uvac.net> In-Reply-To: <20050327142720.V15720@eleanor.us1.wmi.uvac.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at fsn.hu cc: freebsd-hackers@freebsd.org cc: gerarra@tin.it Subject: Re: 5-STABLE kernel build with icc broken 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, 27 Mar 2005 20:49:15 -0000 c0ldbyte wrote: > PS: There is coders from Intel that do work on some of the code for gcc34. Wow. As far as I know, there are some coders from Nominum who do (or did) work on bind9. And? Bind9 is at least 10 times slower on FreeBSD than Nominum's CNS. :( I didn't get your point. -- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone @work: +361 371 3536 ISOs: http://www.fsn.hu/?f=download cell.: +3630 306 6758 From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 21:18:33 2005 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 6585916A4CE for ; Sun, 27 Mar 2005 21:18:33 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7446243D4C for ; Sun, 27 Mar 2005 21:18:32 +0000 (GMT) (envelope-from jilles@stack.nl) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mailhost.stack.nl (Postfix) with ESMTP id 8C8F31F025 for ; Sun, 27 Mar 2005 23:18:31 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id 6CBE61CD4B; Sun, 27 Mar 2005 23:18:31 +0200 (CEST) Date: Sun, 27 Mar 2005 23:18:31 +0200 From: Jilles Tjoelker To: freebsd-hackers@freebsd.org Message-ID: <20050327211831.GD6814@stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 5.3-RELEASE-p5 i386 User-Agent: Mutt/1.5.6i Subject: find -exec {} + fails with -or and ! (bin/79263) 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, 27 Mar 2005 21:18:33 -0000 The current implementation of the final (possibly only) execution of find -exec {} + is incomplete and only works if the -exec is on the top level of (implicitly) -and'ed primaries, not if it is behind -or or !. I have a patch for this in PR bin/79263. Examples (copied from PR): Simple not-so-practical example (/home/jilles/tmp/find is the patched version of /usr/src/usr.bin/find): jilles@jaguar /home/jilles/tmp% find find \! -exec echo {} + (no output) jilles@jaguar /home/jilles/tmp% find/find find \! -exec echo {} + find find/option.c find/extern.h find/find.1 find/find.c find/find.h find/function.c find/getdate.y find/ls.c find/main.c find/misc.c find/operator.c find/Makefile find/find.o find/function.o find/ls.o find/main.o find/misc.o find/operator.o find/option.o find/getdate.c find/getdate.o find/find find/find.1.gz (expected output) Practical example (searching through a Subversion checkout): jilles@jaguar /home/jilles/src/svn/hyperion% find . \( -name .svn -prune \) -o -type f -exec grep -i silence /dev/null {} + (no output) jilles@jaguar /home/jilles/src/svn/hyperion% ~/tmp/find/find . \( -name .svn -prune \) -o -type f -exec grep -i silence /dev/null {} + (expected output, snipped here) In comparison: jilles@jaguar /home/jilles/src/svn/hyperion% find . \( -name .svn -prune \) -o -type f -print0 | xargs -0 grep -i silence /dev/null gives the expected output, even without the patch. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 23:21:50 2005 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 A77C716A4CF for ; Sun, 27 Mar 2005 23:21:50 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8C1743D1D for ; Sun, 27 Mar 2005 23:21:47 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j2RNLbVQ096693; Sun, 27 Mar 2005 18:21:38 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j2RNLbWV096692; Sun, 27 Mar 2005 18:21:37 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Sun, 27 Mar 2005 18:21:37 -0500 From: David Schultz To: c0ldbyte Message-ID: <20050327232137.GA90785@VARK.MIT.EDU> Mail-Followup-To: c0ldbyte , gerarra@tin.it, freebsd-hackers@freebsd.org References: <420008450006DC4F@ims3a.cp.tin.it> <20050327142324.D15693@eleanor.us1.wmi.uvac.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050327142324.D15693@eleanor.us1.wmi.uvac.net> cc: freebsd-hackers@FreeBSD.ORG cc: gerarra@tin.it Subject: Re: 5-STABLE kernel build with icc broken 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, 27 Mar 2005 23:21:50 -0000 On Sun, Mar 27, 2005, c0ldbyte wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sun, 27 Mar 2005 gerarra@tin.it wrote: > > >> > >>Without intending to start any compiler holy wars, what benefits does > >>ICC provide over GCC for the end user? > >> > > > >ICC would provide better low level code (remind: Intel C Compiler. It would > >mean better performance). > > > >rookie > > > > If any, still produces not all that much of a difference of code between > the newer gcc34 and as much performance differance as your going to get > isnt going to even be noticeable in the long run. Your just setting your > self up for failure with something that isnt really going to give you > the desired effects. For some applications, particularly in scientific computing, icc is significantly better. The FreeBSD kernel is not in this category, however. Operating system kernels tend to spend most of their time chasing pointers and copying data, and compilers can't really optimize these operations. From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 14:28:56 2005 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 CAA5016A4CE for ; Sun, 27 Mar 2005 14:28:56 +0000 (GMT) Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id D92A743D49 for ; Sun, 27 Mar 2005 14:28:55 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd27.aul.t-online.de by mailout01.sul.t-online.com with smtp id 1DFYl4-0000kp-02; Sun, 27 Mar 2005 16:28:54 +0200 Received: from Andro-Beta.Leidinger.net (bjgs4kZeYe8eyG2pLKofxoV2N4Chvx2E4BKTUkY6lfIlNdfy6KkFEF@[217.229.215.79]) by fwd27.sul.t-online.de with esmtp id 1DFYkq-0iYkN60; Sun, 27 Mar 2005 16:28:40 +0200 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) j2RERHI2057446; Sun, 27 Mar 2005 16:27:17 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Sun, 27 Mar 2005 16:28:39 +0200 From: Alexander Leidinger To: Avleen Vig Message-ID: <20050327162839.2fafa6aa@Magellan.Leidinger.net> In-Reply-To: <20050327134044.GM78512@silverwraith.com> References: <423C15C5.6040902@fsn.hu> <20050327133059.3d68a78c@Magellan.Leidinger.net> <20050327134044.GM78512@silverwraith.com> X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: bjgs4kZeYe8eyG2pLKofxoV2N4Chvx2E4BKTUkY6lfIlNdfy6KkFEF@t-dialin.net X-TOI-MSGID: a4c8febf-77c4-4532-880f-cfc975149a0d X-Mailman-Approved-At: Mon, 28 Mar 2005 12:50:29 +0000 cc: hackers@freebsd.org Subject: Re: 5-STABLE kernel build with icc broken 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, 27 Mar 2005 14:28:56 -0000 On Sun, 27 Mar 2005 05:40:44 -0800 Avleen Vig wrote: > On Sun, Mar 27, 2005 at 01:30:59PM +0200, Alexander Leidinger wrote: > > > It seems to me that building kernel with icc is currently broken, at > > > least in 5-STABLE. Could somebody investigate this? > > > > I don't have a problem to compile it with a recent -current and a recent > > icc (-stable not tested), but the resulting kernel imediatly panics > > (page fault in _mtx_...()). > > Without intending to start any compiler holy wars, what benefits does > ICC provide over GCC for the end user? Various: - auto-vectorizer (no benefit for the kernel, since we can't use FPU/SIMD instructions at any time... yet (interested hackers can have a look how DragonFly handles it, I can provide the necessary commit logs)) - optimizations for Intel CPUs direct from the manufacturer of the CPU (they have a lot of interest to produce very fast code) - a different set of compiler warnings - better code quality (if is compilable by more than one compiler it may be more portable) Icc already pointed out some bad code (asm code in the IP checksumming code... DragonFly changed it already), and the panic as noticed above may also be an indication that we have some code in the tree which smells bad. Bye, Alexander. -- The dark ages were caused by the Y1K problem. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 28 13:42:54 2005 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 BB87116A4CE; Mon, 28 Mar 2005 13:42:54 +0000 (GMT) Received: from f9.mail.ru (f9.mail.ru [194.67.57.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6EE6743D4C; Mon, 28 Mar 2005 13:42:54 +0000 (GMT) (envelope-from shmukler@mail.ru) Received: from mail by f9.mail.ru with local id 1DFuW4-000PNm-00; Mon, 28 Mar 2005 17:42:52 +0400 Received: from [24.185.245.215] by win.mail.ru with HTTP; Mon, 28 Mar 2005 17:42:52 +0400 From: Igor Shmukler To: Robert Watson Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [24.185.245.215] Date: Mon, 28 Mar 2005 17:42:52 +0400 In-Reply-To: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: cc: hackers@freebsd.org Subject: name cache cont. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Igor Shmukler List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2005 13:42:54 -0000 Robert > which would generally explain the issues. However, the >my.file case is a > bit concerning. Could you confirm that the file descriptor in that case > is definitely pointed at a vnode? Indeed does not work. It only happens when my.file is a file newly created by the shell. If one forwarded output to an existing file, vn_fullpath() returns name just fine. For my purposes the Linux/DragonFly functionality is needed. Is there a way to know that once a patch that correctly resolves corner cases for vn_fullpath() (including name cache changes) exists it will be committed to the 5.x branch? It appears that these changes would require serious labor changing the name cache. Who would be the right person to even decide that these can/cannot be applied to a stable tree? Igor. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 28 18:02:08 2005 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 B017316A4CE for ; Mon, 28 Mar 2005 18:02:08 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52D8943D31 for ; Mon, 28 Mar 2005 18:02:08 +0000 (GMT) (envelope-from maslanbsd@gmail.com) Received: by wproxy.gmail.com with SMTP id 50so326788wri for ; Mon, 28 Mar 2005 10:02:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=DdXMvsNlBsmyccLyhJWOITRWQuS2DSAacSZ3VuL/HxsMeDaa1ZpUjz+pbA/wG1FdKHsgCuDDp3n11S4KTZZaBLJyogCFK/9QJ1IG7aLzW98P2+sd7GYBxs5TiX0Pg+l3aoZJJY8i9T9fRVqgv/ay1FPxGMWn27kKeXVSUYCOSpA= Received: by 10.54.30.77 with SMTP id d77mr2828343wrd; Mon, 28 Mar 2005 10:01:57 -0800 (PST) Received: by 10.54.99.7 with HTTP; Mon, 28 Mar 2005 10:01:56 -0800 (PST) Message-ID: <319cceca0503281001792baf39@mail.gmail.com> Date: Mon, 28 Mar 2005 10:01:56 -0800 From: mohamed aslan To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: organization X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mohamed aslan List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2005 18:02:08 -0000 hi guys it's my first post here, BTW i was a linux hacker and linux kernel mailing list member for 3 years. and i've a comment here , i think the freebsd kernel source files aren't well organized as linux ones. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 28 18:40:46 2005 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 0C9B116A4CE for ; Mon, 28 Mar 2005 18:40:46 +0000 (GMT) Received: from mail22.sea5.speakeasy.net (mail22.sea5.speakeasy.net [69.17.117.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4AE143D41 for ; Mon, 28 Mar 2005 18:40:45 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 31696 invoked from network); 28 Mar 2005 18:40:45 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail22.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 28 Mar 2005 18:40:43 -0000 Received: from hydrogen.funkthat.com (klyvwf@localhost.funkthat.com [127.0.0.1])j2SIegGH009702; Mon, 28 Mar 2005 10:40:43 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id j2SIegcn009701; Mon, 28 Mar 2005 10:40:42 -0800 (PST) Date: Mon, 28 Mar 2005 10:40:42 -0800 From: John-Mark Gurney To: mohamed aslan Message-ID: <20050328184042.GZ37984@funkthat.com> Mail-Followup-To: mohamed aslan , freebsd-hackers@freebsd.org References: <319cceca0503281001792baf39@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <319cceca0503281001792baf39@mail.gmail.com> 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 cc: freebsd-hackers@freebsd.org Subject: Re: organization 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: Mon, 28 Mar 2005 18:40:46 -0000 mohamed aslan wrote this message on Mon, Mar 28, 2005 at 10:01 -0800: > it's my first post here, BTW i was a linux hacker and linux kernel > mailing list member for 3 years. > > and i've a comment here , i think the freebsd kernel source files > aren't well organized as linux ones. If you are going to provide criticism, you should provide some reasons.. and/or examples of why... It's like me saying that the Linux kernel build infastructure isn't very clean... and then giving no reason for it... but I'm not going to be like you, and give you a reason: I can't speek for current versions of Linux, but older ones if you changed a small part of your kernel config, it would require you to rebuild the entire kernel source tree... With FreeBSD, I can add or remove drivers, and my new kernel will be done in about a minute... Much nicer... Please provide more content in your messages to this list... -- 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 Mon Mar 28 18:42:24 2005 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 24A2216A4CE for ; Mon, 28 Mar 2005 18:42:24 +0000 (GMT) Received: from mxsf13.cluster1.charter.net (mxsf13.cluster1.charter.net [209.225.28.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id A481643D53 for ; Mon, 28 Mar 2005 18:42:23 +0000 (GMT) (envelope-from c0ldbyte@myrealbox.com) Received: from mxip09.cluster1.charter.net (mxip09a.cluster1.charter.net [209.225.28.139])j2SIgLpV001356 for ; Mon, 28 Mar 2005 13:42:22 -0500 Received: from 24.247.253.134.gha.mi.chartermi.net (HELO eleanor.us1.wmi.uvac.net) (24.247.253.134) by mxip09.cluster1.charter.net with ESMTP; 28 Mar 2005 13:42:21 -0500 X-Ironport-AV: i="3.91,128,1110171600"; d="scan'208"; a="747785659:sNHT541545348" Date: Mon, 28 Mar 2005 13:42:16 -0500 (EST) From: c0ldbyte To: freebsd-hackers@freebsd.org In-Reply-To: <319cceca0503281001792baf39@mail.gmail.com> Message-ID: <20050328133542.S440@eleanor.us1.wmi.uvac.net> References: <319cceca0503281001792baf39@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: organization 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, 28 Mar 2005 18:42:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 28 Mar 2005, mohamed aslan wrote: > hi guys > it's my first post here, BTW i was a Linux hacker and Linux kernel > mailing list member for 3 years. > > and I've a comment here , i think the freebsd kernel source files > aren't well organized as Linux ones. Well thats nice, Didnt your mommy say once to you before "If you dont have nothing good to say then dont say nothing" ?. Thats not a really detailed look into where you think the files are not well organized. Personly I think you have had your head stuck in the Linux culture to long to comment on anything going on with the Freebsd code or how the system is layed out. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xF7DF979F iD8DBQFCSFALsmFQuvffl58RAgB5AJ43Fjog004aDzcKZMiEPw5DVQSTzACbB4R+ eo+3aE+Bq+JDmEWksXkYhLo= =8AHQ -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 28 19:02:01 2005 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 E730416A4CE; Mon, 28 Mar 2005 19:02:01 +0000 (GMT) Received: from smp500.sitetronics.com (sitetronics.com [82.192.77.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D08D43D31; Mon, 28 Mar 2005 19:02:01 +0000 (GMT) (envelope-from dodell@offmyserver.com) Received: from localhost.sitetronics.com ([127.0.0.1] helo=smp500.sitetronics.com) by smp500.sitetronics.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DFzTQ-000KoN-Sg; Mon, 28 Mar 2005 21:00:28 +0200 Received: (from dodell@localhost) by smp500.sitetronics.com (8.12.11/8.12.11/Submit) id j2SJ0Sen080002; Mon, 28 Mar 2005 21:00:28 +0200 (CEST) (envelope-from dodell@offmyserver.com) X-Authentication-Warning: smp500.sitetronics.com: dodell set sender to dodell@offmyserver.com using -f Date: Mon, 28 Mar 2005 21:00:28 +0200 From: "Devon H. O'Dell " To: freebsd-hackers@freebsd.org Message-ID: <20050328190028.GA79414@smp500.sitetronics.com> Mail-Followup-To: freebsd-hackers@freebsd.org, postmaster@freebsd.org References: <319cceca0503281001792baf39@mail.gmail.com> <20050328133542.S440@eleanor.us1.wmi.uvac.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <20050328133542.S440@eleanor.us1.wmi.uvac.net> User-Agent: Mutt/1.5.8i cc: postmaster@freebsd.org Subject: Re: organization 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, 28 Mar 2005 19:02:02 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 28, 2005 at 01:42:16PM -0500, c0ldbyte wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On Mon, 28 Mar 2005, mohamed aslan wrote: >=20 > >hi guys > >it's my first post here, BTW i was a Linux hacker and Linux kernel > >mailing list member for 3 years. > > > >and I've a comment here , i think the freebsd kernel source files > >aren't well organized as Linux ones. >=20 > Well thats nice, Didnt your mommy say once to you before "If you dont have > nothing good to say then dont say nothing" ?. Thats not a really detailed > look into where you think the files are not well organized. Personly I > think you have had your head stuck in the Linux culture to long to comment > on anything going on with the Freebsd code or how the system is layed out. Perhaps you should take a bit of your own advice `c0ldbyte'. I'm=20 personally sick of your condescending attitude towards everybody on the public lists. Cut it out. --Devon --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCSFRMSkf3jVXOdl0RAnY7AKCSAp7m76/gYZX4yYagq63neL/JTQCfaWmu HFVm/0oloTmgovBcUseF9MY= =UJtp -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 28 19:05:31 2005 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 0A2A316A4CE for ; Mon, 28 Mar 2005 19:05:31 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C322043D39 for ; Mon, 28 Mar 2005 19:05:30 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 652367A423; Mon, 28 Mar 2005 11:05:30 -0800 (PST) Message-ID: <4248557A.7000302@elischer.org> Date: Mon, 28 Mar 2005 11:05:30 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: mohamed aslan References: <319cceca0503281001792baf39@mail.gmail.com> In-Reply-To: <319cceca0503281001792baf39@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: organization 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, 28 Mar 2005 19:05:31 -0000 mohamed aslan wrote: >hi guys >it's my first post here, BTW i was a linux hacker and linux kernel >mailing list member for 3 years. > >and i've a comment here , i think the freebsd kernel source files >aren't well organized as linux ones. > > You are in some ways correct.. Unfortunatly, as our project is significantly older than Linux it has a lot more historical baggage.. The system layout has its roots in teh layout of the original Unix layout from the 1970s. The BSD source tree has lived through several complete generations of hardware. In the beginning for example, IO was one of 5 things.. DISCs (expensive) tape, Teletype (110baud paper printer) or card readers and punches. As things have changed, some of the original layout decisions have become rather outdated. For a slightly better example, check out the layout of the DragonflyBSD kernel sources. Matt took the oportunity to re-arange the FreeBSD sources when he imported them.. To some extent I agree with him (though not necessariy with his positioning of every file). It is possible that we could do with a reoganisation but it isn't a work-free job.. Matt took some time to get everything working again.. possible things that could be done.. Every driver in its own directory. INCLUDING the makefile for the module and the man pages.. All network protocols to be sunk into a "networking" subdirectory ditto for filesystems. Bus drivers being separated slightly from device drivers (though related (/sys/dev/bus?/usb?) The kern directory broken into functional sub parts. (proces control, scheduler, ipc etc) >_______________________________________________ >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 Mar 28 19:08:49 2005 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 2CC5B16A4CE for ; Mon, 28 Mar 2005 19:08:49 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0554643D2D for ; Mon, 28 Mar 2005 19:08:49 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id E195B7A423; Mon, 28 Mar 2005 11:08:48 -0800 (PST) Message-ID: <42485640.8050609@elischer.org> Date: Mon, 28 Mar 2005 11:08:48 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: c0ldbyte References: <319cceca0503281001792baf39@mail.gmail.com> <20050328133542.S440@eleanor.us1.wmi.uvac.net> In-Reply-To: <20050328133542.S440@eleanor.us1.wmi.uvac.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: organization 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, 28 Mar 2005 19:08:49 -0000 c0ldbyte wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mon, 28 Mar 2005, mohamed aslan wrote: > >> hi guys >> it's my first post here, BTW i was a Linux hacker and Linux kernel >> mailing list member for 3 years. >> >> and I've a comment here , i think the freebsd kernel source files >> aren't well organized as Linux ones. > > > Well thats nice, Didnt your mommy say once to you before "If you dont > have > nothing good to say then dont say nothing" ?. Thats not a really detailed > look into where you think the files are not well organized. Personly I > think you have had your head stuck in the Linux culture to long to > comment > on anything going on with the Freebsd code or how the system is layed > out. now now.. don't snap his head off for that.. it's a reasonable comment for someone who is maybe lookign to do work in both places.. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.0 (FreeBSD) > Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xF7DF979F > > iD8DBQFCSFALsmFQuvffl58RAgB5AJ43Fjog004aDzcKZMiEPw5DVQSTzACbB4R+ > eo+3aE+Bq+JDmEWksXkYhLo= > =8AHQ > -----END PGP SIGNATURE----- > _______________________________________________ > 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 Mar 28 19:11:39 2005 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 523D316A4CE; Mon, 28 Mar 2005 19:11:39 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DCE843D49; Mon, 28 Mar 2005 19:11:39 +0000 (GMT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 1F7BD5CA07; Mon, 28 Mar 2005 11:11:39 -0800 (PST) Date: Mon, 28 Mar 2005 21:11:39 +0200 From: Maxime Henrion To: freebsd-hackers@freebsd.org, postmaster@freebsd.org Message-ID: <20050328191139.GB25563@elvis.mu.org> References: <319cceca0503281001792baf39@mail.gmail.com> <20050328133542.S440@eleanor.us1.wmi.uvac.net> <20050328190028.GA79414@smp500.sitetronics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050328190028.GA79414@smp500.sitetronics.com> User-Agent: Mutt/1.4.2.1i Subject: Re: organization 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, 28 Mar 2005 19:11:39 -0000 Devon H. O'Dell wrote: > On Mon, Mar 28, 2005 at 01:42:16PM -0500, c0ldbyte wrote: > > On Mon, 28 Mar 2005, mohamed aslan wrote: > > > > >hi guys > > >it's my first post here, BTW i was a Linux hacker and Linux kernel > > >mailing list member for 3 years. > > > > > >and I've a comment here , i think the freebsd kernel source files > > >aren't well organized as Linux ones. > > > > Well thats nice, Didnt your mommy say once to you before "If you dont have > > nothing good to say then dont say nothing" ?. Thats not a really detailed > > look into where you think the files are not well organized. Personly I > > think you have had your head stuck in the Linux culture to long to comment > > on anything going on with the Freebsd code or how the system is layed out. > > Perhaps you should take a bit of your own advice `c0ldbyte'. I'm > personally sick of your condescending attitude towards everybody > on the public lists. Cut it out. Fully seconded. Even though it clearly wasn't a brilliant idea to criticize FreeBSD source code organization without giving a single reason or example, Mohamed clearly didn't deserve to be flamed like this. A bit more diplomacy wouldn't hurt here... Now responding to Mohamed, I'm really surprised to see you writing this. I've banged my head against the wall so many times to locate some piece of source code in the Linux kernel that I really cannot understand you. For the most part, I find the FreeBSD source organization simply great. There are many criticisms one can legitimally do against FreeBSD, but that one sounds just wrong. Cheers, Maxime From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 28 19:20:09 2005 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 921DD16A4F3 for ; Mon, 28 Mar 2005 19:20:09 +0000 (GMT) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30FEA43D5F for ; Mon, 28 Mar 2005 19:20:09 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (storm.stura.uni-rostock.de [139.30.252.72]) by hydra.bec.de (Postfix) with ESMTP id 2737B35707 for ; Mon, 28 Mar 2005 21:20:07 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1001) id DBFDA7CEC; Mon, 28 Mar 2005 21:17:58 +0200 (CEST) Date: Mon, 28 Mar 2005 21:17:58 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20050328191758.GB3141@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <319cceca0503281001792baf39@mail.gmail.com> <4248557A.7000302@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4248557A.7000302@elischer.org> User-Agent: Mutt/1.5.9i Subject: Re: organization 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, 28 Mar 2005 19:20:09 -0000 On Mon, Mar 28, 2005 at 11:05:30AM -0800, Julian Elischer wrote: > As things have changed, some of the original layout decisions have > become rather > outdated. For a slightly better example, check out the layout of the > DragonflyBSD kernel > sources. Matt took the oportunity to re-arange the FreeBSD sources when > he imported > them.. To some extent I agree with him (though not necessariy with his > positioning of every file). I completely agree here, but it is difficult to get everything into the perfect place. The NetBSD idea of moving i386 and the other platforms into arch/ is also very nice. > It is possible that we could do with a reoganisation but it isn't a > work-free job.. > Matt took some time to get everything working again.. The biggest problem is keeping history here. Doing something like that with CVS is a major PITA. We didn't have any old release, so moving the repository files didn't create a problem. That's impossible in FreeBSD land :) Joerg From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 28 19:26:25 2005 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 98A3316A4CE for ; Mon, 28 Mar 2005 19:26:25 +0000 (GMT) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.FreeBSD.org (Postfix) with SMTP id D38A043D5F for ; Mon, 28 Mar 2005 19:26:21 +0000 (GMT) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 38426 invoked by uid 0); 28 Mar 2005 16:26:15 -0300 Received: from eksffa@freebsdbrasil.com.br by capeta.freebsdbrasil.com.br by uid 82 with qmail-scanner-1.22 Clear:RC:1(200.210.42.5):. Processed in 0.341255 secs); 28 Mar 2005 19:26:15 -0000 Received: from unknown (HELO ?10.69.69.69?) (200.210.42.5) by capeta.freebsdbrasil.com.br with SMTP; 28 Mar 2005 16:26:15 -0300 Message-ID: <42485A54.9000101@freebsdbrasil.com.br> Date: Mon, 28 Mar 2005 16:26:12 -0300 From: Patrick Tracanelli Organization: FreeBSD Brasil LTDA User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050309 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mohamed aslan References: <319cceca0503281001792baf39@mail.gmail.com> In-Reply-To: <319cceca0503281001792baf39@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: organization 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, 28 Mar 2005 19:26:25 -0000 Maybe you are just more familiar to Linux kernel. I am not a kernel hacker, like you and many people here. But I usually read source codes, FreeBSD and also NetBSD and Linux, specially the areas where I am a particular curious. FreeBSD code organization is close to BSD's roots (you can get those Walnut Creek historical CDROM which has code for 4BSD and 386BSD to compare). I like FreeBSD orgaization better. Maybe you will disagree it for a thousand years, or one day find NetBSD approach better than both. In any case I am sure spending more time under FreeBSD's src/ won't make the organization such a deal that deserves this comment. mohamed aslan wrote: > hi guys > it's my first post here, BTW i was a linux hacker and linux kernel > mailing list member for 3 years. > > and i've a comment here , i think the freebsd kernel source files > aren't well organized as linux ones. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 28 20:51:35 2005 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 3DEB116A4CE for ; Mon, 28 Mar 2005 20:51:35 +0000 (GMT) Received: from mail9.messagelabs.com (mail9.messagelabs.com [194.205.110.133]) by mx1.FreeBSD.org (Postfix) with SMTP id 47FFA43D48 for ; Mon, 28 Mar 2005 20:51:34 +0000 (GMT) (envelope-from greg@warprecords.com) X-VirusChecked: Checked X-Env-Sender: greg@warprecords.com X-Msg-Ref: server-29.tower-9.messagelabs.com!1112043092!13813000!1 X-StarScan-Version: 5.4.11; banners=-,-,- X-Originating-IP: [212.135.210.82] Received: (qmail 26197 invoked from network); 28 Mar 2005 20:51:32 -0000 Received: from dsl-212-135-210-82.dsl.easynet.co.uk (HELO warprecords.com) (212.135.210.82) by server-29.tower-9.messagelabs.com with SMTP; 28 Mar 2005 20:51:32 -0000 Received: from [194.106.52.52] (HELO [192.168.0.2]) by warprecords.com (CommuniGate Pro SMTP 4.2.8) with ESMTP-TLS id 4033087 for freebsd-hackers@freebsd.org; Mon, 28 Mar 2005 21:51:24 +0100 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-hackers@freebsd.org From: Greg Eden Date: Mon, 28 Mar 2005 21:51:23 +0100 X-Mailer: Apple Mail (2.619.2) Subject: FreeBSD 5.3R SMP Kernel not detecting 2nd CPU in a HP DL360(?) 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, 28 Mar 2005 20:51:35 -0000 Hello All, I have a co-located HP DL360 G3 server to which I do not have physical access. It has 2 x 2.8GHz Xeon CPUs with HTT. One of the ISP's engineers has confirmed that both CPUs are detected when the BIOS POSTs. I have cvsup'd to the latest 5.3R security release and successfully built 'world', something I have done successfully many times with 4.x releases, using the instructions from the handbook. I used a custom kernel configuration which included 'options SMP' and 'device apic'. On reboot dmesg confirmed that the custom kernel was used, however SMP was not active and the additional CPUs were not launched. Thinking that perhaps my custom kernel conf was at fault, I compiled a GENERIC smp kernel with: # cd /usr/obj # chflags -R noschg * # rm -rf * /usr/src/# make buildkernel KERNCONF=SMP /usr/src/# make installkernel KERNCONF=SMP After reboot the dmesg output is as follows: FreeBSD 5.3-RELEASE-p5 #0: Thu Mar 24 14:37:29 GMT 2005 greg@[snip].warprecords.com:/usr/obj/usr/src/sys/SMP Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2799.22-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebf9ff Hyperthreading: 2 logical CPUs real memory = 2147459072 (2047 MB) avail memory = 2095996928 (1998 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x920-0x923 on acpi0 cpu0: on acpi0 acpi_tz0: on acpi0 pcib0: on acpi0 ACPI link \\_SB_.IN31 has invalid initial irq 3, ignoring pci0: on pcib0 pci0: at device 3.0 (no driver attached) ciss0: port 0x2800-0x28ff mem 0xf5df0000-0xf5df3fff,0xf5f80000-0xf5fbffff irq 11 at device 4.0 on pci0 ciss0: [GIANT-LOCKED] pci0: at device 5.0 (no driver attached) pci0: at device 5.2 (no driver attached) isab0: at device 15.0 on pci0 isa0: on isab0 atapci0: port 0x2000-0x200f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 ohci0: mem 0xf5e70000-0xf5e70fff irq 10 at device 15.2 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered pcib1: on acpi0 pci1: on pcib1 bge0: mem 0xf7ef0000-0xf7efffff irq 11 at device 2.0 on pci1 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:11:85:6b:07:d8 pcib2: on acpi0 pci4: on pcib2 bge1: mem 0xf7ff0000-0xf7ffffff irq 15 at device 2.0 on pci4 miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: Ethernet address: 00:11:85:6b:07:db atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sio0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A fdc0: port 0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 orm0: at iomem 0xee000-0xeffff,0xcc000-0xcd7ff,0xc8000-0xcbfff,0xc0000-0xc7fff on isa0 pmtimer0 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 2799224924 Hz quality 800 Timecounters tick every 10.000 msec acd0: CDROM at ata0-master PIO4 da0 at ciss0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 135.168MB/s transfers da0: 69459MB (142253280 512 byte sectors: 255H 32S/T 17433C) Mounting root from ufs:/dev/da0s1a and ~> sysctl kern.smp.active kern.smp.active: 0 I just don't understand why the kernel isn't running SMP. To my mind it's either something in my method (most likely), a hardware problem, or something odd in the way 5.3R detects the CPUs on the hardware. I have successfully compiled SMP kernels on identical hardware with FreeBSD 4.8R. With the HTT 4 CPUs are launched as they should be here. Now I think about it I have another machine, a HP DL380 with a single HTT Xeon processor, which is displaying the same problem. Thanks in advance. greg. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 28 21:42:36 2005 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 2AE8816A4CE for ; Mon, 28 Mar 2005 21:42:36 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6486043D31 for ; Mon, 28 Mar 2005 21:42:35 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j2SLdNsD085161; Mon, 28 Mar 2005 14:39:24 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 28 Mar 2005 14:39:23 -0700 (MST) Message-Id: <20050328.143923.74664880.imp@bsdimp.com> To: maslanbsd@gmail.com From: Warner Losh In-Reply-To: <319cceca0503281001792baf39@mail.gmail.com> References: <319cceca0503281001792baf39@mail.gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: organization 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, 28 Mar 2005 21:42:36 -0000 > it's my first post here, BTW i was a linux hacker and linux kernel > mailing list member for 3 years. Oh, a Linux list member for 3 years. Wow! > and i've a comment here , i think the freebsd kernel source files > aren't well organized as linux ones. And I think you are wrong and that the Linux sources a tangled mess. This sort of whining isn't productive. Why don't you think they are organized? Because the organization is different than Linux? Or some other reason? Warner From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 28 21:49:33 2005 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 C3FE716A4CE for ; Mon, 28 Mar 2005 21:49:33 +0000 (GMT) Received: from dutch10.digitalus.nl (dutch10.digitalus.nl [81.173.33.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03E0443D31 for ; Mon, 28 Mar 2005 21:49:33 +0000 (GMT) (envelope-from webmaster@shizukana.net) Received: from www.shizukana.net (localhost.localdomain [127.0.0.1]) j2SLnP0g026791; Mon, 28 Mar 2005 23:49:25 +0200 Received: from 84.26.82.135 (SquirrelMail authenticated user webmaster@shizukana.net); by www.shizukana.net with HTTP; Mon, 28 Mar 2005 23:49:25 +0200 (CEST) Message-ID: <51739.84.26.82.135.1112046565.squirrel@84.26.82.135> In-Reply-To: <319cceca0503281001792baf39@mail.gmail.com> References: <319cceca0503281001792baf39@mail.gmail.com> Date: Mon, 28 Mar 2005 23:49:25 +0200 (CEST) From: "Webmaster Shizukana.net" To: "mohamed aslan" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal cc: freebsd-hackers@freebsd.org Subject: Re: organization 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, 28 Mar 2005 21:49:33 -0000 The user " mohamed aslan" wrote this strange object...: > hi guys > it's my first post here, BTW i was a linux hacker and linux kernel > mailing list member for 3 years. > > and i've a comment here , i think the freebsd kernel source files > aren't well organized as linux ones. > _______________________________________________ > 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" > Well, If I have to give my point, I think that FreeBSD has a very nice one, because the things are easy to find in it. I never tried any Linux, only FreeBSD. But you say that it's not organized well, like linux ones, You can discuss this for ages, because you used linux for years and we do *BSD for years so we can say that the linux ones aren't organized. It just depends wat your used to. But everyone has his own point about what he likes to use. Only thing I don't like at FreeBSD is the wine, I need to run Wine with some programs, Like internet explorer but it just dont want to install, followed some tutorials but nothing.. well if you might think you can solve this, please contact me privately I really want to fix this :S even the freebsd-emulators and wine mailinglists doesn't help :( Regards, JeanPaul (Nexohrion) From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 28 21:52:09 2005 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 7FBA516A4CE for ; Mon, 28 Mar 2005 21:52:09 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 056E643D46 for ; Mon, 28 Mar 2005 21:52:09 +0000 (GMT) (envelope-from dleimbac@gmail.com) Received: by rproxy.gmail.com with SMTP id z35so1847334rne for ; Mon, 28 Mar 2005 13:52:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=FEKw4WDHfS8bdO55XU8b2/SPew1uPqm7s47iayWD3auIuQJRHJyKZwAmxH36uYHNBzRr7aJim9z7cScVGp19VJTXG9gj2aIhwfp5WsQVRvzHPPnPtxBsiJ0JWQBx8zm/KbhDMxy3Q4psS1oHavNgFCKrAYach6MA3PpCOAHLfL4= Received: by 10.38.65.57 with SMTP id n57mr2770186rna; Mon, 28 Mar 2005 13:52:06 -0800 (PST) Received: by 10.38.82.48 with HTTP; Mon, 28 Mar 2005 13:52:04 -0800 (PST) Message-ID: <5bbfe7d4050328135210e0c8c7@mail.gmail.com> Date: Mon, 28 Mar 2005 13:52:04 -0800 From: David Leimbach To: "Webmaster Shizukana.net" In-Reply-To: <51739.84.26.82.135.1112046565.squirrel@84.26.82.135> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <319cceca0503281001792baf39@mail.gmail.com> <51739.84.26.82.135.1112046565.squirrel@84.26.82.135> cc: mohamed aslan cc: freebsd-hackers@freebsd.org Subject: Re: organization X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Leimbach List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2005 21:52:09 -0000 On Mon, 28 Mar 2005 23:49:25 +0200 (CEST), Webmaster Shizukana.net wrote: > The user " mohamed aslan" wrote this strange object...: > > hi guys > > it's my first post here, BTW i was a linux hacker and linux kernel > > mailing list member for 3 years. > > > > and i've a comment here , i think the freebsd kernel source files > > aren't well organized as linux ones. > > _______________________________________________ > > 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" > > > > Well, If I have to give my point, > I think that FreeBSD has a very nice one, because the things are easy to > find in it. > I never tried any Linux, only FreeBSD. > > But you say that it's not organized well, like linux ones, > You can discuss this for ages, because you used linux for years > and we do *BSD for years so we can say that the linux ones aren't organized. > It just depends wat your used to. > > But everyone has his own point about what he likes to use. > > Only thing I don't like at FreeBSD is the wine, > I need to run Wine with some programs, Like internet explorer but it just > dont want to install, followed some tutorials but nothing.. > well if you might think you can solve this, please contact me privately > I really want to fix this :S even the freebsd-emulators and wine > mailinglists doesn't help :( > > Regards, > JeanPaul > (Nexohrion) > > _______________________________________________ > 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" > Seems to me people waste a lot of time replying to stupid emails. The best solution is to ignore. Too bad I didn't follow my own advice. Dave From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 28 21:59:11 2005 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 8EFE816A4CE for ; Mon, 28 Mar 2005 21:59:11 +0000 (GMT) Received: from dutch10.digitalus.nl (dutch10.digitalus.nl [81.173.33.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE96843D46 for ; Mon, 28 Mar 2005 21:59:10 +0000 (GMT) (envelope-from webmaster@shizukana.net) Received: from www.shizukana.net (localhost.localdomain [127.0.0.1]) j2SLx40g027440; Mon, 28 Mar 2005 23:59:04 +0200 Received: from 84.26.82.135 (SquirrelMail authenticated user webmaster@shizukana.net); by www.shizukana.net with HTTP; Mon, 28 Mar 2005 23:59:04 +0200 (CEST) Message-ID: <50336.84.26.82.135.1112047144.squirrel@84.26.82.135> In-Reply-To: <5bbfe7d4050328135210e0c8c7@mail.gmail.com> References: <319cceca0503281001792baf39@mail.gmail.com> <51739.84.26.82.135.1112046565.squirrel@84.26.82.135> <5bbfe7d4050328135210e0c8c7@mail.gmail.com> Date: Mon, 28 Mar 2005 23:59:04 +0200 (CEST) From: "Nexohrion (JeanPaul) (Webmaster AT Shizukana.net)" To: "David Leimbach" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal cc: mohamed aslan cc: "Webmaster Shizukana.net" cc: freebsd-hackers@freebsd.org Subject: Re: organization 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, 28 Mar 2005 21:59:11 -0000 The user David Leimbach > On Mon, 28 Mar 2005 23:49:25 +0200 (CEST), Webmaster Shizukana.net > wrote: >> The user " mohamed aslan" wrote this strange object...: >> > hi guys >> > it's my first post here, BTW i was a linux hacker and linux kernel >> > mailing list member for 3 years. >> > >> > and i've a comment here , i think the freebsd kernel source files >> > aren't well organized as linux ones. >> > _______________________________________________ >> > 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" >> > >> >> Well, If I have to give my point, >> I think that FreeBSD has a very nice one, because the things are easy to >> find in it. >> I never tried any Linux, only FreeBSD. >> >> But you say that it's not organized well, like linux ones, >> You can discuss this for ages, because you used linux for years >> and we do *BSD for years so we can say that the linux ones aren't >> organized. >> It just depends wat your used to. >> >> But everyone has his own point about what he likes to use. >> >> Only thing I don't like at FreeBSD is the wine, >> I need to run Wine with some programs, Like internet explorer but it >> just >> dont want to install, followed some tutorials but nothing.. >> well if you might think you can solve this, please contact me privately >> I really want to fix this :S even the freebsd-emulators and wine >> mailinglists doesn't help :( >> >> Regards, >> JeanPaul >> (Nexohrion) >> >> _______________________________________________ >> 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" >> > > > Seems to me people waste a lot of time replying to stupid emails. > > The best solution is to ignore. > > Too bad I didn't follow my own advice. > > Dave > Well that's what you do if you are bored... Or if you are irritated because wine doesn't function proper and it's you're own fault because you can't configure it... (That's what happened to me) -Nexohrion From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 28 22:15:34 2005 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 247B016A4CE for ; Mon, 28 Mar 2005 22:15:34 +0000 (GMT) Received: from seven.Alameda.net (seven.alameda.net [64.81.53.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3923A43D39 for ; Mon, 28 Mar 2005 22:15:33 +0000 (GMT) (envelope-from ulf@Alameda.net) Received: by seven.Alameda.net (Postfix, from userid 1000) id A12283A201; Mon, 28 Mar 2005 14:15:32 -0800 (PST) Date: Mon, 28 Mar 2005 14:15:32 -0800 From: Ulf Zimmermann To: Greg Eden Message-ID: <20050328221531.GA13841@seven.alameda.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 4.10-RELEASE-p2 User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 5.3R SMP Kernel not detecting 2nd CPU in a HP DL360(?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ulf@Alameda.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2005 22:15:34 -0000 On Mon, Mar 28, 2005 at 09:51:23PM +0100, Greg Eden wrote: > > Hello All, > > I have a co-located HP DL360 G3 server to which I do not have physical > access. It has 2 x 2.8GHz Xeon CPUs with HTT. One of the ISP's > engineers has confirmed that both CPUs are detected when the BIOS > POSTs. > > I have cvsup'd to the latest 5.3R security release and successfully > built 'world', something I have done successfully many times with 4.x > releases, using the instructions from the handbook. I used a custom > kernel configuration which included 'options SMP' and 'device apic'. On > reboot dmesg confirmed that the custom kernel was used, however SMP was > not active and the additional CPUs were not launched. > > Thinking that perhaps my custom kernel conf was at fault, I compiled a > GENERIC smp kernel with: > > # cd /usr/obj > # chflags -R noschg * > # rm -rf * > /usr/src/# make buildkernel KERNCONF=SMP > /usr/src/# make installkernel KERNCONF=SMP > > After reboot the dmesg output is as follows: > > FreeBSD 5.3-RELEASE-p5 #0: Thu Mar 24 14:37:29 GMT 2005 > greg@[snip].warprecords.com:/usr/obj/usr/src/sys/SMP > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2799.22-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 > > Features=0xbfebf9ff CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Hyperthreading: 2 logical CPUs > real memory = 2147459072 (2047 MB) > avail memory = 2095996928 (1998 MB) > npx0: [FAST] > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x920-0x923 on acpi0 > cpu0: on acpi0 > acpi_tz0: on acpi0 > pcib0: on acpi0 > ACPI link \\_SB_.IN31 has invalid initial irq 3, ignoring > pci0: on pcib0 > pci0: at device 3.0 (no driver attached) > ciss0: port 0x2800-0x28ff mem > 0xf5df0000-0xf5df3fff,0xf5f80000-0xf5fbffff irq 11 at device 4.0 on > pci0 > ciss0: [GIANT-LOCKED] > pci0: at device 5.0 (no driver attached) > pci0: at device 5.2 (no driver attached) > isab0: at device 15.0 on pci0 > isa0: on isab0 > atapci0: port > 0x2000-0x200f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.1 on > pci0 > ata0: channel #0 on atapci0 > ata1: channel #1 on atapci0 > ohci0: mem 0xf5e70000-0xf5e70fff irq 10 > at device 15.2 on pci0 > ohci0: [GIANT-LOCKED] > usb0: OHCI version 1.0, legacy support > usb0: SMM does not respond, resetting > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 4 ports with 4 removable, self powered > pcib1: on acpi0 > pci1: on pcib1 > bge0: mem > 0xf7ef0000-0xf7efffff irq 11 at device 2.0 on pci1 > miibus0: on bge0 > brgphy0: on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX-FDX, auto > bge0: Ethernet address: 00:11:85:6b:07:d8 > pcib2: on acpi0 > pci4: on pcib2 > bge1: mem > 0xf7ff0000-0xf7ffffff irq 15 at device 2.0 on pci4 > miibus1: on bge1 > brgphy1: on miibus1 > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX-FDX, auto > bge1: Ethernet address: 00:11:85:6b:07:db > atkbdc0: port 0x64,0x60 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > sio0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sio0: type 16550A > fdc0: port 0x3f2-0x3f5 irq 6 drq 2 on > acpi0 > fdc0: [FAST] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > orm0: at iomem > 0xee000-0xeffff,0xcc000-0xcd7ff,0xc8000-0xcbfff,0xc0000-0xc7fff on isa0 > pmtimer0 on isa0 > ppc0: parallel port not found. > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on > isa0 > Timecounter "TSC" frequency 2799224924 Hz quality 800 > Timecounters tick every 10.000 msec > acd0: CDROM at ata0-master PIO4 > da0 at ciss0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-0 device > da0: 135.168MB/s transfers > da0: 69459MB (142253280 512 byte sectors: 255H 32S/T 17433C) > Mounting root from ufs:/dev/da0s1a > > and > > ~> sysctl kern.smp.active > kern.smp.active: 0 > > I just don't understand why the kernel isn't running SMP. To my mind > it's either something in my method (most likely), a hardware problem, > or something odd in the way 5.3R detects the CPUs on the hardware. > > I have successfully compiled SMP kernels on identical hardware with > FreeBSD 4.8R. With the HTT 4 CPUs are launched as they should be here. > > Now I think about it I have another machine, a HP DL380 with a single > HTT Xeon processor, which is displaying the same problem. > > Thanks in advance. > > greg. DL380 g3 have build in iLO. Can your colo hookup that ethernet? That will allow you console access including power on/off, reset and you will be able to see faults (fan, power supply, etc.). I have a DL380 g3 with dual P4-3.2GHz 1MB L3 cache, the kern conf has just "options SMP" to make it work. Here is the top part and bottom part of dmesg from boot: Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-STABLE #0: Sun Feb 20 17:42:41 PST 2005 root@evil.alameda.net:/usr/obj/usr/src/sys/EVIL Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3183.19-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf25 Stepping = 5 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 4026507264 (3839 MB) avail memory = 3941990400 (3759 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard ioapic2 irqs 32-47 on motherboard ioapic3 irqs 48-63 on motherboard npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x920-0x923 on acpi0 cpu0: on acpi0 cpu1: on acpi0 ... SMP: AP CPU #1 Launched! ... kern.smp.active: 1 kern.smp.disabled: 0 kern.smp.cpus: 2 This box was running 5.2.1 before so I am very sure SMP will work on it. -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://seven.Alameda.net/~ulf/resume.html From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 28 22:49:16 2005 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 2B11116A4CE for ; Mon, 28 Mar 2005 22:49:16 +0000 (GMT) Received: from mail23.sea5.speakeasy.net (mail23.sea5.speakeasy.net [69.17.117.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id B34FC43D2D for ; Mon, 28 Mar 2005 22:49:15 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 8049 invoked from network); 28 Mar 2005 22:49:15 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 28 Mar 2005 22:49:14 -0000 Received: from [10.50.41.231] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j2SMn8Ck003417; Mon, 28 Mar 2005 17:49:08 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-hackers@FreeBSD.org Date: Mon, 28 Mar 2005 17:48:55 -0500 User-Agent: KMail/1.6.2 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <200503281748.55388.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: Greg Eden Subject: Re: FreeBSD 5.3R SMP Kernel not detecting 2nd CPU in a HP DL360(?) 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, 28 Mar 2005 22:49:16 -0000 On Monday 28 March 2005 03:51 pm, Greg Eden wrote: > Hello All, > > I have a co-located HP DL360 G3 server to which I do not have physical > access. It has 2 x 2.8GHz Xeon CPUs with HTT. One of the ISP's > engineers has confirmed that both CPUs are detected when the BIOS > POSTs. > > I have cvsup'd to the latest 5.3R security release and successfully > built 'world', something I have done successfully many times with 4.x > releases, using the instructions from the handbook. I used a custom > kernel configuration which included 'options SMP' and 'device apic'. On > reboot dmesg confirmed that the custom kernel was used, however SMP was > not active and the additional CPUs were not launched. > > Thinking that perhaps my custom kernel conf was at fault, I compiled a > GENERIC smp kernel with: > > # cd /usr/obj > # chflags -R noschg * > # rm -rf * > /usr/src/# make buildkernel KERNCONF=SMP > /usr/src/# make installkernel KERNCONF=SMP > > After reboot the dmesg output is as follows: > > FreeBSD 5.3-RELEASE-p5 #0: Thu Mar 24 14:37:29 GMT 2005 > greg@[snip].warprecords.com:/usr/obj/usr/src/sys/SMP > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2799.22-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 > > Features=0xbfebf9ff CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Hyperthreading: 2 logical CPUs > real memory = 2147459072 (2047 MB) > avail memory = 2095996928 (1998 MB) > npx0: [FAST] > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x920-0x923 on acpi0 > cpu0: on acpi0 > acpi_tz0: on acpi0 > pcib0: on acpi0 > ACPI link \\_SB_.IN31 has invalid initial irq 3, ignoring > pci0: on pcib0 > pci0: at device 3.0 (no driver attached) > ciss0: port 0x2800-0x28ff mem > 0xf5df0000-0xf5df3fff,0xf5f80000-0xf5fbffff irq 11 at device 4.0 on > pci0 > ciss0: [GIANT-LOCKED] > pci0: at device 5.0 (no driver attached) > pci0: at device 5.2 (no driver attached) > isab0: at device 15.0 on pci0 > isa0: on isab0 > atapci0: port > 0x2000-0x200f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.1 on > pci0 > ata0: channel #0 on atapci0 > ata1: channel #1 on atapci0 > ohci0: mem 0xf5e70000-0xf5e70fff irq 10 > at device 15.2 on pci0 > ohci0: [GIANT-LOCKED] > usb0: OHCI version 1.0, legacy support > usb0: SMM does not respond, resetting > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 4 ports with 4 removable, self powered > pcib1: on acpi0 > pci1: on pcib1 > bge0: mem > 0xf7ef0000-0xf7efffff irq 11 at device 2.0 on pci1 > miibus0: on bge0 > brgphy0: on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX-FDX, auto > bge0: Ethernet address: 00:11:85:6b:07:d8 > pcib2: on acpi0 > pci4: on pcib2 > bge1: mem > 0xf7ff0000-0xf7ffffff irq 15 at device 2.0 on pci4 > miibus1: on bge1 > brgphy1: on miibus1 > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX-FDX, auto > bge1: Ethernet address: 00:11:85:6b:07:db > atkbdc0: port 0x64,0x60 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > sio0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sio0: type 16550A > fdc0: port 0x3f2-0x3f5 irq 6 drq 2 on > acpi0 > fdc0: [FAST] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > orm0: at iomem > 0xee000-0xeffff,0xcc000-0xcd7ff,0xc8000-0xcbfff,0xc0000-0xc7fff on isa0 > pmtimer0 on isa0 > ppc0: parallel port not found. > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on > isa0 > Timecounter "TSC" frequency 2799224924 Hz quality 800 > Timecounters tick every 10.000 msec > acd0: CDROM at ata0-master PIO4 > da0 at ciss0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-0 device > da0: 135.168MB/s transfers > da0: 69459MB (142253280 512 byte sectors: 255H 32S/T 17433C) > Mounting root from ufs:/dev/da0s1a > > and > > ~> sysctl kern.smp.active > kern.smp.active: 0 > > I just don't understand why the kernel isn't running SMP. To my mind > it's either something in my method (most likely), a hardware problem, > or something odd in the way 5.3R detects the CPUs on the hardware. > > I have successfully compiled SMP kernels on identical hardware with > FreeBSD 4.8R. With the HTT 4 CPUs are launched as they should be here. > > Now I think about it I have another machine, a HP DL380 with a single > HTT Xeon processor, which is displaying the same problem. > > Thanks in advance. > > greg. It's not finding an APIC table (either MPTable or MADT) at all, and it needs that to find CPUs. See if there are any BIOS options for things like MP Table or 'Separate APIC Table' under ACPI. Also, try running 'mptable' to see if it finds a table, and acpidump -t to see if that finds an APIC table. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 28 22:52:50 2005 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 AFC9E16A4CE for ; Mon, 28 Mar 2005 22:52:50 +0000 (GMT) Received: from seven.Alameda.net (seven.alameda.net [64.81.53.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EC9143D1D for ; Mon, 28 Mar 2005 22:52:50 +0000 (GMT) (envelope-from ulf@Alameda.net) Received: by seven.Alameda.net (Postfix, from userid 1000) id 085B63A201; Mon, 28 Mar 2005 14:52:49 -0800 (PST) Date: Mon, 28 Mar 2005 14:52:49 -0800 From: Ulf Zimmermann To: Greg Eden Message-ID: <20050328225249.GC13841@seven.alameda.net> References: <200503281748.55388.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503281748.55388.jhb@FreeBSD.org> Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 4.10-RELEASE-p2 User-Agent: Mutt/1.5.6i cc: freebsd-hackers@FreeBSD.org Subject: Re: FreeBSD 5.3R SMP Kernel not detecting 2nd CPU in a HP DL360(?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ulf@Alameda.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2005 22:52:50 -0000 On Mon, Mar 28, 2005 at 05:48:55PM -0500, John Baldwin wrote: > On Monday 28 March 2005 03:51 pm, Greg Eden wrote: > > Hello All, > > > > I have a co-located HP DL360 G3 server to which I do not have physical > > access. It has 2 x 2.8GHz Xeon CPUs with HTT. One of the ISP's > > engineers has confirmed that both CPUs are detected when the BIOS > > POSTs. > > > > I have cvsup'd to the latest 5.3R security release and successfully > > built 'world', something I have done successfully many times with 4.x > > releases, using the instructions from the handbook. I used a custom > > kernel configuration which included 'options SMP' and 'device apic'. On > > reboot dmesg confirmed that the custom kernel was used, however SMP was > > not active and the additional CPUs were not launched. > > > > Thinking that perhaps my custom kernel conf was at fault, I compiled a > > GENERIC smp kernel with: > > > > # cd /usr/obj > > # chflags -R noschg * > > # rm -rf * > > /usr/src/# make buildkernel KERNCONF=SMP > > /usr/src/# make installkernel KERNCONF=SMP > > > > After reboot the dmesg output is as follows: > > > > FreeBSD 5.3-RELEASE-p5 #0: Thu Mar 24 14:37:29 GMT 2005 > > greg@[snip].warprecords.com:/usr/obj/usr/src/sys/SMP > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2799.22-MHz 686-class CPU) > > Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 > > > > Features=0xbfebf9ff > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > Hyperthreading: 2 logical CPUs > > real memory = 2147459072 (2047 MB) > > avail memory = 2095996928 (1998 MB) > > npx0: [FAST] > > npx0: on motherboard > > npx0: INT 16 interface > > acpi0: on motherboard > > acpi0: Power Button (fixed) > > Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 > > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x920-0x923 on acpi0 > > cpu0: on acpi0 > > acpi_tz0: on acpi0 > > pcib0: on acpi0 > > ACPI link \\_SB_.IN31 has invalid initial irq 3, ignoring > > pci0: on pcib0 > > pci0: at device 3.0 (no driver attached) > > ciss0: port 0x2800-0x28ff mem > > 0xf5df0000-0xf5df3fff,0xf5f80000-0xf5fbffff irq 11 at device 4.0 on > > pci0 > > ciss0: [GIANT-LOCKED] > > pci0: at device 5.0 (no driver attached) > > pci0: at device 5.2 (no driver attached) > > isab0: at device 15.0 on pci0 > > isa0: on isab0 > > atapci0: port > > 0x2000-0x200f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.1 on > > pci0 > > ata0: channel #0 on atapci0 > > ata1: channel #1 on atapci0 > > ohci0: mem 0xf5e70000-0xf5e70fff irq 10 > > at device 15.2 on pci0 > > ohci0: [GIANT-LOCKED] > > usb0: OHCI version 1.0, legacy support > > usb0: SMM does not respond, resetting > > usb0: on ohci0 > > usb0: USB revision 1.0 > > uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > > uhub0: 4 ports with 4 removable, self powered > > pcib1: on acpi0 > > pci1: on pcib1 > > bge0: mem > > 0xf7ef0000-0xf7efffff irq 11 at device 2.0 on pci1 > > miibus0: on bge0 > > brgphy0: on miibus0 > > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > > 1000baseTX-FDX, auto > > bge0: Ethernet address: 00:11:85:6b:07:d8 > > pcib2: on acpi0 > > pci4: on pcib2 > > bge1: mem > > 0xf7ff0000-0xf7ffffff irq 15 at device 2.0 on pci4 > > miibus1: on bge1 > > brgphy1: on miibus1 > > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > > 1000baseTX-FDX, auto > > bge1: Ethernet address: 00:11:85:6b:07:db > > atkbdc0: port 0x64,0x60 irq 1 on acpi0 > > atkbd0: irq 1 on atkbdc0 > > kbd0 at atkbd0 > > atkbd0: [GIANT-LOCKED] > > sio0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > > sio0: type 16550A > > fdc0: port 0x3f2-0x3f5 irq 6 drq 2 on > > acpi0 > > fdc0: [FAST] > > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > > orm0: at iomem > > 0xee000-0xeffff,0xcc000-0xcd7ff,0xc8000-0xcbfff,0xc0000-0xc7fff on isa0 > > pmtimer0 on isa0 > > ppc0: parallel port not found. > > sc0: at flags 0x100 on isa0 > > sc0: VGA <16 virtual consoles, flags=0x300> > > sio1: configured irq 3 not in bitmap of probed irqs 0 > > sio1: port may not be enabled > > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on > > isa0 > > Timecounter "TSC" frequency 2799224924 Hz quality 800 > > Timecounters tick every 10.000 msec > > acd0: CDROM at ata0-master PIO4 > > da0 at ciss0 bus 0 target 0 lun 0 > > da0: Fixed Direct Access SCSI-0 device > > da0: 135.168MB/s transfers > > da0: 69459MB (142253280 512 byte sectors: 255H 32S/T 17433C) > > Mounting root from ufs:/dev/da0s1a > > > > and > > > > ~> sysctl kern.smp.active > > kern.smp.active: 0 > > > > I just don't understand why the kernel isn't running SMP. To my mind > > it's either something in my method (most likely), a hardware problem, > > or something odd in the way 5.3R detects the CPUs on the hardware. > > > > I have successfully compiled SMP kernels on identical hardware with > > FreeBSD 4.8R. With the HTT 4 CPUs are launched as they should be here. > > > > Now I think about it I have another machine, a HP DL380 with a single > > HTT Xeon processor, which is displaying the same problem. > > > > Thanks in advance. > > > > greg. > > It's not finding an APIC table (either MPTable or MADT) at all, and it needs > that to find CPUs. See if there are any BIOS options for things like MP > Table or 'Separate APIC Table' under ACPI. Also, try running 'mptable' to > see if it finds a table, and acpidump -t to see if that finds an APIC table. The DL380 g3 BIOS has different APIC settings for different OS. There is one setting in the main menu and then under advanced options is another menu for APIC. -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://seven.Alameda.net/~ulf/resume.html From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 28 23:02:07 2005 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 D0E6F16A4CF for ; Mon, 28 Mar 2005 23:02:07 +0000 (GMT) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BA3E43D49 for ; Mon, 28 Mar 2005 23:02:06 +0000 (GMT) (envelope-from myself@rojer.pp.ru) Received: from [213.141.131.116] (account rojer@rbc.ru HELO [192.168.10.3]) by hermes.hw.ru (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 75660785; Tue, 29 Mar 2005 03:02:04 +0400 Message-ID: <42488CEA.2020507@rojer.pp.ru> Date: Tue, 29 Mar 2005 03:02:02 +0400 From: Rojer User-Agent: Mozilla Thunderbird 1.0.1 (X11/20050307) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ulf@Alameda.net References: <20050328221531.GA13841@seven.alameda.net> In-Reply-To: <20050328221531.GA13841@seven.alameda.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050701000700080601060006" cc: freebsd-hackers@freebsd.org cc: Greg Eden Subject: Re: FreeBSD 5.3R SMP Kernel not detecting 2nd CPU in a HP DL360(?) 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, 28 Mar 2005 23:02:08 -0000 This is a cryptographically signed message in MIME format. --------------ms050701000700080601060006 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Ulf Zimmermann wrote: > > I have a DL380 g3 with dual P4-3.2GHz 1MB L3 cache, the kern conf has > just "options SMP" to make it work. Here is the top part and bottom part > of dmesg from boot: > ... > > SMP: AP CPU #1 Launched! > > ... > > kern.smp.active: 1 > kern.smp.disabled: 0 > kern.smp.cpus: 2 you should see 4 cpus "launching", assuming you haven't disabled hyperthreading. in fact, i have seen similar situation myself. FreeBSD would not recognize second physical CPU with hyperthreading enabled. it'd launch cpu #1 but not cpus 2 and 3. after eventually noticing it, i tried disabling hyperthreading in BIOS - it worked fine. i still had 2 cpus, but this time 2 physical cpus, and lower cpu load figures confirmed that those 2 "previous" cpus were in fact one physical + 1 hyperdreaded :) and this is not a problem of the particular server, i actually tried replacing the platform (moved hdds to the same box nearby) and it behaved in exactly the same manner. the platform is Fujitsu RX200 (2 x 2.8 Xeon), OS is FreeBSD 4.11-PRERELEASE. i still kinda have a box to play with (can bring it down to test during weekend), so if someone can offer insight, i can provide more info and maybe even a short-term remote ssh/serial console access. -- Deomid Ryabkov aka Rojer myself@rojer.pp.ru rojer@sysadmins.ru ICQ: 8025844 --------------ms050701000700080601060006 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJIzCC AuwwggJVoAMCAQICAwwKdjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwMzMxMjIxODA5WhcNMDUwMzMxMjIxODA5 WjBfMRAwDgYDVQQEEwdSeWFia292MQ8wDQYDVQQqEwZEZW9taWQxFzAVBgNVBAMTDkRlb21p ZCBSeWFia292MSEwHwYJKoZIhvcNAQkBFhJteXNlbGZAcm9qZXIucHAucnUwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBxXgFP/1lZDqp0dzUDzR5IBb7aKki6TD+HMMkRjtP IOcaNHsfoDer9RFrFICoxNQZF86iopYFVYr7msgB9y2dKZTRQQoOA72lFrOyH3sgrztx/3LL axEsihA2cxcrglrIgPEm6FF2aabbKVpSdeslMCDPBr0auAm0QLo8ch9c5j0vuQUBrs8TKU6f 6YZLNO2Sk/fPZP2kfJEkXyZhkU6wq3ER1CHq2qgfNpW2Ni7Kuv/eYI/CV1BGgm37ZPubOyxI LNiRUGT0pv0wocrCIehKqoI1uFPZgGS0ANYTqPJQSdjlSzMGQJjT510PNDJnDfKOvLhcadD+ 6gSL/ovNM/LPAgMBAAGjLzAtMB0GA1UdEQQWMBSBEm15c2VsZkByb2plci5wcC5ydTAMBgNV HRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBACunC6DhFX4I6Nvdy/UevjSd3VmKWPRmqwoR l0RXvuI/JVyPO9KHGqxCMpRu7ArJz7d8ShPVs5kynysrB+Nm6/fwWjeaW21+gViojeO9gGP6 Np/LeMIqkqSYMoElq7Feqh/3qp7a/UxuofFtAW9V/2tRunxaPo4/WOxcdcmdcC86MIIC7DCC AlWgAwIBAgIDDAp2MA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDAzMzEyMjE4MDlaFw0wNTAzMzEyMjE4MDlaMF8x EDAOBgNVBAQTB1J5YWJrb3YxDzANBgNVBCoTBkRlb21pZDEXMBUGA1UEAxMORGVvbWlkIFJ5 YWJrb3YxITAfBgkqhkiG9w0BCQEWEm15c2VsZkByb2plci5wcC5ydTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMHFeAU//WVkOqnR3NQPNHkgFvtoqSLpMP4cwyRGO08g5xo0 ex+gN6v1EWsUgKjE1BkXzqKilgVVivuayAH3LZ0plNFBCg4DvaUWs7IfeyCvO3H/cstrESyK EDZzFyuCWsiA8SboUXZpptspWlJ16yUwIM8GvRq4CbRAujxyH1zmPS+5BQGuzxMpTp/phks0 7ZKT989k/aR8kSRfJmGRTrCrcRHUIeraqB82lbY2Lsq6/95gj8JXUEaCbftk+5s7LEgs2JFQ ZPSm/TChysIh6EqqgjW4U9mAZLQA1hOo8lBJ2OVLMwZAmNPnXQ80MmcN8o68uFxp0P7qBIv+ i80z8s8CAwEAAaMvMC0wHQYDVR0RBBYwFIESbXlzZWxmQHJvamVyLnBwLnJ1MAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAK6cLoOEVfgjo293L9R6+NJ3dWYpY9GarChGXRFe+ 4j8lXI870ocarEIylG7sCsnPt3xKE9WzmTKfKysH42br9/BaN5pbbX6BWKiN472AY/o2n8t4 wiqSpJgygSWrsV6qH/eqntr9TG6h8W0Bb1X/a1G6fFo+jj9Y7Fx1yZ1wLzowggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZy ZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHy v1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsY Pge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0T AQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQe MBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD 6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZ GwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECAwwKdjAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTAzMjgyMzAyMDJaMCMGCSqGSIb3DQEJ BDEWBBQC4Myh5qVlj2tDteUH7DakhMZJizBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg SXNzdWluZyBDQQIDDAp2MHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwwKdjANBgkqhkiG9w0BAQEFAASCAQBS+Gpc TbmzmrIzCa2iK9vbCdfVAe9iEPH5NQk2Dde+cLAlGE/yrm4wytvBrO40oKerojnm79JbmduT mu0tTANC+9jjjac9W8lm6kiM9o2a2hawv8AHGPqv0iNP873bZvzcIN6u+ci/dqIUd0sM7vj1 8w41aSkUxCTh1Wk3DO90WTO+UK0Dw/3yc2+ynCSfQUqRtrOggAhgdUNQum3pvZz/bpepavm1 sVOUcJd28mSLv71saTb3+9MISzakPq9GbYnMAbpVJCYQOmnclkWBWaSCRabf5tnmI8gLFWFp GGvvWkKNnBR+BQwmSzddE6FnN7YP9MG0/PFT1G/8sLKAJOVKAAAAAAAA --------------ms050701000700080601060006-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 28 23:12:26 2005 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 F1D4016A4CE for ; Mon, 28 Mar 2005 23:12:25 +0000 (GMT) Received: from seven.Alameda.net (seven.alameda.net [64.81.53.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3FC943D1F for ; Mon, 28 Mar 2005 23:12:25 +0000 (GMT) (envelope-from ulf@Alameda.net) Received: by seven.Alameda.net (Postfix, from userid 1000) id 626703A201; Mon, 28 Mar 2005 15:12:25 -0800 (PST) Date: Mon, 28 Mar 2005 15:12:25 -0800 From: Ulf Zimmermann To: Rojer Message-ID: <20050328231225.GD13841@seven.alameda.net> References: <20050328221531.GA13841@seven.alameda.net> <42488CEA.2020507@rojer.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42488CEA.2020507@rojer.pp.ru> Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 4.10-RELEASE-p2 User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org cc: ulf@Alameda.net cc: Greg Eden Subject: Re: FreeBSD 5.3R SMP Kernel not detecting 2nd CPU in a HP DL360(?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ulf@Alameda.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2005 23:12:26 -0000 On Tue, Mar 29, 2005 at 03:02:02AM +0400, Rojer wrote: > Ulf Zimmermann wrote: > > > >I have a DL380 g3 with dual P4-3.2GHz 1MB L3 cache, the kern conf has > >just "options SMP" to make it work. Here is the top part and bottom part > >of dmesg from boot: > >... > > > > >SMP: AP CPU #1 Launched! > > > >... > > > >kern.smp.active: 1 > >kern.smp.disabled: 0 > >kern.smp.cpus: 2 > > you should see 4 cpus "launching", assuming you haven't disabled > hyperthreading. > > in fact, i have seen similar situation myself. > FreeBSD would not recognize second physical CPU with hyperthreading enabled. > it'd launch cpu #1 but not cpus 2 and 3. > after eventually noticing it, i tried disabling hyperthreading in BIOS - > it worked fine. i still had 2 cpus, but this time 2 physical cpus, > and lower cpu load figures confirmed that those 2 "previous" cpus were in > fact > one physical + 1 hyperdreaded :) > and this is not a problem of the particular server, i actually tried > replacing > the platform (moved hdds to the same box nearby) and it behaved in exactly > the same manner. > the platform is Fujitsu RX200 (2 x 2.8 Xeon), OS is FreeBSD 4.11-PRERELEASE. > > i still kinda have a box to play with (can bring it down to test during > weekend), > so if someone can offer insight, i can provide more info and maybe even a > short-term > remote ssh/serial console access. I at least have HyperThreading turned off. So seeing 2 cpus is correctly: evil ulf /home/ulf > sysctl -a | grep cpu kern.threads.virtual_cpu: 2 kern.sched.ipiwakeup.onecpu: 0 kern.ccpu: 1948 kern.smp.maxcpus: 16 kern.smp.cpus: 2 debug.kdb.stop_cpus: 1 debug.PMAP1changedcpu: 5 hw.ncpu: 2 hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_usage: 100.00% -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://seven.Alameda.net/~ulf/resume.html From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 28 23:40:17 2005 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 E82F616A4CE for ; Mon, 28 Mar 2005 23:40:17 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54BB743D31 for ; Mon, 28 Mar 2005 23:40:09 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.21] (rat.samsco.home [192.168.254.21]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j2SNiADZ001016; Mon, 28 Mar 2005 16:44:16 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <42489555.6090304@samsco.org> Date: Mon, 28 Mar 2005 16:37:57 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.5) Gecko/20050321 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mohamed aslan References: <319cceca0503281001792baf39@mail.gmail.com> In-Reply-To: <319cceca0503281001792baf39@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: freebsd-hackers@freebsd.org Subject: Re: organization 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, 28 Mar 2005 23:40:18 -0000 mohamed aslan wrote: > hi guys > it's my first post here, BTW i was a linux hacker and linux kernel > mailing list member for 3 years. > > and i've a comment here , i think the freebsd kernel source files > aren't well organized as linux ones. I left a job last year where I developed linux kernel code professionally for almost 5 years. When I first looked at the linux tree, it took some time to get used to how it was layed out, but eventually it came naturally to my fingers. I've also used and developed *BSD kernel code for 12 years, so I know that layout too. And now I'm getting my hands dirty in the OSX/Darwin sources. To tell you the truth, it doesn't make a difference either way. If your concern with a software project is how the source tree is layed out, then I highly doubt we'll be seeing much contribution from you. Thanks. Scott From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 00:03:11 2005 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 78B7416A4CE; Tue, 29 Mar 2005 00:03:11 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [83.167.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A93AB43D31; Tue, 29 Mar 2005 00:03:10 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id F03F4652FE; Tue, 29 Mar 2005 00:59:59 +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 64544-04-6; Tue, 29 Mar 2005 00:59:59 +0100 (BST) Received: from empiric.dek.spc.org (dhcp52.icir.org [192.150.187.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 5016965218; Tue, 29 Mar 2005 00:59:59 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id BB7456893; Mon, 28 Mar 2005 16:03:06 -0800 (PST) Date: Mon, 28 Mar 2005 16:03:06 -0800 From: Bruce M Simpson To: Igor Shmukler Message-ID: <20050329000306.GD752@empiric.icir.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: hackers@freebsd.org cc: Robert Watson Subject: Re: name cache cont. 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, 29 Mar 2005 00:03:11 -0000 On Mon, Mar 28, 2005 at 05:42:52PM +0400, Igor Shmukler wrote: > For my purposes the Linux/DragonFly functionality is needed. > > Is there a way to know that once a patch that correctly resolves corner cases for > vn_fullpath() (including name cache changes) exists it will be committed to the 5.x > branch? Hey, I did some of this work quite some time ago. It is still floating around in the archives. I'm more than happy for people with more vfs knowledge than I to pick it up, review it, and commit it, but I don't have free time to do this right now. BMS From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 01:05:25 2005 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 7D90516A4CE; Tue, 29 Mar 2005 01:05:25 +0000 (GMT) Received: from f16.mail.ru (f16.mail.ru [194.67.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id D476643D46; Tue, 29 Mar 2005 01:05:24 +0000 (GMT) (envelope-from shmukler@mail.ru) Received: from mail by f16.mail.ru with local id 1DG5AU-0008eB-00; Tue, 29 Mar 2005 05:05:18 +0400 Received: from [24.185.245.215] by win.mail.ru with HTTP; Tue, 29 Mar 2005 05:05:18 +0400 From: Igor Shmukler To: Bruce M Simpson Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [24.185.245.215] Date: Tue, 29 Mar 2005 05:05:18 +0400 In-Reply-To: <20050329000306.GD752@empiric.icir.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: cc: hackers@freebsd.org cc: Robert Watson Subject: Re[2]: name cache cont. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Igor Shmukler List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2005 01:05:25 -0000 Bruce, Thank you for your reply. If you could email me a tarball, I would appreciate it. I don't have that much practical experience with FreeBSD name cache. However, I had some expeirence with other systems. I think the big question here do other developers agree that name cache could use some work. Obviously everything here is IMHO. Solaris has a very straightforward scalable cache. The FreeBSD cache is not bad, but as far as I understand issues I mentioned are a side-effect of design desicions aiming to lower pressure on the cache. I would very much be interested to know what Jeff and everyone else thinks about this. Is there a desire within the people who have hands-on expereience maintaining this part of FreeBSD to change the cache. I need d_path() like functionality for a specific kernel module. Right now, to get away, a secondary cache is implemented by intercepting open(2)/close(2). To minimize the amount of memory this cache needs (and keep to code simple) a dedicated kernel thread gc'es duplicate names from this cache, i.e. if vn_fullpath() works delete name from secondary cache). It's ugly, but it works for now. I would rather FreeBSD takes care of this for us. I am willing to contribute if folks who know VFS well, think it's a worthy cause. Igor. > > On Mon, Mar 28, 2005 at 05:42:52PM +0400, Igor Shmukler wrote: > > For my purposes the Linux/DragonFly functionality is needed. > > > > Is there a way to know that once a patch that correctly resolves corner cases for > > vn_fullpath() (including name cache changes) exists it will be committed to the 5.x > > branch? > > Hey, I did some of this work quite some time ago. It is still floating > around in the archives. I'm more than happy for people with more vfs > knowledge than I to pick it up, review it, and commit it, but I don't > have free time to do this right now. > > BMS From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 01:51:46 2005 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 3337016A4CE for ; Tue, 29 Mar 2005 01:51:46 +0000 (GMT) Received: from ms-smtp-03-eri0.southeast.rr.com (ms-smtp-03-lbl.southeast.rr.com [24.25.9.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84E6643D54 for ; Tue, 29 Mar 2005 01:51:45 +0000 (GMT) (envelope-from jason@ec.rr.com) Received: from [192.168.1.100] (cpe-065-184-201-054.ec.rr.com [65.184.201.54]) j2T1pfY4006555; Mon, 28 Mar 2005 20:51:42 -0500 (EST) Message-ID: <4248B723.80907@ec.rr.com> Date: Mon, 28 Mar 2005 21:02:11 -0500 From: jason henson User-Agent: Mozilla Thunderbird 1.0 (X11/20050321) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexander Leidinger References: <423C15C5.6040902@fsn.hu> <20050327133059.3d68a78c@Magellan.Leidinger.net> <20050327134044.GM78512@silverwraith.com> <20050327162839.2fafa6aa@Magellan.Leidinger.net> In-Reply-To: <20050327162839.2fafa6aa@Magellan.Leidinger.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine cc: hackers@freebsd.org Subject: Re: 5-STABLE kernel build with icc broken 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, 29 Mar 2005 01:51:46 -0000 Alexander Leidinger wrote: >On Sun, 27 Mar 2005 05:40:44 -0800 >Avleen Vig wrote: > > > >>On Sun, Mar 27, 2005 at 01:30:59PM +0200, Alexander Leidinger wrote: >> >> >>>>It seems to me that building kernel with icc is currently broken, at >>>>least in 5-STABLE. Could somebody investigate this? >>>> >>>> >>>I don't have a problem to compile it with a recent -current and a recent >>>icc (-stable not tested), but the resulting kernel imediatly panics >>>(page fault in _mtx_...()). >>> >>> >>Without intending to start any compiler holy wars, what benefits does >>ICC provide over GCC for the end user? >> >> > >Various: > - auto-vectorizer (no benefit for the kernel, since we can't use > FPU/SIMD instructions at any time... yet (interested hackers can > have a look how DragonFly handles it, I can provide the necessary > commit logs)) > > Are you implying DragonFly uses FPU/SIMD? For that matter does any kernel? Thanks, jason > - optimizations for Intel CPUs direct from the manufacturer of the CPU > (they have a lot of interest to produce very fast code) > - a different set of compiler warnings > - better code quality (if is compilable by more than one compiler it > may be more portable) > >Icc already pointed out some bad code (asm code in the IP checksumming >code... DragonFly changed it already), and the panic as noticed above >may also be an indication that we have some code in the tree which >smells bad. > >Bye, >Alexander. > > > From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 07:23:21 2005 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 1BAFD16A4CE for ; Tue, 29 Mar 2005 07:23:21 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 832F543D5A for ; Tue, 29 Mar 2005 07:23:20 +0000 (GMT) (envelope-from dleimbac@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so1518426rnf for ; Mon, 28 Mar 2005 23:23:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=n7kpm7M0Xj8AfXgLzLDnEWCayFgwo4FpWk27xUwjIinHpDpIhOePzX6U+Gl7WwEMNWwZO4WPn+SR48FpBzzGnriwwfayJgcr4zisxXW1UoSDPYgKUzzWOOPInsXo2OZDBPKQZHy9Z4XzeJHMsN/e9GUO3Y9iFju1JB1s9XjzzSo= Received: by 10.38.126.32 with SMTP id y32mr3144849rnc; Mon, 28 Mar 2005 23:23:19 -0800 (PST) Received: by 10.38.82.48 with HTTP; Mon, 28 Mar 2005 23:23:19 -0800 (PST) Message-ID: <5bbfe7d405032823232103d537@mail.gmail.com> Date: Mon, 28 Mar 2005 23:23:19 -0800 From: David Leimbach To: hackers@freebsd.org In-Reply-To: <5bbfe7d405032823144fc1af7b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <423C15C5.6040902@fsn.hu> <20050327133059.3d68a78c@Magellan.Leidinger.net> <20050327134044.GM78512@silverwraith.com> <20050327162839.2fafa6aa@Magellan.Leidinger.net> <5bbfe7d405032823144fc1af7b@mail.gmail.com> Subject: Fwd: 5-STABLE kernel build with icc broken X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Leimbach List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2005 07:23:21 -0000 meant to send this to the list too... sorry > Are you implying DragonFly uses FPU/SIMD? For that matter does any kernel? I believe it does use SIMD for some of it's fast memcopy stuff for it's messaging system actually. I remember Matt saying he was working on it. http://leaf.dragonflybsd.org/mailarchive/kernel/2004-04/msg00262.html If you can manage the alignment issues it can be a huge win. Dave > > Thanks, > jason > > > - optimizations for Intel CPUs direct from the manufacturer of the CPU > > (they have a lot of interest to produce very fast code) > > - a different set of compiler warnings > > - better code quality (if is compilable by more than one compiler it > > may be more portable) > > > >Icc already pointed out some bad code (asm code in the IP checksumming > >code... DragonFly changed it already), and the panic as noticed above > >may also be an indication that we have some code in the tree which > >smells bad. > > > >Bye, > >Alexander. > > > > > > > > _______________________________________________ > 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 Tue Mar 29 07:50:35 2005 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 9F72516A4CE for ; Tue, 29 Mar 2005 07:50:35 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBB0443D48 for ; Tue, 29 Mar 2005 07:50:34 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226])j2T7nnpZ027160 for ; Tue, 29 Mar 2005 10:49:49 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) j2T7oWtE017251 for ; Tue, 29 Mar 2005 10:50:32 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost)j2T7oW1l017250 for freebsd-hackers@freebsd.org; Tue, 29 Mar 2005 10:50:32 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Tue, 29 Mar 2005 10:50:32 +0300 From: Giorgos Keramidas To: freebsd-hackers@freebsd.org Message-ID: <20050329075032.GA15892@orion.daedalusnetworks.priv> References: <319cceca0503281001792baf39@mail.gmail.com> <4248557A.7000302@elischer.org> <20050328191758.GB3141@britannica.bec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050328191758.GB3141@britannica.bec.de> Subject: Re: organization 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, 29 Mar 2005 07:50:35 -0000 On 2005-03-28 21:17, Joerg Sonnenberger wrote: >On Mon, Mar 28, 2005 at 11:05:30AM -0800, Julian Elischer wrote: >> As things have changed, some of the original layout decisions have >> become rather outdated. For a slightly better example, check out the >> layout of the DragonflyBSD kernel sources. Matt took the oportunity >> to re-arange the FreeBSD sources when he imported them.. To some >> extent I agree with him (though not necessariy with his positioning >> of every file). > > I completely agree here, but it is difficult to get everything into > the perfect place. The NetBSD idea of moving i386 and the other platforms > into arch/ is also very nice. > >> It is possible that we could do with a reoganisation but it isn't a >> work-free job.. Matt took some time to get everything working >> again.. > > The biggest problem is keeping history here. Doing something like that > with CVS is a major PITA. We didn't have any old release, so moving > the repository files didn't create a problem. That's impossible in > FreeBSD land :) Not impossible. Just extremelly annoying, cumbersome and error-prone. A file may be repo-copied to a new location, then removed from the HEAD branch in the old location and deleted from the rest of the branches in the new location. This way the history will be there, in both places but the file will only 'live' in one place at a time. I go agree though that the work this requires for thousands of files is an immense task, not to be taken lightly. - Giorgos From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 09:57:24 2005 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 7F8CC16A4CF for ; Tue, 29 Mar 2005 09:57:24 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id D90B243D53 for ; Tue, 29 Mar 2005 09:57:23 +0000 (GMT) (envelope-from jumbler.chi@gmail.com) Received: by wproxy.gmail.com with SMTP id 36so5339wri for ; Tue, 29 Mar 2005 01:57:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=TOey0dNhi2LOuPGYZvOTJyIPIuhZbMWkFtDogABonk+HsHOetOh//bOx5EZhCpTsfMHuPxtusmCxML4CLAjp4Sj10HcgaBAf8mxNrrT2+/P9NijWGPUuWGHmNd1lbBVLmheVfB4yHqGMs3QIERHzAANMlQ8W4jsTXgeNnW4Gt7g= Received: by 10.54.20.43 with SMTP id 43mr72587wrt; Tue, 29 Mar 2005 01:57:23 -0800 (PST) Received: by 10.54.19.14 with HTTP; Tue, 29 Mar 2005 01:57:23 -0800 (PST) Message-ID: Date: Tue, 29 Mar 2005 17:57:23 +0800 From: jumbler chi To: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: FreeBSD on Bochs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jumbler chi List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2005 09:57:24 -0000 Hi All: I have a question about Freebsd on bochs. I'm interesting to build owner Freebsd scratch. Due the hardware limited , I want to run this scratch on Bochs. Therefore , I refered a article , http://sig9.com/articles/freebsd-on-bochs , to build a image under 5.2R. when I booted the image file under Bochs-2.0.2 .. it stoped on a prompt , mountroot > . The bochs' console screenshot is following lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 500159 Hz quality 800 Timecounters tick every 10.000 msec ad0: FAILURE - SETFEATURES ENABLE RCACHE status=41 error=4 ad0: FAILURE - SETFEATURES ENABLE WCACHE status=41 error=4 GEOM: create disk ad0 dp=0xc1a81e60 ad0: 511MB [1040/16/63] at ata0-master PIO2 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input ---------------------------------------------------------------------------------------------- the bochs' log records 00505152373i[HD ] SET FEATURES subcommand 0xaa not supported by disk. 00505289771i[HD ] SET FEATURES subcommand 0x02 not supported by disk. What's happen?! Did I miss something else ?! ps. my bochs configuration is as following -------------------------------------------------------------------------------------------------------------------------- megs: 64 romimage: file=$BXSHARE/BIOS-bochs-latest, address=0xf0000 vgaromimage: $BXSHARE/VGABIOS-lgpl-latest floppya: 1_44=/dev/fd0, status=ejected # hard disk ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14 ata0-master: type=disk, path="freebsd.img", mode=flat, cylinders=1040, heads=16, spt=63 boot: disk log: out.txt mouse: enabled=0 keyboard_mapping: enabled=1, map=$BXSHARE/keymaps/sdl-pc-us.map Regards Jumbler From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 11:11:10 2005 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 BBA5216A4CE for ; Tue, 29 Mar 2005 11:11:10 +0000 (GMT) Received: from mail20.syd.optusnet.com.au (mail20.syd.optusnet.com.au [211.29.132.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1983B43D3F for ; Tue, 29 Mar 2005 11:11:10 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j2TBB8Oj023208 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 29 Mar 2005 21:11:08 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j2TBB77l070109; Tue, 29 Mar 2005 21:11:07 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j2TBB7MK070108; Tue, 29 Mar 2005 21:11:07 +1000 (EST) (envelope-from pjeremy) Date: Tue, 29 Mar 2005 21:11:07 +1000 From: Peter Jeremy To: David Leimbach Message-ID: <20050329111107.GD69824@cirb503493.alcatel.com.au> References: <423C15C5.6040902@fsn.hu> <20050327133059.3d68a78c@Magellan.Leidinger.net> <20050327134044.GM78512@silverwraith.com> <20050327162839.2fafa6aa@Magellan.Leidinger.net> <5bbfe7d405032823144fc1af7b@mail.gmail.com> <5bbfe7d405032823232103d537@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5bbfe7d405032823232103d537@mail.gmail.com> User-Agent: Mutt/1.4.2i cc: hackers@freebsd.org Subject: Re: Fwd: 5-STABLE kernel build with icc broken 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, 29 Mar 2005 11:11:10 -0000 On Mon, 2005-Mar-28 23:23:19 -0800, David Leimbach wrote: >meant to send this to the list too... sorry >> Are you implying DragonFly uses FPU/SIMD? For that matter does any kernel? > >I believe it does use SIMD for some of it's fast memcopy stuff for >it's messaging system >actually. I remember Matt saying he was working on it. > >http://leaf.dragonflybsd.org/mailarchive/kernel/2004-04/msg00262.html That's almost a year ago and specifically for the amd64. Does anyone know what the results were? >If you can manage the alignment issues it can be a huge win. For message passing within the kernel, you should be able to mandate alignment as part of the API. I see the bigger issue being the need to save/restore the SIMD engine's state during a system call. Currently, this is only saved on if a different process wants to use the SIMD engine. For MMX, the SIMD state is the FPU state - which is non-trivial. The little reading I've done suggests that SSE and SSE2 are even larger. Saving the SIMD state would be more expensive that using integer registers for small (and probably medium-sized) copies. -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 11:20:06 2005 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 3F5B216A4CE; Tue, 29 Mar 2005 11:20:06 +0000 (GMT) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 913AD43D62; Tue, 29 Mar 2005 11:20:05 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j2TBK4ot017794 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 29 Mar 2005 21:20:04 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j2TBK37l070128; Tue, 29 Mar 2005 21:20:03 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j2TBK3gd070127; Tue, 29 Mar 2005 21:20:03 +1000 (EST) (envelope-from pjeremy) Date: Tue, 29 Mar 2005 21:20:03 +1000 From: Peter Jeremy To: Giorgos Keramidas Message-ID: <20050329112003.GE69824@cirb503493.alcatel.com.au> References: <319cceca0503281001792baf39@mail.gmail.com> <4248557A.7000302@elischer.org> <20050328191758.GB3141@britannica.bec.de> <20050329075032.GA15892@orion.daedalusnetworks.priv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050329075032.GA15892@orion.daedalusnetworks.priv> User-Agent: Mutt/1.4.2i cc: freebsd-hackers@freebsd.org Subject: Re: organization 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, 29 Mar 2005 11:20:06 -0000 On Tue, 2005-Mar-29 10:50:32 +0300, Giorgos Keramidas wrote: >A file may be repo-copied to a new location, then removed from the HEAD >branch in the old location and deleted from the rest of the branches in >the new location. This way the history will be there, in both places >but the file will only 'live' in one place at a time. At the cost of approximately doubling the repository size - ncvs/src/sys is currently abut 366MB. There are an awful lot of repository copies lying around and even at current disk prices, the total cost in dollars is non-trivial. The bigger cost is developer time - kernel developers are familiar with the current re-organisation. It will probably take at least a month for a developer to get used to a new organisation. Multiply that by the number of developers and there's an awful lot of lost productive time. The new layout would have to offer really good incentives to have a net benefit. -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 10:18:28 2005 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 96FB016A4CE for ; Tue, 29 Mar 2005 10:18:28 +0000 (GMT) Received: from smtp.ucla.edu (smtp.ucla.edu [169.232.48.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 590EC43D60 for ; Tue, 29 Mar 2005 10:18:28 +0000 (GMT) (envelope-from ashcs@ucla.edu) Received: from mail.ucla.edu (mail.ucla.edu [169.232.48.135]) by smtp.ucla.edu (8.13.1/8.13.1) with ESMTP id j2TAISkJ007382 for ; Tue, 29 Mar 2005 02:18:28 -0800 Received: from ash (s226-171.resnet.ucla.edu [164.67.226.171]) (authenticated bits=0) by mail.ucla.edu (8.13.3/8.13.3) with ESMTP id j2TAIRQO019647 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 29 Mar 2005 02:18:27 -0800 Message-ID: <000801c53448$b0987bc0$abe243a4@ash> From: "Ashwin Chandra" To: Date: Tue, 29 Mar 2005 02:18:45 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Probable-Spam: no X-Spam-Hits: 0.028 X-Scanned-By: smtp.ucla.edu X-Mailman-Approved-At: Tue, 29 Mar 2005 13:05:56 +0000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Interrupt Service Routines 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, 29 Mar 2005 10:18:28 -0000 Do you guys know of any example code of ISR's in the kernel? Ash From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 11:24:48 2005 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 D1BD116A4CE for ; Tue, 29 Mar 2005 11:24:48 +0000 (GMT) Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCB8A43D5A for ; Tue, 29 Mar 2005 11:24:47 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd25.aul.t-online.de by mailout09.sul.t-online.com with smtp id 1DGEpy-0004ko-03; Tue, 29 Mar 2005 13:24:46 +0200 Received: from Andro-Beta.Leidinger.net (Xd36AaZDoeq5zDt9jZw2+SDJKCVqXU5y7p05nuO8py5fccHhZx6LYi@[217.229.214.41]) by fwd25.sul.t-online.de with esmtp id 1DGEpn-1hfjGa0; Tue, 29 Mar 2005 13:24:35 +0200 Received: from localhost (localhost [127.0.0.1])j2TBNA15039526; Tue, 29 Mar 2005 13:23:10 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from 141.113.101.32 ([141.113.101.32]) by netchild.homeip.net (Horde) with HTTP for ; Tue, 29 Mar 2005 13:23:09 +0200 Message-ID: <20050329132309.v3ylwk2pesk8g80c@netchild.homeip.net> X-Priority: 3 (Normal) Date: Tue, 29 Mar 2005 13:23:09 +0200 From: Alexander Leidinger To: jason henson References: <423C15C5.6040902@fsn.hu> <20050327133059.3d68a78c@Magellan.Leidinger.net> <20050327134044.GM78512@silverwraith.com><4248B723.80907@ec.rr.com> In-Reply-To: <4248B723.80907@ec.rr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.2) / FreeBSD-4.11 X-ID: Xd36AaZDoeq5zDt9jZw2+SDJKCVqXU5y7p05nuO8py5fccHhZx6LYi@t-dialin.net X-TOI-MSGID: 2cbaeee2-de4a-4b38-aa5a-d9ca5dcb4a4f X-Mailman-Approved-At: Tue, 29 Mar 2005 13:05:56 +0000 cc: hackers@freebsd.org Subject: Re: 5-STABLE kernel build with icc broken 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, 29 Mar 2005 11:24:49 -0000 jason henson wrote: > >Various: > > - auto-vectorizer (no benefit for the kernel, since we can't use > > FPU/SIMD instructions at any time... yet (interested hackers can > > have a look how DragonFly handles it, I can provide the necessary > > commit logs)) > > > > Are you implying DragonFly uses FPU/SIMD? For that matter does any kernel? AFAIK DragonFly _allows_ code to use the FPU/SIMD in the kernel. And AFAIR they use SIMD in b{copy,zero} (we do this too, but we do this is in a "controlled environment" whereas DFly just allows the use of FPU/SIMD in an "use as you like" manner everywhere). Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 Closet extrovert. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 13:12:57 2005 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 9455716A4CE for ; Tue, 29 Mar 2005 13:12:57 +0000 (GMT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id B7DBE43D48 for ; Tue, 29 Mar 2005 13:12:56 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 29 Mar 2005 14:12:56 +0100 (BST) Date: Tue, 29 Mar 2005 14:12:53 +0100 From: David Malone To: Peter Jeremy Message-ID: <20050329131253.GA29144@walton.maths.tcd.ie> References: <423C15C5.6040902@fsn.hu> <20050327133059.3d68a78c@Magellan.Leidinger.net> <20050327134044.GM78512@silverwraith.com> <20050327162839.2fafa6aa@Magellan.Leidinger.net> <5bbfe7d405032823144fc1af7b@mail.gmail.com> <5bbfe7d405032823232103d537@mail.gmail.com> <20050329111107.GD69824@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050329111107.GD69824@cirb503493.alcatel.com.au> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie cc: David Leimbach cc: hackers@freebsd.org Subject: Re: Fwd: 5-STABLE kernel build with icc broken 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, 29 Mar 2005 13:12:57 -0000 On Tue, Mar 29, 2005 at 09:11:07PM +1000, Peter Jeremy wrote: > That's almost a year ago and specifically for the amd64. Does anyone > know what the results were? I had a quick dig around on cvsweb this morning: http://grappa.unix-ag.uni-kl.de/cgi-bin/cvsweb/src/sys/i386/i386/bcopy.s?cvsroot=dragonfly I dunno if Matt has benchmarks for before and after. David. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 13:18:32 2005 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 C86EA16A4CE; Tue, 29 Mar 2005 13:18:32 +0000 (GMT) Received: from smp500.sitetronics.com (sitetronics.com [82.192.77.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F35143D4C; Tue, 29 Mar 2005 13:18:32 +0000 (GMT) (envelope-from dodell@offmyserver.com) Received: from localhost.sitetronics.com ([127.0.0.1] helo=smp500.sitetronics.com) by smp500.sitetronics.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DGGaY-0000Dv-CK; Tue, 29 Mar 2005 15:16:58 +0200 Received: (from dodell@localhost) by smp500.sitetronics.com (8.12.11/8.12.11/Submit) id j2TDGv6e000862; Tue, 29 Mar 2005 15:16:57 +0200 (CEST) (envelope-from dodell@offmyserver.com) X-Authentication-Warning: smp500.sitetronics.com: dodell set sender to dodell@offmyserver.com using -f Date: Tue, 29 Mar 2005 15:16:57 +0200 From: "Devon H. O'Dell " To: freebsd-hackers@freebsd.org, hackers@freebsd.org Message-ID: <20050329131657.GI79414@smp500.sitetronics.com> Mail-Followup-To: freebsd-hackers@freebsd.org, hackers@freebsd.org References: <423C15C5.6040902@fsn.hu> <20050327133059.3d68a78c@Magellan.Leidinger.net> <20050327134044.GM78512@silverwraith.com> <20050327162839.2fafa6aa@Magellan.Leidinger.net> <5bbfe7d405032823144fc1af7b@mail.gmail.com> <5bbfe7d405032823232103d537@mail.gmail.com> <20050329111107.GD69824@cirb503493.alcatel.com.au> <20050329131253.GA29144@walton.maths.tcd.ie> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y9PDtDHaFrXNoMPU" Content-Disposition: inline In-Reply-To: <20050329131253.GA29144@walton.maths.tcd.ie> User-Agent: Mutt/1.5.8i Subject: Re: Fwd: 5-STABLE kernel build with icc broken 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, 29 Mar 2005 13:18:32 -0000 --y9PDtDHaFrXNoMPU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 29, 2005 at 02:12:53PM +0100, David Malone wrote: > On Tue, Mar 29, 2005 at 09:11:07PM +1000, Peter Jeremy wrote: > > That's almost a year ago and specifically for the amd64. Does anyone > > know what the results were? >=20 > I had a quick dig around on cvsweb this morning: >=20 > http://grappa.unix-ag.uni-kl.de/cgi-bin/cvsweb/src/sys/i386/i386/bcopy.s= ?cvsroot=3Ddragonfly >=20 >=20 > I dunno if Matt has benchmarks for before and after. >=20 > David. I believe it was asserted on the list that the modification doubled the performance. I have not tested this. --Devon --y9PDtDHaFrXNoMPU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCSVVJSkf3jVXOdl0RAqqFAJ0XUJklEODt26HckEQXI7MblhBSmgCfVTRl rU2T1lTvu6CJUUEEpA39qZ0= =7YtI -----END PGP SIGNATURE----- --y9PDtDHaFrXNoMPU-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 13:18:32 2005 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 C86EA16A4CE; Tue, 29 Mar 2005 13:18:32 +0000 (GMT) Received: from smp500.sitetronics.com (sitetronics.com [82.192.77.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F35143D4C; Tue, 29 Mar 2005 13:18:32 +0000 (GMT) (envelope-from dodell@offmyserver.com) Received: from localhost.sitetronics.com ([127.0.0.1] helo=smp500.sitetronics.com) by smp500.sitetronics.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DGGaY-0000Dv-CK; Tue, 29 Mar 2005 15:16:58 +0200 Received: (from dodell@localhost) by smp500.sitetronics.com (8.12.11/8.12.11/Submit) id j2TDGv6e000862; Tue, 29 Mar 2005 15:16:57 +0200 (CEST) (envelope-from dodell@offmyserver.com) X-Authentication-Warning: smp500.sitetronics.com: dodell set sender to dodell@offmyserver.com using -f Date: Tue, 29 Mar 2005 15:16:57 +0200 From: "Devon H. O'Dell " To: freebsd-hackers@freebsd.org, hackers@freebsd.org Message-ID: <20050329131657.GI79414@smp500.sitetronics.com> Mail-Followup-To: freebsd-hackers@freebsd.org, hackers@freebsd.org References: <423C15C5.6040902@fsn.hu> <20050327133059.3d68a78c@Magellan.Leidinger.net> <20050327134044.GM78512@silverwraith.com> <20050327162839.2fafa6aa@Magellan.Leidinger.net> <5bbfe7d405032823144fc1af7b@mail.gmail.com> <5bbfe7d405032823232103d537@mail.gmail.com> <20050329111107.GD69824@cirb503493.alcatel.com.au> <20050329131253.GA29144@walton.maths.tcd.ie> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y9PDtDHaFrXNoMPU" Content-Disposition: inline In-Reply-To: <20050329131253.GA29144@walton.maths.tcd.ie> User-Agent: Mutt/1.5.8i Subject: Re: Fwd: 5-STABLE kernel build with icc broken 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, 29 Mar 2005 13:18:32 -0000 --y9PDtDHaFrXNoMPU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 29, 2005 at 02:12:53PM +0100, David Malone wrote: > On Tue, Mar 29, 2005 at 09:11:07PM +1000, Peter Jeremy wrote: > > That's almost a year ago and specifically for the amd64. Does anyone > > know what the results were? >=20 > I had a quick dig around on cvsweb this morning: >=20 > http://grappa.unix-ag.uni-kl.de/cgi-bin/cvsweb/src/sys/i386/i386/bcopy.s= ?cvsroot=3Ddragonfly >=20 >=20 > I dunno if Matt has benchmarks for before and after. >=20 > David. I believe it was asserted on the list that the modification doubled the performance. I have not tested this. --Devon --y9PDtDHaFrXNoMPU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCSVVJSkf3jVXOdl0RAqqFAJ0XUJklEODt26HckEQXI7MblhBSmgCfVTRl rU2T1lTvu6CJUUEEpA39qZ0= =7YtI -----END PGP SIGNATURE----- --y9PDtDHaFrXNoMPU-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 13:47:11 2005 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 C817416A4CE for ; Tue, 29 Mar 2005 13:47:11 +0000 (GMT) Received: from mail17.messagelabs.com (mail17.messagelabs.com [62.231.131.67]) by mx1.FreeBSD.org (Postfix) with SMTP id 78BBE43D54 for ; Tue, 29 Mar 2005 13:47:04 +0000 (GMT) (envelope-from JNelson@emaglink.com) X-VirusChecked: Checked X-Env-Sender: JNelson@emaglink.com X-Msg-Ref: server-19.tower-17.messagelabs.com!1112104021!20281477!1 X-StarScan-Version: 5.4.11; banners=-,-,- X-Originating-IP: [216.198.91.164] Received: (qmail 23442 invoked from network); 29 Mar 2005 13:47:01 -0000 Received: from 216-198-91-164.client.cypresscom.net (HELO emag09.emaglink.com) (216.198.91.164) by server-19.tower-17.messagelabs.com with SMTP; 29 Mar 2005 13:47:01 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Mar 2005 08:47:26 -0500 Message-ID: <06EF07780A906F49B4D3AE1503AC5FA6A2D2B7@emag09.emaglink.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: System Panic (Trap 12) Thread-Index: AcU0Zg98YCjc/cWGQk6e1RESqvJi5w== From: "James Nelson" To: X-Mailman-Approved-At: Tue, 29 Mar 2005 14:21:22 +0000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: System Panic (Trap 12) 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, 29 Mar 2005 13:47:11 -0000 Greets, =09 I am getting numerous panics. It seems to be totally random with no = bearing on load. This is a dual proc. AMD 2600, 2 GB Ram. I have included the where results of three seperate core files. Please advise. Thanks in advance. FreeBSD sbftp.sc.emaglink.com 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #7: = Mon Mar 28 13:26:07 EST 2005 = jnelson@sbftp.sc.emaglink.com:/usr/obj/usr/src/sys/SBFTP i386 [GDB will not be able to debug user-mode threads: = /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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-marcel-freebsd". #0 doadump () at pcpu.h:159 159 __asm __volatile("movl %%fs:0,%0" : "=3Dr" (td)); (kgdb) where #0 doadump () at pcpu.h:159 #1 0xc0627d67 in boot (howto=3D260) at = /usr/src/sys/kern/kern_shutdown.c:410 #2 0xc06280bd in panic (fmt=3D0xc08275a2 "%s") at = /usr/src/sys/kern/kern_shutdown.c:566 #3 0xc07deb14 in trap_fatal (frame=3D0xe4d73c5c, eva=3D2883669) at = /usr/src/sys/i386/i386/trap.c:809 #4 0xc07de847 in trap_pfault (frame=3D0xe4d73c5c, usermode=3D0, = eva=3D2883669) at /usr/src/sys/i386/i386/trap.c:727 #5 0xc07de45d in trap (frame=3D {tf_fs =3D 24, tf_es =3D 16, tf_ds =3D 16, tf_edi =3D -1017036800, = tf_esi =3D -1008433408, tf_ebp =3D -455656272, tf_isp =3D -455656312, = tf_ebx =3D 2883655, tf_edx =3D 32, tf_ecx =3D 2883653, tf_eax =3D 2014, = tf_trapno =3D 12, tf_err =3D 2, tf_eip =3D -1068330083, tf_cs =3D 8, = tf_eflags =3D 66054, tf_esp =3D 2, tf_ss =3D -455671807}) at = /usr/src/sys/i386/i386/trap.c:417 #6 0xc07cccba in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #7 0x00000018 in ?? () #8 0x00000010 in ?? () #9 0x00000010 in ?? () #10 0xc3614000 in ?? () #11 0xc3e48700 in ?? () #12 0xe4d73cb0 in ?? () #13 0xe4d73c88 in ?? () #14 0x002c0047 in ?? () #15 0x00000020 in ?? () #16 0x002c0045 in ?? () #17 0x000007de in ?? () #18 0x0000000c in ?? () #19 0x00000002 in ?? () #20 0xc052939d in fxp_add_rfabuf (sc=3D0xc3614000, rxp=3D0xc3614610) at = /usr/src/sys/dev/fxp/if_fxp.c:2288 #21 0xc05285ec in fxp_intr_body (sc=3D0xc3614000, ifp=3D0xc3614000, = statack=3D16 '\020', count=3D-1) at /usr/src/sys/dev/fxp/if_fxp.c:1682 #22 0xc05283d0 in fxp_intr (xsc=3D0xc3614000) at = /usr/src/sys/dev/fxp/if_fxp.c:1555 #23 0xc0613d11 in ithread_loop (arg=3D0xc34f2600) at = /usr/src/sys/kern/kern_intr.c:547 #24 0xc0612dad in fork_exit (callout=3D0xc0613bb8 , = arg=3D0xc34f2600, frame=3D0xe4d73d48) at = /usr/src/sys/kern/kern_fork.c:790 #25 0xc07ccd1c in fork_trampoline () at = /usr/src/sys/i386/i386/exception.s:209 #0 doadump () at pcpu.h:159 #1 0xc0627d67 in boot (howto=3D260) at = /usr/src/sys/kern/kern_shutdown.c:410 #2 0xc06280bd in panic (fmt=3D0xc08275a2 "%s") at = /usr/src/sys/kern/kern_shutdown.c:566 #3 0xc07deb14 in trap_fatal (frame=3D0xe4d73bb4, eva=3D3217033792) at = /usr/src/sys/i386/i386/trap.c:809 #4 0xc07de847 in trap_pfault (frame=3D0xe4d73bb4, usermode=3D0, = eva=3D3217033792) at /usr/src/sys/i386/i386/trap.c:727 #5 0xc07de45d in trap (frame=3D {tf_fs =3D 24, tf_es =3D 16, tf_ds =3D 16, tf_edi =3D 32, tf_esi = =3D -1017067520, tf_ebp =3D -455656364, tf_isp =3D -455656480, tf_ebx = =3D 0, tf_edx =3D 0, tf_ecx =3D 2686976, tf_eax =3D 656, tf_trapno =3D = 12, tf_err =3D 0, tf_eip =3D -1065570907, tf_cs =3D 8, tf_eflags =3D = 66070, tf_esp =3D -1064291104, tf_ss =3D 2689093}) at = /usr/src/sys/i386/i386/trap.c:417 #6 0xc07cccba in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #7 0x00000018 in ?? () #8 0x00000010 in ?? () #9 0x00000010 in ?? () #10 0x00000020 in ?? () #11 0xc360c800 in ?? () #12 0xe4d73c54 in ?? () #13 0xe4d73be0 in ?? () #14 0x00000000 in ?? () #15 0x00000000 in ?? () #16 0x00290000 in ?? () #17 0x00000290 in ?? () #18 0x0000000c in ?? () #19 0x00000000 in ?? () #20 0xc07cada5 in bus_dmamap_load_mbuf (dmat=3D0xc35d8e00, = map=3D0xc3623340, m0=3D0xc3b2ad00, callback=3D0xc058f4b8 = , callback_arg=3D0xe4d73c80, flags=3D1) at pmap.h:200 #21 0xc058ffe3 in re_newbuf (sc=3D0xc360c800, idx=3D32, m=3D0xc3b2ad00) = at /usr/src/sys/dev/re/if_re.c:1403 #22 0xc05902f9 in re_rxeof (sc=3D0xc360c800) at = /usr/src/sys/dev/re/if_re.c:1588 #23 0xc0590811 in re_intr (arg=3D0xc360c800) at = /usr/src/sys/dev/re/if_re.c:1860 #24 0xc0613d11 in ithread_loop (arg=3D0xc34f2600) at = /usr/src/sys/kern/kern_intr.c:547 #25 0xc0612dad in fork_exit (callout=3D0xc0613bb8 , = arg=3D0xc34f2600, frame=3D0xe4d73d48) at = /usr/src/sys/kern/kern_fork.c:790 #26 0xc07ccd1c in fork_trampoline () at = /usr/src/sys/i386/i386/exception.s:209 #0 doadump () at pcpu.h:159 #1 0xc0627d67 in boot (howto=3D260) at = /usr/src/sys/kern/kern_shutdown.c:410 #2 0xc06280bd in panic (fmt=3D0xc08275a2 "%s") at = /usr/src/sys/kern/kern_shutdown.c:566 #3 0xc07deb14 in trap_fatal (frame=3D0xe4d73c5c, eva=3D5177429) at = /usr/src/sys/i386/i386/trap.c:809 #4 0xc07de847 in trap_pfault (frame=3D0xe4d73c5c, usermode=3D0, = eva=3D5177429) at /usr/src/sys/i386/i386/trap.c:727 #5 0xc07de45d in trap (frame=3D {tf_fs =3D 24, tf_es =3D 16, tf_ds =3D 16, tf_edi =3D -1017036800, = tf_esi =3D -1012054784, tf_ebp =3D -455656272, tf_isp =3D -455656312, = tf_ebx =3D 5177415, tf_edx =3D 32, tf_ecx =3D 5177413, tf_eax =3D 2014, = tf_trapno =3D 12, tf_err =3D 2, tf_eip =3D -1068330083, tf_cs =3D 8, = tf_eflags =3D 66054, tf_esp =3D 2, tf_ss =3D -455671807}) at = /usr/src/sys/i386/i386/trap.c:417 #6 0xc07cccba in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #7 0x00000018 in ?? () #8 0x00000010 in ?? () #9 0x00000010 in ?? () #10 0xc3614000 in ?? () #11 0xc3ad4500 in ?? () #12 0xe4d73cb0 in ?? () #13 0xe4d73c88 in ?? () #14 0x004f0047 in ?? () #15 0x00000020 in ?? () #16 0x004f0045 in ?? () #17 0x000007de in ?? () #18 0x0000000c in ?? () #19 0x00000002 in ?? () #20 0xc052939d in fxp_add_rfabuf (sc=3D0xc3614000, rxp=3D0xc3614410) at = /usr/src/sys/dev/fxp/if_fxp.c:2288 #21 0xc05285ec in fxp_intr_body (sc=3D0xc3614000, ifp=3D0xc3614000, = statack=3D16 '\020', count=3D-1) at /usr/src/sys/dev/fxp/if_fxp.c:1682 #22 0xc05283d0 in fxp_intr (xsc=3D0xc3614000) at = /usr/src/sys/dev/fxp/if_fxp.c:1555 #23 0xc0613d11 in ithread_loop (arg=3D0xc34f2600) at = /usr/src/sys/kern/kern_intr.c:547 #24 0xc0612dad in fork_exit (callout=3D0xc0613bb8 , = arg=3D0xc34f2600, frame=3D0xe4d73d48) at = /usr/src/sys/kern/kern_fork.c:790 #25 0xc07ccd1c in fork_trampoline () at = /usr/src/sys/i386/i386/exception.s:209 James Nelson=20 Emag Solutions, LLC=20 Phone: (404) 995-1665=20 Email: jnelson@emaglink.com=20 Visit us on the web at:=20 http://www.emaglink.com=20 This transmission may contain information that is privileged, = confidential and/or exempt from disclosure under applicable law. If you = are not the intended recipient, you are hereby notified that any = disclosure, copying, distribution, or use of the information contained = herein (including any reliance thereon) is STRICTLY PROHIBITED. If you = received this transmission in error, please immediately contact the = sender and destroy the material in its entirety, whether in electronic = or hard copy format. If you are unable or unwilling to comply with this = requirement, please inform the sender of this message immediately and = remove all correspondence from eMag Solutions from your e-mail system. = If no objection is immediately raised, you hereby agree that lack of = action on your part constitutes implied consent to abide by the terms = set forth above.=20 From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 15:05:42 2005 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 C4E9516A4CE for ; Tue, 29 Mar 2005 15:05:42 +0000 (GMT) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6113F43D39 for ; Tue, 29 Mar 2005 15:05:41 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (8.13.3/8.13.3) with ESMTP id j2TF5c0n084810 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 29 Mar 2005 17:05:38 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.3/8.13.3/Submit) id j2TF5cof084809 for freebsd-hackers@freebsd.org; Tue, 29 Mar 2005 17:05:38 +0200 (CEST) Date: Tue, 29 Mar 2005 17:05:38 +0200 From: Divacky Roman To: freebsd-hackers@freebsd.org Message-ID: <20050329150538.GA84533@stud.fit.vutbr.cz> References: <319cceca0503281001792baf39@mail.gmail.com> <4248557A.7000302@elischer.org> <20050328191758.GB3141@britannica.bec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050328191758.GB3141@britannica.bec.de> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.49 on 147.229.10.14 Subject: Re: organization 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, 29 Mar 2005 15:05:42 -0000 > The biggest problem is keeping history here. Doing something like that > with CVS is a major PITA. We didn't have any old release, so moving > the repository files didn't create a problem. That's impossible in > FreeBSD land :) wasnt here some discussion about moving FreeBSD to subversion (as some other projects did - samba, mono etc.)? and subversion solves this... roman From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 15:24:37 2005 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 2F19616A4CE for ; Tue, 29 Mar 2005 15:24:37 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C71343D39 for ; Tue, 29 Mar 2005 15:24:34 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j2TFOJkD082419; Wed, 30 Mar 2005 00:54:20 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Wed, 30 Mar 2005 00:54:06 +0930 User-Agent: KMail/1.8 References: <000801c53448$b0987bc0$abe243a4@ash> In-Reply-To: <000801c53448$b0987bc0$abe243a4@ash> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1442016.mcGugjm3uC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200503300054.14873.doconnor@gsoft.com.au> X-Spam-Score: -2.5 () IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: Ashwin Chandra Subject: Re: Interrupt Service Routines 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, 29 Mar 2005 15:24:37 -0000 --nextPart1442016.mcGugjm3uC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, 29 Mar 2005 19:48, Ashwin Chandra wrote: > Do you guys know of any example code of ISR's in the kernel? Most of the drivers in the kernel? Look for XXXXintr in /usr/src/sys/dev/*/*.c eg line 1507 of /usr/src/sys/dev/fxp/if_fxp.c =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1442016.mcGugjm3uC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBCSXMe5ZPcIHs/zowRApkVAKCkyebFVH65t22/fq6PfJfy0t5uRQCgnuKm 8cG591e/b8i0Lfmadjqmb/Y= =4YfN -----END PGP SIGNATURE----- --nextPart1442016.mcGugjm3uC-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 15:41:27 2005 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 3066616A4CE for ; Tue, 29 Mar 2005 15:41:27 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0B3A43D39 for ; Tue, 29 Mar 2005 15:41:26 +0000 (GMT) (envelope-from maslanbsd@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so547143wra for ; Tue, 29 Mar 2005 07:41:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=uNAOOuO5H1yIYq8P5K2TEOC+h2NNkyf78xaH+itOuW2pr/pacxQhP6eTwJOAK2B4w7fIqWgSMYAAA67kB68dVSp0knW8w+QsAxuliCSrFk9BoBvfJfW0WgsRpawaCj/Xi4zQwEON+sGPLqUzovrkN2Qov4Pg51c6TcoAKNNY48s= Received: by 10.54.10.41 with SMTP id 41mr1006558wrj; Tue, 29 Mar 2005 07:41:25 -0800 (PST) Received: by 10.54.99.7 with HTTP; Tue, 29 Mar 2005 07:41:25 -0800 (PST) Message-ID: <319cceca05032907411014a218@mail.gmail.com> Date: Tue, 29 Mar 2005 07:41:25 -0800 From: mohamed aslan To: FreeBSD Hackers In-Reply-To: <42487982.30909@freebsdbrasil.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <319cceca0503281001792baf39@mail.gmail.com> <42485A54.9000101@freebsdbrasil.com.br> <319cceca05032811484cb1a95b@mail.gmail.com> <42487982.30909@freebsdbrasil.com.br> Subject: Re: organization X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mohamed aslan List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2005 15:41:27 -0000 guys this is not a flame war but the linux way in arranging the source file is really better than freebsd way, it's a fact. however it's easy to rearrange it in 1 min as someone said before. but i mean this step should be done from the core team. for example all fs has to go in a subdir called fs arch specific file should go in subdir called arch/(arch name) and so on . if ls the files in freebsd sys subdir , u will got about 54 subdirs and a makefile while linux contains about 15 subdirs only. guys, don't take my words against bsd , i admit that the performace of bsd is much better than linux and i'm planning to change to it as my primary os. but we can get the good things from linux and through out the bad ones. On Mon, 28 Mar 2005 18:39:14 -0300, Patrick Tracanelli wrote: > Hey there Mohamed, hello. > > I did not take it as a flame war initiative nor reason for such a thing. > This kind of consideration is good to make people think about some > points which are rarerely discussed. I personally disagree w/ you but it > is also my very personal opinion. > > Anyway, this is not the reason I am emailing you now. > > You reply came to me only, since the list does not change the reply-to > header you should retype the address or Reply All. I think your points > should go on the list, so resend it there if it is the case. > > I am considering you really intended to reply to the list. If its not > the case and you wanted to reply only to me, do not consider this message. > > Thanks, Bye :-) > > mohamed aslan wrote: > > guys this is not a flame war > > but the linux way in arranging the source file is really better than > > freebsd way, it's a fact. > > however it's easy to rearrange it in 1 min as someone said before. > > but i mean this step should be done from the core team. > > for example all fs has to go in a subdir called fs > > arch specific file should go in subdir called arch/(arch name) > > and so on . > > if ls the files in freebsd sys subdir , u will got about 54 subdirs > > and a makefile while linux contains about 15 subdirs only. > > > > guys, don't take my words against bsd , i admit that the performace of > > bsd is much better than linux and i'm planning to change to it as my > > primary os. but we can get the good things from linux and through out > > the bad ones. > > > > On Mon, 28 Mar 2005 16:26:12 -0300, Patrick Tracanelli > > wrote: > > > >>Maybe you are just more familiar to Linux kernel. > >> > >>I am not a kernel hacker, like you and many people here. But I usually > >>read source codes, FreeBSD and also NetBSD and Linux, specially the > >>areas where I am a particular curious. FreeBSD code organization is > >>close to BSD's roots (you can get those Walnut Creek historical CDROM > >>which has code for 4BSD and 386BSD to compare). > >> > >>I like FreeBSD orgaization better. Maybe you will disagree it for a > >>thousand years, or one day find NetBSD approach better than both. In any > >>case I am sure spending more time under FreeBSD's src/ won't make the > >>organization such a deal that deserves this comment. > >> > >>mohamed aslan wrote: > >> > >>>hi guys > >>>it's my first post here, BTW i was a linux hacker and linux kernel > >>>mailing list member for 3 years. > >>> > >>>and i've a comment here , i think the freebsd kernel source files > >>>aren't well organized as linux ones. > >> > > > > > -- I'm Searching For Perfection, So Even If U Need Portability U've To Use Assembly ;-) http://www.maslanlab.org From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 15:49:43 2005 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 B05F316A4CE for ; Tue, 29 Mar 2005 15:49:43 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D6A243D4C for ; Tue, 29 Mar 2005 15:49:43 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j2TFmHff001134; Tue, 29 Mar 2005 08:48:17 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 29 Mar 2005 08:48:17 -0700 (MST) Message-Id: <20050329.084817.41630990.imp@bsdimp.com> To: maslanbsd@gmail.com From: Warner Losh In-Reply-To: <319cceca05032907411014a218@mail.gmail.com> References: <319cceca05032811484cb1a95b@mail.gmail.com> <42487982.30909@freebsdbrasil.com.br> <319cceca05032907411014a218@mail.gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: organization 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, 29 Mar 2005 15:49:43 -0000 From: mohamed aslan Subject: Re: organization Date: Tue, 29 Mar 2005 07:41:25 -0800 > guys this is not a flame war > but the linux way in arranging the source file is really better than > freebsd way, it's a fact. > however it's easy to rearrange it in 1 min as someone said before. > but i mean this step should be done from the core team. > for example all fs has to go in a subdir called fs > arch specific file should go in subdir called arch/(arch name) > and so on . The problem is getting consensus on what is to be done. Sure, one can arbitrarily say this goes here or that goes there, but everyone's notion of reorg is a little different. It would take a lot of time and energy to get this consensus, which is better spent making things work better... Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 16:05:57 2005 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 1466316A4CE for ; Tue, 29 Mar 2005 16:05:57 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E1F543D2F for ; Tue, 29 Mar 2005 16:05:54 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.21] (rat.samsco.home [192.168.254.21]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j2TG9uIM004943; Tue, 29 Mar 2005 09:09:56 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <42497C65.7010807@samsco.org> Date: Tue, 29 Mar 2005 09:03:49 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.5) Gecko/20050321 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mohamed aslan References: <319cceca0503281001792baf39@mail.gmail.com> <42485A54.9000101@freebsdbrasil.com.br> <319cceca05032811484cb1a95b@mail.gmail.com> <42487982.30909@freebsdbrasil.com.br> <319cceca05032907411014a218@mail.gmail.com> In-Reply-To: <319cceca05032907411014a218@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: FreeBSD Hackers Subject: Re: organization 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, 29 Mar 2005 16:05:57 -0000 mohamed aslan wrote: > guys this is not a flame war > but the linux way in arranging the source file is really better than > freebsd way, it's a fact. > however it's easy to rearrange it in 1 min as someone said before. > but i mean this step should be done from the core team. > for example all fs has to go in a subdir called fs > arch specific file should go in subdir called arch/(arch name) > and so on . > if ls the files in freebsd sys subdir , u will got about 54 subdirs > and a makefile while linux contains about 15 subdirs only. > > guys, don't take my words against bsd , i admit that the performace of > bsd is much better than linux and i'm planning to change to it as my > primary os. but we can get the good things from linux and through out > the bad ones. > Have you ever thought that time is better spent on engineering rather than silly dicussions of 'facts' like yours? I really don't give a hoot what Linux's layout is, nor whether you think that changing FreeBSD to be more like it is a trivial task. Scott From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 16:15:30 2005 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 CEAF816A4CE for ; Tue, 29 Mar 2005 16:15:30 +0000 (GMT) Received: from BASE.OTEL.net (BASE.OTEL.net [212.36.8.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B8BF43D48 for ; Tue, 29 Mar 2005 16:15:30 +0000 (GMT) (envelope-from tbyte@OTEL.net) Received: from dragon.otel.net ([212.36.8.135]) by BASE.OTEL.net with esmtp (Exim 4.30; FreeBSD) id 1DGJNI-000O0n-NT for freebsd-hackers@freebsd.org; Tue, 29 Mar 2005 19:15:28 +0300 Message-ID: <42497F1B.4040804@OTEL.net> Date: Tue, 29 Mar 2005 19:15:23 +0300 From: Iasen Kostov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050321 X-Accept-Language: bg, en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <319cceca05032811484cb1a95b@mail.gmail.com> <42487982.30909@freebsdbrasil.com.br> <319cceca05032907411014a218@mail.gmail.com> <20050329.084817.41630990.imp@bsdimp.com> In-Reply-To: <20050329.084817.41630990.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: organization 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, 29 Mar 2005 16:15:30 -0000 Warner Losh wrote: >From: mohamed aslan >Subject: Re: organization >Date: Tue, 29 Mar 2005 07:41:25 -0800 > > > >>guys this is not a flame war >>but the linux way in arranging the source file is really better than >>freebsd way, it's a fact. >>however it's easy to rearrange it in 1 min as someone said before. >>but i mean this step should be done from the core team. >>for example all fs has to go in a subdir called fs >>arch specific file should go in subdir called arch/(arch name) >>and so on . >> >> > >The problem is getting consensus on what is to be done. Sure, one can >arbitrarily say this goes here or that goes there, but everyone's >notion of reorg is a little different. It would take a lot of time >and energy to get this consensus, which is better spent making things >work better... > >Warner >_______________________________________________ >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" > > > And the worts of all is that You are both right to some extent. The new developers want the source tree arranged in the way mohamed says it should be. Not some device drivers live in pci/ other in dev/ and things like that. And on the other hand experienced kernel hackers who want things to stay as they are so it is easy for them to navigate in know waters. IMHO mohamed is a bit "more" right. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 16:29:02 2005 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 A368316A4CE for ; Tue, 29 Mar 2005 16:29:02 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 140E143D4C for ; Tue, 29 Mar 2005 16:29:02 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.21] (rat.samsco.home [192.168.254.21]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j2TGX3d4005074; Tue, 29 Mar 2005 09:33:03 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <424981D1.40000@samsco.org> Date: Tue, 29 Mar 2005 09:26:57 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.5) Gecko/20050321 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iasen Kostov References: <319cceca05032811484cb1a95b@mail.gmail.com> <42487982.30909@freebsdbrasil.com.br> <319cceca05032907411014a218@mail.gmail.com> <20050329.084817.41630990.imp@bsdimp.com> <42497F1B.4040804@OTEL.net> In-Reply-To: <42497F1B.4040804@OTEL.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: freebsd-hackers@freebsd.org Subject: Re: organization 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, 29 Mar 2005 16:29:02 -0000 Iasen Kostov wrote: > Warner Losh wrote: > >> From: mohamed aslan >> Subject: Re: organization >> Date: Tue, 29 Mar 2005 07:41:25 -0800 >> >> >> >>> guys this is not a flame war >>> but the linux way in arranging the source file is really better than >>> freebsd way, it's a fact. >>> however it's easy to rearrange it in 1 min as someone said before. >>> but i mean this step should be done from the core team. >>> for example all fs has to go in a subdir called fs >>> arch specific file should go in subdir called arch/(arch name) >>> and so on . >>> >> >> >> The problem is getting consensus on what is to be done. Sure, one can >> arbitrarily say this goes here or that goes there, but everyone's >> notion of reorg is a little different. It would take a lot of time >> and energy to get this consensus, which is better spent making things >> work better... >> >> Warner >> _______________________________________________ >> 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" >> >> >> > And the worts of all is that You are both right to some extent. The > new developers want the source tree arranged in the way mohamed says it > should be. Not some device drivers live in pci/ other in dev/ and things > like that. And on the other hand experienced kernel hackers who want > things to stay as they are so it is easy for them to navigate in know > waters. IMHO mohamed is a bit "more" right. > What do you think the reaction would be if you or Mr. Aslan trotted over to the linux kernel hackers list and told them that they were all 'wrong' for piling all of the storage drivers into linux/drivers/scsi instead of separating them out into subdirectories? What do you think the reaction would be if you told Theo DeRadt that OpenBSD is 'wrong' for piling dozens of drivers into sys/dev/ic instead of separating them out more logically? At best, you'd be ignored. Telling a group that they are right or wrong based on your personal opinion of how the world should be is, um, a waste of time. Scott From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 16:36:05 2005 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 C5BA516A4CE for ; Tue, 29 Mar 2005 16:36:05 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 637C043D4C for ; Tue, 29 Mar 2005 16:36:05 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j2TGZuMG014249; Tue, 29 Mar 2005 11:35:56 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j2TGZul8014248; Tue, 29 Mar 2005 11:35:56 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Tue, 29 Mar 2005 11:35:56 -0500 From: David Schultz To: Warner Losh Message-ID: <20050329163556.GA14181@VARK.MIT.EDU> Mail-Followup-To: Warner Losh , maslanbsd@gmail.com, freebsd-hackers@freebsd.org References: <319cceca05032811484cb1a95b@mail.gmail.com> <42487982.30909@freebsdbrasil.com.br> <319cceca05032907411014a218@mail.gmail.com> <20050329.084817.41630990.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050329.084817.41630990.imp@bsdimp.com> cc: maslanbsd@gmail.com cc: freebsd-hackers@FreeBSD.ORG Subject: Re: organization 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, 29 Mar 2005 16:36:05 -0000 On Tue, Mar 29, 2005, Warner Losh wrote: > From: mohamed aslan > Subject: Re: organization > Date: Tue, 29 Mar 2005 07:41:25 -0800 > > > guys this is not a flame war > > but the linux way in arranging the source file is really better than > > freebsd way, it's a fact. > > however it's easy to rearrange it in 1 min as someone said before. > > but i mean this step should be done from the core team. > > for example all fs has to go in a subdir called fs > > arch specific file should go in subdir called arch/(arch name) > > and so on . > > The problem is getting consensus on what is to be done. Sure, one can > arbitrarily say this goes here or that goes there, but everyone's > notion of reorg is a little different. It would take a lot of time > and energy to get this consensus, which is better spent making things > work better... I think few people would disagree with certain changes, like putting MD bits in subdirectories called 'arch' as in NetBSD. The real question is whether people care enough to justify the repo bloat and the extra load on the cvsup mirrors. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 16:39:19 2005 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 8A26A16A4CE for ; Tue, 29 Mar 2005 16:39:19 +0000 (GMT) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E58E43D31 for ; Tue, 29 Mar 2005 16:39:19 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j2TGdGXd032063; Tue, 29 Mar 2005 11:39:17 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <319cceca05032907411014a218@mail.gmail.com> References: <319cceca0503281001792baf39@mail.gmail.com> <42485A54.9000101@freebsdbrasil.com.br> <319cceca05032811484cb1a95b@mail.gmail.com> <42487982.30909@freebsdbrasil.com.br> <319cceca05032907411014a218@mail.gmail.com> Date: Tue, 29 Mar 2005 11:39:15 -0500 To: mohamed aslan , FreeBSD Hackers From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.3 Subject: Re: organization 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, 29 Mar 2005 16:39:19 -0000 At 7:41 AM -0800 3/29/05, mohamed aslan wrote: >guys this is not a flame war >but the linux way in arranging the source file is really better >than freebsd way, it's a fact. > >however it's easy to rearrange it in 1 min as someone said before. >but i mean this step should be done from the core team. >for example all fs has to go in a subdir called fs >arch specific file should go in subdir called arch/(arch name) >and so on . One thing to watch out for is the mess this would cause in the CVS repository. CVS does not track "file moves", so if we move a lot of things around then we just end up with them in *both* the old and the new locations. I certainly believe the tree could be organized better than it is, but the benefits from reorganizing are just not worth the time and effort it would take (*), and the mess it would make out of the CVS repository. (* - 99% of the time and effort would be in getting everyone to *agree* on the best layout...) -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 16:55:41 2005 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 B94BC16A4CE; Tue, 29 Mar 2005 16:55:41 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A83B43D46; Tue, 29 Mar 2005 16:55:41 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j2TGrjlq003278; Tue, 29 Mar 2005 09:53:46 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 29 Mar 2005 09:52:49 -0700 (MST) Message-Id: <20050329.095249.71088143.imp@bsdimp.com> To: das@FreeBSD.ORG From: "M. Warner Losh" In-Reply-To: <20050329163556.GA14181@VARK.MIT.EDU> References: <319cceca05032907411014a218@mail.gmail.com> <20050329.084817.41630990.imp@bsdimp.com> <20050329163556.GA14181@VARK.MIT.EDU> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: maslanbsd@gmail.com cc: freebsd-hackers@FreeBSD.ORG Subject: Re: organization 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, 29 Mar 2005 16:55:41 -0000 In message: <20050329163556.GA14181@VARK.MIT.EDU> David Schultz writes: : On Tue, Mar 29, 2005, Warner Losh wrote: : > From: mohamed aslan : > Subject: Re: organization : > Date: Tue, 29 Mar 2005 07:41:25 -0800 : > : > > guys this is not a flame war : > > but the linux way in arranging the source file is really better than : > > freebsd way, it's a fact. : > > however it's easy to rearrange it in 1 min as someone said before. : > > but i mean this step should be done from the core team. : > > for example all fs has to go in a subdir called fs : > > arch specific file should go in subdir called arch/(arch name) : > > and so on . : > : > The problem is getting consensus on what is to be done. Sure, one can : > arbitrarily say this goes here or that goes there, but everyone's : > notion of reorg is a little different. It would take a lot of time : > and energy to get this consensus, which is better spent making things : > work better... : : I think few people would disagree with certain changes, like : putting MD bits in subdirectories called 'arch' as in NetBSD. The : real question is whether people care enough to justify the repo : bloat and the extra load on the cvsup mirrors. You've proven my point exactly: Some folks want to see i386 moved to arch/i386, others think it is stupid to do that. Discussion isn't possible here, so nothing will happen since there's no compelling reason to do anything, just a weak argument about how things might be nicer. The fact that we even consider cvsup load when discussing this means that clearly it is a weak idea: if we have to worry about the impact on how we distribute the sources for a change, isn't that really a weird criteria to use? Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 16:59:54 2005 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 ECC7816A4CE for ; Tue, 29 Mar 2005 16:59:54 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 848C343D39 for ; Tue, 29 Mar 2005 16:59:54 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j2TH0FbG022394; Tue, 29 Mar 2005 09:00:20 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j2TH091i022393; Tue, 29 Mar 2005 09:00:09 -0800 (PST) (envelope-from www) Date: Tue, 29 Mar 2005 09:00:09 -0800 (PST) Message-Id: <200503291700.j2TH091i022393@marlena.vvi.at> To: tbyte@OTEL.net From: "ALeine" cc: freebsd-hackers@freebsd.org Subject: Re: organization 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, 29 Mar 2005 16:59:55 -0000 tbyte@OTEL.net wrote: > And the worts of all is that You are both right to some extent. The > new developers want the source tree arranged in the way mohamed says it > should be. Not some device drivers live in pci/ other in dev/ and things > like that. And on the other hand experienced kernel hackers who want > things to stay as they are so it is easy for them to navigate in know > waters. IMHO mohamed is a bit "more" right. If you are really dedicated to studying the kernel sources at that level issues such as learning the layout are really nonissues, the time a new developer initially spends hunting around for files because they are not familiar with the layout is insignificant compared to the time experienced developers would lose as a result of a new layout being introduced, especially during a critical development stage. Once all the major changes are finished and we move to micro optimization a new, more consistent and logical layout would be an option, but until then, IMHO, things should stay the way they are. Also, the benefit of such a reorganization at this time does not justify the work needed to make it happen. It Would Be Nice (TM), but it's not practical. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 17:00:32 2005 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 61A2416A4CE for ; Tue, 29 Mar 2005 17:00:32 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id D32D243D49 for ; Tue, 29 Mar 2005 17:00:31 +0000 (GMT) (envelope-from dleimbac@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so1641410rnf for ; Tue, 29 Mar 2005 09:00:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=PFcMEC2kwcfi4wbVJ04s8+KZZ+tDD8aymvxpDDxWqONuxzShdNb2rhbbAi7Kf3GZrj47K5Nmi93uQopw2aoLoxgxm8aRX47gvujUQvdcshtlCGJdR2HJkex1oxyqi78sSJqHPkPV025XHg+x2HOasruTHpe8juvoxUpCsNq8MD8= Received: by 10.38.11.32 with SMTP id 32mr3548500rnk; Tue, 29 Mar 2005 08:54:04 -0800 (PST) Received: by 10.38.82.48 with HTTP; Tue, 29 Mar 2005 08:54:04 -0800 (PST) Message-ID: <5bbfe7d405032908542b2b0c71@mail.gmail.com> Date: Tue, 29 Mar 2005 08:54:04 -0800 From: David Leimbach To: Peter Jeremy In-Reply-To: <20050329111107.GD69824@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <423C15C5.6040902@fsn.hu> <20050327133059.3d68a78c@Magellan.Leidinger.net> <20050327134044.GM78512@silverwraith.com> <20050327162839.2fafa6aa@Magellan.Leidinger.net> <5bbfe7d405032823144fc1af7b@mail.gmail.com> <5bbfe7d405032823232103d537@mail.gmail.com> <20050329111107.GD69824@cirb503493.alcatel.com.au> cc: hackers@freebsd.org Subject: Re: Fwd: 5-STABLE kernel build with icc broken X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Leimbach List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2005 17:00:32 -0000 On Tue, 29 Mar 2005 21:11:07 +1000, Peter Jeremy wrote: > On Mon, 2005-Mar-28 23:23:19 -0800, David Leimbach wrote: > >meant to send this to the list too... sorry > >> Are you implying DragonFly uses FPU/SIMD? For that matter does any kernel? > > > >I believe it does use SIMD for some of it's fast memcopy stuff for > >it's messaging system > >actually. I remember Matt saying he was working on it. > > > >http://leaf.dragonflybsd.org/mailarchive/kernel/2004-04/msg00262.html > > That's almost a year ago and specifically for the amd64. Does anyone > know what the results were? Actually I don't remember precisely what came of it, but I do remember that we had some interesting stability issues while Matt worked out some bugs around that time, I think they were related to the SIMD stuff. > > >If you can manage the alignment issues it can be a huge win. > > For message passing within the kernel, you should be able to mandate > alignment as part of the API. > > I see the bigger issue being the need to save/restore the SIMD > engine's state during a system call. Currently, this is only saved on > if a different process wants to use the SIMD engine. For MMX, the > SIMD state is the FPU state - which is non-trivial. The little > reading I've done suggests that SSE and SSE2 are even larger. > > Saving the SIMD state would be more expensive that using integer > registers for small (and probably medium-sized) copies. > Yes, you'd have to have a fairly smart copy to know when to avoid the setup overhead. Apple's bcopy stuff does a lot of checking if I recall. It's been a while since I've looked at that either. [the stuff that's mapped into the COMM_PAGE of Mac OS X 10.3.x processes] Dave > -- > Peter Jeremy > From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 17:01:39 2005 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 5D6A416A4CE for ; Tue, 29 Mar 2005 17:01:39 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id D987E43D1F for ; Tue, 29 Mar 2005 17:01:38 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j2TGxqbb003383; Tue, 29 Mar 2005 09:59:52 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 29 Mar 2005 09:59:55 -0700 (MST) Message-Id: <20050329.095955.58455889.imp@bsdimp.com> To: xdivac02@stud.fit.vutbr.cz From: "M. Warner Losh" In-Reply-To: <20050329150538.GA84533@stud.fit.vutbr.cz> References: <4248557A.7000302@elischer.org> <20050328191758.GB3141@britannica.bec.de> <20050329150538.GA84533@stud.fit.vutbr.cz> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: organization 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, 29 Mar 2005 17:01:39 -0000 In message: <20050329150538.GA84533@stud.fit.vutbr.cz> Divacky Roman writes: : > The biggest problem is keeping history here. Doing something like that : > with CVS is a major PITA. We didn't have any old release, so moving : > the repository files didn't create a problem. That's impossible in : > FreeBSD land :) : : wasnt here some discussion about moving FreeBSD to subversion (as some other : projects did - samba, mono etc.)? and subversion solves this... Subversion was deemed to be insufficiently mature for FreeBSD last time it was evaluated formally. Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 17:18:02 2005 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 7956016A4CE for ; Tue, 29 Mar 2005 17:18:02 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1567443D31 for ; Tue, 29 Mar 2005 17:18:02 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j2THHroi014485; Tue, 29 Mar 2005 12:17:53 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j2THHrxU014484; Tue, 29 Mar 2005 12:17:53 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Tue, 29 Mar 2005 12:17:53 -0500 From: David Schultz To: "M. Warner Losh" Message-ID: <20050329171753.GA14452@VARK.MIT.EDU> Mail-Followup-To: "M. Warner Losh" , maslanbsd@gmail.com, freebsd-hackers@FreeBSD.ORG References: <319cceca05032907411014a218@mail.gmail.com> <20050329.084817.41630990.imp@bsdimp.com> <20050329163556.GA14181@VARK.MIT.EDU> <20050329.095249.71088143.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050329.095249.71088143.imp@bsdimp.com> cc: maslanbsd@gmail.com cc: freebsd-hackers@FreeBSD.ORG Subject: Re: organization 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, 29 Mar 2005 17:18:02 -0000 On Tue, Mar 29, 2005, M. Warner Losh wrote: > In message: <20050329163556.GA14181@VARK.MIT.EDU> > David Schultz writes: > : On Tue, Mar 29, 2005, Warner Losh wrote: > : > From: mohamed aslan > : > Subject: Re: organization > : > Date: Tue, 29 Mar 2005 07:41:25 -0800 > : > > : > > guys this is not a flame war > : > > but the linux way in arranging the source file is really better than > : > > freebsd way, it's a fact. > : > > however it's easy to rearrange it in 1 min as someone said before. > : > > but i mean this step should be done from the core team. > : > > for example all fs has to go in a subdir called fs > : > > arch specific file should go in subdir called arch/(arch name) > : > > and so on . > : > > : > The problem is getting consensus on what is to be done. Sure, one can > : > arbitrarily say this goes here or that goes there, but everyone's > : > notion of reorg is a little different. It would take a lot of time > : > and energy to get this consensus, which is better spent making things > : > work better... > : > : I think few people would disagree with certain changes, like > : putting MD bits in subdirectories called 'arch' as in NetBSD. The > : real question is whether people care enough to justify the repo > : bloat and the extra load on the cvsup mirrors. > > You've proven my point exactly: Some folks want to see i386 moved to > arch/i386, others think it is stupid to do that. Discussion isn't > possible here, so nothing will happen since there's no compelling > reason to do anything, just a weak argument about how things might be > nicer. > > The fact that we even consider cvsup load when discussing this means > that clearly it is a weak idea: if we have to worry about the impact > on how we distribute the sources for a change, isn't that really a > weird criteria to use? Indeed, both the pro and con arguments are weak, which is probably why nothing has happened. I for one would love to see libm called libm and not msun, for instance, but when it comes down to it, I have better things to do. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 17:22:23 2005 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 AAC3416A4CE for ; Tue, 29 Mar 2005 17:22:23 +0000 (GMT) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6734B43D41 for ; Tue, 29 Mar 2005 17:22:23 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: by ion.gank.org (mail, from userid 1001) id 1DBB82D0F1; Tue, 29 Mar 2005 11:22:23 -0600 (CST) Date: Tue, 29 Mar 2005 11:22:19 -0600 From: Craig Boston To: Divacky Roman Message-ID: <20050329172218.GA86797@nowhere> Mail-Followup-To: Craig Boston , Divacky Roman , freebsd-hackers@freebsd.org References: <319cceca0503281001792baf39@mail.gmail.com> <4248557A.7000302@elischer.org> <20050328191758.GB3141@britannica.bec.de> <20050329150538.GA84533@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050329150538.GA84533@stud.fit.vutbr.cz> User-Agent: Mutt/1.4.2.1i cc: freebsd-hackers@freebsd.org Subject: Re: organization 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, 29 Mar 2005 17:22:23 -0000 On Tue, Mar 29, 2005 at 05:05:38PM +0200, Divacky Roman wrote: > wasnt here some discussion about moving FreeBSD to subversion (as some other > projects did - samba, mono etc.)? and subversion solves this... Yes, a few people have looked at it from time to time (raises hand as one of the guilty parties). The last I heard, subversion did not scale well to the massive amount of files that are in the FreeBSD repository. IIRC it's been a while since this was tested, so it may or may not be true anymore. SVK may partially address this by bypassing libwc. Also, repository size is a big issue (no pun intended). If adding a few hundred megs for repo-copies is prohibitively expensive, I don't think increasing the repo size by many gigabytes would go over very well. Subversion repositories can easily be several times the size of a CVS repository containing the same data. Craig From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 17:31:49 2005 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 809E416A4CE for ; Tue, 29 Mar 2005 17:31:49 +0000 (GMT) Received: from mail9.messagelabs.com (mail9.messagelabs.com [194.205.110.133]) by mx1.FreeBSD.org (Postfix) with SMTP id 86A9243D2F for ; Tue, 29 Mar 2005 17:31:48 +0000 (GMT) (envelope-from greg@warprecords.com) X-VirusChecked: Checked X-Env-Sender: greg@warprecords.com X-Msg-Ref: server-14.tower-9.messagelabs.com!1112117506!19032145!1 X-StarScan-Version: 5.4.11; banners=-,-,- X-Originating-IP: [212.135.210.82] Received: (qmail 18027 invoked from network); 29 Mar 2005 17:31:46 -0000 Received: from dsl-212-135-210-82.dsl.easynet.co.uk (HELO warprecords.com) (212.135.210.82) by server-14.tower-9.messagelabs.com with SMTP; 29 Mar 2005 17:31:46 -0000 Received: from [194.106.52.52] (HELO [192.168.0.2]) by warprecords.com (CommuniGate Pro SMTP 4.2.8) with ESMTP-TLS id 4036203; Tue, 29 Mar 2005 18:31:46 +0100 In-Reply-To: <20050328225249.GC13841@seven.alameda.net> References: <200503281748.55388.jhb@FreeBSD.org> <20050328225249.GC13841@seven.alameda.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <49c4b2702ba53af92a5e028a9371114b@warprecords.com> Content-Transfer-Encoding: 7bit From: Greg Eden Date: Tue, 29 Mar 2005 18:31:47 +0100 To: ulf@Alameda.net X-Mailer: Apple Mail (2.619.2) cc: freebsd-hackers@FreeBSD.org Subject: Re: FreeBSD 5.3R SMP Kernel not detecting 2nd CPU in a HP DL360(?) 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, 29 Mar 2005 17:31:49 -0000 On 28 Mar 2005, at 23:52, Ulf Zimmermann wrote: > On Mon, Mar 28, 2005 at 05:48:55PM -0500, John Baldwin wrote: >> >> It's not finding an APIC table (either MPTable or MADT) at all, and >> it needs >> that to find CPUs. See if there are any BIOS options for things like >> MP >> Table or 'Separate APIC Table' under ACPI. Also, try running >> 'mptable' to >> see if it finds a table, and acpidump -t to see if that finds an APIC >> table. > > The DL380 g3 BIOS has different APIC settings for different OS. There > is one setting in the main menu and then under advanced options is > another menu for APIC. Happy to report the box is now up and running with 2 CPUs. There was indeed a BIOS setting along the lines of APIC 'Full Table' which was not the default. HTT was disabled which is why there are 2 not 4 CPUs Unfortunately the ISP's engineer also flashed the BIOS to the latest release at the same time so that may also have had an effect. Thanks for the help. greg. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 17:46:58 2005 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 102CA16A4CE for ; Tue, 29 Mar 2005 17:46:58 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD00B43D41 for ; Tue, 29 Mar 2005 17:46:57 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j2THk0bG022958; Tue, 29 Mar 2005 09:46:04 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j2THjs3S022957; Tue, 29 Mar 2005 09:45:54 -0800 (PST) (envelope-from www) Date: Tue, 29 Mar 2005 09:45:54 -0800 (PST) Message-Id: <200503291745.j2THjs3S022957@marlena.vvi.at> To: imp@bsdimp.com From: "ALeine" cc: freebsd-hackers@freebsd.org Subject: Re: organization 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, 29 Mar 2005 17:46:58 -0000 imp@bsdimp.com wrote: > You've proven my point exactly: Some folks want to see i386 moved to > arch/i386, others think it is stupid to do that. Discussion isn't > possible here, so nothing will happen since there's no compelling > reason to do anything, just a weak argument about how things might be > nicer. If such a layout change were to happen I think the least time wasting procedure would go something like this: - issue a request for new layout propositions - for a week accept proposition submissions (web based) - have the FreeBSD community vote on the proposed layouts (web based) - assign a deadline by which a decision has to be made and then discuss the most popular layouts and try to get the Core Team and the committers to reach a consensus No consensus, no change. In any case, a lot of time and energy would be spent discussing this change, it's more of a bike shed issue than some might think, it's just not worth even starting this process in the near future. > The fact that we even consider cvsup load when discussing this means > that clearly it is a weak idea: if we have to worry about the impact > on how we distribute the sources for a change, isn't that really a > weird criteria to use? It does not prove that the idea itself is weak, it's a criterion that proves that CVS is not well suited to such changes. The thing is that even if such a change would be trivial to implement with no additional overhead, the process of deciding which new layout to adopt would take too much time and energy compared to the benefits gained by adopting a new layout, at least at this stage of development. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 17:47:08 2005 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 774CA16A4CE for ; Tue, 29 Mar 2005 17:47:08 +0000 (GMT) Received: from mail77.messagelabs.com (mail77.messagelabs.com [62.231.131.243]) by mx1.FreeBSD.org (Postfix) with SMTP id 16F4043D49 for ; Tue, 29 Mar 2005 17:47:07 +0000 (GMT) (envelope-from JNelson@emaglink.com) X-VirusChecked: Checked X-Env-Sender: JNelson@emaglink.com X-Msg-Ref: server-12.tower-77.messagelabs.com!1112118424!20847750!1 X-StarScan-Version: 5.4.11; banners=-,-,- X-Originating-IP: [216.198.91.164] Received: (qmail 394 invoked from network); 29 Mar 2005 17:47:04 -0000 Received: from 216-198-91-164.client.cypresscom.net (HELO emag09.emaglink.com) (216.198.91.164) by server-12.tower-77.messagelabs.com with SMTP; 29 Mar 2005 17:47:04 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Mar 2005 12:47:30 -0500 Message-ID: <06EF07780A906F49B4D3AE1503AC5FA6A2D2B9@emag09.emaglink.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: System Panic (Trap 12) Thread-Index: AcU0Zg98YCjc/cWGQk6e1RESqvJi5w== From: "James Nelson" To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: System Panic (Trap 12) 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, 29 Mar 2005 17:47:08 -0000 Greets, =09 I am getting numerous panics. It seems to be totally random with no = bearing on load. This is a dual proc. AMD 2600, 2 GB Ram. I have included the where results of three seperate core files. Please advise. Thanks in advance. FreeBSD sbftp.sc.emaglink.com 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #7: = Mon Mar 28 13:26:07 EST 2005 = jnelson@sbftp.sc.emaglink.com:/usr/obj/usr/src/sys/SBFTP i386 [GDB will not be able to debug user-mode threads: = /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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-marcel-freebsd". #0 doadump () at pcpu.h:159 159 __asm __volatile("movl %%fs:0,%0" : "=3Dr" (td)); (kgdb) where #0 doadump () at pcpu.h:159 #1 0xc0627d67 in boot (howto=3D260) at = /usr/src/sys/kern/kern_shutdown.c:410 #2 0xc06280bd in panic (fmt=3D0xc08275a2 "%s") at = /usr/src/sys/kern/kern_shutdown.c:566 #3 0xc07deb14 in trap_fatal (frame=3D0xe4d73c5c, eva=3D2883669) at = /usr/src/sys/i386/i386/trap.c:809 #4 0xc07de847 in trap_pfault (frame=3D0xe4d73c5c, usermode=3D0, = eva=3D2883669) at /usr/src/sys/i386/i386/trap.c:727 #5 0xc07de45d in trap (frame=3D {tf_fs =3D 24, tf_es =3D 16, tf_ds =3D 16, tf_edi =3D -1017036800, = tf_esi =3D -1008433408, tf_ebp =3D -455656272, tf_isp =3D -455656312, = tf_ebx =3D 2883655, tf_edx =3D 32, tf_ecx =3D 2883653, tf_eax =3D 2014, = tf_trapno =3D 12, tf_err =3D 2, tf_eip =3D -1068330083, tf_cs =3D 8, = tf_eflags =3D 66054, tf_esp =3D 2, tf_ss =3D -455671807}) at = /usr/src/sys/i386/i386/trap.c:417 #6 0xc07cccba in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #7 0x00000018 in ?? () #8 0x00000010 in ?? () #9 0x00000010 in ?? () #10 0xc3614000 in ?? () #11 0xc3e48700 in ?? () #12 0xe4d73cb0 in ?? () #13 0xe4d73c88 in ?? () #14 0x002c0047 in ?? () #15 0x00000020 in ?? () #16 0x002c0045 in ?? () #17 0x000007de in ?? () #18 0x0000000c in ?? () #19 0x00000002 in ?? () #20 0xc052939d in fxp_add_rfabuf (sc=3D0xc3614000, rxp=3D0xc3614610) at = /usr/src/sys/dev/fxp/if_fxp.c:2288 #21 0xc05285ec in fxp_intr_body (sc=3D0xc3614000, ifp=3D0xc3614000, = statack=3D16 '\020', count=3D-1) at /usr/src/sys/dev/fxp/if_fxp.c:1682 #22 0xc05283d0 in fxp_intr (xsc=3D0xc3614000) at = /usr/src/sys/dev/fxp/if_fxp.c:1555 #23 0xc0613d11 in ithread_loop (arg=3D0xc34f2600) at = /usr/src/sys/kern/kern_intr.c:547 #24 0xc0612dad in fork_exit (callout=3D0xc0613bb8 , = arg=3D0xc34f2600, frame=3D0xe4d73d48) at = /usr/src/sys/kern/kern_fork.c:790 #25 0xc07ccd1c in fork_trampoline () at = /usr/src/sys/i386/i386/exception.s:209 #0 doadump () at pcpu.h:159 #1 0xc0627d67 in boot (howto=3D260) at = /usr/src/sys/kern/kern_shutdown.c:410 #2 0xc06280bd in panic (fmt=3D0xc08275a2 "%s") at = /usr/src/sys/kern/kern_shutdown.c:566 #3 0xc07deb14 in trap_fatal (frame=3D0xe4d73bb4, eva=3D3217033792) at = /usr/src/sys/i386/i386/trap.c:809 #4 0xc07de847 in trap_pfault (frame=3D0xe4d73bb4, usermode=3D0, = eva=3D3217033792) at /usr/src/sys/i386/i386/trap.c:727 #5 0xc07de45d in trap (frame=3D {tf_fs =3D 24, tf_es =3D 16, tf_ds =3D 16, tf_edi =3D 32, tf_esi = =3D -1017067520, tf_ebp =3D -455656364, tf_isp =3D -455656480, tf_ebx = =3D 0, tf_edx =3D 0, tf_ecx =3D 2686976, tf_eax =3D 656, tf_trapno =3D = 12, tf_err =3D 0, tf_eip =3D -1065570907, tf_cs =3D 8, tf_eflags =3D = 66070, tf_esp =3D -1064291104, tf_ss =3D 2689093}) at = /usr/src/sys/i386/i386/trap.c:417 #6 0xc07cccba in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #7 0x00000018 in ?? () #8 0x00000010 in ?? () #9 0x00000010 in ?? () #10 0x00000020 in ?? () #11 0xc360c800 in ?? () #12 0xe4d73c54 in ?? () #13 0xe4d73be0 in ?? () #14 0x00000000 in ?? () #15 0x00000000 in ?? () #16 0x00290000 in ?? () #17 0x00000290 in ?? () #18 0x0000000c in ?? () #19 0x00000000 in ?? () #20 0xc07cada5 in bus_dmamap_load_mbuf (dmat=3D0xc35d8e00, = map=3D0xc3623340, m0=3D0xc3b2ad00, callback=3D0xc058f4b8 = , callback_arg=3D0xe4d73c80, flags=3D1) at pmap.h:200 #21 0xc058ffe3 in re_newbuf (sc=3D0xc360c800, idx=3D32, m=3D0xc3b2ad00) = at /usr/src/sys/dev/re/if_re.c:1403 #22 0xc05902f9 in re_rxeof (sc=3D0xc360c800) at = /usr/src/sys/dev/re/if_re.c:1588 #23 0xc0590811 in re_intr (arg=3D0xc360c800) at = /usr/src/sys/dev/re/if_re.c:1860 #24 0xc0613d11 in ithread_loop (arg=3D0xc34f2600) at = /usr/src/sys/kern/kern_intr.c:547 #25 0xc0612dad in fork_exit (callout=3D0xc0613bb8 , = arg=3D0xc34f2600, frame=3D0xe4d73d48) at = /usr/src/sys/kern/kern_fork.c:790 #26 0xc07ccd1c in fork_trampoline () at = /usr/src/sys/i386/i386/exception.s:209 #0 doadump () at pcpu.h:159 #1 0xc0627d67 in boot (howto=3D260) at = /usr/src/sys/kern/kern_shutdown.c:410 #2 0xc06280bd in panic (fmt=3D0xc08275a2 "%s") at = /usr/src/sys/kern/kern_shutdown.c:566 #3 0xc07deb14 in trap_fatal (frame=3D0xe4d73c5c, eva=3D5177429) at = /usr/src/sys/i386/i386/trap.c:809 #4 0xc07de847 in trap_pfault (frame=3D0xe4d73c5c, usermode=3D0, = eva=3D5177429) at /usr/src/sys/i386/i386/trap.c:727 #5 0xc07de45d in trap (frame=3D {tf_fs =3D 24, tf_es =3D 16, tf_ds =3D 16, tf_edi =3D -1017036800, = tf_esi =3D -1012054784, tf_ebp =3D -455656272, tf_isp =3D -455656312, = tf_ebx =3D 5177415, tf_edx =3D 32, tf_ecx =3D 5177413, tf_eax =3D 2014, = tf_trapno =3D 12, tf_err =3D 2, tf_eip =3D -1068330083, tf_cs =3D 8, = tf_eflags =3D 66054, tf_esp =3D 2, tf_ss =3D -455671807}) at = /usr/src/sys/i386/i386/trap.c:417 #6 0xc07cccba in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #7 0x00000018 in ?? () #8 0x00000010 in ?? () #9 0x00000010 in ?? () #10 0xc3614000 in ?? () #11 0xc3ad4500 in ?? () #12 0xe4d73cb0 in ?? () #13 0xe4d73c88 in ?? () #14 0x004f0047 in ?? () #15 0x00000020 in ?? () #16 0x004f0045 in ?? () #17 0x000007de in ?? () #18 0x0000000c in ?? () #19 0x00000002 in ?? () #20 0xc052939d in fxp_add_rfabuf (sc=3D0xc3614000, rxp=3D0xc3614410) at = /usr/src/sys/dev/fxp/if_fxp.c:2288 #21 0xc05285ec in fxp_intr_body (sc=3D0xc3614000, ifp=3D0xc3614000, = statack=3D16 '\020', count=3D-1) at /usr/src/sys/dev/fxp/if_fxp.c:1682 #22 0xc05283d0 in fxp_intr (xsc=3D0xc3614000) at = /usr/src/sys/dev/fxp/if_fxp.c:1555 #23 0xc0613d11 in ithread_loop (arg=3D0xc34f2600) at = /usr/src/sys/kern/kern_intr.c:547 #24 0xc0612dad in fork_exit (callout=3D0xc0613bb8 , = arg=3D0xc34f2600, frame=3D0xe4d73d48) at = /usr/src/sys/kern/kern_fork.c:790 #25 0xc07ccd1c in fork_trampoline () at = /usr/src/sys/i386/i386/exception.s:209 James Nelson=20 Emag Solutions, LLC=20 Phone: (404) 995-1665=20 Email: jnelson@emaglink.com=20 Visit us on the web at:=20 http://www.emaglink.com=20 This transmission may contain information that is privileged, = confidential and/or exempt from disclosure under applicable law. If you = are not the intended recipient, you are hereby notified that any = disclosure, copying, distribution, or use of the information contained = herein (including any reliance thereon) is STRICTLY PROHIBITED. If you = received this transmission in error, please immediately contact the = sender and destroy the material in its entirety, whether in electronic = or hard copy format. If you are unable or unwilling to comply with this = requirement, please inform the sender of this message immediately and = remove all correspondence from eMag Solutions from your e-mail system. = If no objection is immediately raised, you hereby agree that lack of = action on your part constitutes implied consent to abide by the terms = set forth above.=20 From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 19:20:02 2005 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 BE0DF16A4CE for ; Tue, 29 Mar 2005 19:20:02 +0000 (GMT) Received: from mail.revolutionsp.com (ganymede.revolutionsp.com [64.246.0.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AEDF43D39 for ; Tue, 29 Mar 2005 19:20:02 +0000 (GMT) (envelope-from security@revolutionsp.com) Received: from mail.revolutionsp.com (localhost [127.0.0.1]) by mail.revolutionsp.com (Postfix) with ESMTP id 87C4F15CA6 for ; Tue, 29 Mar 2005 13:19:06 -0600 (CST) Received: from 81.84.174.37 (SquirrelMail authenticated user security@revolutionsp.com) by mail.revolutionsp.com with HTTP; Tue, 29 Mar 2005 13:19:06 -0600 (CST) Message-ID: <61910.81.84.174.37.1112123946.squirrel@mail.revolutionsp.com> Date: Tue, 29 Mar 2005 13:19:06 -0600 (CST) From: "H. S." To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: A few thoughts.. 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, 29 Mar 2005 19:20:03 -0000 Hey all, I've been using FreeBSD for a long time, it's my favorite OS and I use it on all my servers and most workstations. However, due to the nature of some of the servers, I've always wondered about something, tho. It is related to something deep in the OS. Let me try to explain. For example, assume a shell server. There are permission restrictions everywhere, to avoid users from seeing information that should be available only to the administrator (ie: dmesg,systat, vmstat, and so on). One could assume users won't be able to access the information provided by these utilities. Please consider the following example: [UNAME@WORKSTATION:/home/UNAME/] sftp USERNAME@192.168.0.254 Connecting to 192.168.0.254... -- lan gateway -- USERNAME@192.168.0.254's password: sftp> put /sbin/dmesg dmesg 100% 5392 122.4KB/s 00:00 sftp> quit [UNAME@WORKSTATION:/home/UNAME/] ssh USERNAME@192.168.0.254 -- lan gateway -- USERNAME@192.168.0.254's password: Last login: Tue Mar 29 19:36:42 2005 from WORKSTATION Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD ?.?.? (UNKNOWN) Welcome to FreeBSD! Before seeking technical support, please use the following resources: o Security advisories and updated errata information for all releases are at http://www.FreeBSD.org/releases/ - always consult the ERRATA section for your release first as it's updated frequently. o The Handbook and FAQ documents are at http://www.FreeBSD.org/ and, along with the mailing lists, can be searched by going to http://www.FreeBSD.org/search/. If the doc distribution has been installed, they're also available formatted in /usr/share/doc. If you still have a question or problem, please take the output of `uname -a', along with any relevant error messages, and email it as a question to the questions@FreeBSD.org mailing list. If you are unfamiliar with FreeBSD's directory layout, please refer to the hier(7) manual page. If you are not familiar with manual pages, type `man man'. You may also use sysinstall(8) to re-enter the installation and configuration utility. Edit /etc/motd to change this login announcement. "man tuning" gives some tips how to tune performance of your FreeBSD system. -- David Scheidt [USERNAME@SERVER:/home/USERNAME]$ ./dmesg Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-STABLE #1: Wed Dec 15 20:18:13 WET 2004 ???@???:/usr/obj/usr/src/sys/??? Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium/P55C (199.31-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x544 Stepping = 4 Features=0x8001bf real memory = 83886080 (80 MB) avail memory = 72318976 (68 MB) (changed hostnames/logins - 192.168.0.254 is a host on my lan) My "USERNAME" account doesn't have access to /sbin/dmesg, but I uploaded a /sbin/dmesg from a 5.2.1-RELEASE to a 5.3-STABLE box, and then I could have access to this system information. The same goes for systat , vmstat, and all these commands that (most people think) shouldn't be available for regular users. Shouldn't this information be protected at kernel level? Am I missing something I can do about this ? Because this method works with everything that ressembles permissions in order to hide system information that can be obtained without root privileges. Another thought, one can use the "logger" utility to write to some logfile that is accessible via syslogd. example: [UNAME@WORKSTATION:/home/UNAME/] logger -t su: evilone to root on/dev/ttyp0 # tail /var/log/messages Mar 29 20:14:11 WORKSTATION su:: evilone to root on/dev/ttyp0 If you can't trust your logs.. This also poses another problem, with a little patience, one can fill up /var. Lastly, anyone knows if FreeBSD is getting systrace support ? I think of it as a major drawback in the security field, one can do very interesting things with systrace. Added with other freebsd features (jails, etc), it makes a very good security tool. Any comments appreciated! Regards. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 19:28:32 2005 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 6E96716A4EE for ; Tue, 29 Mar 2005 19:28:32 +0000 (GMT) Received: from mail28.sea5.speakeasy.net (mail28.sea5.speakeasy.net [69.17.117.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BA2F43D1D for ; Tue, 29 Mar 2005 19:28:32 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 7340 invoked from network); 29 Mar 2005 19:28:31 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail28.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 29 Mar 2005 19:28:30 -0000 Received: from hydrogen.funkthat.com (nspslg@localhost.funkthat.com [127.0.0.1])j2TJSTGH047336; Tue, 29 Mar 2005 11:28:29 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id j2TJSTPS047335; Tue, 29 Mar 2005 11:28:29 -0800 (PST) Date: Tue, 29 Mar 2005 11:28:28 -0800 From: John-Mark Gurney To: mohamed aslan Message-ID: <20050329192828.GC37984@funkthat.com> Mail-Followup-To: mohamed aslan , FreeBSD Hackers References: <319cceca0503281001792baf39@mail.gmail.com> <42485A54.9000101@freebsdbrasil.com.br> <319cceca05032811484cb1a95b@mail.gmail.com> <42487982.30909@freebsdbrasil.com.br> <319cceca05032907411014a218@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <319cceca05032907411014a218@mail.gmail.com> 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 cc: FreeBSD Hackers Subject: Re: organization 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, 29 Mar 2005 19:28:32 -0000 mohamed aslan wrote this message on Tue, Mar 29, 2005 at 07:41 -0800: Also, learn not to top post... it looses context... > guys this is not a flame war > but the linux way in arranging the source file is really better than > freebsd way, it's a fact. well, as I stated in a previous email, if you make a statement without detailing your reasons, many people feel that you are attacking FreeBSD.. You should be impressed that you didn't get more flames... > however it's easy to rearrange it in 1 min as someone said before. > but i mean this step should be done from the core team. No, this step should only be done by the repo manager... and let the people who have extensive experience handle it.. in some cases, it means that we'll have to keep two copies of the files for a long time so that all branches are properly buildable, or we'll have to go back and change all the old branches to make sure they use the new location.. That's a large undertaking... > for example all fs has to go in a subdir called fs well, not even NetBSD does this, and they are "better organized" than FreeBSD is... but luckily, you can just do ls -d *fs and get them... Though the reasons that ufs and nfs and isofs aren't in the fs is hysterical raisins... It's been a while since I looked at this, but I was surprised how many were in the fs dir.. so, this is more of a minor point.. > arch specific file should go in subdir called arch/(arch name) > and so on . > if ls the files in freebsd sys subdir , u will got about 54 subdirs > and a makefile while linux contains about 15 subdirs only. Again, FreeBSD was originally only i386 (and pc64), and for a long time, only a two arch project.. it wasn't till a few years ago that we started to grow many new arches (amd64, ia64, sparc64, powerpc, arm, and others).. So, at the time, putting i386 (and pc98 and alpha) at the top level made sense, but now that we have so many, yes, it doesn't make sense, but at the same time the cost (as others have layed out) is expensive to do.... Also, as time permits, such as when new drivers are written, old drivers retires, drivers rewritten, things are improving... such as the dev dir, instead of putting the drivers in isa, they are moved into dev.. one example is sio.c.. that used to be an isa device driver, but now lives in dev/sio + the various bus attachments since it is no longer isa specific... > guys, don't take my words against bsd , i admit that the performace of > bsd is much better than linux and i'm planning to change to it as my > primary os. but we can get the good things from linux and through out > the bad ones. Or at least the ideas.. :) we can't take in too much GPL code into the tree.. then it'd just be pointless... :) -- 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 Mar 29 19:35:56 2005 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 366D516A4CE for ; Tue, 29 Mar 2005 19:35:56 +0000 (GMT) Received: from mindfields.energyhq.es.eu.org (73.Red-213-97-200.pooles.rima-tde.net [213.97.200.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D19343D48 for ; Tue, 29 Mar 2005 19:35:52 +0000 (GMT) (envelope-from flynn@energyhq.es.eu.org) Received: from scienide.energyhq.es.eu.org (scienide.energyhq.es.eu.org [IPv6:2001:470:1f01:198:210:4bff:fe3d:e256]) by mindfields.energyhq.es.eu.org (Postfix) with SMTP id 9576E355EB; Tue, 29 Mar 2005 21:35:50 +0200 (CEST) Date: Tue, 29 Mar 2005 21:35:28 +0200 From: Miguel Mendez To: "H. S." Message-Id: <20050329213528.59dab2e2.flynn@energyhq.es.eu.org> In-Reply-To: <61910.81.84.174.37.1112123946.squirrel@mail.revolutionsp.com> References: <61910.81.84.174.37.1112123946.squirrel@mail.revolutionsp.com> X-Mailer: Sylpheed version 1.9.5 (GTK+ 2.6.4; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Tue__29_Mar_2005_21_35_28_+0200_.E0Fc9_bWDttBM9d" cc: freebsd-hackers@freebsd.org Subject: Re: A few thoughts.. 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, 29 Mar 2005 19:35:56 -0000 --Signature=_Tue__29_Mar_2005_21_35_28_+0200_.E0Fc9_bWDttBM9d Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 29 Mar 2005 13:19:06 -0600 (CST) "H. S." wrote: > [USERNAME@SERVER:/home/USERNAME]$ ./dmesg > Copyright (c) 1992-2004 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 [...] > real memory =3D 83886080 (80 MB) > avail memory =3D 72318976 (68 MB) > My "USERNAME" account doesn't have access to /sbin/dmesg, but I uploaded a > /sbin/dmesg from a 5.2.1-RELEASE to a 5.3-STABLE box, and then I could > have access to this system information. The same goes for systat , vmstat, > and all these commands that (most people think) shouldn't be available for > regular users. If you don't want users to run random binaries put /home and /tmp on their own partitions and mount them noexec. Also note that users can still read that info by accessing /var/log/messages and /var/run/ dmesg.boot > Shouldn't this information be protected at kernel level? Am I missing > something I can do about this ? Because this method works with everything > that ressembles permissions in order to hide system information that can > be obtained without root privileges. Sounds like security through obscurity to me. If you don't trust your shell users put them in a jail, where any bad behaviour can be contained. > If you can't trust your logs.. This also poses another problem, with a > little patience, one can fill up /var. =20 > Lastly, anyone knows if FreeBSD is getting systrace support ? I think of > it as a major drawback in the security field, one can do very interesting > things with systrace. Added with other freebsd features (jails, etc), it > makes a very good security tool. Have a look at mac(3), mac(4) and mac.conf(5), it's not systrace but you ca= n achieve similar results. Cheers, --=20 Miguel Mendez http://www.energyhq.es.eu.org PGP Key: 0xDC8514F1 --Signature=_Tue__29_Mar_2005_21_35_28_+0200_.E0Fc9_bWDttBM9d Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCSa4EnLctrNyFFPERAh27AJwP7eViE+d9CTZ1/2EBvJ5TnIYP9wCgrX3i seDsr1QRgxYT8Fa7tz8XGGY= =qd62 -----END PGP SIGNATURE----- --Signature=_Tue__29_Mar_2005_21_35_28_+0200_.E0Fc9_bWDttBM9d-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 19:57:55 2005 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 89CF516A4CF for ; Tue, 29 Mar 2005 19:57:55 +0000 (GMT) Received: from meisai.numachi.com (meisai.numachi.com [198.175.254.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 5A23843D54 for ; Tue, 29 Mar 2005 19:57:54 +0000 (GMT) (envelope-from reichert@numachi.com) Received: (qmail 76571 invoked from network); 29 Mar 2005 19:57:53 -0000 Received: from natto.numachi.com (198.175.254.216) by meisai.numachi.com with SMTP; 29 Mar 2005 19:57:53 -0000 Received: (qmail 29387 invoked by uid 1001); 29 Mar 2005 19:57:52 -0000 Date: Tue, 29 Mar 2005 14:57:52 -0500 From: Brian Reichert To: jumbler chi Message-ID: <20050329195752.GJ24326@numachi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i cc: freebsd-hackers@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: FreeBSD on Bochs 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, 29 Mar 2005 19:57:55 -0000 On Tue, Mar 29, 2005 at 05:57:23PM +0800, jumbler chi wrote: > Hi All: > I have a question about Freebsd on bochs. > I'm interesting to build owner Freebsd scratch. > Due the hardware limited , I want to run this scratch on Bochs. > Therefore , I refered a article , > http://sig9.com/articles/freebsd-on-bochs , to build a image under > 5.2R. > when I booted the image file under Bochs-2.0.2 .. it stoped on a > prompt , mountroot > . This doesn't address you're question directly, but I'd like to point out that I've had very good luck with FreeBSD under qemu, and it feels much faster than Bochs did. > Regards > > Jumbler > _______________________________________________ > 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" -- Brian Reichert 55 Crystal Ave. #286 Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 20:47:22 2005 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 6C5BA16A4CE for ; Tue, 29 Mar 2005 20:47:22 +0000 (GMT) Received: from priv-edtnes28.telusplanet.net (outbound04.telus.net [199.185.220.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1A0643D31 for ; Tue, 29 Mar 2005 20:47:21 +0000 (GMT) (envelope-from cpressey@catseye.mine.nu) Received: from catseye.biscuit.boo ([154.20.76.195]) by priv-edtnes28.telusplanet.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with SMTP <20050329204721.PKOL15504.priv-edtnes28.telusplanet.net@catseye.biscuit.boo> for ; Tue, 29 Mar 2005 13:47:21 -0700 Date: Tue, 29 Mar 2005 12:49:06 -0800 From: Chris Pressey To: freebsd-hackers@freebsd.org Message-Id: <20050329124906.1f5be3fd.cpressey@catseye.mine.nu> In-Reply-To: <20050329171753.GA14452@VARK.MIT.EDU> References: <319cceca05032907411014a218@mail.gmail.com> <20050329.084817.41630990.imp@bsdimp.com> <20050329163556.GA14181@VARK.MIT.EDU> <20050329.095249.71088143.imp@bsdimp.com> <20050329171753.GA14452@VARK.MIT.EDU> Organization: Cat's Eye Technologies X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: organization 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, 29 Mar 2005 20:47:22 -0000 On Tue, 29 Mar 2005 12:17:53 -0500 David Schultz wrote: > On Tue, Mar 29, 2005, M. Warner Losh wrote: > > In message: <20050329163556.GA14181@VARK.MIT.EDU> > > David Schultz writes: > > : On Tue, Mar 29, 2005, Warner Losh wrote: > > : > From: mohamed aslan > > : > Subject: Re: organization > > : > Date: Tue, 29 Mar 2005 07:41:25 -0800 > > : > > > : > > guys this is not a flame war > > : > > but the linux way in arranging the source file is really > > better than : > > freebsd way, it's a fact. > > : > > however it's easy to rearrange it in 1 min as someone said > > before. : > > but i mean this step should be done from the core > > team. : > > for example all fs has to go in a subdir called fs > > : > > arch specific file should go in subdir called arch/(arch name) > > : > > and so on . > > : > > > : > The problem is getting consensus on what is to be done. Sure, > > one can : > arbitrarily say this goes here or that goes there, but > > everyone's : > notion of reorg is a little different. It would take > > a lot of time : > and energy to get this consensus, which is better > > spent making things : > work better... > > : > > : I think few people would disagree with certain changes, like > > : putting MD bits in subdirectories called 'arch' as in NetBSD. The > > : real question is whether people care enough to justify the repo > > : bloat and the extra load on the cvsup mirrors. > > > > You've proven my point exactly: Some folks want to see i386 moved > > to arch/i386, others think it is stupid to do that. Discussion > > isn't possible here, so nothing will happen since there's no > > compelling reason to do anything, just a weak argument about how > > things might be nicer. > > > > The fact that we even consider cvsup load when discussing this means > > that clearly it is a weak idea: if we have to worry about the impact > > on how we distribute the sources for a change, isn't that really a > > weird criteria to use? > > Indeed, both the pro and con arguments are weak, which is probably > why nothing has happened. I for one would love to see libm called > libm and not msun, for instance, but when it comes down to it, I > have better things to do. Equivalent (or nearly equivalent) gains could probably be made by simply documenting the current layout better. Also, that's the sort of project that someone like Mohamed could undertake with minimal contention from the rest of the project. -Chris From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 21:13:21 2005 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 376D616A4D2 for ; Tue, 29 Mar 2005 21:13:21 +0000 (GMT) Received: from mail.revolutionsp.com (ganymede.revolutionsp.com [64.246.0.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3CE043D54 for ; Tue, 29 Mar 2005 21:13:20 +0000 (GMT) (envelope-from security@revolutionsp.com) Received: from mail.revolutionsp.com (localhost [127.0.0.1]) by mail.revolutionsp.com (Postfix) with ESMTP id 21EDD15CA6 for ; Tue, 29 Mar 2005 15:12:25 -0600 (CST) Received: from 81.84.174.37 (SquirrelMail authenticated user security@revolutionsp.com) by mail.revolutionsp.com with HTTP; Tue, 29 Mar 2005 15:12:25 -0600 (CST) Message-ID: <62208.81.84.174.37.1112130745.squirrel@mail.revolutionsp.com> In-Reply-To: <20050329213528.59dab2e2.flynn@energyhq.es.eu.org> References: <61910.81.84.174.37.1112123946.squirrel@mail.revolutionsp.com> <20050329213528.59dab2e2.flynn@energyhq.es.eu.org> Date: Tue, 29 Mar 2005 15:12:25 -0600 (CST) From: "H. S." To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: A few thoughts.. 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, 29 Mar 2005 21:13:21 -0000 > On Tue, 29 Mar 2005 13:19:06 -0600 (CST) > "H. S." wrote: > > >> [USERNAME@SERVER:/home/USERNAME]$ ./dmesg >> Copyright (c) 1992-2004 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > [...] >> real memory = 83886080 (80 MB) >> avail memory = 72318976 (68 MB) > >> My "USERNAME" account doesn't have access to /sbin/dmesg, but I uploaded >> a >> /sbin/dmesg from a 5.2.1-RELEASE to a 5.3-STABLE box, and then I could >> have access to this system information. The same goes for systat , >> vmstat, >> and all these commands that (most people think) shouldn't be available >> for >> regular users. > > If you don't want users to run random binaries put /home and /tmp on > their own partitions and mount them noexec. Also note that users can > still read that info by accessing /var/log/messages and /var/run/ > dmesg.boot > I do want them to run random binaries, such as psybncs, eggdrops, shoutcast servers, etc. Mounting /home noexec isn't an option, /tmp is noexec tho. >> Shouldn't this information be protected at kernel level? Am I missing >> something I can do about this ? Because this method works with >> everything >> that ressembles permissions in order to hide system information that can >> be obtained without root privileges. > > Sounds like security through obscurity to me. If you don't trust your > shell users put them in a jail, where any bad behaviour can be > contained. > They need multiple IPs, and there are lots of users. Creating a jail for each user is not pratical in any mean (firewall rules, number of jails, disk space, to name a few). The ideal would be only root accessing this information, so users would need a setuid binary in order to be able to see such stuff. And since only the administrator could set the setuid bit.. This could be compared to what was done in FreeBSD lately, I remember in 4.7 (and probably later, up to 4.10 I think) a user could see the full connection lists (even connections from other users), only later the kern.ps_showallprocs/security.bsd.see_other_uids took effect for these matters too. I don't know how hard would it be to implement this kind of information containment in the heart of the system, and it surely could lead to many discussing about what should be hidden from users and what shouldnt. Personally, I don't like the hability of having users checking the kernel message buffer, or seeing the vmstat / tcp statistics etc. >> If you can't trust your logs.. This also poses another problem, with a >> little patience, one can fill up /var. > >> Lastly, anyone knows if FreeBSD is getting systrace support ? I think of >> it as a major drawback in the security field, one can do very >> interesting >> things with systrace. Added with other freebsd features (jails, etc), it >> makes a very good security tool. > > Have a look at mac(3), mac(4) and mac.conf(5), it's not systrace but you > can achieve > similar results. Systrace is much more complex than mac. > > Cheers, > -- > Miguel Mendez > http://www.energyhq.es.eu.org > PGP Key: 0xDC8514F1 > > From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 21:25:21 2005 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 C7A2E16A4CE; Tue, 29 Mar 2005 21:25:21 +0000 (GMT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D01943D54; Tue, 29 Mar 2005 21:25:21 +0000 (GMT) (envelope-from bmah@freebsd.org) Received: from localhost.localdomain (dns.packetdesign.com [65.192.41.10]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j2TLPJEK013796 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 29 Mar 2005 13:25:20 -0800 From: "Bruce A. Mah" To: Craig Boston In-Reply-To: <20050329172218.GA86797@nowhere> References: <319cceca0503281001792baf39@mail.gmail.com> <20050328191758.GB3141@britannica.bec.de> <20050329172218.GA86797@nowhere> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-o9yWFGK5ROPzT4meVODS" Date: Tue, 29 Mar 2005 13:25:19 -0800 Message-Id: <1112131519.749.64.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port cc: "Bruce A. Mah" cc: Divacky Roman cc: freebsd-hackers@freebsd.org Subject: Re: organization 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, 29 Mar 2005 21:25:21 -0000 --=-o9yWFGK5ROPzT4meVODS Content-Type: text/plain Content-Transfer-Encoding: quoted-printable If memory serves me right, Craig Boston wrote: > On Tue, Mar 29, 2005 at 05:05:38PM +0200, Divacky Roman wrote: > > wasnt here some discussion about moving FreeBSD to subversion (as some = other > > projects did - samba, mono etc.)? and subversion solves this... >=20 > Yes, a few people have looked at it from time to time (raises hand as > one of the guilty parties). >=20 > The last I heard, subversion did not scale well to the massive amount of > files that are in the FreeBSD repository. IIRC it's been a while since > this was tested, so it may or may not be true anymore. SVK may > partially address this by bypassing libwc. Well, someone's part-way there with a Subversion mirror of src/. From http://www.freebsd.org/support.html: A public Subversion mirror of the FreeBSD src/ CVS repository is provided at svn://svn.clkao.org/freebsd/. A web interface is also available. This is intended for people who would like to try the svk distributed version control system. This of course doesn't include ports/ or doc/, so it doesn't really answer the scalability question. > Also, repository size is a big issue (no pun intended). If adding a few > hundred megs for repo-copies is prohibitively expensive, I don't think > increasing the repo size by many gigabytes would go over very well. > Subversion repositories can easily be several times the size of a CVS > repository containing the same data. This is dependent (among other things) on the nature of the files in the repository and which repository back-end is used. I did a conversion at ${REALJOB} in December where I converted 1.3GB of CVS repository to about 1.5GB in Subversion. For the curious, the back-end was FSFS, and an earlier test conversion using the BDB back-end took about 2.1GB. I know this is smaller than the FreeBSD repository. I have this vague, handwavy feeling (colored no doubt by positive experiences using it at ${REALJOB}) that Subversion, as well as the conversion tool (cvs2svn) have matured a bit since the last time this topic came up. But I'm not necessarily advocating a switch either. Cheers, Bruce. --=-o9yWFGK5ROPzT4meVODS Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCSce/2MoxcVugUsMRAgIXAKDDu2FERptl7H9fKqQx34rVXuN7xACggzQ3 nlExb+gcNfqiYzu+8U1qLYU= =wxGS -----END PGP SIGNATURE----- --=-o9yWFGK5ROPzT4meVODS-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 21:30:25 2005 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 6959216A4CE for ; Tue, 29 Mar 2005 21:30:25 +0000 (GMT) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E92343D49 for ; Tue, 29 Mar 2005 21:30:25 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (storm.stura.uni-rostock.de [139.30.252.72]) by hydra.bec.de (Postfix) with ESMTP id BE61535707 for ; Tue, 29 Mar 2005 23:30:22 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1001) id E2F737CEF; Tue, 29 Mar 2005 23:28:10 +0200 (CEST) Date: Tue, 29 Mar 2005 23:28:10 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20050329212810.GB3199@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <61910.81.84.174.37.1112123946.squirrel@mail.revolutionsp.com> <20050329213528.59dab2e2.flynn@energyhq.es.eu.org> <62208.81.84.174.37.1112130745.squirrel@mail.revolutionsp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62208.81.84.174.37.1112130745.squirrel@mail.revolutionsp.com> User-Agent: Mutt/1.5.9i Subject: Re: A few thoughts.. 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, 29 Mar 2005 21:30:25 -0000 On Tue, Mar 29, 2005 at 03:12:25PM -0600, H. S. wrote: > This could be compared to what was done in FreeBSD lately, I remember in > 4.7 (and probably later, up to 4.10 I think) a user could see the full > connection lists (even connections from other users), only later the > kern.ps_showallprocs/security.bsd.see_other_uids took effect for these > matters too. It needs time to implement and actually process such checks. > > Have a look at mac(3), mac(4) and mac.conf(5), it's not systrace but you > > can achieve > > similar results. > > Systrace is much more complex than mac. That's a good one! It's actually quite the reverse, MAC is much more powerful than systrace, simply because it operates on a different level. You can do all this kind of checks with a MAC policy, if something does not have the necessary hooks, complain to Robert Watson :) Joerg From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 21:36:24 2005 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 9F27A16A4CE for ; Tue, 29 Mar 2005 21:36:24 +0000 (GMT) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F83543D4C for ; Tue, 29 Mar 2005 21:36:24 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (storm.stura.uni-rostock.de [139.30.252.72]) by hydra.bec.de (Postfix) with ESMTP id 108C335707; Tue, 29 Mar 2005 23:36:23 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1001) id 569F67CEF; Tue, 29 Mar 2005 23:34:11 +0200 (CEST) Date: Tue, 29 Mar 2005 23:34:11 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20050329213411.GC3199@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org, Craig Boston , Divacky Roman References: <319cceca0503281001792baf39@mail.gmail.com> <4248557A.7000302@elischer.org> <20050328191758.GB3141@britannica.bec.de> <20050329150538.GA84533@stud.fit.vutbr.cz> <20050329172218.GA86797@nowhere> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050329172218.GA86797@nowhere> User-Agent: Mutt/1.5.9i cc: Craig Boston cc: Divacky Roman Subject: Re: organization 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, 29 Mar 2005 21:36:24 -0000 On Tue, Mar 29, 2005 at 11:22:19AM -0600, Craig Boston wrote: > The last I heard, subversion did not scale well to the massive amount of > files that are in the FreeBSD repository. IIRC it's been a while since > this was tested, so it may or may not be true anymore. SVK may > partially address this by bypassing libwc. That's not true. There are two major problems with subversion, compared to CVS: - the size of the working copy is doubled (because of the local cache) - annotation is linear in the number of revisions (of a file?) The first can be work-arounded by using SVK, but often is also an advantage, because e.g. diff is a pure local operation which doesn't have to contact the server. The second is related to how subversion stores the data. There are some persons working on speeding it up by using a cache, but I'm not sure how far the work is. On the other hand, CVS definitely doesn't scale to large repositories too, just think about the time a "cvs up" or "cvs tag" needs. You can't make everything fast, it is a compromise between speed, disk space and not to forget atomarity. Joerg From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 21:53:58 2005 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 2589016A4CE; Tue, 29 Mar 2005 21:53:58 +0000 (GMT) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id D477743D1F; Tue, 29 Mar 2005 21:53:57 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: by ion.gank.org (mail, from userid 1001) id 8988E2AF51; Tue, 29 Mar 2005 15:53:57 -0600 (CST) Date: Tue, 29 Mar 2005 15:53:53 -0600 From: Craig Boston To: "Bruce A. Mah" Message-ID: <20050329215352.GB86797@nowhere> Mail-Followup-To: Craig Boston , "Bruce A. Mah" , Divacky Roman , freebsd-hackers@freebsd.org References: <319cceca0503281001792baf39@mail.gmail.com> <20050328191758.GB3141@britannica.bec.de> <20050329172218.GA86797@nowhere> <1112131519.749.64.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112131519.749.64.camel@localhost> User-Agent: Mutt/1.4.2.1i cc: freebsd-hackers@freebsd.org cc: Divacky Roman Subject: Re: organization 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, 29 Mar 2005 21:53:58 -0000 On Tue, Mar 29, 2005 at 01:25:19PM -0800, Bruce A. Mah wrote: > Well, someone's part-way there with a Subversion mirror of src/. From > http://www.freebsd.org/support.html: > > A public Subversion mirror of the FreeBSD src/ CVS repository is > provided at svn://svn.clkao.org/freebsd/. Ah, yes, I do remember Chia-liang Kao was working on a CVS <-> Subversion bridge for use with svk. The ability to do incremental updates, even if it's only one-way, is a big win on both sides of the fence. > This of course doesn't include ports/ or doc/, so it doesn't really > answer the scalability question. Most of what I ran into was just in src/. I hesitate to say anything since it's been a long time and my memory is vague. ISTR a few simple operations on a file at the top level were causing the entire tree to be traversed. Unfortunately I don't remember exactly -- maybe it's time to test it again... One issue I do remember had to more do with apache and davsvn rather than subversion itself. Attempting to cancel a long running operation (say an accidental svn diff of the whole tree) would kill the frontend but leave the backend churning away on the server, which would bog down further requests (locking?), causing them to hang for a while, build up requests, and make the situation worse. I use subversion exclusively for my personal projects but none are big enough that I've run into that problem again. It may well have been fixed by now -- the version number has been creeping up while I wasn't looking :) > This is dependent (among other things) on the nature of the files in > the repository and which repository back-end is used. I did a > conversion at ${REALJOB} in December where I converted 1.3GB of CVS > repository to about 1.5GB in Subversion. For the curious, the > back-end was FSFS, and an earlier test conversion using the BDB > back-end took about 2.1GB. I know this is smaller than the FreeBSD > repository. Ah, I haven't played with FSFS yet. All my repositories are BDB that have been upgraded and migrated from version 0.something. Craig From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 22:09:37 2005 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 01FE116A4CE for ; Tue, 29 Mar 2005 22:09:37 +0000 (GMT) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id C90BA43D53 for ; Tue, 29 Mar 2005 22:09:36 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: by ion.gank.org (mail, from userid 1001) id 974192AF51; Tue, 29 Mar 2005 16:09:36 -0600 (CST) Date: Tue, 29 Mar 2005 16:09:34 -0600 From: Craig Boston To: freebsd-hackers@freebsd.org Message-ID: <20050329220933.GC86797@nowhere> Mail-Followup-To: Craig Boston , freebsd-hackers@freebsd.org References: <319cceca0503281001792baf39@mail.gmail.com> <4248557A.7000302@elischer.org> <20050328191758.GB3141@britannica.bec.de> <20050329150538.GA84533@stud.fit.vutbr.cz> <20050329172218.GA86797@nowhere> <20050329213411.GC3199@britannica.bec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050329213411.GC3199@britannica.bec.de> User-Agent: Mutt/1.4.2.1i Subject: Re: organization 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, 29 Mar 2005 22:09:37 -0000 On Tue, Mar 29, 2005 at 11:34:11PM +0200, Joerg Sonnenberger wrote: > That's not true. There are two major problems with subversion, compared > to CVS: > - the size of the working copy is doubled (because of the local cache) > - annotation is linear in the number of revisions (of a file?) Not trying to spread false information about Subversion -- I like it very much and use it for all my personal projects :) Just stating my opinion based on observations made while using it. > The first can be work-arounded by using SVK, but often is also an > advantage, because e.g. diff is a pure local operation which doesn't > have to contact the server. Well, you don't have the extra working copy files, but you usually end up eating up at least as much space for your local repository mirror; unless you have a lot of working copies checked out. > On the other hand, CVS definitely doesn't scale to large repositories too, > just think about the time a "cvs up" or "cvs tag" needs. You can't make > everything fast, it is a compromise between speed, disk space and not to > forget atomarity. Keeping in mind that the tests I ran were back in the pre-1.0 days (right before 1.0 IIRC), Subversion was much faster on update, but significantly slower for checkout and diffs. Those operations scaled worse than O(n) as the repository grew. It would be interesting to run some more benchmarks (clkao's mirror eliminates much of the import hassle) and see how the latest subversion compares. Also, as Bruce reminded me, the new fsfs storage backend may have different characteristics that need to be taken into account. Of course Subversion fares much better on the atomicity issue, that's a given :) svk may be able to help too. I tried it for a while but eventually gave up because getting the perl bindings installed and working was a bit of a black art. Probably time to try the port again. Craig From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 22:29:15 2005 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 5D82B16A4CE; Tue, 29 Mar 2005 22:29:15 +0000 (GMT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FF8A43D49; Tue, 29 Mar 2005 22:29:15 +0000 (GMT) (envelope-from bmah@freebsd.org) Received: from localhost.localdomain (dns.packetdesign.com [65.192.41.10]) (authenticated bits=0) by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j2TMTDfp014648 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 29 Mar 2005 14:29:14 -0800 From: "Bruce A. Mah" To: Craig Boston In-Reply-To: <20050329215352.GB86797@nowhere> References: <319cceca0503281001792baf39@mail.gmail.com> <20050329172218.GA86797@nowhere><20050329215352.GB86797@nowhere> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-IfnshBWlmKQ5lUOZL/SN" Date: Tue, 29 Mar 2005 14:29:13 -0800 Message-Id: <1112135353.749.84.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port cc: "Bruce A. Mah" cc: Divacky Roman cc: freebsd-hackers@freebsd.org Subject: Re: organization 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, 29 Mar 2005 22:29:15 -0000 --=-IfnshBWlmKQ5lUOZL/SN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable If memory serves me right, Craig Boston wrote: > On Tue, Mar 29, 2005 at 01:25:19PM -0800, Bruce A. Mah wrote: > > This of course doesn't include ports/ or doc/, so it doesn't really > > answer the scalability question. >=20 > Most of what I ran into was just in src/. I hesitate to say anything > since it's been a long time and my memory is vague. ISTR a few simple > operations on a file at the top level were causing the entire tree to be > traversed. Unfortunately I don't remember exactly -- maybe it's time to > test it again... I know what you mean...I was looking through my notes for more details about our repository conversion and they were a little lacking. :-p > One issue I do remember had to more do with apache and davsvn rather > than subversion itself. Attempting to cancel a long running operation > (say an accidental svn diff of the whole tree) would kill the frontend > but leave the backend churning away on the server, which would bog down > further requests (locking?), causing them to hang for a while, build up > requests, and make the situation worse. Sounds like a bad situation there. On our server we use svn+ssh, except for a few Windows clients that use https. (BTW our server is running 4-STABLE and it's wonderful.) > I use subversion exclusively for my personal projects but none are big > enough that I've run into that problem again. It may well have been > fixed by now -- the version number has been creeping up while I wasn't > looking :) Heh. :-) 1.1.3 is current now, but one can find mentions of a 1.1.4 bugfix release being planned, as well as the (farther out) 1.2 release with locking. > > This is dependent (among other things) on the nature of the files in > > the repository and which repository back-end is used. I did a > > conversion at ${REALJOB} in December where I converted 1.3GB of CVS > > repository to about 1.5GB in Subversion. For the curious, the > > back-end was FSFS, and an earlier test conversion using the BDB > > back-end took about 2.1GB. I know this is smaller than the FreeBSD > > repository. >=20 > Ah, I haven't played with FSFS yet. All my repositories are BDB that > have been upgraded and migrated from version 0.something. While BDB worked well for us in testing, FSFS gave us the ability to do incremental backups of the repository, which was important for getting buy-in from my IT support group. I was a little nervous at using new code for the backend but it's had nary a hiccup. (Knock on wood.) As you probably know, a number of people have reported lockups with the BDB backend...it turns out to be more problems with the way that Subversion uses BDB, as well as people just not setting it up correctly. Bruce. --=-IfnshBWlmKQ5lUOZL/SN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCSda52MoxcVugUsMRAhpDAKD8aL6j+EmL1jm4Thn9T6y9GPKA1wCg8wsb Q2TB/Ppuxeby2s9dI9o0nyA= =Gp9W -----END PGP SIGNATURE----- --=-IfnshBWlmKQ5lUOZL/SN-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 22:41:21 2005 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 60E4716A4CE for ; Tue, 29 Mar 2005 22:41:21 +0000 (GMT) Received: from mail.revolutionsp.com (ganymede.revolutionsp.com [64.246.0.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id F307843D1F for ; Tue, 29 Mar 2005 22:41:20 +0000 (GMT) (envelope-from security@revolutionsp.com) Received: from mail.revolutionsp.com (localhost [127.0.0.1]) by mail.revolutionsp.com (Postfix) with ESMTP id 05CA315CA6 for ; Tue, 29 Mar 2005 16:40:20 -0600 (CST) Received: from 81.84.174.37 (SquirrelMail authenticated user security@revolutionsp.com) by mail.revolutionsp.com with HTTP; Tue, 29 Mar 2005 16:40:20 -0600 (CST) Message-ID: <62770.81.84.174.37.1112136020.squirrel@mail.revolutionsp.com> In-Reply-To: <20050329212810.GB3199@britannica.bec.de> References: <61910.81.84.174.37.1112123946.squirrel@mail.revolutionsp.com> <20050329213528.59dab2e2.flynn@energyhq.es.eu.org> <62208.81.84.174.37.1112130745.squirrel@mail.revolutionsp.com> <20050329212810.GB3199@britannica.bec.de> Date: Tue, 29 Mar 2005 16:40:20 -0600 (CST) From: "H. S." To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: A few thoughts.. 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, 29 Mar 2005 22:41:21 -0000 > On Tue, Mar 29, 2005 at 03:12:25PM -0600, H. S. wrote: >> This could be compared to what was done in FreeBSD lately, I remember in >> 4.7 (and probably later, up to 4.10 I think) a user could see the full >> connection lists (even connections from other users), only later the >> kern.ps_showallprocs/security.bsd.see_other_uids took effect for these >> matters too. > > It needs time to implement and actually process such checks. I understand, and can only congratulate the freebsd developers for the nice programming you've all gotten us used to. I can't code C enough to be able to do anything really complex, however I do have a noction of how much effort is put into stuff like this. > >> > Have a look at mac(3), mac(4) and mac.conf(5), it's not systrace but >> you >> > can achieve >> > similar results. >> >> Systrace is much more complex than mac. > > That's a good one! It's actually quite the reverse, MAC is much more > powerful than systrace, simply because it operates on a different > level. You can do all this kind of checks with a MAC policy, if > something does not have the necessary hooks, complain to Robert Watson :) > > Joerg Hmm, I'll furthen my MAC knowledge then :-) > _______________________________________________ > 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 Tue Mar 29 22:46:08 2005 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 33C4D16A4CE; Tue, 29 Mar 2005 22:46:08 +0000 (GMT) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2E0443D2D; Tue, 29 Mar 2005 22:46:07 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: by ion.gank.org (mail, from userid 1001) id 8F54C2AF51; Tue, 29 Mar 2005 16:46:07 -0600 (CST) Date: Tue, 29 Mar 2005 16:46:04 -0600 From: Craig Boston To: "Bruce A. Mah" Message-ID: <20050329224603.GD86797@nowhere> Mail-Followup-To: Craig Boston , "Bruce A. Mah" , freebsd-hackers@freebsd.org References: <319cceca0503281001792baf39@mail.gmail.com> <1112135353.749.84.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112135353.749.84.camel@localhost> User-Agent: Mutt/1.4.2.1i cc: freebsd-hackers@freebsd.org Subject: Re: organization 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, 29 Mar 2005 22:46:08 -0000 At the risk of going further and further off-topic from freebsd-hackers... On Tue, Mar 29, 2005 at 02:29:13PM -0800, Bruce A. Mah wrote: > Sounds like a bad situation there. On our server we use svn+ssh, except > for a few Windows clients that use https. (BTW our server is running > 4-STABLE and it's wonderful.) Hmmm, I initially didn't want to use that because I read that it suffers from the same security issues as CVS. The appeal of being able to fine-tune permissions and grant subversion access without shell access is quite luring. HTTP timeouts during long operations, on the other hand, suck. ( my server is woefully underpowered :-D ). Note to davsvn users with slow servers: http-timeout = 3600 is your friend. > Heh. :-) 1.1.3 is current now, but one can find mentions of a 1.1.4 > bugfix release being planned, as well as the (farther out) 1.2 release > with locking. Oh, I've been running 1.1.3 on both client and server since it went into ports (many dump/loads later). Just haven't taken the time to see what's new and compare to older versions. :) Craig From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 23:51:26 2005 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 BBA7A16A4FC for ; Tue, 29 Mar 2005 23:51:26 +0000 (GMT) Received: from smtp805.mail.sc5.yahoo.com (smtp805.mail.sc5.yahoo.com [66.163.168.184]) by mx1.FreeBSD.org (Postfix) with SMTP id 318D643D46 for ; Tue, 29 Mar 2005 23:51:26 +0000 (GMT) (envelope-from rsharpe@richardsharpe.com) Received: from unknown (HELO ns.aus.com) (ngsharpe1@sbcglobal.net@63.206.123.133 with plain) by smtp805.mail.sc5.yahoo.com with SMTP; 29 Mar 2005 23:51:25 -0000 Received: from ns.aus.com (durable [127.0.0.1]) by ns.aus.com (8.12.11/8.12.8) with ESMTP id j2TNfQTf004567 for ; Tue, 29 Mar 2005 15:41:49 -0800 Received: from localhost (rsharpe@localhost) by ns.aus.com (8.12.11/8.12.11/Submit) with ESMTP id j2TNfFQ6004564 for ; Tue, 29 Mar 2005 15:41:26 -0800 X-Authentication-Warning: ns.aus.com: rsharpe owned process doing -bs Date: Tue, 29 Mar 2005 15:41:15 -0800 (PST) From: Richard Sharpe X-X-Sender: rsharpe@durable To: freebsd-hackers@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Possible problems with mmap/munmap on 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: Tue, 29 Mar 2005 23:51:26 -0000 Hi, I am having some problems with the tdb package on FreeBSD 4.6.2 and 4.10. One of the things the above package does is: mmap the tdb file to a region of memory store stuff in the region (memmov etc). when it needs to extend the size of the region { munmap the region write data at the end of the file mmap the region again with a larger size } What I am seeing is that after the munmap the data written to the region is gone. However, if I insert an msync before the munmap, everything is nicely coherent. This seems odd (in the sense that it works without the msync under Linux). The region is mmapped with: mmap(NULL, tdb->map_size, PROT_READ|(tdb->read_only? 0:PROT_WRITE), MAP_SHARED|MAP_FILE, tdb->fd, 0); What I notice is that all the calls to mmap return the same address. A careful reading of the man pages for mmap and munmap does not suggest that I am doing anything wrong. Is it possible that FreeBSD is deferring flushing the dirty data, and then forgets to do it when the same starting address is used etc? Regards ----- Richard Sharpe, rsharpe[at]richardsharpe.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 00:43:58 2005 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 35F8716A4CE for ; Wed, 30 Mar 2005 00:43:58 +0000 (GMT) Received: from mxsf20.cluster1.charter.net (mxsf20.cluster1.charter.net [209.225.28.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id C395043D3F for ; Wed, 30 Mar 2005 00:43:57 +0000 (GMT) (envelope-from c0ldbyte@myrealbox.com) Received: from mxip08.cluster1.charter.net (mxip08a.cluster1.charter.net [209.225.28.138])j2U0huOd028203 for ; Tue, 29 Mar 2005 19:43:56 -0500 Received: from 24.247.253.134.gha.mi.chartermi.net (HELO eleanor.us1.wmi.uvac.net) (24.247.253.134) by mxip08.cluster1.charter.net with ESMTP; 29 Mar 2005 19:43:55 -0500 X-Ironport-AV: i="3.91,132,1110171600"; d="scan'208"; a="781478297:sNHT536541300" Date: Tue, 29 Mar 2005 19:43:52 -0500 (EST) From: c0ldbyte To: freebsd-hackers@freebsd.org In-Reply-To: <62208.81.84.174.37.1112130745.squirrel@mail.revolutionsp.com> Message-ID: <20050329193558.L33759@eleanor.us1.wmi.uvac.net> References: <61910.81.84.174.37.1112123946.squirrel@mail.revolutionsp.com> <20050329213528.59dab2e2.flynn@energyhq.es.eu.org> <62208.81.84.174.37.1112130745.squirrel@mail.revolutionsp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: A few thoughts.. 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, 30 Mar 2005 00:43:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 29 Mar 2005, H. S. wrote: >> If you don't want users to run random binaries put /home and /tmp on >> their own partitions and mount them noexec. Also note that users can >> still read that info by accessing /var/log/messages and /var/run/ >> dmesg.boot >> > > I do want them to run random binaries, such as psybncs, eggdrops, > shoutcast servers, etc. Mounting /home noexec isn't an option, /tmp is > noexec tho. On another hand, you could provide safe and secure system provided binaries that they would have to use instead of compiling their own. which would solve the case and ultimately when upgrading the package provided to them would upgrade all the users at once without you having to worry about insecurities being scattered throughout your system. Now I could see if this was a development server then you obviously would want to allow your users to do such a thing but since you mentioned things like psybnc, shoutcast, etc... the thought to me doesnt resemble a development server. So my suggestion would be provide the software they need on a as-is-basis and take requests and mount the user partition with the [noexec] option and tune sysctl and operate in a secure level + chmod/chflag the proper files and make 1 jail for the whole user based part of the system for all that to run out of. Best of luck, --c0ldbyte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCSfZKsmFQuvffl58RAsw0AJkB6cLDGL4dsY9FAGrKZatn8+MotQCfeEX3 5R8zcR7nyVJQL1dgub0/nj0= =h8hs -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 00:53:40 2005 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 428BC16A4CF for ; Wed, 30 Mar 2005 00:53:40 +0000 (GMT) Received: from mxsf34.cluster1.charter.net (mxsf34.cluster1.charter.net [209.225.28.159]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBE8E43D53 for ; Wed, 30 Mar 2005 00:53:39 +0000 (GMT) (envelope-from c0ldbyte@myrealbox.com) Received: from mxip14.cluster1.charter.net (mxip14a.cluster1.charter.net [209.225.28.144])j2U0rcxA009275 for ; Tue, 29 Mar 2005 19:53:38 -0500 Received: from 24.247.253.134.gha.mi.chartermi.net (HELO eleanor.us1.wmi.uvac.net) (24.247.253.134) by mxip14.cluster1.charter.net with ESMTP; 29 Mar 2005 19:53:38 -0500 X-Ironport-AV: i="3.91,132,1110171600"; d="scan'208"; a="139781759:sNHT20805060" Date: Tue, 29 Mar 2005 19:53:34 -0500 (EST) From: c0ldbyte To: freebsd-hackers@freebsd.org In-Reply-To: <1606503991.1112143381070.JavaMail.nobody@app5.ni.bg> Message-ID: <20050329195102.Y33863@eleanor.us1.wmi.uvac.net> References: <1606503991.1112143381070.JavaMail.nobody@app5.ni.bg> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: =?windows-1251?b?QUJWLkJHIODi8u7s4PLo9+XtIO7y4+7i7vA=?= 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, 30 Mar 2005 00:53:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 30 Mar 2005 freebsd-hackers@freebsd.org wrote: > blagodarq za izpratenoto ot Vas pismo nai skoro shte vi otgovorq!! > Can you guys at (Headquarters) turn the above auto reply off. By god it is not even readable. Thanks -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xF7DF979F iD8DBQFCSfiSsmFQuvffl58RAiXnAJ4sGmLJGYFY26qED+wFtQqPFg124gCghCiQ 1phAaGNZACBRy4hkJ2aY1DI= =V5zw -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 02:18:40 2005 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 C05B816A4CE; Wed, 30 Mar 2005 02:18:40 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5712843D4C; Wed, 30 Mar 2005 02:18:40 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j2U2IWjc032980; Tue, 29 Mar 2005 21:18:32 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j2U2IWr9032979; Tue, 29 Mar 2005 21:18:32 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Tue, 29 Mar 2005 21:18:32 -0500 From: David Schultz To: Richard Sharpe Message-ID: <20050330021831.GA26006@VARK.MIT.EDU> Mail-Followup-To: Richard Sharpe , freebsd-hackers@FreeBSD.ORG, alc@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: alc@FreeBSD.ORG cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Possible problems with mmap/munmap on 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: Wed, 30 Mar 2005 02:18:41 -0000 On Tue, Mar 29, 2005, Richard Sharpe wrote: > Hi, > > I am having some problems with the tdb package on FreeBSD 4.6.2 and 4.10. > > One of the things the above package does is: > > mmap the tdb file to a region of memory > store stuff in the region (memmov etc). > when it needs to extend the size of the region { > munmap the region > write data at the end of the file > mmap the region again with a larger size > } > > What I am seeing is that after the munmap the data written to the region > is gone. > > However, if I insert an msync before the munmap, everything is nicely > coherent. This seems odd (in the sense that it works without the msync > under Linux). > > The region is mmapped with: > > mmap(NULL, tdb->map_size, > PROT_READ|(tdb->read_only? 0:PROT_WRITE), > MAP_SHARED|MAP_FILE, tdb->fd, 0); > > What I notice is that all the calls to mmap return the same address. > > A careful reading of the man pages for mmap and munmap does not suggest > that I am doing anything wrong. > > Is it possible that FreeBSD is deferring flushing the dirty data, and then > forgets to do it when the same starting address is used etc? It looks like all of the underlying pages are getting invalidated in vm_object_page_remove(). This is clearly the right thing to do for private mappings, but it seems wrong for shared mappings. Perhaps Alan has some insight. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 03:46:49 2005 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 6289D16A4CE for ; Wed, 30 Mar 2005 03:46:49 +0000 (GMT) Received: from ms-smtp-03-eri0.southeast.rr.com (ms-smtp-03-lbl.southeast.rr.com [24.25.9.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEE0F43D48 for ; Wed, 30 Mar 2005 03:46:48 +0000 (GMT) (envelope-from jason@ec.rr.com) Received: from [192.168.1.100] (cpe-065-184-201-054.ec.rr.com [65.184.201.54]) j2U3kjY4024111; Tue, 29 Mar 2005 22:46:45 -0500 (EST) Message-ID: <424A23A8.5040109@ec.rr.com> Date: Tue, 29 Mar 2005 22:57:28 -0500 From: jason henson User-Agent: Mozilla Thunderbird 1.0 (X11/20050321) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Jeremy References: <423C15C5.6040902@fsn.hu> <20050327133059.3d68a78c@Magellan.Leidinger.net> <20050327134044.GM78512@silverwraith.com> <20050327162839.2fafa6aa@Magellan.Leidinger.net> <5bbfe7d405032823144fc1af7b@mail.gmail.com> <5bbfe7d405032823232103d537@mail.gmail.com> <20050329111107.GD69824@cirb503493.alcatel.com.au> In-Reply-To: <20050329111107.GD69824@cirb503493.alcatel.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine cc: David Leimbach cc: hackers@freebsd.org Subject: Re: Fwd: 5-STABLE kernel build with icc broken 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, 30 Mar 2005 03:46:49 -0000 Peter Jeremy wrote: >On Mon, 2005-Mar-28 23:23:19 -0800, David Leimbach wrote: > > >>meant to send this to the list too... sorry >> >> >>>Are you implying DragonFly uses FPU/SIMD? For that matter does any kernel? >>> >>> >>I believe it does use SIMD for some of it's fast memcopy stuff for >>it's messaging system >>actually. I remember Matt saying he was working on it. >> >>http://leaf.dragonflybsd.org/mailarchive/kernel/2004-04/msg00262.html >> >> > >That's almost a year ago and specifically for the amd64. Does anyone >know what the results were? > > > >>If you can manage the alignment issues it can be a huge win. >> >> > >For message passing within the kernel, you should be able to mandate >alignment as part of the API. > >I see the bigger issue being the need to save/restore the SIMD >engine's state during a system call. Currently, this is only saved on >if a different process wants to use the SIMD engine. For MMX, the >SIMD state is the FPU state - which is non-trivial. The little >reading I've done suggests that SSE and SSE2 are even larger. > >Saving the SIMD state would be more expensive that using integer >registers for small (and probably medium-sized) copies. > > > Later in that thread they discuss skipping the restore state to make things faster. The minimum buffer size they say this will be good for is between 2-4k. Does this make sense, or am I showing my ignorance? http://leaf.dragonflybsd.org/mailarchive/kernel/2004-04/msg00264.html From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 06:51:17 2005 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 69EBE16A4CE for ; Wed, 30 Mar 2005 06:51:17 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id DEC8C43D1D for ; Wed, 30 Mar 2005 06:51:15 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 5105 invoked from network); 30 Mar 2005 06:51:07 -0000 Received: from unknown (HELO straylight.ringlet.net) (213.16.36.82) by gandalf.online.bg with SMTP; 30 Mar 2005 06:51:07 -0000 Received: (qmail 11325 invoked by uid 1000); 30 Mar 2005 06:51:13 -0000 Date: Wed, 30 Mar 2005 09:51:12 +0300 From: Peter Pentchev To: c0ldbyte Message-ID: <20050330065112.GD4651@straylight.m.ringlet.net> Mail-Followup-To: c0ldbyte , freebsd-hackers@freebsd.org References: <1606503991.1112143381070.JavaMail.nobody@app5.ni.bg> <20050329195102.Y33863@eleanor.us1.wmi.uvac.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Uwl7UQhJk99r8jnw" Content-Disposition: inline In-Reply-To: <20050329195102.Y33863@eleanor.us1.wmi.uvac.net> User-Agent: Mutt/1.5.9i cc: freebsd-hackers@freebsd.org Subject: Re: ABV.BG =?windows-1251?b?4OLy7uzg8uj35e0g7vLj7uLu8A==?= 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, 30 Mar 2005 06:51:17 -0000 --Uwl7UQhJk99r8jnw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 29, 2005 at 07:53:34PM -0500, c0ldbyte wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On Wed, 30 Mar 2005 freebsd-hackers@freebsd.org wrote: >=20 > >blagodarq za izpratenoto ot Vas pismo nai skoro shte vi otgovorq!! > > >=20 > Can you guys at (Headquarters) turn the above auto reply off. > By god it is not even readable. There's pretty much nothing the guys at FreeBSD.org can do, except maybe find out which of the @abv.bg addresses subscribed to the lists generates this autoreply and unsubscribe it. ABV.BG is a widely-used Bulgarian free webmail service; apparently they have misconfigured their autoresponse setup very badly recently (including the faking of a sender address for no apparent reason at all), since I've seen similar complaints on several lists totally unrelated to FreeBSD.org. As to the response itself, it says 'thank you for the letter you sent; I'll respond as soon as possible'. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I've heard that this sentence is a rumor. --Uwl7UQhJk99r8jnw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCSkxg7Ri2jRYZRVMRAkKyAJ4/w09mPYQuSJWPyRHb6vA0E0aXwwCeJ5S6 parWaocwt/6u/qv176Tgfg8= =ly5D -----END PGP SIGNATURE----- --Uwl7UQhJk99r8jnw-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 08:01:24 2005 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 E502916A4CE for ; Wed, 30 Mar 2005 08:01:24 +0000 (GMT) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2050E43D54 for ; Wed, 30 Mar 2005 08:01:22 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j2U81EoQ026089 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 30 Mar 2005 18:01:14 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j2U81E7l071446; Wed, 30 Mar 2005 18:01:14 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j2U81D3S071445; Wed, 30 Mar 2005 18:01:13 +1000 (EST) (envelope-from pjeremy) Date: Wed, 30 Mar 2005 18:01:13 +1000 From: Peter Jeremy To: jason henson Message-ID: <20050330080113.GA71384@cirb503493.alcatel.com.au> References: <423C15C5.6040902@fsn.hu> <20050327133059.3d68a78c@Magellan.Leidinger.net> <20050327134044.GM78512@silverwraith.com> <20050327162839.2fafa6aa@Magellan.Leidinger.net> <5bbfe7d405032823144fc1af7b@mail.gmail.com> <5bbfe7d405032823232103d537@mail.gmail.com> <20050329111107.GD69824@cirb503493.alcatel.com.au> <424A23A8.5040109@ec.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <424A23A8.5040109@ec.rr.com> User-Agent: Mutt/1.4.2i cc: hackers@freebsd.org Subject: Re: Fwd: 5-STABLE kernel build with icc broken 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, 30 Mar 2005 08:01:25 -0000 On Tue, 2005-Mar-29 22:57:28 -0500, jason henson wrote: >Later in that thread they discuss skipping the restore state to make >things faster. The minimum buffer size they say this will be good for >is between 2-4k. Does this make sense, or am I showing my ignorance? > >http://leaf.dragonflybsd.org/mailarchive/kernel/2004-04/msg00264.html Yes. There are a variety of options for saving/restoring FPU state: a) save FPU state on kernel entry b) save FPU state on a context switch (or if the kernel wants the FPU) c) only save FPU state if a different process (or the kernel) wants the FPU 1) restore FPU on kernel exit 2) restore FPU state if a process wants the FPU. a and 1 are the most obvious - that's the way the integer registers are handled. I thought FreeBSD used to be c2 but it seems it has been changed to b2 since I looked last. Based on the mail above, it looks like Dfly was changed from 1 to 2 (I'm not sure if it's 'a' or 'c' on save). On the i386 (and probably most other CPUs), you can place the FPU into am "unavailable" state. This means that any attempt to use it will trigger a trap. The kernel will then restore FPU state and return. On a normal system call, if the FPU hasn't been used, the kernel will see that it's still in an "unavailable" state and can avoid saving the state. (On an i386, "unavailable" state is achieved by either setting CR0_TS or CR0_EM). This means you avoid having to always restore FPU state at the expense of an additional trap if the process actually uses the FPU. -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 13:00:58 2005 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 ECEFA16A4CE; Wed, 30 Mar 2005 13:00:58 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FD2F43D1F; Wed, 30 Mar 2005 13:00:58 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j2UD0qj6004486; Wed, 30 Mar 2005 08:00:52 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j2UD0pvt004485; Wed, 30 Mar 2005 08:00:51 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Wed, 30 Mar 2005 08:00:51 -0500 From: David Schultz To: Peter Jeremy Message-ID: <20050330130051.GA4416@VARK.MIT.EDU> Mail-Followup-To: Peter Jeremy , jason henson , hackers@FreeBSD.ORG, bde@FreeBSD.ORG References: <423C15C5.6040902@fsn.hu> <20050327133059.3d68a78c@Magellan.Leidinger.net> <20050327134044.GM78512@silverwraith.com> <20050327162839.2fafa6aa@Magellan.Leidinger.net> <5bbfe7d405032823144fc1af7b@mail.gmail.com> <5bbfe7d405032823232103d537@mail.gmail.com> <20050329111107.GD69824@cirb503493.alcatel.com.au> <424A23A8.5040109@ec.rr.com> <20050330080113.GA71384@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050330080113.GA71384@cirb503493.alcatel.com.au> cc: hackers@FreeBSD.ORG cc: jason henson cc: bde@FreeBSD.ORG Subject: Re: Fwd: 5-STABLE kernel build with icc broken 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, 30 Mar 2005 13:00:59 -0000 On Wed, Mar 30, 2005, Peter Jeremy wrote: > On Tue, 2005-Mar-29 22:57:28 -0500, jason henson wrote: > >Later in that thread they discuss skipping the restore state to make > >things faster. The minimum buffer size they say this will be good for > >is between 2-4k. Does this make sense, or am I showing my ignorance? > > > >http://leaf.dragonflybsd.org/mailarchive/kernel/2004-04/msg00264.html > > Yes. There are a variety of options for saving/restoring FPU state: > a) save FPU state on kernel entry > b) save FPU state on a context switch (or if the kernel wants the FPU) > c) only save FPU state if a different process (or the kernel) wants the FPU > 1) restore FPU on kernel exit > 2) restore FPU state if a process wants the FPU. > > a and 1 are the most obvious - that's the way the integer registers are > handled. > > I thought FreeBSD used to be c2 but it seems it has been changed to b2 > since I looked last. > > Based on the mail above, it looks like Dfly was changed from 1 to 2 > (I'm not sure if it's 'a' or 'c' on save). > > On the i386 (and probably most other CPUs), you can place the FPU into > am "unavailable" state. This means that any attempt to use it will > trigger a trap. The kernel will then restore FPU state and return. > On a normal system call, if the FPU hasn't been used, the kernel will > see that it's still in an "unavailable" state and can avoid saving the > state. (On an i386, "unavailable" state is achieved by either setting > CR0_TS or CR0_EM). This means you avoid having to always restore FPU > state at the expense of an additional trap if the process actually > uses the FPU. This is basically what FreeBSD does on i386 and amd64. (As a disclaimer, I haven't read the code very carefully, so I might be missing some of the details.) Upon taking a trap for a process that has never used the FPU before, we save the FPU state for the last process to use the FPU, then load a fresh FPU state. On subsequent context switches, the FPU state for processes that have already used the FPU gets loaded before entering user mode, I think. I haven't studied the code in enough detail to know what happens for SMP, where a process could be scheduled on a different processor before its FPU state is saved on the first processor. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 22:45:55 2005 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 3FD4B16A4CE for ; Tue, 29 Mar 2005 22:45:55 +0000 (GMT) Received: from geri.cc.fer.hr (geri.cc.fer.hr [161.53.72.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7556D43D46 for ; Tue, 29 Mar 2005 22:45:54 +0000 (GMT) (envelope-from ivoras@geri.cc.fer.hr) Received: from geri.cc.fer.hr (localhost.cc.fer.hr [127.0.0.1]) by geri.cc.fer.hr (8.13.1/8.13.1) with ESMTP id j2TMjlFt007909 for ; Wed, 30 Mar 2005 00:45:47 +0200 (CEST) (envelope-from ivoras@geri.cc.fer.hr) Received: from localhost (ivoras@localhost) by geri.cc.fer.hr (8.13.1/8.13.1/Submit) with ESMTP id j2TMjl6g007906 for ; Wed, 30 Mar 2005 00:45:47 +0200 (CEST) (envelope-from ivoras@geri.cc.fer.hr) Date: Wed, 30 Mar 2005 00:45:47 +0200 (CEST) From: Ivan Voras To: hackers@freebsd.org Message-ID: <20050330003901.H7826@geri.cc.fer.hr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Wed, 30 Mar 2005 13:10:27 +0000 Subject: MAC (was: A few thoughts...) 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, 29 Mar 2005 22:45:55 -0000 In the thread ("A few thoughts..") some problems were mentioned (disallowing users to start certain binaries) and some solutions (like putting the /home tree on a dedicated partition and using mount options). I'm interested could this be done with MAC, and how? There's not much documentation on *using* FreeBSD MAC capabilities (or I've just had no luck finding it), so could anyone give some examples, for this particular case? (The above thing can be done with SELinux MAC implementation) -- Every sufficiently advanced magic is indistinguishable from technology - Arthur C Anticlarke From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 03:57:35 2005 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 97E3A16A4CE for ; Wed, 30 Mar 2005 03:57:35 +0000 (GMT) Received: from delight.idiom.com (delight.idiom.com [216.240.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6219643D2D for ; Wed, 30 Mar 2005 03:57:35 +0000 (GMT) (envelope-from mwm-dated-1113019053.3ffb1c@mired.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id C30E119C920 for ; Tue, 29 Mar 2005 19:57:34 -0800 (PST) Received: from mired.org (mwm@idiom [216.240.32.1]) by idiom.com (8.12.11/8.12.11) with SMTP id j2U3vXMf019787 for ; Tue, 29 Mar 2005 19:57:34 -0800 (PST) (envelope-from mwm-dated-1113019053.3ffb1c@mired.org) Received: (qmail 85041 invoked by uid 1001); 30 Mar 2005 03:57:33 -0000 Received: by guru.mired.org (tmda-sendmail, from uid 1001); Tue, 29 Mar 2005 21:57:32 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16970.9131.32691.306914@guru.mired.org> Date: Tue, 29 Mar 2005 21:57:31 -0600 To: "H. S." In-Reply-To: <61910.81.84.174.37.1112123946.squirrel@mail.revolutionsp.com> References: <61910.81.84.174.37.1112123946.squirrel@mail.revolutionsp.com> X-Mailer: VM 7.17 under 21.4 (patch 16) "Corporate Culture" XEmacs Lucid X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Mike Meyer X-Mailman-Approved-At: Wed, 30 Mar 2005 13:10:27 +0000 cc: freebsd-hackers@freebsd.org Subject: Re: A few thoughts.. 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, 30 Mar 2005 03:57:35 -0000 In <61910.81.84.174.37.1112123946.squirrel@mail.revolutionsp.com>, H. S. typed: > My "USERNAME" account doesn't have access to /sbin/dmesg, but I uploaded a > /sbin/dmesg from a 5.2.1-RELEASE to a 5.3-STABLE box, and then I could > have access to this system information. The same goes for systat , vmstat, > and all these commands that (most people think) shouldn't be available for > regular users. I wouldn't say "most people think" those things shouldn't be available for regular users, because that's the first time in 25 years of managing Unix systems that I've run into that sentiment. What I'm really curious about is what makes you think FreeBSD itself tries to enforce your opinion. I'm running 5.3-STABLE built from fresh install of 5.3-RELEASE, haven't done anything to any of those binaries, and they are all world/group executable on my system. That means that there's no way to prevent any user from running them. dmesg isn't in the normal $PATH, but that's not an indication that users shouldn't be able to run it, merely that they aren't expected to need it. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 13:55:18 2005 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 E34A116A4CE for ; Wed, 30 Mar 2005 13:55:17 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id E665B43D58 for ; Wed, 30 Mar 2005 13:55:16 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j2UDtNh3005945; Wed, 30 Mar 2005 05:55:25 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j2UDtHrV005944; Wed, 30 Mar 2005 05:55:17 -0800 (PST) (envelope-from www) Date: Wed, 30 Mar 2005 05:55:17 -0800 (PST) Message-Id: <200503301355.j2UDtHrV005944@marlena.vvi.at> To: elric@imrryr.org From: "ALeine" cc: freebsd-hackers@freebsd.org cc: phk@phk.freebsd.dk cc: tech-security@netbsd.org Subject: A bunch of memory allocation bugs in CGD 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, 30 Mar 2005 13:55:18 -0000 I took a quick look at the latest NetBSD CGD code and found out that out of 19 memory allocation operations 11 (almost 60%) are done in a way that could lead to a segmentation violation which would leave behind a core dump full of sensitive information that could be used to compromise a CGD encrypted disk. While this attack is not very practical since it requires the attacker to be able to cause resource starvation at a specific time when cgdconfig is used, it is still possible. Here are the details... Memory allocation operations in files in src/sbin/cgdconfig: params.c 1 wrong, 1 correct pkcs5_pbkdf2.c 1 wrong, 1 correct utils.c 9 wrong, 6 correct params.c:90: p = malloc(sizeof(*p)); params.c-91- params_init(p); params.c-92- return p; params.c-93-} params.c-94- params.c-95-static void params.c-96-params_init(struct params *p) params.c-97-{ params.c-98- params.c-99- p->algorithm = NULL; -- pkcs5_pbkdf2.c:103: data = malloc(Slen + 4); pkcs5_pbkdf2.c-104- memcpy(data, S, Slen); -- utils.c:94: ret = malloc((nwords+1) * sizeof(char *)); utils.c-95- tmp1 = tmp = strdup(line); utils.c-96- while ((cur = strsep_getnext(&tmp, " \t")) != NULL) utils.c-97- ret[i++] = strdup(cur); -- utils.c:150: out = malloc(sizeof(*out)); utils.c-151- out->length = inlength; utils.c:152: out->text = malloc(out->length + 1); utils.c-153- memcpy(out->text, intext, out->length); utils.c-154- out->text[out->length] = '\0'; -- utils.c:188: sum = malloc(sizeof(*sum)); utils.c-189- sum->length = a1->length + a2->length; utils.c:190: sum->text = malloc(sum->length + 1); utils.c-191- memcpy(sum->text, a1->text, a1->length); -- utils.c-255- /* XXX do some level of error checking here */ utils.c:256: b = malloc(sizeof(*b)); utils.c-257- b->length = len; utils.c:258: b->text = malloc(BITS2BYTES(b->length)); utils.c-259- memcpy(b->text, buf, BITS2BYTES(b->length)); -- utils.c-323- /* XXX do some level of error checking here */ utils.c:324: b = malloc(sizeof(*b)); utils.c-325- b->length = MAX(x1->length, x2->length); utils.c:326: b->text = calloc(1, BITS2BYTES(b->length)); utils.c-327- for (i=0; i < BITS2BYTES(MIN(x1->length, x2->length)); i++) utils.c-328- b->text[i] = x1->text[i] ^ x2->text[i]; Also, using free_notnull() is pointless, that function should be removed and all calls to that function should be replaced with calls to free(3), since free(3) takes no action if the pointer is NULL. utils.c:171: free_notnull(s->text); utils.c:276: free_notnull(b->text); utils.c:411: free_notnull(tmp); utils.c:412: free_notnull(out); -- utils.c-495-void utils.c:496:free_notnull(void *b) utils.c-497-{ utils.c-498- utils.c-499- if (b) utils.c-500- free(b); utils.c-501-} I find it alarming that this kind of sloppy programming can be found in a piece of software that is supposedly designed to be secure and provide security. I believe the CGD code should be seriously audited before anyone considers using it in a production environment. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 14:39:36 2005 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 B387F16A4CE for ; Wed, 30 Mar 2005 14:39:36 +0000 (GMT) Received: from mindfields.energyhq.es.eu.org (73.Red-213-97-200.pooles.rima-tde.net [213.97.200.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E94D43D49 for ; Wed, 30 Mar 2005 14:39:32 +0000 (GMT) (envelope-from flynn@energyhq.es.eu.org) Received: from scienide.energyhq.es.eu.org (scienide.energyhq.es.eu.org [IPv6:2001:470:1f01:198:210:4bff:fe3d:e256]) by mindfields.energyhq.es.eu.org (Postfix) with SMTP id E4107366DE; Wed, 30 Mar 2005 16:39:29 +0200 (CEST) Date: Wed, 30 Mar 2005 16:39:03 +0200 From: Miguel Mendez To: "ALeine" Message-Id: <20050330163903.6bd36f46.flynn@energyhq.es.eu.org> In-Reply-To: <200503301355.j2UDtHrV005944@marlena.vvi.at> References: <200503301355.j2UDtHrV005944@marlena.vvi.at> X-Mailer: Sylpheed version 1.9.5 (GTK+ 2.6.4; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Wed__30_Mar_2005_16_39_03_+0200_/CLUuiykr5IJvPOa" cc: freebsd-hackers@freebsd.org Subject: Re: A bunch of memory allocation bugs in CGD 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, 30 Mar 2005 14:39:36 -0000 --Signature=_Wed__30_Mar_2005_16_39_03_+0200_/CLUuiykr5IJvPOa Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 30 Mar 2005 05:55:17 -0800 (PST) "ALeine" wrote: [Trollish CC trimmed.] > I find it alarming that this kind of sloppy programming can be found in > a piece of software that is supposedly designed to be secure and provide > security. I believe the CGD code should be seriously audited before > anyone considers using it in a production environment. This has nothing to do with FreeBSD development, take it elsewhere. What's your intention, start another flamefest like the endless CGD vs GBDE thread? Please. If you've found flaws in CGD contact the NetBSD developers and send patches or shut up (TM). Cheers, --=20 Miguel Mendez http://www.energyhq.es.eu.org PGP Key: 0xDC8514F1 --Signature=_Wed__30_Mar_2005_16_39_03_+0200_/CLUuiykr5IJvPOa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCSroOnLctrNyFFPERAq52AJ9fc8R2YW4Myh6Skee0MckkrqMIdgCdHpY9 izYin/wk/lYMiVksj6cdDCM= =FunC -----END PGP SIGNATURE----- --Signature=_Wed__30_Mar_2005_16_39_03_+0200_/CLUuiykr5IJvPOa-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 15:06:05 2005 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 A73D016A4CE for ; Wed, 30 Mar 2005 15:06:05 +0000 (GMT) Received: from mail.loquefaltaba.com (78.Red-213-96-97.pooles.rima-tde.net [213.96.97.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3708343D4C for ; Wed, 30 Mar 2005 15:06:04 +0000 (GMT) (envelope-from sico@loquefaltaba.com) Received: from localhost (localhost.loquefaltaba.com [127.0.0.1]) by mail.loquefaltaba.com (Postfix) with ESMTP id 88C4FC1BC for ; Wed, 30 Mar 2005 15:42:50 +0200 (CEST) Received: from mail.loquefaltaba.com ([127.0.0.1]) by localhost (sico.loquefaltaba.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86258-02 for ; Wed, 30 Mar 2005 15:42:49 +0200 (CEST) Received: from webmail.loquefaltaba.com (localhost.loquefaltaba.com [127.0.0.1]) by mail.loquefaltaba.com (Postfix) with ESMTP id EA6F3C1AF for ; Wed, 30 Mar 2005 15:42:48 +0200 (CEST) Received: from 187.red-80-38-105.pooles.rima-tde.net ([80.38.105.187]) (SquirrelMail authenticated user sico) by webmail.loquefaltaba.com with HTTP; Wed, 30 Mar 2005 15:42:48 +0200 (CEST) Message-ID: <2476.80.38.105.187.1112190168.squirrel@webmail.loquefaltaba.com> In-Reply-To: <20050330003901.H7826@geri.cc.fer.hr> References: <20050330003901.H7826@geri.cc.fer.hr> Date: Wed, 30 Mar 2005 15:42:48 +0200 (CEST) From: "David Barbero" To: hackers@freebsd.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at loquefaltaba.com Subject: Re: MAC (was: A few thoughts...) 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, 30 Mar 2005 15:06:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! See chpter 15 of the handbook http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac.html regards. - -- "Linux is for people who hate Windows, BSD is for people who love UNIX" "Social Engineer -> Because there is no patch for human stupidity" Ivan Voras dijo: > In the thread ("A few thoughts..") some problems were mentioned > (disallowing users to start certain binaries) and some solutions (like > putting the /home tree on a dedicated partition and using mount options). > I'm interested could this be done with MAC, and how? There's not much > documentation on *using* FreeBSD MAC capabilities (or I've just > had no luck finding it), so could anyone give some examples, for this > particular case? > > (The above thing can be done with SELinux MAC implementation) > > > -- > Every sufficiently advanced magic is indistinguishable from technology > - Arthur C Anticlarke > > _______________________________________________ > 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" > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iQIVAwUBQkqs2FzCah3DrEDZAQLKLA//T7PkOHSX+gtna1/VhE7Ix/Muew+spNL7 IvZ60QuCpBm/6u2Tza33FPCSHrq8hXC+9983BS4jexHeGSeAiMIQIEoFgBgtC8wm oVMv8NNlJkKvUX4cIcMxWUCwnzAavvhst1I4NQCwsn1avzMhorHh5dgnJvval6Ka Yoo8ApLSOgMSY5WVuIdtn4yuOCj/NOGDi0PfiLsB9hbSm+VwdU5ay0RkLrjifygC w/am5w2K+yPyZ/z1TyyRe2rPNQ8VystyBnivjfLqK2BKWuC6MTxt1LqvP82diWGP lBDDAwKUNl0DowXZL9325uaww/cQz2MZJlmCOOYwabueKxB78y/KxiTNviPwei2g kX69kpWl7+sLjNLzS1+b0rNC+Ga1iWy5mTqIZ8yii+zd7ChlfwnCsorgYeUW+unf oHfVUgUkJ7CmlXUftBxj9+c2DwcTfhBxH/9GShTLIUZySuFPfgwHhx0XuVrFm83V FgzYFLHw1POmi48wNiPV0RbSsyu64065Nq0pUThngZH8yWaampX8m0mqTUjkFCwP Bq1EtLgyRaBcfl8Y1FctUasSEHNRbPHrSQ839h+zPCgbalsLematAARkdto9nwPz X+v04l/7vyJb+TOPkbMUzpTySwHVsLZ9ztfatuz1GZ78dVVm3di4/JLVB8vMa307 oc9xEpY9EYM= =haid -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 15:49:37 2005 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 8C27916A4CE for ; Wed, 30 Mar 2005 15:49:37 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52CE443D39 for ; Wed, 30 Mar 2005 15:49:37 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j2UFnah3007481; Wed, 30 Mar 2005 07:49:37 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j2UFnLU7007478; Wed, 30 Mar 2005 07:49:21 -0800 (PST) (envelope-from www) Date: Wed, 30 Mar 2005 07:49:21 -0800 (PST) Message-Id: <200503301549.j2UFnLU7007478@marlena.vvi.at> To: flynn@energyhq.es.eu.org From: "ALeine" cc: freebsd-hackers@freebsd.org Subject: Re: A bunch of memory allocation bugs in CGD 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, 30 Mar 2005 15:49:37 -0000 flynn@energyhq.es.eu.org wrote: > This has nothing to do with FreeBSD development, take it > elsewhere. What's your intention, start another flamefest > like the endless CGD vs GBDE thread? Please. This may come as a surprise to you, but there are people on the freebsd-hackers mailing list who are not on the relevant NetBSD mailing lists, but who are still interested in CGD and who are likely candidates to do a 3rd party audit of CGD. Developers from BSD communities share code and ideas and they do peer reviews and audits from which everyone in the BSD communities benefits. There might be some heated discussions at times, but that's normal and as long as some good comes out of such discussions they can't be all bad, they make people work harder and focus more attention on issues that need to be improved. The fact that you posted inflammatory comments after falsely assuming that my motivation was the same as yours when replying to my post is more than ironic. > If you've found flaws in CGD contact the NetBSD developers and > send patches or shut up (TM). I notified the author and other people in BSD communities who are most likely to be interested in knowing about this and improving CGD. You may want to start paying attention and reading before you post or you could just apply a patch and take your own (TM) advice. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 16:00:24 2005 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 1E6B716A4CE for ; Wed, 30 Mar 2005 16:00:24 +0000 (GMT) Received: from arioch.imrryr.org (arioch.imrryr.org [216.254.67.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8605343D2F for ; Wed, 30 Mar 2005 16:00:23 +0000 (GMT) (envelope-from elric@imrryr.org) Received: from imrryr.org (localhost [127.0.0.1]) by arioch.imrryr.org (Postfix) with ESMTP id 1AE6837010; Wed, 30 Mar 2005 10:59:47 -0500 (EST) To: "ALeine" In-reply-to: Your message of "Wed, 30 Mar 2005 05:55:17 PST." <200503301355.j2UDtHrV005944@marlena.vvi.at> Organization: The Fall of Imrryr User-Agent: nmh-1.0.4 (NetBSD/alpha) X-Copyright: Copyright 2004, R. C. Dowdeswell. All Rights Reserved. X-Window-System: Release 6.3 Date: Wed, 30 Mar 2005 10:59:47 -0500 From: Roland Dowdeswell Message-Id: <20050330155947.1AE6837010@arioch.imrryr.org> cc: freebsd-hackers@freebsd.org cc: phk@phk.freebsd.dk cc: tech-security@netbsd.org Subject: Re: A bunch of memory allocation bugs in CGD 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, 30 Mar 2005 16:00:24 -0000 On 1112190917 seconds since the Beginning of the UNIX epoch "ALeine" wrote: > >I took a quick look at the latest NetBSD CGD code and found >out that out of 19 memory allocation operations 11 (almost 60%) >are done in a way that could lead to a segmentation violation >which would leave behind a core dump full of sensitive >information that could be used to compromise a CGD encrypted >disk. While this attack is not very practical since it requires >the attacker to be able to cause resource starvation at a >specific time when cgdconfig is used, it is still possible. >Here are the details... Thanks for having a look at that. I have checked in a fix. I presume that you have addressed the cases in GBDE where malloc's return code has not been checked? If so, perhaps cvsweb is a little behind. It looks to me like 2 or 4 mallocs can use a buffer without checking the return code. I am not convinced that you'd be able to exploit these in either CGD or GBDE because {Net,Free}BSD use an overcommit strategy for memory allocation, so it is unlikely that the process will be denied memory. It will just get killed without a core dump when it tries to instantiate memory that does not exist. All that said, I've fixed the problem and will be submitting a pullup request for the next NetBSD release. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 17:05:15 2005 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 84E4116A4D2 for ; Wed, 30 Mar 2005 17:05:15 +0000 (GMT) Received: from smtp811.mail.sc5.yahoo.com (smtp811.mail.sc5.yahoo.com [66.163.170.81]) by mx1.FreeBSD.org (Postfix) with SMTP id 98F4B43D2D for ; Wed, 30 Mar 2005 17:05:14 +0000 (GMT) (envelope-from rsharpe@richardsharpe.com) Received: from unknown (HELO ns.aus.com) (ngsharpe1@sbcglobal.net@67.122.205.175 with plain) by smtp811.mail.sc5.yahoo.com with SMTP; 30 Mar 2005 17:04:57 -0000 Received: from ns.aus.com (durable [127.0.0.1]) by ns.aus.com (8.12.11/8.12.8) with ESMTP id j2UGtGlu003482; Wed, 30 Mar 2005 08:55:18 -0800 Received: from localhost (rsharpe@localhost) by ns.aus.com (8.12.11/8.12.11/Submit) with ESMTP id j2UGtDZ5003479; Wed, 30 Mar 2005 08:55:16 -0800 X-Authentication-Warning: ns.aus.com: rsharpe owned process doing -bs Date: Wed, 30 Mar 2005 08:55:13 -0800 (PST) From: Richard Sharpe X-X-Sender: rsharpe@durable To: David Schultz In-Reply-To: <20050330021831.GA26006@VARK.MIT.EDU> Message-ID: References: <20050330021831.GA26006@VARK.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: alc@FreeBSD.ORG cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Possible problems with mmap/munmap on 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: Wed, 30 Mar 2005 17:05:15 -0000 On Tue, 29 Mar 2005, David Schultz wrote: > On Tue, Mar 29, 2005, Richard Sharpe wrote: > > Hi, > > > > I am having some problems with the tdb package on FreeBSD 4.6.2 and 4.10. > > > > One of the things the above package does is: > > > > mmap the tdb file to a region of memory > > store stuff in the region (memmov etc). > > when it needs to extend the size of the region { > > munmap the region > > write data at the end of the file > > mmap the region again with a larger size > > } > > > > What I am seeing is that after the munmap the data written to the region > > is gone. > > > > However, if I insert an msync before the munmap, everything is nicely > > coherent. This seems odd (in the sense that it works without the msync > > under Linux). > > > > The region is mmapped with: > > > > mmap(NULL, tdb->map_size, > > PROT_READ|(tdb->read_only? 0:PROT_WRITE), > > MAP_SHARED|MAP_FILE, tdb->fd, 0); > > It looks like all of the underlying pages are getting invalidated > in vm_object_page_remove(). This is clearly the right thing to do > for private mappings, but it seems wrong for shared mappings. > Perhaps Alan has some insight. OK, a simple test program that: writes some content C1 to a file mmaps file to S1 writes content C2 to S1 munmaps S1 mmaps S1 compares shows expected behavior writes content C1 to S1 munmaps S1 mmaps S1 compares shows expected behavior So, now to do things like extend the file after mmapping etc to see where the problem lies. Regards ----- Richard Sharpe, rsharpe[at]richardsharpe.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 17:07:50 2005 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 9448C16A4CE for ; Wed, 30 Mar 2005 17:07:50 +0000 (GMT) Received: from mail.revolutionsp.com (ganymede.revolutionsp.com [64.246.0.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3435D43D1D for ; Wed, 30 Mar 2005 17:07:50 +0000 (GMT) (envelope-from security@revolutionsp.com) Received: from mail.revolutionsp.com (localhost [127.0.0.1]) by mail.revolutionsp.com (Postfix) with ESMTP id 8ACF215CA6 for ; Wed, 30 Mar 2005 11:06:53 -0600 (CST) Received: from 81.84.174.37 (SquirrelMail authenticated user security@revolutionsp.com) by mail.revolutionsp.com with HTTP; Wed, 30 Mar 2005 11:06:53 -0600 (CST) Message-ID: <63519.81.84.174.37.1112202413.squirrel@mail.revolutionsp.com> In-Reply-To: <63511.81.84.174.37.1112202327.squirrel@mail.revolutionsp.com> References: <61910.81.84.174.37.1112123946.squirrel@mail.revolutionsp.com> <20050329213528.59dab2e2.flynn@energyhq.es.eu.org> <62208.81.84.174.37.1112130745.squirrel@mail.revolutionsp.com> <20050329193558.L33759@eleanor.us1.wmi.uvac.net> <63511.81.84.174.37.1112202327.squirrel@mail.revolutionsp.com> Date: Wed, 30 Mar 2005 11:06:53 -0600 (CST) From: "H. S." To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: A few thoughts.. 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, 30 Mar 2005 17:07:50 -0000 Thanks for all the replies, I'm considering mounting /home noexec, and installing the most common stuff system-wide, so it can be executed by any user. As I stated previously, I'm not much of a C programmer, but I can do some coding. I've been thinking into changing the core of the system a bit to return errors if some information is accessed by a normal user. I'd like to know if getuid() would work that deep in the system? And how can I register sysctl mibs in the kernel ? For example, say I wanted to create a kern.disclosure.no_dmesg ; Assuming I could find the piece(s) of code that dmesg (talking dmesg here, but I'll try to change some other stuff too) ultimately goes to, how would I compare the sysctl kern.disclosure.no_dmesg to 1 or 0 ? A good paper on this would be a very nice lead. Thanks! > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On Tue, 29 Mar 2005, H. S. wrote: >> >>>> If you don't want users to run random binaries put /home and /tmp on >>>> their own partitions and mount them noexec. Also note that users can >>>> still read that info by accessing /var/log/messages and /var/run/ >>>> dmesg.boot >>>> >>> >>> I do want them to run random binaries, such as psybncs, eggdrops, >>> shoutcast servers, etc. Mounting /home noexec isn't an option, /tmp is >>> noexec tho. >> >> On another hand, you could provide safe and secure system provided >> binaries that they would have to use instead of compiling their own. >> which would solve the case and ultimately when upgrading the package >> provided to them would upgrade all the users at once without you >> having to worry about insecurities being scattered throughout your >> system. Now I could see if this was a development server then you >> obviously would want to allow your users to do such a thing but since >> you mentioned things like psybnc, shoutcast, etc... the thought to me >> doesnt resemble a development server. So my suggestion would be >> provide the software they need on a as-is-basis and take requests and >> mount the user partition with the [noexec] option and tune sysctl >> and operate in a secure level + chmod/chflag the proper files and >> make 1 jail for the whole user based part of the system for all that >> to run out of. >> >> Best of luck, >> --c0ldbyte >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.0 (FreeBSD) >> >> iD8DBQFCSfZKsmFQuvffl58RAsw0AJkB6cLDGL4dsY9FAGrKZatn8+MotQCfeEX3 >> 5R8zcR7nyVJQL1dgub0/nj0= >> =h8hs >> -----END PGP SIGNATURE----- >> _______________________________________________ >> 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 Wed Mar 30 17:30:53 2005 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 844E416A4CE for ; Wed, 30 Mar 2005 17:30:53 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03BF943D41 for ; Wed, 30 Mar 2005 17:30:53 +0000 (GMT) (envelope-from maslanbsd@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so237469wra for ; Wed, 30 Mar 2005 09:30:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=NsOOG5ybcC27NCDZFm7nD6F8G0gxHSlN5tWKboagH8saWJ6nwKYXlJSnk6BJjGNFs+rIgY3fJviNO++7rRfqN84bwa+MX/44sguezOsxbMMiXwW7dZmBDFcwDILIRrDkGvrQwV9j2AzmxhOYerWs0VJ7xoP508mkSCEcs3MDQxc= Received: by 10.54.35.71 with SMTP id i71mr611817wri; Wed, 30 Mar 2005 09:30:47 -0800 (PST) Received: by 10.54.99.7 with HTTP; Wed, 30 Mar 2005 09:30:47 -0800 (PST) Message-ID: <319cceca05033009305c410e85@mail.gmail.com> Date: Wed, 30 Mar 2005 09:30:47 -0800 From: mohamed aslan To: freebsd-hackers@freebsd.org In-Reply-To: <20050329224603.GD86797@nowhere> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <319cceca0503281001792baf39@mail.gmail.com> <1112135353.749.84.camel@localhost> <20050329224603.GD86797@nowhere> Subject: Re: organization X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mohamed aslan List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2005 17:30:53 -0000 i cann't reply to all of ur comments but , that is what makes u break off , as DragonFly split of u u took my opinion as an attack, u just wanna flaming, u also got off topic "CVS and SVN", my words were really facts Mr Scott , Linux layout is better than FreeBSD layout , FreeBSD performance it better than Linux one , and thnx for silly reply. that's why i hate forums and maillists and i should mail this directly to the core members. On Tue, 29 Mar 2005 16:46:04 -0600, Craig Boston wrote: > At the risk of going further and further off-topic from > freebsd-hackers... > > On Tue, Mar 29, 2005 at 02:29:13PM -0800, Bruce A. Mah wrote: > > Sounds like a bad situation there. On our server we use svn+ssh, except > > for a few Windows clients that use https. (BTW our server is running > > 4-STABLE and it's wonderful.) > > Hmmm, I initially didn't want to use that because I read that it suffers > from the same security issues as CVS. The appeal of being able to > fine-tune permissions and grant subversion access without shell access > is quite luring. > > HTTP timeouts during long operations, on the other hand, suck. ( my > server is woefully underpowered :-D ). > > Note to davsvn users with slow servers: http-timeout = 3600 is your > friend. > > > Heh. :-) 1.1.3 is current now, but one can find mentions of a 1.1.4 > > bugfix release being planned, as well as the (farther out) 1.2 release > > with locking. > > Oh, I've been running 1.1.3 on both client and server since it went into > ports (many dump/loads later). Just haven't taken the time to see > what's new and compare to older versions. :) > > Craig > _______________________________________________ > 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" > -- I'm Searching For Perfection, So Even If U Need Portability U've To Use Assembly ;-) http://www.maslanlab.org From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 17:36:23 2005 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 70AEF16A4CE; Wed, 30 Mar 2005 17:36:23 +0000 (GMT) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EFD843D1F; Wed, 30 Mar 2005 17:36:23 +0000 (GMT) (envelope-from alc@cs.rice.edu) Received: from localhost (calypso.cs.rice.edu [128.42.1.127]) by cs.rice.edu (Postfix) with ESMTP id EC2934A9A5; Wed, 30 Mar 2005 11:36:22 -0600 (CST) Received: from cs.rice.edu ([128.42.1.30]) by localhost (calypso.cs.rice.edu [128.42.1.127]) (amavisd-new, port 10024) with LMTP id 30531-01-94; Wed, 30 Mar 2005 11:36:22 -0600 (CST) Received: by cs.rice.edu (Postfix, from userid 19572) id 739104A9A2; Wed, 30 Mar 2005 11:36:22 -0600 (CST) Date: Wed, 30 Mar 2005 11:36:22 -0600 From: Alan Cox To: Richard Sharpe , freebsd-hackers@FreeBSD.ORG, alc@FreeBSD.ORG Message-ID: <20050330173622.GJ20275@cs.rice.edu> References: <20050330021831.GA26006@VARK.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050330021831.GA26006@VARK.MIT.EDU> User-Agent: Mutt/1.4.2i X-Virus-Scanned: by amavis-2.2.1 at cs.rice.edu Subject: Re: Possible problems with mmap/munmap on 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: Wed, 30 Mar 2005 17:36:23 -0000 On Tue, Mar 29, 2005 at 09:18:32PM -0500, David Schultz wrote: > On Tue, Mar 29, 2005, Richard Sharpe wrote: > > Hi, > > > > I am having some problems with the tdb package on FreeBSD 4.6.2 and 4.10. > > > > One of the things the above package does is: > > > > mmap the tdb file to a region of memory > > store stuff in the region (memmov etc). > > when it needs to extend the size of the region { > > munmap the region > > write data at the end of the file > > mmap the region again with a larger size > > } > > > > What I am seeing is that after the munmap the data written to the region > > is gone. > > > > However, if I insert an msync before the munmap, everything is nicely > > coherent. This seems odd (in the sense that it works without the msync > > under Linux). > > > > The region is mmapped with: > > > > mmap(NULL, tdb->map_size, > > PROT_READ|(tdb->read_only? 0:PROT_WRITE), > > MAP_SHARED|MAP_FILE, tdb->fd, 0); > > > > What I notice is that all the calls to mmap return the same address. > > > > A careful reading of the man pages for mmap and munmap does not suggest > > that I am doing anything wrong. > > > > Is it possible that FreeBSD is deferring flushing the dirty data, and then > > forgets to do it when the same starting address is used etc? > > It looks like all of the underlying pages are getting invalidated > in vm_object_page_remove(). This is clearly the right thing to do > for private mappings, but it seems wrong for shared mappings. > Perhaps Alan has some insight. Hmm. In this code path we don't call vm_object_page_remove() on vnode-backed objects, only default/swap-backed objects that have no other mappings that reference them. Regards, Alan From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 18:12:11 2005 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 7D52216A4CE for ; Wed, 30 Mar 2005 18:12:11 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 815F943D54 for ; Wed, 30 Mar 2005 18:12:10 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 3411C1F007 for ; Wed, 30 Mar 2005 20:12:09 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 054086433; Wed, 30 Mar 2005 20:12:08 +0200 (CEST) Date: Wed, 30 Mar 2005 20:12:08 +0200 From: Marc Olzheim To: freebsd-hackers@freebsd.org Message-ID: <20050330181208.GA64275@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline X-Operating-System: FreeBSD hammer.stack.nl 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Subject: Making gcc "-Wformat" more verbose 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, 30 Mar 2005 18:12:11 -0000 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi. When programming, I'd like to be able to make sure that what I think what the code that I type does, is what I want it to do. Who doesn't? Anyway, since I'm already compiling with most warnings on and I'm linting my code, I'm trying my best to be more sure of it. There where I find problems that could have been detected by my tools, but weren't, I'd like to make sure that the tools get updated. This prompted me to produce a patch for FreeBSD 5-STABLE's GCC (3.4.2). GCC 3.4.2 takes a shortcut in checking the argument to printf()-like functions with -Wformat. Since arguments to a varargs function smaller than an int are promoted to an int (and floats to double), the check doesn't care what the types originally passed to the function were exactly, as long as after promotion it is good enough. To make things worse, "good enough" here doesn't include checking the signdness. I've made a simple copy-paste patch that makes sure that arguments to those functions are checked _before_ _and_ _after_ the varargs-promotion and that their sign meets the formatstring. Please have a look at it and tell me whether this could be useful for FreeBSD or whether that's a bridge too far... The patch is at http://www.stack.nl/~marcolz/FreeBSD/gcc-printf.patch.txt Besides that, you'll need to include the inttypes.h at http://www.stack.nl/~marcolz/FreeBSD/inttypes.h instead of /usr/include/inttypes.h If you want to compile the kernel with it, make sure to turn of -Werror... (Or install into somewhere else then /usr/libexec and use CFLAGS=-B to gcc to try it out. I know, that other varargs functions' handling isn't modified yet; I just thought I'd start with printf() and see whether it was useful. Please let me know what you think. Marc --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCSuv4ezjnobFOgrERAi2ZAJ9/KSpapa8iSLWnVVmsLnZZ8qPrWgCgs04s vUgWXAGbikDQ7YRH2MFyJg0= =42HX -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 18:15:31 2005 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 C210A16A4CE for ; Wed, 30 Mar 2005 18:15:31 +0000 (GMT) Received: from smtp.xbsd.org (xbsd.org [82.233.2.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3464443D1D for ; Wed, 30 Mar 2005 18:15:31 +0000 (GMT) (envelope-from flz@xbsd.org) Received: from localhost (localhost.xbsd.org [127.0.0.1]) by smtp.xbsd.org (Postfix) with ESMTP id 0BB64114A2; Wed, 30 Mar 2005 20:17:54 +0200 (CEST) Received: from smtp.xbsd.org ([127.0.0.1]) by localhost (srv1.xbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57505-06; Wed, 30 Mar 2005 20:17:48 +0200 (CEST) Received: from cream.xbsd.org (cream.xbsd.org [192.168.42.6]) by smtp.xbsd.org (Postfix) with ESMTP id 4507B11441; Wed, 30 Mar 2005 20:17:48 +0200 (CEST) From: Florent Thoumie To: mohamed aslan In-Reply-To: <319cceca05033009305c410e85@mail.gmail.com> References: <319cceca0503281001792baf39@mail.gmail.com> <1112135353.749.84.camel@localhost> <20050329224603.GD86797@nowhere> <319cceca05033009305c410e85@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hDtAQYnBYULTJShWEqls" Date: Wed, 30 Mar 2005 20:15:27 +0200 Message-Id: <1112206527.761.5.camel@cream.xbsd.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port X-Virus-Scanned: amavisd-new at xbsd.org cc: freebsd-hackers@freebsd.org Subject: Re: organization 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, 30 Mar 2005 18:15:31 -0000 --=-hDtAQYnBYULTJShWEqls Content-Type: text/plain; charset=iso8859-15 Content-Transfer-Encoding: quoted-printable Le Mercredi 30 mars 2005 =E0 09:30 -0800, mohamed aslan a =E9crit : > i cann't reply to all of ur comments=20 > but , that is what makes u break off , as DragonFly split of u >=20 > u took my opinion as an attack, > u just wanna flaming, *shrug* > u also got off topic "CVS and SVN",=20 That's a long time topic. > my words were really facts Mr Scott , Linux layout is better than > FreeBSD layout , FreeBSD performance it better than Linux one , and > thnx for silly reply. You {c,sh}ould have been flamed a lot for such a message. After=20 reading your three messages, I'm not sure that's not what you=20 were looking for. If you want to talk about facts, don't say "I think that ...". > that's why i hate forums and maillists and i should mail this directly > to the core members. I'm quite sure you'll get the same answer. --=20 Florent Thoumie flz@xbsd.org --=-hDtAQYnBYULTJShWEqls Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCSuy/MxEkbVFH3PQRApwXAKCIJyfc0a6r80tzjye/Ed70tXz0HwCcCeRd IfEdyoHFigD5+qJXD/uxF18= =4Jc9 -----END PGP SIGNATURE----- --=-hDtAQYnBYULTJShWEqls-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 18:17:47 2005 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 C3A3B16A4CE for ; Wed, 30 Mar 2005 18:17:47 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 604BE43D2D for ; Wed, 30 Mar 2005 18:17:45 +0000 (GMT) (envelope-from fbsd.hackers@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so167289rnf for ; Wed, 30 Mar 2005 10:17:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=hoTRaVp0tqmmGwpO5kRecn1FnaeySfpM/ANlqORmot+ENbCtet6v9piRp9WepBsja1Hbd0/V+TX4o4pdbmuoi2GUbzIgTPCSpfau9azRG5PMXxx2aFEkBqPq2toRmBKPhgzSN7N1Ch84PId9SDE+nSFmIxzH6WuCeKX76IG5lgk= Received: by 10.38.1.73 with SMTP id 73mr500979rna; Wed, 30 Mar 2005 10:17:43 -0800 (PST) Received: by 10.38.11.43 with HTTP; Wed, 30 Mar 2005 10:17:43 -0800 (PST) Message-ID: Date: Wed, 30 Mar 2005 14:17:43 -0400 From: zean zean To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: the best form to wait the finish of execution of a child... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: zean zean List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2005 18:17:47 -0000 Hi Hackers: Excuse for my badly English. which is the best form to wait the finish of execution of a child. My idea is: pid_t chilpid; while(childpid != wait(&status)) ; Any aid to obtain the best way is very welcome. PD. Excuse my ignorance and I hope they can guide me. Bye and thanxs ;) From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 18:25:59 2005 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 513FC16A4CE for ; Wed, 30 Mar 2005 18:25:59 +0000 (GMT) Received: from vms048pub.verizon.net (vms048pub.verizon.net [206.46.252.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CCD543D45 for ; Wed, 30 Mar 2005 18:25:59 +0000 (GMT) (envelope-from ringworm01@gmail.com) Received: from ringworm.mechee.com ([4.27.46.32])0.04 <0IE6007Q7GJANQY0@vms048.mailsrvcs.net> for freebsd-hackers@freebsd.org; Wed, 30 Mar 2005 12:25:58 -0600 (CST) Received: by ringworm.mechee.com (Postfix, from userid 1001) id F09132CE76A; Wed, 30 Mar 2005 10:25:57 -0800 (PST) Date: Wed, 30 Mar 2005 10:25:57 -0800 From: "Michael C. Shultz" In-reply-to: To: freebsd-hackers@freebsd.org Message-id: <200503301025.57363.ringworm01@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Content-disposition: inline References: User-Agent: KMail/1.8 Subject: Re: the best form to wait the finish of execution of a child... 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, 30 Mar 2005 18:25:59 -0000 On Wednesday 30 March 2005 10:17 am, zean zean wrote: > Hi Hackers: > > Excuse for my badly English. which is the best form to wait the > finish of execution of a child. > > My idea is: > > pid_t chilpid; > > while(childpid != wait(&status)) > ; > > Any aid to obtain the best way is very welcome. > > PD. Excuse my ignorance and I hope they can guide me. > > Bye and thanxs ;) > _______________________________________________ > 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" Here is how I do it, likely someone will have a better way: pid_t pid; pid = fork(); if( !pid ) { execl( "/bin/mkdir", "mkdir", "directory_name", 0 ); } wait( (int*)pid ); -Mike From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 18:28:35 2005 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 E2EAF16A4CE for ; Wed, 30 Mar 2005 18:28:35 +0000 (GMT) Received: from smtp.xbsd.org (xbsd.org [82.233.2.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E51243D5A for ; Wed, 30 Mar 2005 18:28:35 +0000 (GMT) (envelope-from flz@xbsd.org) Received: from localhost (localhost.xbsd.org [127.0.0.1]) by smtp.xbsd.org (Postfix) with ESMTP id 4E1F9114BE; Wed, 30 Mar 2005 20:31:00 +0200 (CEST) Received: from smtp.xbsd.org ([127.0.0.1]) by localhost (srv1.xbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77706-02; Wed, 30 Mar 2005 20:30:51 +0200 (CEST) Received: from cream.xbsd.org (cream.xbsd.org [192.168.42.6]) by smtp.xbsd.org (Postfix) with ESMTP id B3757114A2; Wed, 30 Mar 2005 20:30:50 +0200 (CEST) From: Florent Thoumie To: zean zean In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-MWIT1vZ14wuqb69n378u" Date: Wed, 30 Mar 2005 20:28:29 +0200 Message-Id: <1112207309.761.15.camel@cream.xbsd.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port X-Virus-Scanned: amavisd-new at xbsd.org cc: freebsd-hackers@freebsd.org Subject: Re: the best form to wait the finish of execution of a child... 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, 30 Mar 2005 18:28:36 -0000 --=-MWIT1vZ14wuqb69n378u Content-Type: text/plain; charset=iso8859-15 Content-Transfer-Encoding: quoted-printable Le Mercredi 30 mars 2005 =E0 14:17 -0400, zean zean a =E9crit : > Hi Hackers: >=20 > Excuse for my badly English. which is the best form to wait the > finish of execution of a child. It depends on the context of your program=20 (synchronous/asynchronous). > My idea is: >=20 > pid_t chilpid; >=20 > while(childpid !=3D wait(&status)) > ; That's a possibility, you can catch SIGCHLD with a signal=20 handler (see signal(3), sigprocmask(2), sigaction(2)) which=20 would set a global flag, and then use a non-blocking waitpid(2)=20 or wait4(2) instead. Note: What you suggested isn't really safe. You shouldn't=20 ignore wait(2) return status (could be -1 because something unexpected happened, see ERRORS section from the manpage). --=20 Florent Thoumie flz@xbsd.org --=-MWIT1vZ14wuqb69n378u Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCSu/NMxEkbVFH3PQRAucgAJwM2h60Y7KbZdCgcBi01W1C+ulhigCfbsDE 9zmy7UyCzLSmX2Aetf2wu2A= =uMXj -----END PGP SIGNATURE----- --=-MWIT1vZ14wuqb69n378u-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 18:29:52 2005 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 7C9DB16A4CE for ; Wed, 30 Mar 2005 18:29:52 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id D683543D55 for ; Wed, 30 Mar 2005 18:29:51 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j2UIU0h3010222; Wed, 30 Mar 2005 10:30:01 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j2UITrlt010221; Wed, 30 Mar 2005 10:29:53 -0800 (PST) (envelope-from www) Date: Wed, 30 Mar 2005 10:29:53 -0800 (PST) Message-Id: <200503301829.j2UITrlt010221@marlena.vvi.at> To: elric@imrryr.org From: "ALeine" cc: freebsd-hackers@freebsd.org cc: phk@phk.freebsd.dk cc: tech-security@netbsd.org Subject: Re: A bunch of memory allocation bugs in CGD 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, 30 Mar 2005 18:29:52 -0000 elric@imrryr.org wrote: > Thanks for having a look at that. I have checked in a fix. Thanks for responding so quickly. > I presume that you have addressed the cases in GBDE where > malloc's return code has not been checked? If so, perhaps > cvsweb is a little behind. It looks to me like 2 or 4 mallocs > can use a buffer without checking the return code. There are two malloc bugs in GBDE, but both are minor and have no security implications. Both bugs are in src/sbin/gbde/gbde.c: - the first bug is in cmd_nuke() and could not be seen as much of a bug because cmd_nuke() is used to destroy lock sectors. If this fails due to memory starvation no sensitive information is leaked, only a write(2) call fails and gbde terminates correctly upon catching and reporting the write error. - the second bug is in cmd_write(), where a buffer is allocated and checked, but not immediately, so there is a case where it can be used before it gets checked. However, even if this happens, only a read(2) call fails and gbde terminates correctly upon catching and reporting the read error. In src/sys/geom/bde/g_bde.c there is also a g_malloc() allocated buffer which is unchecked, but since the allocation is done with the M_WAITOK flag it's safe. This means there are no malloc bugs in GBDE which could cause a segmentation violation. I have sent the patch for the minor malloc bugs I described above to Poul-Henning, so I expect him to review it and commit the appropriate fix in the near future. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 18:42:29 2005 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 B6A8016A4CE for ; Wed, 30 Mar 2005 18:42:29 +0000 (GMT) Received: from smtp.xbsd.org (xbsd.org [82.233.2.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30FED43D45 for ; Wed, 30 Mar 2005 18:42:29 +0000 (GMT) (envelope-from flz@xbsd.org) Received: from localhost (localhost.xbsd.org [127.0.0.1]) by smtp.xbsd.org (Postfix) with ESMTP id E7EEB115F2; Wed, 30 Mar 2005 20:44:53 +0200 (CEST) Received: from smtp.xbsd.org ([127.0.0.1]) by localhost (srv1.xbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77706-05; Wed, 30 Mar 2005 20:44:44 +0200 (CEST) Received: from cream.xbsd.org (cream.xbsd.org [192.168.42.6]) by smtp.xbsd.org (Postfix) with ESMTP id 45C2C114BE; Wed, 30 Mar 2005 20:44:44 +0200 (CEST) From: Florent Thoumie To: "Michael C. Shultz" In-Reply-To: <200503301025.57363.ringworm01@gmail.com> References: <200503301025.57363.ringworm01@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-av4fWDHRsPTLN1s8eXuc" Date: Wed, 30 Mar 2005 20:42:23 +0200 Message-Id: <1112208143.33469.7.camel@cream.xbsd.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port X-Virus-Scanned: amavisd-new at xbsd.org cc: freebsd-hackers@freebsd.org Subject: Re: the best form to wait the finish of execution of a child... 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, 30 Mar 2005 18:42:29 -0000 --=-av4fWDHRsPTLN1s8eXuc Content-Type: text/plain; charset=iso8859-15 Content-Transfer-Encoding: quoted-printable Le Mercredi 30 mars 2005 =E0 10:25 -0800, Michael C. Shultz a =E9crit : > On Wednesday 30 March 2005 10:17 am, zean zean wrote: > > Hi Hackers: > > > > Excuse for my badly English. which is the best form to wait the > > finish of execution of a child. > > > > My idea is: > > > > pid_t chilpid; > > > > while(childpid !=3D wait(&status)) > > ; > > > > Any aid to obtain the best way is very welcome. > > > > PD. Excuse my ignorance and I hope they can guide me. > > > > Bye and thanxs ;) > > _______________________________________________ > > 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" >=20 > Here is how I do it, likely someone will have a better way: >=20 > pid_t pid; >=20 > pid =3D fork(); > if( !pid ) > { > execl( "/bin/mkdir", "mkdir", "directory_name", 0 ); > } > wait( (int*)pid ); Something like this would be better I think : pid_t pid; int ret;=09 pid =3D fork(); if (pid < 0) { perror("fork"); /* exit(1); if you want */ } else if (pid =3D=3D 0) { if (execl("/bin/mkdir", "mkdir", "directory_name", 0 )) perror("execl"); } else { wait(&ret); /* plus return code handling, YMMV */ } =09 You need to check fork(2) return code or your wait(2) is useless. Don't mix pid_t with int just for the gain of one variable. I haven't played with this for some time, I guess it's correct. --=20 Florent Thoumie flz@xbsd.org --=-av4fWDHRsPTLN1s8eXuc Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCSvMPMxEkbVFH3PQRAhn7AJ0WL8NEUY0s5Ruo+0MK2Yp/9btNQgCdHC5P RcNj+lwgZsiiUn8j3j6255U= =uSjs -----END PGP SIGNATURE----- --=-av4fWDHRsPTLN1s8eXuc-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 18:42:30 2005 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 05EC516A4CE for ; Wed, 30 Mar 2005 18:42:30 +0000 (GMT) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28FAD43D41 for ; Wed, 30 Mar 2005 18:42:29 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j2UIgPwT018482 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 31 Mar 2005 04:42:27 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j2UIgP7l075029; Thu, 31 Mar 2005 04:42:25 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j2UIgP5f075028; Thu, 31 Mar 2005 04:42:25 +1000 (EST) (envelope-from pjeremy) Date: Thu, 31 Mar 2005 04:42:25 +1000 From: Peter Jeremy To: "H. S." Message-ID: <20050330184224.GC71384@cirb503493.alcatel.com.au> References: <61910.81.84.174.37.1112123946.squirrel@mail.revolutionsp.com> <20050329213528.59dab2e2.flynn@energyhq.es.eu.org> <62208.81.84.174.37.1112130745.squirrel@mail.revolutionsp.com> <20050329193558.L33759@eleanor.us1.wmi.uvac.net> <63511.81.84.174.37.1112202327.squirrel@mail.revolutionsp.com> <63519.81.84.174.37.1112202413.squirrel@mail.revolutionsp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63519.81.84.174.37.1112202413.squirrel@mail.revolutionsp.com> User-Agent: Mutt/1.4.2i cc: freebsd-hackers@freebsd.org Subject: Re: A few thoughts.. 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, 30 Mar 2005 18:42:30 -0000 On Wed, 2005-Mar-30 11:06:53 -0600, H. S. wrote: >As I stated previously, I'm not much of a C programmer, but I can do some >coding. I've been thinking into changing the core of the system a bit to >return errors if some information is accessed by a normal user. Wouldn't making /sbin and /usr/sbin mode 750 be enough? > I'd like >to know if getuid() would work that deep in the system? In general, system calls can't be used within the kernel. The uid and gid could be determined by directly dereferencing curproc or the thread pointer passed around in most kernel internal calls. Note that the only checks the (non-MAC) kernel currently does is "root" or "not-root" using suser(9) (apart from the checks in kill(2)). Restrictions for non-root users are implemented using file permissions. > And how can I register sysctl mibs in the kernel ? Look at sysctl(3), /sys/sys/sysctl.h and (eg) /sys/kern/subr_msgbuf.c -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 19:05:29 2005 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 A5AC416A4CE for ; Wed, 30 Mar 2005 19:05:29 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id B309143D2D for ; Wed, 30 Mar 2005 19:05:28 +0000 (GMT) (envelope-from dleimbac@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so178617rnf for ; Wed, 30 Mar 2005 11:05:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=QTucWZISpBTkBbC35dSbaQLQPKq6X1eWVfgVT9FSF3yehRjTE40I9wdQ0SSg1dgs+/YiX7g276ncMd/tvCxbrhGtRla4ICkpQ2mD322lDc96USqfQU3NYzW9JN5UewOGoweb+e/b+nKQuN/KRBXtc/5SlMQMB5lUYdKKLelGo3E= Received: by 10.39.2.79 with SMTP id e79mr722599rni; Wed, 30 Mar 2005 11:05:28 -0800 (PST) Received: by 10.38.82.48 with HTTP; Wed, 30 Mar 2005 11:05:27 -0800 (PST) Message-ID: <5bbfe7d405033011053b12b2c6@mail.gmail.com> Date: Wed, 30 Mar 2005 11:05:28 -0800 From: David Leimbach To: mohamed aslan In-Reply-To: <319cceca05033009305c410e85@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <319cceca0503281001792baf39@mail.gmail.com> <1112135353.749.84.camel@localhost> <20050329224603.GD86797@nowhere> <319cceca05033009305c410e85@mail.gmail.com> cc: freebsd-hackers@freebsd.org Subject: Re: organization X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Leimbach List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2005 19:05:29 -0000 On Wed, 30 Mar 2005 09:30:47 -0800, mohamed aslan wrote: > i cann't reply to all of ur comments > but , that is what makes u break off , as DragonFly split of u So you're going to fork FreeBSD because we didn't think your comments were constructive and that you don't like the organization of FreeBSD's sources? Ok, have fun :). > > u took my opinion as an attack, > u just wanna flaming, > u also got off topic "CVS and SVN", > You have to keep in mind that what you intended may not come through with the way your email reads. Popping into a forum and saying "this sucks" is a sure fire way to get flamed ANYWHERE. You should have provided some reasoning why you believed FreeBSD's source layout was not as good as Linux's from whatever perspective you were looking at it. > my words were really facts Mr Scott , Linux layout is better than > FreeBSD layout , FreeBSD performance it better than Linux one , and > thnx for silly reply. "FreeBSD performance is better than Linux." That's yet another interesting claim. For the applications I run no one would touch FreeBSD as it doesn't do as well as Linux so that's a very general and very vague claim. > > that's why i hate forums and maillists and i should mail this directly > to the core members. So stop posting to them. > > On Tue, 29 Mar 2005 16:46:04 -0600, Craig Boston wrote: > > At the risk of going further and further off-topic from > > freebsd-hackers... > > > > On Tue, Mar 29, 2005 at 02:29:13PM -0800, Bruce A. Mah wrote: > > > Sounds like a bad situation there. On our server we use svn+ssh, except > > > for a few Windows clients that use https. (BTW our server is running > > > 4-STABLE and it's wonderful.) > > > > Hmmm, I initially didn't want to use that because I read that it suffers > > from the same security issues as CVS. The appeal of being able to > > fine-tune permissions and grant subversion access without shell access > > is quite luring. > > > > HTTP timeouts during long operations, on the other hand, suck. ( my > > server is woefully underpowered :-D ). > > > > Note to davsvn users with slow servers: http-timeout = 3600 is your > > friend. > > > > > Heh. :-) 1.1.3 is current now, but one can find mentions of a 1.1.4 > > > bugfix release being planned, as well as the (farther out) 1.2 release > > > with locking. > > > > Oh, I've been running 1.1.3 on both client and server since it went into > > ports (many dump/loads later). Just haven't taken the time to see > > what's new and compare to older versions. :) > > > > Craig > > _______________________________________________ > > 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" > > > > -- > I'm Searching For Perfection, > So Even If U Need Portability U've To Use Assembly ;-) > http://www.maslanlab.org > _______________________________________________ > 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 Wed Mar 30 19:10:16 2005 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 9782916A4CE for ; Wed, 30 Mar 2005 19:10:16 +0000 (GMT) Received: from hotmail.com (bay10-f41.bay10.hotmail.com [64.4.37.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F74843D2F for ; Wed, 30 Mar 2005 19:10:16 +0000 (GMT) (envelope-from ghanekar_rajesh@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 30 Mar 2005 11:10:16 -0800 Message-ID: Received: from 210.210.81.200 by by10fd.bay10.hotmail.msn.com with HTTP; Wed, 30 Mar 2005 19:10:15 GMT X-Originating-IP: [210.210.81.200] X-Originating-Email: [ghanekar_rajesh@hotmail.com] X-Sender: ghanekar_rajesh@hotmail.com From: "Rajesh Ghanekar" To: freebsd-hackers@freebsd.org Date: Thu, 31 Mar 2005 00:40:15 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 30 Mar 2005 19:10:16.0133 (UTC) FILETIME=[1B4EA750:01C5355C] Subject: physical address to virtual address conversion 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, 30 Mar 2005 19:10:16 -0000 Hi, I am trying to convert a physical memory location (address 0x000F0000) to virtual memory address in kernel module with pmap_map() / pmap_enter(). Whenever i call these two functions, system hangs. Is this a proper way for conversion? The same physical address can be accessed from the userspace by opening /dev/mem. The code which does the memory mapping to /dev/mem at kernel level is in ./sys/i386/i386/mem.c as mmrw() which also uses pmap_enter(). kernel = FreeBSD 4.10 - Rajesh _________________________________________________________________ NRIs, operate Rupee Checking Account. http://creative.mediaturf.net/creatives/citibankrca/rca_msntagofline.htm Without minimum balance for 20 yrs! From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 19:11:59 2005 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 7325416A4CE for ; Wed, 30 Mar 2005 19:11:59 +0000 (GMT) Received: from mail23.syd.optusnet.com.au (mail23.syd.optusnet.com.au [211.29.133.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2C5F43D5A for ; Wed, 30 Mar 2005 19:11:58 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j2UJBu9c029239 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 31 Mar 2005 05:11:57 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j2UJBu7l075077; Thu, 31 Mar 2005 05:11:56 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j2UJBuAP075076; Thu, 31 Mar 2005 05:11:56 +1000 (EST) (envelope-from pjeremy) Date: Thu, 31 Mar 2005 05:11:56 +1000 From: Peter Jeremy To: mohamed aslan Message-ID: <20050330191156.GD71384@cirb503493.alcatel.com.au> References: <319cceca0503281001792baf39@mail.gmail.com> <1112135353.749.84.camel@localhost> <20050329224603.GD86797@nowhere> <319cceca05033009305c410e85@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <319cceca05033009305c410e85@mail.gmail.com> User-Agent: Mutt/1.4.2i cc: freebsd-hackers@freebsd.org Subject: Re: organization 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, 30 Mar 2005 19:11:59 -0000 On Wed, 2005-Mar-30 09:30:47 -0800, mohamed aslan wrote: >u took my opinion as an attack, Your phrasing was provocative (though at least you agree that it's just your opinion - elsewhere, you continue to claim that your opinions are facts). >u just wanna flaming, Given your statements, I was surprised at how restrained people were. >u also got off topic "CVS and SVN", Many people can see areas where the FreeBSD layout is less than ideal. One major stumbling block to global change is CVS - which can't really handle renaming files. CVS's shortcomings are widely known and there are regular side-discussions on what (if anything) to do about changing. Since you proposed a major rename, it was reasonable to discuss how this could be achieved. >my words were really facts Mr Scott , Linux layout is better than >FreeBSD layout , This is a very subjective statement. The only "evidence" you've provided to justify it is that an "ls" on the top level kernel source directory is shorter on Linux than FreeBSD - without explaining why the short list is better. If you are serious about the Linux layout being better, how about proposing a new layout, providing a list of rules that define what files go where (so that someone with a new kernel file to add can identify where it goes), explaining how your new layout is better than the current layout and providing a mapping for all current file locations to new file locations. > FreeBSD performance it better than Linux one , Whilst "performance" can be measured, it's impossible to define overall system performance, irrespective of the hardware or task, as a single number that can be compared between two systems. >thnx for silly reply. I saw very few of those. >that's why i hate forums and maillists and i should mail this directly >to the core members. I'm not sure this is the best way to endear yourself to the FreeBSD community. This strikes me as a good way to get yourself added to personal killfiles. -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 19:27:13 2005 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 5D61F16A4CE for ; Wed, 30 Mar 2005 19:27:13 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A815343D53 for ; Wed, 30 Mar 2005 19:27:10 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.21] (rat.samsco.home [192.168.254.21]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j2UJV0Nk011877; Wed, 30 Mar 2005 12:31:00 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <424AFD12.7070505@samsco.org> Date: Wed, 30 Mar 2005 12:25:06 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.5) Gecko/20050321 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rajesh Ghanekar References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: freebsd-hackers@freebsd.org Subject: Re: physical address to virtual address conversion 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, 30 Mar 2005 19:27:13 -0000 Rajesh Ghanekar wrote: > Hi, > > I am trying to convert a physical memory location (address 0x000F0000) > to virtual memory address in kernel module with pmap_map() / pmap_enter(). > Whenever i call these two functions, system hangs. Is this a proper > way for conversion? > > The same physical address can be accessed from the userspace by opening > /dev/mem. The code which does the memory mapping to /dev/mem at kernel > level is in ./sys/i386/i386/mem.c as mmrw() which also uses pmap_enter(). > > kernel = FreeBSD 4.10 > > - Rajesh > pmap_mapdev() is probably what you want. However, what exactly are you trying to do? Why do you need access to a specific physical location? Scott From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 19:27:42 2005 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 3058416A4CE for ; Wed, 30 Mar 2005 19:27:42 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 747C943D2F for ; Wed, 30 Mar 2005 19:27:41 +0000 (GMT) (envelope-from aaron.glenn@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so190830rng for ; Wed, 30 Mar 2005 11:27:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=TiKElLHnknZFvNJ05sLCZcz6PccoKthV/w8Ispzo9CQta68UK+3ZqT1+ek1pg/67Y1TDDkoZlB/QcaPppcDgFVM1l0FbchYW9XT2Y2EPgewqkXSezYk4OBaJnGAK0Gb4J9RC03cZARhRuSRRQpOdBpdF41WTVGXiW+745/7Bshk= Received: by 10.38.87.21 with SMTP id k21mr720029rnb; Wed, 30 Mar 2005 11:27:39 -0800 (PST) Received: by 10.38.151.34 with HTTP; Wed, 30 Mar 2005 11:27:36 -0800 (PST) Message-ID: <18f6019405033011277d9443a7@mail.gmail.com> Date: Wed, 30 Mar 2005 11:27:36 -0800 From: Aaron Glenn To: freebsd-hackers@freebsd.org In-Reply-To: <63519.81.84.174.37.1112202413.squirrel@mail.revolutionsp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <61910.81.84.174.37.1112123946.squirrel@mail.revolutionsp.com> <20050329213528.59dab2e2.flynn@energyhq.es.eu.org> <62208.81.84.174.37.1112130745.squirrel@mail.revolutionsp.com> <20050329193558.L33759@eleanor.us1.wmi.uvac.net> <63511.81.84.174.37.1112202327.squirrel@mail.revolutionsp.com> <63519.81.84.174.37.1112202413.squirrel@mail.revolutionsp.com> Subject: Re: A few thoughts.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Aaron Glenn List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2005 19:27:42 -0000 On Wed, 30 Mar 2005 11:06:53 -0600 (CST), H. S. wrote: > As I stated previously, I'm not much of a C programmer, but I can do some > coding. I've been thinking into changing the core of the system a bit to > return errors if some information is accessed by a normal user. I'd like > to know if getuid() would work that deep in the system? And how can I > register sysctl mibs in the kernel ? Let me chime in with A single thought of my own: isn't this scenario a textbook use-case for the hard work Robert Watson did with MAC? I haven't kept up with 5.x's latest features in a while... aaron.glenn From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 20:06:58 2005 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 2017616A4CE for ; Wed, 30 Mar 2005 20:06:58 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88B0A43D2F for ; Wed, 30 Mar 2005 20:06:57 +0000 (GMT) (envelope-from fbsd.hackers@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so193511rnf for ; Wed, 30 Mar 2005 12:06:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Kf0kzDqNVFI6kGvsLbTfhdIxUk0Ep4AFt5ZR7qHgE1sUjOGnlSe9QfTRisbuyFEdo55BtFozgsDkvzj9lH6mD3vEnshvykndsy1u9hyZoDWHiZQE5Ageyi5tIgUI6Zh87W2WFMw+hCxMV6GoHr4yiyHbgAk05L0f0QgMmTEqWYI= Received: by 10.38.75.70 with SMTP id x70mr781418rna; Wed, 30 Mar 2005 12:06:55 -0800 (PST) Received: by 10.38.11.43 with HTTP; Wed, 30 Mar 2005 12:06:55 -0800 (PST) Message-ID: Date: Wed, 30 Mar 2005 16:06:55 -0400 From: zean zean To: freebsd-hackers@freebsd.org In-Reply-To: <20050330115132.N76928@skutsje.san.webweaving.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <20050330115132.N76928@skutsje.san.webweaving.org> Subject: Re: the best form to wait the finish of execution of a child... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: zean zean List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2005 20:06:58 -0000 thanks to all by responding me so fast. Florent I will continue your counsels. Dirk-Willem My idea is to avoid all the processes zombies. thanks by the recommendation. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 20:16:03 2005 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 08AE316A4CE for ; Wed, 30 Mar 2005 20:16:03 +0000 (GMT) Received: from mail.revolutionsp.com (ganymede.revolutionsp.com [64.246.0.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF52243D1D for ; Wed, 30 Mar 2005 20:16:02 +0000 (GMT) (envelope-from security@revolutionsp.com) Received: from mail.revolutionsp.com (localhost [127.0.0.1]) by mail.revolutionsp.com (Postfix) with ESMTP id A2FC615CB4 for ; Wed, 30 Mar 2005 14:15:05 -0600 (CST) Received: from 81.84.174.37 (SquirrelMail authenticated user security@revolutionsp.com) by mail.revolutionsp.com with HTTP; Wed, 30 Mar 2005 14:15:05 -0600 (CST) Message-ID: <63776.81.84.174.37.1112213705.squirrel@mail.revolutionsp.com> In-Reply-To: <20050330184224.GC71384@cirb503493.alcatel.com.au> References: <61910.81.84.174.37.1112123946.squirrel@mail.revolutionsp.com> <20050329213528.59dab2e2.flynn@energyhq.es.eu.org> <62208.81.84.174.37.1112130745.squirrel@mail.revolutionsp.com> <20050329193558.L33759@eleanor.us1.wmi.uvac.net> <63511.81.84.174.37.1112202327.squirrel@mail.revolutionsp.com> <63519.81.84.174.37.1112202413.squirrel@mail.revolutionsp.com> <20050330184224.GC71384@cirb503493.alcatel.com.au> Date: Wed, 30 Mar 2005 14:15:05 -0600 (CST) From: "H. S." To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: A few thoughts.. 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, 30 Mar 2005 20:16:03 -0000 > On Wed, 2005-Mar-30 11:06:53 -0600, H. S. wrote: >>As I stated previously, I'm not much of a C programmer, but I can do some >>coding. I've been thinking into changing the core of the system a bit to >>return errors if some information is accessed by a normal user. > > Wouldn't making /sbin and /usr/sbin mode 750 be enough? That's the "heart" of my question. A user uploading a dmesg binary to his homedir and then ./dmesg will overcome these permissions. People suggested making /home noexec, I'm still considering the implications of that in my scenario. > >> I'd like >>to know if getuid() would work that deep in the system? > > In general, system calls can't be used within the kernel. The uid and > gid could be determined by directly dereferencing curproc or the > thread pointer passed around in most kernel internal calls. Note that > the only checks the (non-MAC) kernel currently does is "root" or > "not-root" using suser(9) (apart from the checks in kill(2)). > Restrictions for non-root users are implemented using file > permissions. > >> And how can I register sysctl mibs in the kernel ? > > Look at sysctl(3), /sys/sys/sysctl.h and (eg) /sys/kern/subr_msgbuf.c > Thanks, I'll have a look, also will have a look at MAC. I think I have a completely wrong idea of what MAC does. > -- > Peter Jeremy > From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 20:53:56 2005 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 26C8B16A4CE for ; Wed, 30 Mar 2005 20:53:56 +0000 (GMT) Received: from arioch.imrryr.org (arioch.imrryr.org [216.254.67.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id C892A43D39 for ; Wed, 30 Mar 2005 20:53:55 +0000 (GMT) (envelope-from elric@imrryr.org) Received: from imrryr.org (localhost [127.0.0.1]) by arioch.imrryr.org (Postfix) with ESMTP id 2C0BD3700F; Wed, 30 Mar 2005 15:53:19 -0500 (EST) To: "ALeine" In-reply-to: Your message of "Wed, 30 Mar 2005 10:29:53 PST." <200503301829.j2UITrlt010221@marlena.vvi.at> Organization: The Fall of Imrryr User-Agent: nmh-1.0.4 (NetBSD/alpha) X-Copyright: Copyright 2004, R. C. Dowdeswell. All Rights Reserved. X-Window-System: Release 6.3 Date: Wed, 30 Mar 2005 15:53:19 -0500 From: Roland Dowdeswell Message-Id: <20050330205319.2C0BD3700F@arioch.imrryr.org> cc: freebsd-hackers@freebsd.org cc: phk@phk.freebsd.dk cc: tech-security@netbsd.org Subject: Re: A bunch of memory allocation bugs in CGD 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, 30 Mar 2005 20:53:56 -0000 On 1112207393 seconds since the Beginning of the UNIX epoch "ALeine" wrote: > >Thanks for responding so quickly. No problem. >- the first bug is in cmd_nuke() and could not be seen as much > of a bug because cmd_nuke() is used to destroy lock sectors. > If this fails due to memory starvation no sensitive information > is leaked, only a write(2) call fails and gbde terminates > correctly upon catching and reporting the write error. Having a quick read it looks like the call to cmd_nuke() is preceded by a cmd_open(). cmd_open() loads the decrypted decoded contents of the lock sector into memory which contain all of the information needed to decrypt the disk. In cmd_nuke(), the malloc is followed immediately by a memset(3) which could core dump. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 21:37:55 2005 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 73AA516A4CE for ; Wed, 30 Mar 2005 21:37:55 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09FD143D41 for ; Wed, 30 Mar 2005 21:37:55 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j2ULbxh3012729; Wed, 30 Mar 2005 13:38:01 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j2ULbrNd012728; Wed, 30 Mar 2005 13:37:53 -0800 (PST) (envelope-from www) Date: Wed, 30 Mar 2005 13:37:53 -0800 (PST) Message-Id: <200503302137.j2ULbrNd012728@marlena.vvi.at> To: elric@imrryr.org From: "ALeine" cc: freebsd-hackers@freebsd.org cc: phk@phk.freebsd.dk cc: tech-security@netbsd.org Subject: Re: A bunch of memory allocation bugs in CGD 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, 30 Mar 2005 21:37:55 -0000 elric@imrryr.org wrote: > Having a quick read it looks like the call to cmd_nuke() is > preceded by a cmd_open(). cmd_open() loads the decrypted decoded > contents of the lock sector into memory which contain all of the > information needed to decrypt the disk. In cmd_nuke(), the malloc is > followed immediately by a memset(3) which could core dump. You're right on both counts, I apologize for the confusion, I have several versions of GBDE files around and just before I made that comment about segmentation violation not being possible I took a look at the malloc(3) line in my patched version by mistake. In that version I replaced the malloc(3) and memset(3) calls in cmd_nuke() with a single malloc(3) call with the M_ZERO flag set. Using mlockall(2) to prevent paging and setrlimit(2) to prevent core from being dumped would also be an improvement for both CGD and GBDE. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 21:44:49 2005 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 0B8F616A4CE for ; Wed, 30 Mar 2005 21:44:49 +0000 (GMT) Received: from arioch.imrryr.org (arioch.imrryr.org [216.254.67.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5ED143D46 for ; Wed, 30 Mar 2005 21:44:48 +0000 (GMT) (envelope-from elric@imrryr.org) Received: from imrryr.org (localhost [127.0.0.1]) by arioch.imrryr.org (Postfix) with ESMTP id 383933700F; Wed, 30 Mar 2005 16:44:13 -0500 (EST) To: "ALeine" In-reply-to: Your message of "Wed, 30 Mar 2005 13:37:53 PST." <200503302137.j2ULbrNd012728@marlena.vvi.at> Organization: The Fall of Imrryr User-Agent: nmh-1.0.4 (NetBSD/alpha) X-Copyright: Copyright 2004, R. C. Dowdeswell. All Rights Reserved. X-Window-System: Release 6.3 Date: Wed, 30 Mar 2005 16:44:13 -0500 From: Roland Dowdeswell Message-Id: <20050330214413.383933700F@arioch.imrryr.org> cc: freebsd-hackers@freebsd.org cc: phk@phk.freebsd.dk cc: tech-security@netbsd.org Subject: Re: A bunch of memory allocation bugs in CGD 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, 30 Mar 2005 21:44:49 -0000 On 1112218673 seconds since the Beginning of the UNIX epoch "ALeine" wrote: > >Using mlockall(2) to prevent paging and setrlimit(2) to prevent core >from being dumped would also be an improvement for both CGD and GBDE. That's what I just did. :-) -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 00:21:51 2005 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 A35FB16A4CE for ; Thu, 31 Mar 2005 00:21:51 +0000 (GMT) Received: from arc.nasa.gov (pony2pub.arc.nasa.gov [128.102.31.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7524C43D3F for ; Thu, 31 Mar 2005 00:21:51 +0000 (GMT) (envelope-from jtoung@arc.nasa.gov) Received: from mrcrab.nas.nasa.gov ([129.99.139.47] verified) by pony2pub.arc.nasa.gov (CommuniGate Pro SMTP 4.2.8) with ESMTP id 18029650; Wed, 30 Mar 2005 16:21:50 -0800 From: Jerry Toung To: hackers Date: Wed, 30 Mar 2005 16:20:24 -0800 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503301620.24086.jtoung@arc.nasa.gov> cc: Julian Elischer Subject: netgraph TTY X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jtoung@arc.nasa.gov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2005 00:21:51 -0000 Good afternoon list, I am still trying to build a simple netgraph using ng_tty. Ultimately I would like to go from inet->tee->ng_tty(/dev/cuaa0). Please advise what I am doing wrong as I still see an error message (see bottom of email). Excuse me for the slighty long thread. Here is my very simple line discipline code: int d; int ldisc; ldisc = NETGRAPHDISC; if ((d = open("/dev/cuaa0", O_RDWR)) == -1) { perror("open"); } else { printf("descripto # %d\n", d); if ((ioctl(d, TIOCSETD, &ldisc)) == -1) { perror("ioctl"); } } printf("Netgraph TTY node initialized successfully\nPress any key to destroy it"); getc(stdin); close(d); exit; mrcrab# gcc -g netgraph.c -o test mrcrab# ./test descripto # 3 Netgraph TTY node initialized successfully Press any key to destroy it + list There are 2 total nodes: Name: ngctl27022 Type: socket ID: 0000000a Num hooks: 0 Name: tty1 Type: tty ID: 00000008 Num hooks: 0 + mpeer . tee myhook right ngctl: "mpeer": unknown command + mkpeer . tee myhook right + name .:myhook mytee + mkpeer mytee: tty left hook ngctl: send msg: Operation not permitted + From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 01:23:20 2005 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 9800016A4CE for ; Thu, 31 Mar 2005 01:23:20 +0000 (GMT) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1ABDF43D46 for ; Thu, 31 Mar 2005 01:23:20 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate1b.savvis.net (Postfix) with ESMTP id 84C6F3BF38; Wed, 30 Mar 2005 19:23:19 -0600 (CST) Received: from mailgate1b.savvis.net ([127.0.0.1]) by localhost (mailgate1b.savvis.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 24864-01-73; Wed, 30 Mar 2005 19:23:19 -0600 (CST) Received: from out002.email.savvis.net (out002.apptix.savvis.net [216.91.32.45]) by mailgate1b.savvis.net (Postfix) with ESMTP id 2C76A3BE53; Wed, 30 Mar 2005 19:23:19 -0600 (CST) Received: from s228130hz1ew03.apptix-01.savvis.net ([10.146.4.28]) by out002.email.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Mar 2005 19:23:03 -0600 Received: from [10.254.186.111] ([66.35.239.94]) by s228130hz1ew03.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Mar 2005 19:22:55 -0600 Message-ID: <424B50EC.1020502@savvis.net> Date: Wed, 30 Mar 2005 17:22:52 -0800 From: Maksim Yevmenkin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040822 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jtoung@arc.nasa.gov References: <200503301620.24086.jtoung@arc.nasa.gov> In-Reply-To: <200503301620.24086.jtoung@arc.nasa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Mar 2005 01:22:55.0841 (UTC) FILETIME=[2ABB5510:01C53590] X-Virus-Scanned: amavisd-new at savvis.net cc: hackers cc: Julian Elischer Subject: Re: netgraph TTY 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: Thu, 31 Mar 2005 01:23:20 -0000 Jerry, draw a picture :) it really helps :) for example right2left left2right \ / [ksocket] ------- [tee] -------- [hole] left right # ngctl + mkpeer hole hook hook -- create ng_hole node + name hook hole -- name ng_hole node + mkpeer hole: tee right right -- create ng_tee node and connect to hole + name hole:right tee -- name ng_tee node + mkpeer tee: ksocket left local/stream/0 -- create ksocket node and connect to tee + name tee:left ksocket -- name ksocket node + msg ksocket: bind local/"/tmp/foo" -- bind ksocket + show tee: Name: tee Type: tee ID: 00000011 Num hooks: 2 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- left ksocket ksocket 00000012 local/stream/0 right hole hole 00000010 right + show ksocket: Name: ksocket Type: ksocket ID: 00000012 Num hooks: 1 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- local/stream/0 tee tee 00000011 left + show hole: Name: hole Type: hole ID: 00000010 Num hooks: 2 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- right tee tee 00000011 right hook ngctl8529 socket 0000000f hook now connect nghook(8) to "tee:left2right" (or you could connect ng_tty node there), then connect to the unix socket at "/tmp/foo" and send something to the socket. you should see output. since we have ng_hole on the "right" then "right2left" will never get any data. if you need to capture traffic from from "right2left" then you will need to connect "one2many" node to both "right2left" (to "one2many:many0") and "right2left" (to "one2name:many1") and then connect your tty node to the "one2many:one" hook like so + mkpeer tee: one2many left2right many0 + connect tee: tee:left2right right2left many1 + show one2many: Name: one2many Type: one2many ID: 00000014 Num hooks: 2 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- many1 tee tee 00000011 right2left many0 tee tee 00000011 left2right + show tee: Name: tee Type: tee ID: 00000011 Num hooks: 4 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- right2left one2many one2many 00000014 many1 left2right one2many one2many 00000014 many0 left ksocket ksocket 00000012 local/stream/0 right hole hole 00000010 right hope this helps :) max Jerry Toung wrote: > Good afternoon list, > I am still trying to build a simple netgraph using ng_tty. Ultimately I would > like to go from inet->tee->ng_tty(/dev/cuaa0). > > Please advise what I am doing wrong as I still see an error message (see > bottom of email). Excuse me for the slighty long thread. > > Here is my very simple line discipline code: > > int d; > int ldisc; > ldisc = NETGRAPHDISC; > > > if ((d = open("/dev/cuaa0", O_RDWR)) == -1) { > perror("open"); > } else { > printf("descripto # %d\n", d); > if ((ioctl(d, TIOCSETD, &ldisc)) == -1) { > perror("ioctl"); > } > } > printf("Netgraph TTY node initialized successfully\nPress any key to > destroy it"); > getc(stdin); > close(d); > exit; > > > mrcrab# gcc -g netgraph.c -o test > mrcrab# ./test > descripto # 3 > Netgraph TTY node initialized successfully > Press any key to destroy it > > + list > There are 2 total nodes: > Name: ngctl27022 Type: socket ID: 0000000a Num hooks: 0 > Name: tty1 Type: tty ID: 00000008 Num hooks: 0 > + mpeer . tee myhook right > ngctl: "mpeer": unknown command > + mkpeer . tee myhook right > + name .:myhook mytee > + mkpeer mytee: tty left hook > ngctl: send msg: Operation not permitted > + > > > _______________________________________________ > 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 Thu Mar 31 01:43:14 2005 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 E8FDA16A4CE for ; Thu, 31 Mar 2005 01:43:14 +0000 (GMT) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3ED8043D41 for ; Thu, 31 Mar 2005 01:43:14 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr5.xs4all.nl (8.12.11/8.12.11) with ESMTP id j2V1hCDm048567 for ; Thu, 31 Mar 2005 03:43:12 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.3/8.12.9) with ESMTP id j2V1hCbk096618 for ; Thu, 31 Mar 2005 03:43:12 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.3/8.13.1/Submit) id j2V1hCWE096617 for freebsd-hackers@freebsd.org; Thu, 31 Mar 2005 03:43:12 +0200 (CEST) (envelope-from wb) Date: Thu, 31 Mar 2005 03:43:12 +0200 From: Wilko Bulte To: freebsd-hackers@freebsd.org Message-ID: <20050331014311.GA96606@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-OS: FreeBSD 4.11-STABLE User-Agent: Mutt/1.5.6i X-Virus-Scanned: by XS4ALL Virus Scanner Subject: So, who makes this one run 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: Thu, 31 Mar 2005 01:43:15 -0000 http://linuxdevices.com/news/NS8386088053.html -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 02:03:15 2005 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 75AE316A4CE for ; Thu, 31 Mar 2005 02:03:15 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF68243D1D for ; Thu, 31 Mar 2005 02:03:12 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.21] (rat.samsco.home [192.168.254.21]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j2V26vE1013772; Wed, 30 Mar 2005 19:06:57 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <424B59E1.9040208@samsco.org> Date: Wed, 30 Mar 2005 19:01:05 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.5) Gecko/20050321 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wilko Bulte References: <20050331014311.GA96606@freebie.xs4all.nl> In-Reply-To: <20050331014311.GA96606@freebie.xs4all.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: freebsd-hackers@freebsd.org Subject: Re: So, who makes this one run 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: Thu, 31 Mar 2005 02:03:15 -0000 Wilko Bulte wrote: > http://linuxdevices.com/news/NS8386088053.html > It's an AMR7, which is pretty minimal. I'm not sure if the existing ARM code has any considerations for scaling that low. Would be a very interesting project, though. Scott From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 02:09:48 2005 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 3B5D516A4CE for ; Thu, 31 Mar 2005 02:09:48 +0000 (GMT) Received: from ns.kpvs.tp.edu.tw (ldap.kpvs.tp.edu.tw [203.72.253.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16EF343D58 for ; Thu, 31 Mar 2005 02:09:46 +0000 (GMT) (envelope-from kevlo@FreeBSD.org) Received: from [192.168.3.122] (220-130-133-26.HINET-IP.hinet.net [220.130.133.26]) (authenticated bits=0) by ns.kpvs.tp.edu.tw (8.13.3/8.13.3) with ESMTP id j2VA5Ywm023149 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 31 Mar 2005 10:05:38 GMT From: Kevin Lo To: freebsd-hackers@FreeBSD.org In-Reply-To: <20050331014311.GA96606@freebie.xs4all.nl> References: <20050331014311.GA96606@freebie.xs4all.nl> Content-Type: text/plain Date: Thu, 31 Mar 2005 10:11:01 +0800 Message-Id: <1112235062.23602.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on ns.kpvs.tp.edu.tw X-Virus-Status: Clean Subject: Re: So, who makes this one run 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: Thu, 31 Mar 2005 02:09:48 -0000 Wilko Bulte wrote: > http://linuxdevices.com/news/NS8386088053.html Netsilicon's NS7520 is ARM7TDMI based processor and no MMU. That would not be a good choice for running FreeBSD :-) Kevin From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 02:32:27 2005 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 2F45616A4CE for ; Thu, 31 Mar 2005 02:32:27 +0000 (GMT) Received: from vms042pub.verizon.net (vms042pub.verizon.net [206.46.252.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04D3243D2D for ; Thu, 31 Mar 2005 02:32:27 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from verizon.net ([141.153.250.105])0.04 <0IE7004JM320QP50@vms042.mailsrvcs.net> for freebsd-hackers@freebsd.org; Wed, 30 Mar 2005 20:32:26 -0600 (CST) Date: Wed, 30 Mar 2005 21:32:23 -0500 From: Sergey Babkin Sender: root@FreeBSD.ORG To: mohamed aslan Message-id: <424B6137.15A5940A@verizon.net> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.7-RELEASE i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en, ru References: <319cceca0503281001792baf39@mail.gmail.com> <42485A54.9000101@freebsdbrasil.com.br> <319cceca05032811484cb1a95b@mail.gmail.com> <42487982.30909@freebsdbrasil.com.br> <319cceca05032907411014a218@mail.gmail.com> cc: FreeBSD Hackers Subject: Re: organization X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: babkin@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2005 02:32:27 -0000 mohamed aslan wrote: > > guys this is not a flame war > but the linux way in arranging the source file is really better than > freebsd way, it's a fact. Nope. It's real difficult to organize the files worse than in Linux. FreeBSD is actually real good. Way better than UnixWare, and of course anything beats Linux with its crazy patchwork. > primary os. but we can get the good things from linux and through out > the bad ones. Yes, procfs rules! -SB From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 02:44:42 2005 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 218AB16A4CE for ; Thu, 31 Mar 2005 02:44:42 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF2E243D5F for ; Thu, 31 Mar 2005 02:44:41 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 11F3946B45; Wed, 30 Mar 2005 21:44:41 -0500 (EST) Date: Thu, 31 Mar 2005 02:41:25 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: "H. S." In-Reply-To: <61910.81.84.174.37.1112123946.squirrel@mail.revolutionsp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: A few thoughts.. 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: Thu, 31 Mar 2005 02:44:42 -0000 On Tue, 29 Mar 2005, H. S. wrote: > My "USERNAME" account doesn't have access to /sbin/dmesg, but I uploaded > a /sbin/dmesg from a 5.2.1-RELEASE to a 5.3-STABLE box, and then I could > have access to this system information. The same goes for systat , > vmstat, and all these commands that (most people think) shouldn't be > available for regular users. dmesg is implemented as an unprivileged program that uses an unprivileged sysctl to retrieve the message buffer, kern.msgbuf. You can set the sysctl security.bsd.unprivileged_read_msgbuf to 0 to block unprivileged reading of the buffer. > Shouldn't this information be protected at kernel level? Am I missing > something I can do about this ? Because this method works with > everything that ressembles permissions in order to hide system > information that can be obtained without root privileges. In essense, yes. Historically, system information was retrieved by programs using /dev/mem, which required privilege. In that scenario, deleting or removing set{ug}id from /sbin/dmesg (et al) removed the ability to retrieve the information for an unprivileged user. Changes were made to limit the use of privileged programs, which represent a substantially risky approach (privileged code rather than a controlled interface), FreeBSD has generally moved to exporting system information using the sysctl MIB, which generally doesn't require privilege. Some system export MIB entries make use of access control to limit the export of system information -- for example, we export process information for use by ps(1) using sysctl, but the sysctls in question will check whether the user has the right to retrieve information on specific processes (such as with jail, or security.bsd.see_other_uids=0). However, this approach has not been taken universally with sysctls, because it adds moderate complexity to the implementation, and adding restrictions to many of the MIB entries isn't useful in most environments. Using the MAC Framework, it's possibel to construct a module that would restrict access to a broad range of sysctls -- however, this also prevents calls like gethostname() from succeeding, so this approach also would have to be taken cautiously. Robert N M Watson From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 02:50:58 2005 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 C4F4616A4CF for ; Thu, 31 Mar 2005 02:50:58 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44F1F43D58 for ; Thu, 31 Mar 2005 02:50:58 +0000 (GMT) (envelope-from dleimbac@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so264198rnf for ; Wed, 30 Mar 2005 18:50:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=uYuQpe2Ht+AXJK/3KySkMWsfWUT3Gtl0X3QTtSnWlFvDztmnxNNfXWvtFbOZU2JZwsql0e3Fdks1WzezJb89ct6TGqWmpdo4wwFHcOVWg4FYa4/F5f4YcxAD5a6Fa+fPwIwB2vO0esyaYrs+IU3Tcheg5pXXl+HkSv/roxeC+N4= Received: by 10.38.1.73 with SMTP id 73mr860007rna; Wed, 30 Mar 2005 18:50:55 -0800 (PST) Received: by 10.38.82.48 with HTTP; Wed, 30 Mar 2005 18:50:55 -0800 (PST) Message-ID: <5bbfe7d405033018504af3140d@mail.gmail.com> Date: Wed, 30 Mar 2005 18:50:55 -0800 From: David Leimbach To: babkin@freebsd.org In-Reply-To: <424B6137.15A5940A@verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <319cceca0503281001792baf39@mail.gmail.com> <42485A54.9000101@freebsdbrasil.com.br> <319cceca05032811484cb1a95b@mail.gmail.com> <42487982.30909@freebsdbrasil.com.br> <319cceca05032907411014a218@mail.gmail.com> <424B6137.15A5940A@verizon.net> cc: mohamed aslan cc: FreeBSD Hackers Subject: Re: organization X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Leimbach List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2005 02:50:59 -0000 > Yes, procfs rules! Procfs is from linux? I thought it was from Plan 9... along with rfork :). > > -SB > _______________________________________________ > 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 Thu Mar 31 03:05:33 2005 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 3CCDF16A4CE for ; Thu, 31 Mar 2005 03:05:33 +0000 (GMT) Received: from pop-a065d23.pas.sa.earthlink.net (pop-a065d23.pas.sa.earthlink.net [207.217.121.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04A0043D49 for ; Thu, 31 Mar 2005 03:05:33 +0000 (GMT) (envelope-from jtoung@arc.nasa.gov) Received: from h-68-164-242-172.snvacaid.dynamic.covad.net ([68.164.242.172]) by pop-a065d23.pas.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DGpzv-0007UY-00; Wed, 30 Mar 2005 19:05:31 -0800 From: Jerry Toung To: Maksim Yevmenkin Date: Wed, 30 Mar 2005 19:07:15 -0800 User-Agent: KMail/1.5.4 References: <200503301620.24086.jtoung@arc.nasa.gov> <424B50EC.1020502@savvis.net> In-Reply-To: <424B50EC.1020502@savvis.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503301907.15654.jtoung@arc.nasa.gov> cc: hackers cc: Julian Elischer Subject: Re: netgraph TTY 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: Thu, 31 Mar 2005 03:05:33 -0000 Hey Max, all I can say is thank you. That's a very nice tutorial. I am sure other people will benefit. Take care my friend. Jerry On Wednesday 30 March 2005 05:22 pm, Maksim Yevmenkin wrote: > Jerry, > > draw a picture :) it really helps :) for example > > right2left left2right > \ / > [ksocket] ------- [tee] -------- [hole] > left right > > # ngctl > > + mkpeer hole hook hook -- create ng_hole node > + name hook hole -- name ng_hole node > > > + mkpeer hole: tee right right -- create ng_tee node and connect to hole > + name hole:right tee -- name ng_tee node > > > + mkpeer tee: ksocket left local/stream/0 -- create ksocket node and > connect to tee > + name tee:left ksocket -- name ksocket node > + msg ksocket: bind local/"/tmp/foo" -- bind ksocket > > > + show tee: > Name: tee Type: tee ID: 00000011 Num hooks: 2 > Local hook Peer name Peer type Peer ID Peer > hook > ---------- --------- --------- ------- > --------- > left ksocket ksocket 00000012 > local/stream/0 > right hole hole 00000010 right > > > > + show ksocket: > Name: ksocket Type: ksocket ID: 00000012 Num hooks: 1 > Local hook Peer name Peer type Peer ID Peer > hook > ---------- --------- --------- ------- > --------- > local/stream/0 tee tee 00000011 left > > > > + show hole: > Name: hole Type: hole ID: 00000010 Num hooks: 2 > Local hook Peer name Peer type Peer ID Peer > hook > ---------- --------- --------- ------- > --------- > right tee tee 00000011 right > > hook ngctl8529 socket 0000000f hook > > > > now connect nghook(8) to "tee:left2right" (or you could connect ng_tty > node there), then connect to the unix socket at "/tmp/foo" and send > something to the socket. you should see output. since we have ng_hole on > the "right" then "right2left" will never get any data. if you need to > capture traffic from from "right2left" then you will need to connect > "one2many" node to both "right2left" (to "one2many:many0") and > "right2left" (to "one2name:many1") and then connect your tty node to the > "one2many:one" hook > > like so > > + mkpeer tee: one2many left2right many0 > + connect tee: tee:left2right right2left many1 > + show one2many: > Name: one2many Type: one2many ID: 00000014 Num hooks: 2 > Local hook Peer name Peer type Peer ID Peer > hook > ---------- --------- --------- ------- > --------- > many1 tee tee 00000011 > right2left > many0 tee tee 00000011 > left2right > > > + show tee: > Name: tee Type: tee ID: 00000011 Num hooks: 4 > Local hook Peer name Peer type Peer ID Peer > hook > ---------- --------- --------- ------- > --------- > right2left one2many one2many 00000014 many1 > > left2right one2many one2many 00000014 many0 > > left ksocket ksocket 00000012 > local/stream/0 > right hole hole 00000010 right > > > > hope this helps :) > > max > > Jerry Toung wrote: > > Good afternoon list, > > I am still trying to build a simple netgraph using ng_tty. Ultimately I > > would like to go from inet->tee->ng_tty(/dev/cuaa0). > > > > Please advise what I am doing wrong as I still see an error message (see > > bottom of email). Excuse me for the slighty long thread. > > > > Here is my very simple line discipline code: > > > > int d; > > int ldisc; > > ldisc = NETGRAPHDISC; > > > > > > if ((d = open("/dev/cuaa0", O_RDWR)) == -1) { > > perror("open"); > > } else { > > printf("descripto # %d\n", d); > > if ((ioctl(d, TIOCSETD, &ldisc)) == -1) { > > perror("ioctl"); > > } > > } > > printf("Netgraph TTY node initialized successfully\nPress any key > > to destroy it"); > > getc(stdin); > > close(d); > > exit; > > > > > > mrcrab# gcc -g netgraph.c -o test > > mrcrab# ./test > > descripto # 3 > > Netgraph TTY node initialized successfully > > Press any key to destroy it > > > > + list > > There are 2 total nodes: > > Name: ngctl27022 Type: socket ID: 0000000a Num hooks: 0 > > Name: tty1 Type: tty ID: 00000008 Num hooks: 0 > > + mpeer . tee myhook right > > ngctl: "mpeer": unknown command > > + mkpeer . tee myhook right > > + name .:myhook mytee > > + mkpeer mytee: tty left hook > > ngctl: send msg: Operation not permitted > > + > > > > > > _______________________________________________ > > 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 Thu Mar 31 03:20:44 2005 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 5588316A4CE for ; Thu, 31 Mar 2005 03:20:44 +0000 (GMT) Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0C9143D2F for ; Thu, 31 Mar 2005 03:20:43 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [192.168.1.254] (really [70.32.199.60]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with ESMTP id <20050331032043.ZYFI4618.mta13.adelphia.net@[192.168.1.254]>; Wed, 30 Mar 2005 22:20:43 -0500 Message-ID: <424B6CA0.9060202@savvis.net> Date: Wed, 30 Mar 2005 19:21:04 -0800 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jerry Toung References: <200503301620.24086.jtoung@arc.nasa.gov> <424B50EC.1020502@savvis.net> <200503301907.15654.jtoung@arc.nasa.gov> In-Reply-To: <200503301907.15654.jtoung@arc.nasa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: hackers cc: Julian Elischer Subject: Re: netgraph TTY 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: Thu, 31 Mar 2005 03:20:44 -0000 Jerry Toung wrote: > Hey Max, > all I can say is thank you. That's a very nice tutorial. I am sure other > people will benefit. so, did i get job at nasa? :) btw, i did miss one command (naming one2many node) while cut-and-paste'ing this from my screen, i.e. >>+ mkpeer tee: one2many left2right many0 >>+ connect tee: tee:left2right right2left many1 + name tee:left2right one2many >>+ show one2many: thanks, max > Take care my friend. > Jerry > > On Wednesday 30 March 2005 05:22 pm, Maksim Yevmenkin wrote: > >>Jerry, >> >>draw a picture :) it really helps :) for example >> >> right2left left2right >> \ / >>[ksocket] ------- [tee] -------- [hole] >> left right >> >># ngctl >> >>+ mkpeer hole hook hook -- create ng_hole node >>+ name hook hole -- name ng_hole node >> >> >>+ mkpeer hole: tee right right -- create ng_tee node and connect to hole >>+ name hole:right tee -- name ng_tee node >> >> >>+ mkpeer tee: ksocket left local/stream/0 -- create ksocket node and >>connect to tee >>+ name tee:left ksocket -- name ksocket node >>+ msg ksocket: bind local/"/tmp/foo" -- bind ksocket >> >> >>+ show tee: >> Name: tee Type: tee ID: 00000011 Num hooks: 2 >> Local hook Peer name Peer type Peer ID Peer >>hook >> ---------- --------- --------- ------- >>--------- >> left ksocket ksocket 00000012 >>local/stream/0 >> right hole hole 00000010 right >> >> >> >>+ show ksocket: >> Name: ksocket Type: ksocket ID: 00000012 Num hooks: 1 >> Local hook Peer name Peer type Peer ID Peer >>hook >> ---------- --------- --------- ------- >>--------- >> local/stream/0 tee tee 00000011 left >> >> >> >>+ show hole: >> Name: hole Type: hole ID: 00000010 Num hooks: 2 >> Local hook Peer name Peer type Peer ID Peer >>hook >> ---------- --------- --------- ------- >>--------- >> right tee tee 00000011 right >> >> hook ngctl8529 socket 0000000f hook >> >> >> >>now connect nghook(8) to "tee:left2right" (or you could connect ng_tty >>node there), then connect to the unix socket at "/tmp/foo" and send >>something to the socket. you should see output. since we have ng_hole on >>the "right" then "right2left" will never get any data. if you need to >>capture traffic from from "right2left" then you will need to connect >>"one2many" node to both "right2left" (to "one2many:many0") and >>"right2left" (to "one2name:many1") and then connect your tty node to the >>"one2many:one" hook >> >>like so >> >>+ mkpeer tee: one2many left2right many0 >>+ connect tee: tee:left2right right2left many1 >>+ show one2many: >> Name: one2many Type: one2many ID: 00000014 Num hooks: 2 >> Local hook Peer name Peer type Peer ID Peer >>hook >> ---------- --------- --------- ------- >>--------- >> many1 tee tee 00000011 >>right2left >> many0 tee tee 00000011 >>left2right >> >> >>+ show tee: >> Name: tee Type: tee ID: 00000011 Num hooks: 4 >> Local hook Peer name Peer type Peer ID Peer >>hook >> ---------- --------- --------- ------- >>--------- >> right2left one2many one2many 00000014 many1 >> >> left2right one2many one2many 00000014 many0 >> >> left ksocket ksocket 00000012 >>local/stream/0 >> right hole hole 00000010 right >> >> >> >>hope this helps :) >> >>max From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 03:36:06 2005 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 D50C016A4CE for ; Thu, 31 Mar 2005 03:36:06 +0000 (GMT) Received: from pop-a065d19.pas.sa.earthlink.net (pop-a065d19.pas.sa.earthlink.net [207.217.121.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8427943D5D for ; Thu, 31 Mar 2005 03:36:06 +0000 (GMT) (envelope-from jtoung@arc.nasa.gov) Received: from h-68-164-242-172.snvacaid.dynamic.covad.net ([68.164.242.172]) by pop-a065d19.pas.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DGqTV-0005aY-00; Wed, 30 Mar 2005 19:36:05 -0800 From: Jerry Toung To: Maksim Yevmenkin Date: Wed, 30 Mar 2005 19:37:49 -0800 User-Agent: KMail/1.5.4 References: <200503301620.24086.jtoung@arc.nasa.gov> <200503301907.15654.jtoung@arc.nasa.gov> <424B6CA0.9060202@savvis.net> In-Reply-To: <424B6CA0.9060202@savvis.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503301937.49349.jtoung@arc.nasa.gov> cc: hackers cc: Julian Elischer Subject: Re: netgraph TTY 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: Thu, 31 Mar 2005 03:36:06 -0000 only if you can answer this: Is there another Luke Skywalker? :-) On Wednesday 30 March 2005 07:21 pm, Maksim Yevmenkin wrote: > Jerry Toung wrote: > > Hey Max, > > all I can say is thank you. That's a very nice tutorial. I am sure other > > people will benefit. > > so, did i get job at nasa? :) > From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 04:19:09 2005 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 8831D16A4CF for ; Thu, 31 Mar 2005 04:19:09 +0000 (GMT) Received: from ns2.alphaque.com (ns2.alphaque.com [202.75.47.153]) by mx1.FreeBSD.org (Postfix) with SMTP id 7A12743D39 for ; Thu, 31 Mar 2005 04:19:07 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: (qmail 23166 invoked by uid 0); 31 Mar 2005 04:19:05 -0000 Received: from lucifer.net-gw.com (HELO prophet.alphaque.com) (202.75.47.153) by lucifer.net-gw.com with SMTP; 31 Mar 2005 04:19:05 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by prophet.alphaque.com (8.13.3/8.13.3) with ESMTP id j2V4IrF9001840; Thu, 31 Mar 2005 12:18:53 +0800 (MYT) (envelope-from dinesh@alphaque.com) Message-ID: <424B7A2D.5060902@alphaque.com> Date: Thu, 31 Mar 2005 12:18:53 +0800 From: Dinesh Nair User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050326 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-acpi@freebsd.org References: <42334057.5070705@gmx.net> <42492F0B.3040704@alphaque.com> In-Reply-To: <42492F0B.3040704@alphaque.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: enable acpi 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: Thu, 31 Mar 2005 04:19:09 -0000 acpi related, but on freebsd 4.11 (cvsupped and built on 24 march). i've compiled with device acpica in the kernel, but i get sporadic page faults as attached. i do know that acpica is experimental and that LINT does warn of kernel panics and machine hangs. however i was wondering if anyone has got this working succesfully on any machine. gdb trace of the kernel crashdump reveals: #0 dumpsys () at ../../kern/kern_shutdown.c:487 #1 0xc01d3e17 in boot (howto=260) at ../../kern/kern_shutdown.c:316 #2 0xc01d4255 in panic (fmt=0xc03c816c "%s") at ../../kern/kern_shutdown.c:595 #3 0xc03484df in trap_fatal (frame=0xc03d15ac, eva=48) at ../../i386/i386/trap.c:974 #4 0xc034818d in trap_pfault (frame=0xc03d15ac, usermode=0, eva=48) at ../../i386/i386/trap.c:867 #5 0xc0347d33 in trap (frame={tf_fs = 16, tf_es = -969474032, tf_ds = -969474032, tf_edi = 0, tf_esi = -1043903232, tf_ebp = -1069738508, tf_isp = -1069738536, tf_ebx = -1069565924, tf_edx = 6867968, tf_ecx = -693655040, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1070897928, tf_cs = 8, tf_eflags = 66182, tf_esp = -1043903232, tf_ss = -1043903232}) at ../../i386/i386/trap.c:466 #6 0xc02b64f8 in acquire_lock (lk=0xc03fb81c) at ../../ufs/ffs/ffs_softdep.c:266 #7 0xc02ba5f8 in softdep_update_inodeblock (ip=0xc1c74d00, bp=0xc63732a8, waitfor=0) at ../../ufs/ffs/ffs_softdep.c:3813 #8 0xc02b562d in ffs_update (vp=0xd6a7aa00, waitfor=0) at ../../ufs/ffs/ffs_inode.c:106 #9 0xc02bf15d in ffs_fsync (ap=0xc03d16a0) at ../../ufs/ffs/ffs_vnops.c:273 #10 0xc02bda23 in ffs_sync (mp=0xc1c31800, waitfor=2, cred=0xc0d8d680, p=0xc0444d00) at vnode_if.h:558 #11 0xc02058cb in sync (p=0xc0444d00, uap=0x0) at ../../kern/vfs_syscalls.c:583 #12 0xc01d3bb2 in boot (howto=256) at ../../kern/kern_shutdown.c:235 #13 0xc01d4255 in panic (fmt=0xc03c816c "%s") at ../../kern/kern_shutdown.c:595 #14 0xc03484df in trap_fatal (frame=0xc03d17b8, eva=112) at ../../i386/i386/trap.c:974 #15 0xc034818d in trap_pfault (frame=0xc03d17b8, usermode=0, eva=112) at ../../i386/i386/trap.c:867 #16 0xc0347d33 in trap (frame={tf_fs = -1069744112, tf_es = -1070137328, tf_ds = -1070137328, tf_edi = 0, tf_esi = -1069380132, tf_ebp = -1069737956, tf_isp = -1069738012, tf_ebx = 0, tf_edx = 12800, tf_ecx = 200, tf_eax = 6291456, tf_trapno = 12, tf_err = 0, tf_eip = -1071812936, tf_cs = 8, tf_eflags = 65606, tf_esp = 12800, tf_ss = 274877907}) at ../../i386/i386/trap.c:466 #17 0xc01d6eb8 in tsleep (ident=0xc0428ddc, priority=0, wmesg=0xc03806a3 "acpislp", timo=200) at ../../kern/kern_synch.c:436 #18 0xc0179ff2 in AcpiOsSleep (Seconds=0, Milliseconds=200) at ../../dev/acpica/Osd/OsdSchedule.c:256 #19 0xc0159685 in AcpiExSystemDoSuspend (HowLong=200) at ../../contrib/dev/acpica/exsystem.c:261 #20 0xc015580e in AcpiExOpcode_1A_0T_0R (WalkState=0xc1b6fc28) at ../../contrib/dev/acpica/exoparg1.c:202 #21 0xc014bcb1 in AcpiDsExecEndOp (WalkState=0xc1b6fc28) at ../../contrib/dev/acpica/dswexec.c:516 #22 0xc01615f8 in AcpiPsParseLoop (WalkState=0xc1b6fc28) at ../../contrib/dev/acpica/psparse.c:977 #23 0xc0161af5 in AcpiPsParseAml (WalkState=0xc1b6fc28) at ../../contrib/dev/acpica/psparse.c:1258 #24 0xc0162892 in AcpiPsxExecute (MethodNode=0xc1b5e328, Params=0x0, ReturnObjDesc=0xc03d1a1c) at ../../contrib/dev/acpica/psxface.c:281 #25 0xc015d0fb in AcpiNsExecuteControlMethod (MethodNode=0xc1b5e328, Params=0x0, ReturnObjDesc=0xc03d1a1c) at ../../contrib/dev/acpica/nseval.c:527 #26 0xc015cfdf in AcpiNsEvaluateByHandle (Handle=0xc1b5e328, Params=0x0, ReturnObject=0xc03d1abc) at ../../contrib/dev/acpica/nseval.c:409 #27 0xc015cd62 in AcpiNsEvaluateRelative (Handle=0xc1b5b4a8, Pathname=0xc03d1b00 "_Q11", Params=0x0, ReturnObject=0xc03d1abc) at ../../contrib/dev/acpica/nseval.c:225 #28 0xc015f941 in AcpiEvaluateObject (Handle=0xc1b5b4a8, Pathname=0xc03d1b00 "_Q11", ExternalParams=0x0, ReturnBuffer=0x0) at ../../contrib/dev/acpica/nsxfeval.c:357 #29 0xc0175aeb in EcGpeQueryHandler (Context=0xc1b7a540) at ../../dev/acpica/acpi_ec.c:503 #30 0xc0179f63 in AcpiOsExecuteQueue (arg=0xc1b88440, pending=1) at ../../dev/acpica/Osd/OsdSchedule.c:234 #31 0xc01e349d in taskqueue_run (queue=0xc0d862c0) at ../../kern/subr_taskqueue.c:186 #32 0xc01e34d6 in taskqueue_swi_run () at ../../kern/subr_taskqueue.c:202 #33 0xc033a860 in splz_swi () the segment of code in tsleep() kern/kern_sync.c says, s = splhigh(); if (cold || panicstr) { /* * After a panic, or during autoconfiguration, * just give interrupts a chance, then just return; * don't run any other procs or panic below, * in case this is the idle process and already asleep. */ splx(safepri); splx(s); return (0); } so tsleep() catches the panic and tries to return(0). question is, why is AcpiOsSleep() borking on it's tsleep(&dummy, 0, "acpislp", timo) call ? i've tried replacing the tsleep() in AcpiOsSleep() with DELAY(microseconds) instead, and it works. however this isnt an ideal fix as the CPU isn't relinquished by a DELAY() like a tsleep() does. is there another kernel sleep() call i can use, since AcpiOsSleep() just needs to sleep and not wait for events ? the box in question is a Benq Joybook 6000 with the following dmesg segment: Mar 29 17:50:44 prophet /kernel: Copyright (c) 1992-2005 The FreeBSD Project. Mar 29 17:50:44 prophet /kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Mar 29 17:50:44 prophet /kernel: The Regents of the University of California. All rights reserved. Mar 29 17:50:44 prophet /kernel: FreeBSD 4.11-STABLE #3: Tue Mar 29 17:40:52 MYT 2005 Mar 29 17:50:44 prophet /kernel: dinesh@prophet.alphaque.com:/usr/obj/usr/src/sys/ALPHAQUE Mar 29 17:50:44 prophet /kernel: Timecounter "i8254" frequency 1193182 Hz Mar 29 17:50:44 prophet /kernel: Timecounter "TSC" frequency 1395479702 Hz Mar 29 17:50:44 prophet /kernel: CPU: Intel(R) Pentium(R) M processor 1400MHz (1395.48-MHz 686-class CPU) Mar 29 17:50:44 prophet /kernel: Origin = "GenuineIntel" Id = 0x695 Stepping = 5 Mar 29 17:50:44 prophet /kernel: Features=0xa7e9f9bf Mar 29 17:50:44 prophet /kernel: real memory = 234815488 (229312K bytes) Mar 29 17:50:44 prophet /kernel: avail memory = 223420416 (218184K bytes) Mar 29 17:50:44 prophet /kernel: Preloaded elf kernel "kernel" at 0xc04a4000. Mar 29 17:50:44 prophet /kernel: netsmb_dev: loaded Mar 29 17:50:44 prophet /kernel: Pentium Pro MTRR support enabled Mar 29 17:50:44 prophet /kernel: md0: Malloc disk Mar 29 17:50:44 prophet /kernel: Using $PIR table, 6 entries at 0xc00fe840 Mar 29 17:50:44 prophet /kernel: acpi0: on motherboard Mar 29 17:50:44 prophet /kernel: acpi0: power button is handled as a fixed feature programming model. Mar 29 17:50:44 prophet /kernel: Timecounter "ACPI-fast" frequency 3579545 Hz Mar 29 17:50:44 prophet /kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 Mar 29 17:50:44 prophet /kernel: acpi_cpu0: on acpi0 Mar 29 17:50:44 prophet /kernel: acpi_tz0: on acpi0 Mar 29 17:50:44 prophet /kernel: acpi_button0: on acpi0 Mar 29 17:50:44 prophet /kernel: acpi_lid0: on acpi0 Mar 29 17:50:44 prophet /kernel: acpi_button1: on acpi0 Mar 29 17:50:44 prophet /kernel: acpi_acad0: on acpi0 Mar 29 17:50:44 prophet /kernel: acpi_cmbat0: on acpi0 Mar 29 17:50:44 prophet /kernel: acpi_cmbat1: on acpi0 Mar 29 17:50:44 prophet /kernel: acpi_ec0: port 0x66,0x62 on acpi0 and the following acpi sysctls: hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: S1 hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 0 hw.acpi.s4bios: 1 hw.acpi.verbose: 0 hw.acpi.disable_on_poweroff: 1 hw.acpi.cpu.max_speed: 8 hw.acpi.cpu.current_speed: 8 hw.acpi.cpu.performance_speed: 8 hw.acpi.cpu.economy_speed: 4 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 30 hw.acpi.thermal.tz0.temperature: 3152 hw.acpi.thermal.tz0.active: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 3762 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 3762 hw.acpi.thermal.tz0._ACx: 3760 3130 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.acline: 1 hw.acpi.battery.life: -1 hw.acpi.battery.time: -1 hw.acpi.battery.state: 7 hw.acpi.battery.units: 2 hw.acpi.battery.info_expire: 5 any pointers would be much appreciated. ------------------------------------------------------------------------ Mar 29 17:55:10 prophet /kernel.working: kernel trap 12 with interrupts disabled Mar 29 17:55:10 prophet /kernel.working: Mar 29 17:55:10 prophet /kernel.working: Mar 29 17:55:10 prophet /kernel.working: Fatal trap 12: page fault while in kernel mode Mar 29 17:55:10 prophet /kernel.working: fault virtual address = 0x70 Mar 29 17:55:10 prophet /kernel.working: fault code = supervisor read, page not present Mar 29 17:55:10 prophet /kernel.working: instruction pointer = 0x8:0xc01bb87c Mar 29 17:55:10 prophet /kernel.working: stack pointer = 0x10:0xc03a0528 Mar 29 17:55:10 prophet /kernel.working: frame pointer = 0x10:0xc03a054c Mar 29 17:55:10 prophet /kernel.working: code segment = base 0x0, limit 0xfffff, type 0x1b Mar 29 17:55:10 prophet /kernel.working: = DPL 0, pres 1, def32 1, gran 1 Mar 29 17:55:10 prophet /kernel.working: processor eflags = resume, IOPL = 0 Mar 29 17:55:10 prophet /kernel.working: current process = Idle Mar 29 17:55:10 prophet /kernel.working: interrupt mask = net tty bio cam Mar 29 17:55:10 prophet /kernel.working: trap number = 12 Mar 29 17:55:10 prophet /kernel.working: panic: page fault Mar 29 17:55:10 prophet /kernel.working: Mar 29 17:55:10 prophet /kernel.working: syncing disks... Mar 29 17:55:10 prophet /kernel.working: Mar 29 17:55:10 prophet /kernel.working: Fatal trap 12: page fault while in kernel mode Mar 29 17:55:10 prophet /kernel.working: fault virtual address = 0x30 Mar 29 17:55:10 prophet /kernel.working: fault code = supervisor read, page not present Mar 29 17:55:10 prophet /kernel.working: instruction pointer = 0x8:0xc029ac00 Mar 29 17:55:10 prophet /kernel.working: stack pointer = 0x10:0xc03a0258 Mar 29 17:55:10 prophet /kernel.working: frame pointer = 0x10:0xc03a0260 Mar 29 17:55:10 prophet /kernel.working: code segment = base 0x0, limit 0xfffff, type 0x1b Mar 29 17:55:10 prophet /kernel.working: = DPL 0, pres 1, def32 1, gran 1 Mar 29 17:55:10 prophet /kernel.working: processor eflags = interrupt enabled, resume, IOPL = 0 Mar 29 17:55:11 prophet /kernel.working: current process = Idle Mar 29 17:55:11 prophet /kernel.working: interrupt mask = net tty bio cam Mar 29 17:55:11 prophet /kernel.working: trap number = 12 Mar 29 17:55:11 prophet /kernel.working: panic: page fault Mar 29 17:55:11 prophet /kernel.working: Uptime: 1m52s Mar 29 17:55:11 prophet /kernel.working: Terminate ACPI Mar 29 17:55:11 prophet /kernel.working: Automatic reboot in 15 seconds - press a key on the console to abort Mar 29 17:55:11 prophet /kernel.working: Rebooting... -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.alphaque.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 07:03:24 2005 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 0498C16A4CE for ; Thu, 31 Mar 2005 07:03:24 +0000 (GMT) Received: from grunt9.ihug.co.nz (grunt9.ihug.co.nz [203.109.254.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id E553043D54 for ; Thu, 31 Mar 2005 07:03:22 +0000 (GMT) (envelope-from mjl@luckie.org.nz) Received: from 203-173-150-25.bliink.ihug.co.nz (lycra.luckie.org.nz) [203.173.150.25] by grunt9.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1DGti5-0004UU-00; Thu, 31 Mar 2005 19:03:21 +1200 Received: from 203-173-154-140.bliink.ihug.co.nz ([203.173.154.140] helo=[192.168.1.6]) by lycra.luckie.org.nz with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DGti4-0008T4-JE for freebsd-hackers@freebsd.org; Thu, 31 Mar 2005 19:03:20 +1200 Message-ID: <424BA0B5.2000302@luckie.org.nz> Date: Thu, 31 Mar 2005 19:03:17 +1200 From: Matthew Luckie User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: kqueue and ordinary files 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: Thu, 31 Mar 2005 07:03:24 -0000 Does kqueue signal EOF on an ordinary file when there is nothing left to read? The code at http://www.wand.net.nz/~mjl12/kqfile.c.txt cc -Wall -o kqfile kqfile.c ./kqfile kqueue.c doesn't ever get EOF notification as far as i can tell. as in, it isn't signaled in kevent.flags, nor does kqueue signal the file is ready for reading and then read(2) return 0. ident 3 filter 0xffffffff flags 0x0001 fflags 0x0000 data 128 read 128 bytes how should i detect that the file no longer has anything left to read with kqueue? at the moment I use select but would like to use kqueue where available. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 07:32:14 2005 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 BB39116A4CE for ; Thu, 31 Mar 2005 07:32:14 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66AFD43D41 for ; Thu, 31 Mar 2005 07:32:14 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j2V7WEAF037127; Thu, 31 Mar 2005 01:32:14 -0600 (CST) (envelope-from dan) Date: Thu, 31 Mar 2005 01:32:13 -0600 From: Dan Nelson To: Matthew Luckie Message-ID: <20050331073213.GE46288@dan.emsphone.com> References: <424BA0B5.2000302@luckie.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <424BA0B5.2000302@luckie.org.nz> X-OS: FreeBSD 5.4-PRERELEASE X-message-flag: Outlook Error User-Agent: Mutt/1.5.8i cc: freebsd-hackers@freebsd.org Subject: Re: kqueue and ordinary files 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: Thu, 31 Mar 2005 07:32:14 -0000 In the last episode (Mar 31), Matthew Luckie said: > Does kqueue signal EOF on an ordinary file when there is nothing left > to read? > > The code at http://www.wand.net.nz/~mjl12/kqfile.c.txt > > cc -Wall -o kqfile kqfile.c > ./kqfile kqueue.c > > doesn't ever get EOF notification as far as i can tell. as in, it > isn't signaled in kevent.flags, nor does kqueue signal the file is > ready for reading and then read(2) return 0. > > ident 3 filter 0xffffffff flags 0x0001 fflags 0x0000 data 128 > read 128 bytes > > how should i detect that the file no longer has anything left to read > with kqueue? at the moment I use select but would like to use kqueue > where available. You can get it indirectly by examining the data field. You can see that the call just before the final kqueue returns data=60, so if your read call returns 60, you're done. The current behaviour is useful for things like tail or syslog watchers, so that they get an EVFILT_READ event when the file grows. They may be better off registering an EVFILT_VNODE/NOTE_EXTEND event though, so you could make a case for returning EV_EOF on EVFILT_READ instead of blocking. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 07:37:23 2005 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 8669516A4CE for ; Thu, 31 Mar 2005 07:37:23 +0000 (GMT) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0A6B43D49 for ; Thu, 31 Mar 2005 07:37:22 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j2V7bLYk030667 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 31 Mar 2005 17:37:21 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j2V7bK7l075665; Thu, 31 Mar 2005 17:37:20 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j2V7bKjt075664; Thu, 31 Mar 2005 17:37:20 +1000 (EST) (envelope-from pjeremy) Date: Thu, 31 Mar 2005 17:37:20 +1000 From: Peter Jeremy To: zean zean Message-ID: <20050331073720.GE71384@cirb503493.alcatel.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i cc: freebsd-hackers@freebsd.org Subject: Re: the best form to wait the finish of execution of a child... 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: Thu, 31 Mar 2005 07:37:23 -0000 On Wed, 2005-Mar-30 14:17:43 -0400, zean zean wrote: >Excuse for my badly English. which is the best form to wait the >finish of execution of a child. That's virtually impossible to answer as a general case. The best form depends on exactly what you want to do. >My idea is: > >pid_t chilpid; > >while(childpid != wait(&status)) >; If you want to wait for a specific pid, look at waitpid() or wait4(): if (waitpid(childpid, &status, 0) == -1) { handle error } -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 07:43:49 2005 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 EF39916A4CE for ; Thu, 31 Mar 2005 07:43:49 +0000 (GMT) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43DFF43D5E for ; Thu, 31 Mar 2005 07:43:49 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j2V7hlX1013046 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 31 Mar 2005 17:43:48 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j2V7hl7l075694; Thu, 31 Mar 2005 17:43:47 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j2V7hliV075693; Thu, 31 Mar 2005 17:43:47 +1000 (EST) (envelope-from pjeremy) Date: Thu, 31 Mar 2005 17:43:47 +1000 From: Peter Jeremy To: zean zean Message-ID: <20050331074347.GF71384@cirb503493.alcatel.com.au> References: <20050330115132.N76928@skutsje.san.webweaving.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i cc: freebsd-hackers@freebsd.org Subject: Re: the best form to wait the finish of execution of a child... 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: Thu, 31 Mar 2005 07:43:50 -0000 On Wed, 2005-Mar-30 16:06:55 -0400, zean zean wrote: >Dirk-Willem My idea is to avoid all the processes zombies. thanks by >the recommendation. If you just want to avoid zombies and don't care about the return status, you can set SIGCHLD to SIG_IGN with SA_NOCLDWAIT (see sigaction(2)) and not have to use wait() at all. Note that if you don't bother to wait() for children and don't otherwise keep track of how many children you have, you can run into overload problems if you start creating children faster than they complete. -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 10:17:16 2005 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 162E616A4CE; Thu, 31 Mar 2005 10:17:16 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12BAB43D53; Thu, 31 Mar 2005 10:17:13 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.21] (rat.samsco.home [192.168.254.21]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j2VAKsiJ016179; Thu, 31 Mar 2005 03:20:55 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <424BCDAA.40604@samsco.org> Date: Thu, 31 Mar 2005 03:15:06 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.5) Gecko/20050321 X-Accept-Language: en-us, en MIME-Version: 1.0 To: thomas@freebsd.org Content-Type: multipart/mixed; boundary="------------090700030006080708070500" X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: hackers@freebsd.org cc: sos@freebsd.org Subject: ATAPICAM for ATA-MKIII 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: Thu, 31 Mar 2005 10:17:16 -0000 This is a multi-part message in MIME format. --------------090700030006080708070500 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thomas, Attached are patches for atapicam for ATA-MKIII. I've only done light testing, but they seem to work as expected. They work both as a module and compiled into the kernel. Scott --------------090700030006080708070500 Content-Type: text/plain; name="atapicam.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="atapicam.diff" Index: ata-all.c =================================================================== RCS file: /usr/ncvs/src/sys/dev/ata/ata-all.c,v retrieving revision 1.236 diff -u -r1.236 ata-all.c --- ata-all.c 30 Mar 2005 12:03:37 -0000 1.236 +++ ata-all.c 31 Mar 2005 10:08:47 -0000 @@ -142,6 +142,8 @@ return error; } + device_add_child(dev, "atapicam", -1); + /* do not attach devices if we are in early boot */ if (ata_delayed_attach) return 0; Index: ata-all.h =================================================================== RCS file: /usr/ncvs/src/sys/dev/ata/ata-all.h,v retrieving revision 1.88 diff -u -r1.88 ata-all.h --- ata-all.h 30 Mar 2005 12:03:37 -0000 1.88 +++ ata-all.h 31 Mar 2005 08:05:36 -0000 @@ -270,6 +270,7 @@ int unit; /* physical unit */ #define ATA_MASTER 0x00 #define ATA_SLAVE 0x10 +#define ATA_ATAPI_CAM 0x100 struct ata_params param; /* ata param structure */ int mode; /* current transfermode */ Index: atapi-cam.c =================================================================== RCS file: /usr/ncvs/src/sys/dev/ata/atapi-cam.c,v retrieving revision 1.35 diff -u -r1.35 atapi-cam.c --- atapi-cam.c 17 Jun 2004 07:29:56 -0000 1.35 +++ atapi-cam.c 31 Mar 2005 10:08:36 -0000 @@ -40,6 +40,7 @@ #include #include #include +#include #include #include @@ -51,6 +52,23 @@ #include #include +#include + +/* private data associated with an ATA bus */ +struct atapi_xpt_softc { + struct ata_device atapi_cam_dev; /* must be first */ + device_t dev; + device_t parent; + struct ata_channel *ata_ch; + struct cam_path *path; + struct cam_sim *sim; + int flags; +#define BUS_REGISTERED 0x01 +#define RESOURCE_SHORTAGE 0x02 + + TAILQ_HEAD(,atapi_hcb) pending_hcbs; + struct ata_device *atadev[2]; +}; /* hardware command descriptor block */ struct atapi_hcb { @@ -67,23 +85,13 @@ TAILQ_ENTRY(atapi_hcb) chain; }; -/* private data associated with an ATA bus */ -struct atapi_xpt_softc { - struct ata_channel *ata_ch; - struct cam_path *path; - struct cam_sim *sim; - int flags; -#define BUS_REGISTERED 0x01 -#define RESOURCE_SHORTAGE 0x02 - - TAILQ_HEAD(,atapi_hcb) pending_hcbs; - LIST_ENTRY(atapi_xpt_softc) chain; -}; - enum reinit_reason { BOOT_ATTACH, ATTACH, RESET }; -static struct mtx atapicam_softc_mtx; -static LIST_HEAD(,atapi_xpt_softc) all_buses = LIST_HEAD_INITIALIZER(all_buses); +/* Device methods */ +static int atapi_cam_probe(device_t dev); +static int atapi_cam_attach(device_t dev); +static int atapi_cam_detach(device_t dev); +static int atapi_cam_reinit(device_t dev); /* CAM XPT methods */ static void atapi_action(struct cam_sim *, union ccb *); @@ -94,7 +102,6 @@ /* internal functions */ static void reinit_bus(struct atapi_xpt_softc *scp, enum reinit_reason reason); -static void setup_dev(struct atapi_xpt_softc *, struct ata_device *); static void setup_async_cb(struct atapi_xpt_softc *, uint32_t); static void cam_rescan_callback(struct cam_periph *, union ccb *); static void cam_rescan(struct cam_sim *); @@ -102,64 +109,85 @@ static struct atapi_hcb *allocate_hcb(struct atapi_xpt_softc *, int, int, union ccb *); static void free_hcb(struct atapi_hcb *hcb); static void free_softc(struct atapi_xpt_softc *scp); -static struct atapi_xpt_softc *get_softc(struct ata_channel *ata_ch); -static struct ata_device *get_ata_device(struct atapi_xpt_softc *scp, int id); static MALLOC_DEFINE(M_ATACAM, "ATA CAM transport", "ATA driver CAM-XPT layer"); -void -atapi_cam_attach_bus(struct ata_channel *ata_ch) +static device_method_t atapi_cam_methods[] = { + DEVMETHOD(device_probe, atapi_cam_probe), + DEVMETHOD(device_attach, atapi_cam_attach), + DEVMETHOD(device_detach, atapi_cam_detach), + DEVMETHOD(ata_reinit, atapi_cam_reinit), + {0, 0} +}; + +static driver_t atapi_cam_driver = { + "atapicam", + atapi_cam_methods, + sizeof(struct atapi_xpt_softc) +}; + +static devclass_t atapi_cam_devclass; +DRIVER_MODULE(atapicam, ata, atapi_cam_driver, atapi_cam_devclass, 0, 0); +DRIVER_MODULE(atapicam, atapci, atapi_cam_driver, atapi_cam_devclass, 0, 0); +DRIVER_MODULE(atapicam, atacbus, atapi_cam_driver, atapi_cam_devclass, 0, 0); +MODULE_VERSION(atapicam, 1); +MODULE_DEPEND(atapicam, ata, 1, 1, 1); + +static int +atapi_cam_probe(device_t dev) +{ + device_set_desc(dev, "ATAPI CAM Attachment"); + return (0); +} + +static int +atapi_cam_attach(device_t dev) { struct atapi_xpt_softc *scp = NULL; struct cam_devq *devq = NULL; struct cam_sim *sim = NULL; struct cam_path *path = NULL; - int unit; - - GIANT_REQUIRED; - - if (mtx_initialized(&atapicam_softc_mtx) == 0) - mtx_init(&atapicam_softc_mtx, "ATAPI/CAM softc mutex", NULL, MTX_DEF); - - mtx_lock(&atapicam_softc_mtx); + int unit, error; - LIST_FOREACH(scp, &all_buses, chain) { - if (scp->ata_ch == ata_ch) - break; + scp = (struct atapi_xpt_softc *)device_get_softc(dev); + if (scp == NULL) { + device_printf(dev, "Cannot get softc\n"); + return (ENOMEM); } - mtx_unlock(&atapicam_softc_mtx); - - if (scp != NULL) - return; - if ((scp = malloc(sizeof(struct atapi_xpt_softc), - M_ATACAM, M_NOWAIT | M_ZERO)) == NULL) - goto error; + /* The ATA core expects all of its children to have an ata_device */ + scp->atapi_cam_dev.unit = ATA_ATAPI_CAM; + scp->atapi_cam_dev.dev = dev; - scp->ata_ch = ata_ch; + scp->dev = dev; + scp->parent = device_get_parent(dev); + scp->ata_ch = device_get_softc(scp->parent); TAILQ_INIT(&scp->pending_hcbs); - LIST_INSERT_HEAD(&all_buses, scp, chain); - unit = device_get_unit(ata_ch->dev); + unit = device_get_unit(dev); - if ((devq = cam_simq_alloc(16)) == NULL) - goto error; + if ((devq = cam_simq_alloc(16)) == NULL) { + error = ENOMEM; + goto out; + } if ((sim = cam_sim_alloc(atapi_action, atapi_poll, "ata", (void *)scp, unit, 1, 1, devq)) == NULL) { - cam_simq_free(devq); - goto error; + error = ENOMEM; + goto out; } scp->sim = sim; if (xpt_bus_register(sim, 0) != CAM_SUCCESS) { - goto error; + error = EINVAL; + goto out; } scp->flags |= BUS_REGISTERED; if (xpt_create_path(&path, /*periph*/ NULL, cam_sim_path(sim), CAM_TARGET_WILDCARD, CAM_LUN_WILDCARD) != CAM_REQ_CMP) { - goto error; + error = ENOMEM; + goto out; } scp->path = path; @@ -167,25 +195,27 @@ setup_async_cb(scp, AC_LOST_DEVICE); reinit_bus(scp, cold ? BOOT_ATTACH : ATTACH); - return; + error = 0; -error: - free_softc(scp); +out: + if (error != 0) + free_softc(scp); + + return (error); } -void -atapi_cam_detach_bus(struct ata_channel *ata_ch) +static int +atapi_cam_detach(device_t dev) { - struct atapi_xpt_softc *scp = get_softc(ata_ch); + struct atapi_xpt_softc *scp = device_get_softc(dev); - mtx_lock(&Giant); free_softc(scp); - mtx_unlock(&Giant); + return (0); } -void -atapi_cam_reinit_bus(struct ata_channel *ata_ch) { - struct atapi_xpt_softc *scp = get_softc(ata_ch); +static int +atapi_cam_reinit(device_t dev) { + struct atapi_xpt_softc *scp = device_get_softc(dev); /* * scp might be null if the bus is being reinitialised during @@ -193,21 +223,38 @@ */ if (scp != NULL) { - mtx_lock(&Giant); reinit_bus(scp, RESET); - mtx_unlock(&Giant); } + return (0); } static void reinit_bus(struct atapi_xpt_softc *scp, enum reinit_reason reason) { + struct ata_device *atadev; + device_t *children; + int nchildren, i; GIANT_REQUIRED; + if (device_get_children(scp->parent, &children, &nchildren) != 0) { + return; + } + + scp->atadev[0] = NULL; + scp->atadev[1] = NULL; - if (scp->ata_ch->devices & ATA_ATAPI_MASTER) - setup_dev(scp, &scp->ata_ch->device[MASTER]); - if (scp->ata_ch->devices & ATA_ATAPI_SLAVE) - setup_dev(scp, &scp->ata_ch->device[SLAVE]); + for (i = 0; i < nchildren; i++) { + /* XXX Does the child need to actually be attached yet? */ + if (children[i] != NULL) { + atadev = device_get_softc(children[i]); + if ((atadev->unit == ATA_MASTER) && + (scp->ata_ch->devices & ATA_ATAPI_MASTER) != 0) + scp->atadev[0] = atadev; + if ((atadev->unit == ATA_SLAVE) && + (scp->ata_ch->devices & ATA_ATAPI_SLAVE) != 0) + scp->atadev[1] = atadev; + } + } + free(children, M_TEMP); switch (reason) { case BOOT_ATTACH: @@ -222,17 +269,6 @@ } static void -setup_dev(struct atapi_xpt_softc *scp, struct ata_device *atp) -{ - if (atp->softc == NULL) { - ata_set_name(atp, "atapicam", - 2 * device_get_unit(atp->channel->dev) + - (atp->unit == ATA_MASTER) ? 0 : 1); - atp->softc = (void *)scp; - } -} - -static void setup_async_cb(struct atapi_xpt_softc *scp, uint32_t events) { struct ccb_setasync csa; @@ -262,6 +298,7 @@ switch (ccb_h->func_code) { case XPT_PATH_INQ: { struct ccb_pathinq *cpi = &ccb->cpi; + int tid = ccb_h->target_id; cpi->version_num = 1; cpi->hba_inquiry = 0; @@ -281,8 +318,13 @@ cpi->bus_id = cam_sim_bus(sim); cpi->base_transfer_speed = 3300; - if (softc->ata_ch && ccb_h->target_id != CAM_TARGET_WILDCARD) { - switch (softc->ata_ch->device[ccb_h->target_id].mode) { + if (softc->ata_ch && tid != CAM_TARGET_WILDCARD) { + if (softc->atadev[tid] == NULL) { + ccb->ccb_h.status = CAM_DEV_NOT_THERE; + xpt_done(ccb); + return; + } + switch (softc->atadev[ccb_h->target_id]->mode) { case ATA_PIO1: cpi->base_transfer_speed = 5200; break; @@ -320,10 +362,9 @@ case XPT_RESET_DEV: { int tid = ccb_h->target_id; - struct ata_device *dev = get_ata_device(softc, tid); CAM_DEBUG(ccb->ccb_h.path, CAM_DEBUG_SUBTRACE, ("dev reset\n")); - ata_controlcmd(dev, ATA_ATAPI_RESET, 0, 0, 0); + ata_controlcmd(softc->atadev[tid], ATA_ATAPI_RESET, 0, 0, 0); ccb->ccb_h.status = CAM_REQ_CMP; xpt_done(ccb); return; @@ -331,7 +372,7 @@ case XPT_RESET_BUS: CAM_DEBUG(ccb->ccb_h.path, CAM_DEBUG_SUBTRACE, ("bus reset\n")); - ata_reinit(softc->ata_ch); + ata_reinit(softc->parent); ccb->ccb_h.status = CAM_REQ_CMP; xpt_done(ccb); return; @@ -370,22 +411,22 @@ case XPT_SCSI_IO: { struct ccb_scsiio *csio = &ccb->csio; int tid = ccb_h->target_id, lid = ccb_h->target_lun; - struct ata_device *dev = get_ata_device(softc, tid); int request_flags = ATA_R_QUIET | ATA_R_ATAPI; CAM_DEBUG(ccb_h->path, CAM_DEBUG_SUBTRACE, ("XPT_SCSI_IO\n")); + if (softc->atadev[tid] == NULL) { + ccb->ccb_h.status = CAM_DEV_NOT_THERE; + xpt_done(ccb); + return; + } + /* check that this request was not aborted already */ if ((ccb_h->status & CAM_STATUS_MASK) != CAM_REQ_INPROG) { printf("XPT_SCSI_IO received but already in progress?\n"); xpt_done(ccb); return; } - if (dev == NULL) { - CAM_DEBUG(ccb_h->path, CAM_DEBUG_SUBTRACE, - ("SCSI IO received for invalid device\n")); - goto action_invalid; - } if (lid > 0) { CAM_DEBUG(ccb_h->path, CAM_DEBUG_SUBTRACE, ("SCSI IO received for invalid lun %d\n", lid)); @@ -414,10 +455,10 @@ /* No flags need to be set */ break; default: - ata_prtdev(dev, "unknown IO operation\n"); + device_printf(softc->dev, "unknown IO operation\n"); goto action_invalid; } - if (dev->mode < ATA_DMA) + if (softc->atadev[tid]->mode < ATA_DMA) request_flags &= ~ATA_R_DMA; if ((hcb = allocate_hcb(softc, unit, bus, ccb)) == NULL) { @@ -491,7 +532,7 @@ goto action_oom; } } - request->device = dev; + request->dev = softc->atadev[tid]->dev; request->driver = hcb; request->data = buf; request->bytecount = len; @@ -764,40 +805,5 @@ printf("Can't free %s SIM (still registered)\n", cam_sim_name(scp->sim)); } - LIST_REMOVE(scp, chain); - free(scp, M_ATACAM); - } -} - -static struct atapi_xpt_softc * -get_softc(struct ata_channel *ata_ch) { - struct atapi_xpt_softc *scp = NULL; - - mtx_lock(&atapicam_softc_mtx); - LIST_FOREACH(scp, &all_buses, chain) { - if (scp->ata_ch == ata_ch) - break; - } - mtx_unlock(&atapicam_softc_mtx); - return scp; -} - -static struct ata_device * -get_ata_device(struct atapi_xpt_softc *scp, int id) -{ - int role = ATA_ATAPI_MASTER; - - switch (id) { - case 1: - role = ATA_ATAPI_SLAVE; - /* FALLTHROUGH */ - - case 0: - if (scp->ata_ch->devices & role) - return &scp->ata_ch->device[id]; - /* FALLTHROUGH */ - - default: - return NULL; } } --------------090700030006080708070500 Content-Type: text/plain; name="Makefile" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Makefile" # $FreeBSD: src/sys/modules/ata/atacam/Makefile,v 1.1 2005/03/30 12:03:39 sos Exp $ .PATH: ${.CURDIR}/../../../dev/ata KMOD= atapicam SRCS= atapi-cam.c SRCS+= opt_ata.h opt_cam.h ata_if.h device_if.h bus_if.h pci_if.h .include --------------090700030006080708070500-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 10:37:27 2005 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 A27D316A4CE for ; Thu, 31 Mar 2005 10:37:27 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0030A43D3F for ; Thu, 31 Mar 2005 10:37:26 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0)j2VAbFsf036895 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 31 Mar 2005 12:37:18 +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 j2VAaGhs012119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Mar 2005 12:36:17 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j2VAaGiK002067; Thu, 31 Mar 2005 12:36:16 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j2VAaFcC002066; Thu, 31 Mar 2005 12:36:15 +0200 (CEST) (envelope-from ticso) Date: Thu, 31 Mar 2005 12:36:15 +0200 From: Bernd Walter To: Wilko Bulte Message-ID: <20050331103614.GL33677@cicely12.cicely.de> References: <20050331014311.GA96606@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050331014311.GA96606@freebie.xs4all.nl> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=no version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de cc: freebsd-hackers@freebsd.org Subject: Re: So, who makes this one run FreeBSD? ;-) 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: Thu, 31 Mar 2005 10:37:27 -0000 On Thu, Mar 31, 2005 at 03:43:12AM +0200, Wilko Bulte wrote: > http://linuxdevices.com/news/NS8386088053.html As others already said - to small to run FreeBSD. No MMU, very tight RAM and code space. Note that they are not based on Linux, but on uCLinux, which is something different. RTEMS should be a good candidate - it is not Linux, but unfortunately has large portions under GPL too. But considered the small price distance to the smallest Soekris, which runs FreeBSD, only the size and supply power is an interesting point. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 10:44:02 2005 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 0B05C16A4CE for ; Thu, 31 Mar 2005 10:44:02 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9079543D39 for ; Thu, 31 Mar 2005 10:44:01 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.21] (rat.samsco.home [192.168.254.21]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j2VAlUes016307; Thu, 31 Mar 2005 03:47:30 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <424BD3E6.2040002@samsco.org> Date: Thu, 31 Mar 2005 03:41:42 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.5) Gecko/20050321 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ticso@cicely.de References: <20050331014311.GA96606@freebie.xs4all.nl> <20050331103614.GL33677@cicely12.cicely.de> In-Reply-To: <20050331103614.GL33677@cicely12.cicely.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: Wilko Bulte cc: freebsd-hackers@freebsd.org Subject: Re: So, who makes this one run 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: Thu, 31 Mar 2005 10:44:02 -0000 Bernd Walter wrote: > On Thu, Mar 31, 2005 at 03:43:12AM +0200, Wilko Bulte wrote: > >>http://linuxdevices.com/news/NS8386088053.html > > > As others already said - to small to run FreeBSD. > No MMU, very tight RAM and code space. > Note that they are not based on Linux, but on uCLinux, which is > something different. > RTEMS should be a good candidate - it is not Linux, but unfortunately > has large portions under GPL too. > But considered the small price distance to the smallest Soekris, > which runs FreeBSD, only the size and supply power is an interesting > point. > An MMU-less port of any BSD would be very worthwhile, even if it requires a radical divergence from the original codebase. I was hoping that such a treat would appear out of NetBSD, but that doesn't seem to be the case. Scott From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 10:46:45 2005 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 86D6916A4CE; Thu, 31 Mar 2005 10:46:45 +0000 (GMT) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id C108C43D39; Thu, 31 Mar 2005 10:46:44 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j2VAkbIP005417 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 31 Mar 2005 20:46:37 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j2VAka7l075885; Thu, 31 Mar 2005 20:46:36 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j2VAkZu8075884; Thu, 31 Mar 2005 20:46:35 +1000 (EST) (envelope-from pjeremy) Date: Thu, 31 Mar 2005 20:46:35 +1000 From: Peter Jeremy To: Bruce Evans Message-ID: <20050331104635.GH71384@cirb503493.alcatel.com.au> References: <20050327133059.3d68a78c@Magellan.Leidinger.net> <20050327134044.GM78512@silverwraith.com> <20050327162839.2fafa6aa@Magellan.Leidinger.net> <5bbfe7d405032823144fc1af7b@mail.gmail.com> <5bbfe7d405032823232103d537@mail.gmail.com> <20050329111107.GD69824@cirb503493.alcatel.com.au> <424A23A8.5040109@ec.rr.com> <20050330080113.GA71384@cirb503493.alcatel.com.au> <20050330130051.GA4416@VARK.MIT.EDU> <20050331155418.F20400@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050331155418.F20400@delplex.bde.org> User-Agent: Mutt/1.4.2i cc: David Schultz cc: hackers@freebsd.org cc: jason henson cc: bde@freebsd.org Subject: Re: Fwd: 5-STABLE kernel build with icc broken 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: Thu, 31 Mar 2005 10:46:45 -0000 On Thu, 2005-Mar-31 17:17:58 +1000, Bruce Evans wrote: >>>On the i386 (and probably most other CPUs), you can place the FPU into >>>am "unavailable" state. This means that any attempt to use it will >>>trigger a trap. The kernel will then restore FPU state and return. >>>On a normal system call, if the FPU hasn't been used, the kernel will >>>see that it's still in an "unavailable" state and can avoid saving the >>>state. (On an i386, "unavailable" state is achieved by either setting >>>CR0_TS or CR0_EM). This means you avoid having to always restore FPU >>>state at the expense of an additional trap if the process actually >>>uses the FPU. > >I remember that you (Peter) did extensive benchmarks of this. That was a long time ago and I don't recall them being that extensive. I suspect the results are in my archives at work - I can't quickly find them here. From memory the tests were on 2.2 and just counted the number of context switches, FP saves and restores. > I still >think fully lazy switching (c2) is the best general method. I think it depends on the FP workload. It's a definite win if there is exactly one FP thread - in this case the FPU state never needs to be saved (and you could even optimise away the DNA trap by clearing the TS and EM bits if the switched-to curthread is fputhread). The worst case is two (or more) FP-intensive threads - in this case, lazy switching is of no benefit. The DNA trap overheads mean that the performance is worse than just saving/restoring the FP state during a context switch. My guess is that the current generation workstation is closer to the second case - current generation graphical bloatware uses a lot of FP for rendering, not to mention that the idle task has a reasonable chance of being an FP-intensive distributed computing task (setiathome or similar). It's probably time to do some more measuring (I'm not offering just now, I have lots of other things on my TODO list). SMP adds a whole new can of worms. (I originally suspected that lazy switching had been lost during the SMP transition). Given CPU (FPU) affinity, you can just add "per CPU" to the above but I'm not sure that changes my conclusion. > Maybe FP state should be loaded in advance based on FPU affinity. Pre-loading the FPU state is an advantage for FP-intensive threads - if the thread will definitely use the FPU before the next context switch, you save the cost of a DNA trap by pre-loading the FPU state. > It might be >good for CPU affinity to depend on FPU use (prfer not to switch >threads away from a CPU if they own that CPU via its FPU). FPU affinity is only an advantage if full lazy switching is implemented. (And I thought we didn't even have CPU affinity working well). The first step is probably gathering some data on whether lazy switching is any benefit. >BTW, David and I recently found a bug in the context switching in the >fxsr case, at least on Athlon-XP's and AMD64's. I gather this is not noticable unless the application is doing its own FPU save/restore. Is there a solution or work-around? -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 11:02:28 2005 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 39C2A16A4CE for ; Thu, 31 Mar 2005 11:02:28 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C2D643D46 for ; Thu, 31 Mar 2005 11:02:27 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0)j2VB2Hsf037668 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 31 Mar 2005 13:02:20 +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 j2VB1vhs012318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Mar 2005 13:01:58 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j2VB1vUO002240; Thu, 31 Mar 2005 13:01:57 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j2VB1vLs002239; Thu, 31 Mar 2005 13:01:57 +0200 (CEST) (envelope-from ticso) Date: Thu, 31 Mar 2005 13:01:57 +0200 From: Bernd Walter To: Scott Long Message-ID: <20050331110156.GA2072@cicely12.cicely.de> References: <20050331014311.GA96606@freebie.xs4all.nl> <20050331103614.GL33677@cicely12.cicely.de> <424BD3E6.2040002@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <424BD3E6.2040002@samsco.org> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-0.9 required=3.0 tests=BAYES_10 autolearn=no version=2.64 X-Spam-Report: * -0.9 BAYES_10 BODY: Bayesian spam probability is 10 to 20% * [score: 0.1137] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de cc: Wilko Bulte cc: ticso@cicely.de cc: freebsd-hackers@freebsd.org Subject: Re: So, who makes this one run FreeBSD? ;-) 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: Thu, 31 Mar 2005 11:02:28 -0000 On Thu, Mar 31, 2005 at 03:41:42AM -0700, Scott Long wrote: > Bernd Walter wrote: > >On Thu, Mar 31, 2005 at 03:43:12AM +0200, Wilko Bulte wrote: > > > >>http://linuxdevices.com/news/NS8386088053.html > > > > > >As others already said - to small to run FreeBSD. > >No MMU, very tight RAM and code space. > >Note that they are not based on Linux, but on uCLinux, which is > >something different. > >RTEMS should be a good candidate - it is not Linux, but unfortunately > >has large portions under GPL too. > >But considered the small price distance to the smallest Soekris, > >which runs FreeBSD, only the size and supply power is an interesting > >point. > > > > An MMU-less port of any BSD would be very worthwhile, even if it > requires a radical divergence from the original codebase. I was > hoping that such a treat would appear out of NetBSD, but that doesn't > seem to be the case. It's a matter on how far you want to go. There are many MMU and GPL less solutions available. The following can be considered as the other extrem end: uIP, lwIP, Nut/OS, ... Just having the essential to run network based services. There is very much room of what people might expect from systems with more features. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 11:03:30 2005 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 BD2B616A4CE for ; Thu, 31 Mar 2005 11:03:30 +0000 (GMT) Received: from comsys.ntu-kpi.kiev.ua (comsys.ntu-kpi.kiev.ua [195.245.194.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C65243D4C for ; Thu, 31 Mar 2005 11:03:21 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from pm514-9.comsys.ntu-kpi.kiev.ua (pm514-9.comsys.ntu-kpi.kiev.ua [10.18.54.109]) (authenticated bits=0)j2VB76iX059257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 31 Mar 2005 14:07:07 +0300 (EEST) Received: by pm514-9.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1000) id 22CD7371; Thu, 31 Mar 2005 14:02:55 +0300 (EEST) Date: Thu, 31 Mar 2005 14:02:54 +0300 From: Andrey Simonenko To: freebsd-hackers@freebsd.org Message-ID: <20050331110254.GA340@pm514-9.comsys.ntu-kpi.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on comsys.ntu-kpi.kiev.ua X-Virus-Scanned: ClamAV 0.82/791/Sun Mar 27 00:26:49 2005 on comsys.ntu-kpi.kiev.ua X-Virus-Status: Clean Subject: Comments about vm_fault, vm_map_lookup and user-wired memory, part 1 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: Thu, 31 Mar 2005 11:03:30 -0000 Greetings, I have two questions or comments about of user-wired memory (system 5.3). First question. If memory is user-wired, read-only and COW, then it is impossible to change protection for this memory: 1. mprotect() calls vm_map_protect(), which change entry->protection to writeable. 2. When write page fault occurs for this memory, vm_fault() calls vm_map_lookup(), which notices that entry->protection allows write to this memory (first if() statement in vm_map_lookup()), but, then it does not allow write page fault, since flag VM_PROT_OVERRIDE_WRITE is not set, since this is a normal page fault from a process. As the result, we have KERN_PROTECTION_FAILURE. From the other side, if this user-wired (now read-write after mprotect() call) and COW memory is modified by debugger, which uses VM_PROT_OVERRIDE_WRITE or'ed with VM_PROT_WRITE, then vm_map_lookup() creates shadow object, which shadows original memory and new page is created in the new shadow object. Since vm_fault() was called without any *WIRE* bit, then new page in the shadow object becomes unwired. Then when process which has user-wired memory exits, vm_map_unwire() is called for a page in that shadow object, since its vm_entry has wired_count greater than 0, since new page for the shadow object was not wired we get panic from vm_page_unwire(), since vm_map_delete() -> vm_map_entry_unwire() -> vm_fault_unwire() does not expect to see shadow objects for wired vm_entry When another process exits we get panic in vm_page_free() from vm_object_backing_scan(), when shadow object and original object in a process with user-wired memory are collapsed in vm_object_collapse(), since shadow object has copy of a page of user-wired page, vm_object_backing_scan() frees wired page. Here is my question: why it is not allowed to change protection of user- wired, r/o and COW memory? If it is not allowed to create shadow objects for wired memory for the same process, why they are created with the help from the debugger? Note, that such behavior causes panic, because some parts of the VM system are not aware of shadow object for objects with user-wired pages. Second question in the next letter. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 11:08:04 2005 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 F141716A4CE for ; Thu, 31 Mar 2005 11:08:04 +0000 (GMT) Received: from comsys.ntu-kpi.kiev.ua (comsys.ntu-kpi.kiev.ua [195.245.194.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A75843D2D for ; Thu, 31 Mar 2005 11:07:20 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from pm514-9.comsys.ntu-kpi.kiev.ua (pm514-9.comsys.ntu-kpi.kiev.ua [10.18.54.109]) (authenticated bits=0)j2VBB6iX059296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 31 Mar 2005 14:11:06 +0300 (EEST) Received: by pm514-9.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1000) id EF281371; Thu, 31 Mar 2005 14:06:54 +0300 (EEST) Date: Thu, 31 Mar 2005 14:06:54 +0300 From: Andrey Simonenko To: freebsd-hackers@freebsd.org Message-ID: <20050331110654.GB340@pm514-9.comsys.ntu-kpi.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on comsys.ntu-kpi.kiev.ua X-Virus-Scanned: ClamAV 0.82/791/Sun Mar 27 00:26:49 2005 on comsys.ntu-kpi.kiev.ua X-Virus-Status: Clean Subject: Comments about vm_fault, vm_map_lookup and user-wired memory, part 2 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: Thu, 31 Mar 2005 11:08:05 -0000 Greetings, Second question. Consider following code (listing is given at the end of this letter): mmap() anonymous private read-only memory, fork() and mlock() this memory only in one process. Here we have: COW, NEEDS_COPY, read-only memory in both processes, but in one process it is USER_WIRED. Both memories refer to the same vm_object. Let's modify one byte in USER_WIRED memory from the debugger, as the result both processes will get modification in own memories: 1. When debugger wants to modify something in a memory, it calls vm_fault() with VM_PROT_WRITE and VM_PROT_OVERRIDE_WRITE. 2. vm_fault() calls vm_map_lookup(). 3. Since VM_PROT_OVERRIDE_WITE is on, vm_map_lookup() takes entry->max_protection and finds out that VM_PROT_WRITE is Ok for this memory (first if() condition passes). Since flag VM_PROT_OVERRIDE_WRITE is on, we continue (second if() condition passes). Since fault is on wired memory, vm_map_lookup() drops fault_tipe to entry->protection, which has only VM_PROT_READ, since our memory is read-only. As the result, shadow object is not created. 4. Debugger calls uiomove_fromphys() and modifies memory in the object, shared by both processes, but mappings are MAP_PRIVATE. Here is my question: what is the idea of this code in vm_map_lookup(), I mean modification of fault_type: *wired = (entry->wired_count != 0); if (*wired) prot = fault_type = entry->protection; And the result question from both my questions. As I understand something is wrong here, at least I cannot find good explanation. Is it allowed to create shadow objects for user-wired memory? If yes, then should pages in a shared object, which shadow user-wired pages, be also user-wired? ----- if ( (addr = mmap((void *)0, 1, PROT_READ, MAP_ANON|MAP_PRIVATE, -1, 0)) == MAP_FAILED) err(1, "mmap"); printf("addr %p\n", addr); if (fork() == 0) for (;;) { printf("<%c>\n", *(char *)addr); sleep(1); } if (mlock(addr, 1) < 0) err(1, "mlock"); for (;;) { printf("[%c]\n", *(char *)addr); sleep(1); } From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 11:13:08 2005 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 C157A16A4CE for ; Thu, 31 Mar 2005 11:13:08 +0000 (GMT) Received: from web52703.mail.yahoo.com (web52703.mail.yahoo.com [206.190.39.154]) by mx1.FreeBSD.org (Postfix) with SMTP id 1C7DF43D49 for ; Thu, 31 Mar 2005 11:13:08 +0000 (GMT) (envelope-from kamalpr@yahoo.com) Received: (qmail 72835 invoked by uid 60001); 31 Mar 2005 11:13:07 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=feDtmhU6+irCyHJDL0m/7HuZ9gkt2dAunp/FdDvV4OGM/zQqLn9pARiWKvcN5BQNlZJd6emWEVxKHV81E1N4cIpCMwkZJ90TXhhOduQNNEDE7FlvYtsUOF4cVgickL+dbEmFmrkVFaEaHWLAf0kGkpN6Fb9Kg4aFcNYYp5XCHvY= ; Message-ID: <20050331111307.72833.qmail@web52703.mail.yahoo.com> Received: from [61.11.104.70] by web52703.mail.yahoo.com via HTTP; Thu, 31 Mar 2005 03:13:07 PST Date: Thu, 31 Mar 2005 03:13:07 -0800 (PST) From: "Kamal R. Prasad" To: hackers@freebsd.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: So, who makes this one run FreeBSD? ;-) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kamalp@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2005 11:13:08 -0000 --- Scott Long wrote: [snip] > > An MMU-less port of any BSD would be very > worthwhile, even if it > requires a radical divergence from the original > codebase. I was woudn''t it be rather inefficient (in the BEST case) -handling numerous memory contextx -1 per process? > hoping that such a treat would appear out of NetBSD, > but that doesn't > seem to be the case. > > Scott They have taken a conscious decision not to work in that direction -as it would screw up their overall s/w architecture in accomodating that port [if they do manage to get a non-mmu port ready]. regards -kamal > _______________________________________________ > 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" > ------------------------------------------------------------ Kamal R. Prasad UNIX systems consultant kamalp@acm.org In theory, there is no difference between theory and practice. In practice, there is:-). ------------------------------------------------------------ __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 11:16:28 2005 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 D941716A4CE for ; Thu, 31 Mar 2005 11:16:28 +0000 (GMT) Received: from dexter.zoopee.org (zoopee.org [192.117.108.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1EEC43D68 for ; Thu, 31 Mar 2005 11:16:27 +0000 (GMT) (envelope-from alsbergt@zoopee.org) Received: from alsbergt by dexter.zoopee.org with local (Exim 4.43) id 1DGxez-0003Xj-8j for freebsd-hackers@freebsd.org; Thu, 31 Mar 2005 13:16:25 +0200 Date: Thu, 31 Mar 2005 13:16:25 +0200 From: Tom Alsberg To: FreeBSD Hackers List Message-ID: <20050331111625.GA13338@zoopee.org> Mail-Followup-To: Tom Alsberg , FreeBSD Hackers List Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline X-Face: "5"j@Y1Peoz1; ftTv>\|['ox-csmV+:_RDNdi/2lSe2x?0:HVAeVW~ajwQ7RfDlcb^18eJ; t,O,s5-aNdU/DJ2E8h1s,..4}N9$27u`pWmH|; s!zlqqVwr9R^_ji=1\3}Z6gQBYyQ]{gd5-V8s^fYf{$V2*_&S>eA|SH@Y\hOVUjd[5eah{EO@gCr.ydSpJHJIU[QsH~bC?$C@O:SzF=CaUxp80-iknM(]q(W List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2005 11:16:29 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Perhaps this should go to -STABLE, I just couldn't be sure. We are trying out FreeBSD 5.4-PRERELEASE on diskless clients. I noticed one problem, being that when setting the LD_LIBRARY_PATH (or for that matter, LD_PRELOAD, and LD_LIBMAP_DISABLE) environment variables, nothing will run, as /libexec/ld-elf.so.1 complains: Cannot execute objects on / According to the sources, this was added in 5.4, and will happen if / is mounted noexec. In this case, / is mounted by the BTX PXE loader over NFS (from a FreeBSD 5.3 server, right now). "mount" does not show the noexec flag. However, with the attached little C program I verified that statfs really returns this flag (0x00000006). Now, I see that on FreeBSD 5.3 diskless clients this flag is also returned on / - just it happened that nobody looked at it until the change in rtld.c of FreeBSD 5.4: if (fs.f_flags & MNT_NOEXEC) { _rtld_error("Cannot execute objects on %s\n", fs.f_mntonname); close(fd); return NULL; } I didn't yet understand (didn't check much) - why does statfs report the MNT_NOEXEC flag on the / filesystem (and only the / filesystem, when it's mounted from NFS by the bootloader - not any other NFS filesystems)? BTW, this happens also with NetApp as the NFS server - just to rule out any possibility of relation here. Ideas appreciated, -- Tom -- Tom Alsberg - certified insane, complete illiterate. Homepage: http://www.cs.huji.ac.il/~alsbergt/ * An idea is not responsible for the people who believe in it. --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="fstatfs.c" #include #include #include #include int main(int argc, char *argv[]) { if (argc != 2) { fprintf(stderr, "invalid number of arguments"); return -1; } struct statfs stbuf; if (statfs(argv[1], &stbuf) != 0) { perror("fstatfs"); return -1; } printf("FLAGS: 0x%08X\n", stbuf.f_flags); if (stbuf.f_flags & MNT_NOEXEC) printf("MNT_NOEXEC\n"); return 0; } --OXfL5xGRrasGEqWY-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 11:17:25 2005 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 E3F1316A4CE for ; Thu, 31 Mar 2005 11:17:25 +0000 (GMT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B58043D46 for ; Thu, 31 Mar 2005 11:17:25 +0000 (GMT) SRS0+4645612789ec337a2d11+585+infradead.org+hch@pentafluge.srs.infradead.org) Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DGxft-0003tS-GK; Thu, 31 Mar 2005 12:17:21 +0100 Date: Thu, 31 Mar 2005 12:17:21 +0100 From: Christoph Hellwig To: ticso@cicely.de Message-ID: <20050331111721.GA14949@infradead.org> References: <20050331014311.GA96606@freebie.xs4all.nl> <20050331103614.GL33677@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050331103614.GL33677@cicely12.cicely.de> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html cc: Wilko Bulte cc: freebsd-hackers@freebsd.org Subject: Re: So, who makes this one run 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: Thu, 31 Mar 2005 11:17:26 -0000 On Thu, Mar 31, 2005 at 12:36:15PM +0200, Bernd Walter wrote: > Note that they are not based on Linux, but on uCLinux, which is > something different. Not really. It's just a linux kernel compiled without support for MMUs. Which compiles out most of the linux VM code and adds some smart stubs instead. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 11:26:23 2005 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 8EAFD16A4CE for ; Thu, 31 Mar 2005 11:26:23 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id B917343D48 for ; Thu, 31 Mar 2005 11:26:22 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0)j2VBQGsf038268 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 31 Mar 2005 13:26:17 +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 j2VBPlhs012445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Mar 2005 13:25:47 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j2VBPkmK002358; Thu, 31 Mar 2005 13:25:46 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j2VBPj3x002357; Thu, 31 Mar 2005 13:25:45 +0200 (CEST) (envelope-from ticso) Date: Thu, 31 Mar 2005 13:25:45 +0200 From: Bernd Walter To: kamalp@acm.org Message-ID: <20050331112545.GB2072@cicely12.cicely.de> References: <20050331111307.72833.qmail@web52703.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050331111307.72833.qmail@web52703.mail.yahoo.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-1.5 required=3.0 tests=BAYES_01 autolearn=no version=2.64 X-Spam-Report: * -1.5 BAYES_01 BODY: Bayesian spam probability is 1 to 10% * [score: 0.0767] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de cc: hackers@freebsd.org Subject: Re: So, who makes this one run FreeBSD? ;-) 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: Thu, 31 Mar 2005 11:26:23 -0000 On Thu, Mar 31, 2005 at 03:13:07AM -0800, Kamal R. Prasad wrote: > > --- Scott Long wrote: > [snip] > > > > An MMU-less port of any BSD would be very > > worthwhile, even if it > > requires a radical divergence from the original > > codebase. I was > > woudn''t it be rather inefficient (in the BEST case) > -handling numerous memory contextx -1 per process? > > > hoping that such a treat would appear out of NetBSD, > > but that doesn't > > seem to be the case. > > > > Scott > > They have taken a conscious decision not to work in > that direction -as it would screw up their overall s/w > architecture in accomodating that port [if they do > manage to get a non-mmu port ready]. There is no doubt that this would be better as a complete split off. It is even the question if you want to start by using an established BSD or start from zero and import. However - I see limited use from this. The low end doesn't need posix API, process management and runs with very simple hardware. E.g. you can get ARMv7 CPUs with internal RAM of up to 64k and I already run control systems with Ethernet and Webinterface on a 32K RAM 8 bit CPU - the memory is mostly populated by TCP buffers. If you want more then you need at least external RAM - prices get higher and finally your price is very close to ARMv9 and even smaller x86 Systems. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 11:55:27 2005 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 2F05D16A4CE for ; Thu, 31 Mar 2005 11:55:27 +0000 (GMT) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17F6C43D1D for ; Thu, 31 Mar 2005 11:55:26 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=ganbold.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.43 (FreeBSD)) id 1DGyR3-0002CK-6Q for freebsd-hackers@FreeBSD.org; Thu, 31 Mar 2005 21:06:06 +0900 Message-Id: <6.2.0.14.2.20050331203318.031f2050@202.179.0.80> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 31 Mar 2005 20:53:12 +0900 To: freebsd-hackers@FreeBSD.org From: Ganbold Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: subtracting days from localtime problem 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: Thu, 31 Mar 2005 11:55:27 -0000 Hi hackers, I have problem subtracting days from current date using test program. We have daylight saving occured on 2AM of March 26, 2005. As you can see below, there is missing March 26th line from program output. And all lines after 27th March are wrong. Instead of 25th March it should be 26th March, 24th March should be 25th March and so on. Can somebody tell me why is this happening? How can I correct this problem? thanks in advance, Ganbold Here is system info: # uname -an FreeBSD backend.ub.mng.net 4.11-PRERELEASE FreeBSD 4.11-PRERELEASE #4: Tue Dec 14 18:18:34 ULAT 2004 tsgan@backend.ub.mng.net:/usr/obj/usr/src/sys/DB i386 # env | grep TZ TZ=Asia/Ulaanbaatar # date Thu Mar 31 20:45:14 ULAST 2005 Here is program output: # ./test_date Thu Mar 31 20:36:47 2005 Current Date: 2005-03-31 0 day(s) before current Date: 2005-03-31 1 day(s) before current Date: 2005-03-30 2 day(s) before current Date: 2005-03-29 3 day(s) before current Date: 2005-03-28 4 day(s) before current Date: 2005-03-27 5 day(s) before current Date: 2005-03-25 6 day(s) before current Date: 2005-03-24 7 day(s) before current Date: 2005-03-23 8 day(s) before current Date: 2005-03-22 9 day(s) before current Date: 2005-03-21 10 day(s) before current Date: 2005-03-20 11 day(s) before current Date: 2005-03-19 12 day(s) before current Date: 2005-03-18 13 day(s) before current Date: 2005-03-17 14 day(s) before current Date: 2005-03-16 15 day(s) before current Date: 2005-03-15 16 day(s) before current Date: 2005-03-14 17 day(s) before current Date: 2005-03-13 18 day(s) before current Date: 2005-03-12 19 day(s) before current Date: 2005-03-11 20 day(s) before current Date: 2005-03-10 21 day(s) before current Date: 2005-03-09 22 day(s) before current Date: 2005-03-08 23 day(s) before current Date: 2005-03-07 24 day(s) before current Date: 2005-03-06 25 day(s) before current Date: 2005-03-05 26 day(s) before current Date: 2005-03-04 27 day(s) before current Date: 2005-03-03 28 day(s) before current Date: 2005-03-02 29 day(s) before current Date: 2005-03-01 30 day(s) before current Date: 2005-02-28 31 day(s) before current Date: 2005-02-27 Total run time = 0 sec # Here is test program. test_date.c ------------------------------------------------------------------------------------------ #include #include #include #include #include #include char *getDate(int day); char *my_alloc(char *strin); int main(int argc, char *argv[]){ time_t now; int start_day = 1; struct timeval t1; struct timeval t2; char *m_date, *cur_date; int i; long d; gettimeofday(&t1,NULL); now = time(NULL); fprintf(stderr, "%s\n",ctime(&now)); start_day = 32; cur_date = getDate(0); for(i=0;itm_mday -= day; t->tm_hour = t->tm_min = t->tm_sec = 0; p = mktime(t); if (p == (time_t)-1) printf ("mktime failed\n"); snprintf (date,11,"%d-%.2d-%.2d", t->tm_year + 1900, t->tm_mon + 1, t->tm_mday); if((localdate=my_alloc(date))==NULL){ fprintf(stderr, "Allocation error!\n"); exit(2); } printf("Date: %s\n",localdate); return localdate; } /*---------------------------------------------------------------------------------------------------------------------*/ char *my_alloc(char *strin) { int len; char *p; len = strlen (strin) + 1; p = (char *)malloc(len); if (p != NULL) { strcpy (p, strin); } return (p); } From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 12:20:19 2005 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 451DA16A4CF; Thu, 31 Mar 2005 12:20:19 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id DED0A43D45; Thu, 31 Mar 2005 12:20:18 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j2VCKDQF011143; Thu, 31 Mar 2005 07:20:13 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j2VCKDO6011142; Thu, 31 Mar 2005 07:20:13 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Thu, 31 Mar 2005 07:20:13 -0500 From: David Schultz To: David Leimbach Message-ID: <20050331122013.GA11100@VARK.MIT.EDU> Mail-Followup-To: David Leimbach , babkin@FreeBSD.ORG, mohamed aslan , FreeBSD Hackers References: <319cceca0503281001792baf39@mail.gmail.com> <42485A54.9000101@freebsdbrasil.com.br> <319cceca05032811484cb1a95b@mail.gmail.com> <42487982.30909@freebsdbrasil.com.br> <319cceca05032907411014a218@mail.gmail.com> <424B6137.15A5940A@verizon.net> <5bbfe7d405033018504af3140d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5bbfe7d405033018504af3140d@mail.gmail.com> cc: mohamed aslan cc: babkin@FreeBSD.ORG cc: FreeBSD Hackers Subject: Re: organization 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: Thu, 31 Mar 2005 12:20:19 -0000 On Wed, Mar 30, 2005, David Leimbach wrote: > > Yes, procfs rules! > > Procfs is from linux? > > I thought it was from Plan 9... along with rfork :). Nope. It was first implemented by Sun's Roger Faulkner in SVR4, well before Linux or Plan 9 existed. Actually, someone wrote a prototype for Unix years earlier than raf, but I don't remember who. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 12:25:05 2005 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 8A2D616A4CE; Thu, 31 Mar 2005 12:25:05 +0000 (GMT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id F061843D48; Thu, 31 Mar 2005 12:25:04 +0000 (GMT) SRS0+4645612789ec337a2d11+585+infradead.org+hch@pentafluge.srs.infradead.org) Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DGyjP-000493-L8; Thu, 31 Mar 2005 13:25:03 +0100 Date: Thu, 31 Mar 2005 13:25:03 +0100 From: Christoph Hellwig To: David Leimbach , babkin@FreeBSD.ORG, mohamed aslan , FreeBSD Hackers Message-ID: <20050331122503.GA15904@infradead.org> References: <319cceca0503281001792baf39@mail.gmail.com> <42485A54.9000101@freebsdbrasil.com.br> <319cceca05032811484cb1a95b@mail.gmail.com> <42487982.30909@freebsdbrasil.com.br> <319cceca05032907411014a218@mail.gmail.com> <424B6137.15A5940A@verizon.net> <5bbfe7d405033018504af3140d@mail.gmail.com> <20050331122013.GA11100@VARK.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050331122013.GA11100@VARK.MIT.EDU> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Subject: Re: organization 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: Thu, 31 Mar 2005 12:25:05 -0000 On Thu, Mar 31, 2005 at 07:20:13AM -0500, David Schultz wrote: > On Wed, Mar 30, 2005, David Leimbach wrote: > > > Yes, procfs rules! > > > > Procfs is from linux? > > > > I thought it was from Plan 9... along with rfork :). > > Nope. It was first implemented by Sun's Roger Faulkner in SVR4, > well before Linux or Plan 9 existed. Actually, someone wrote a > prototype for Unix years earlier than raf, but I don't remember > who. procfs comes from v8 (research) unix, a direct predecessor of Plan 9, way before SVR4. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 12:36:08 2005 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 CC36D16A4CE for ; Thu, 31 Mar 2005 12:36:08 +0000 (GMT) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9922743D49 for ; Thu, 31 Mar 2005 12:36:07 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j2VCa6Ae036838 for ; Thu, 31 Mar 2005 06:36:06 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <424BEE9B.4020004@centtech.com> Date: Thu, 31 Mar 2005 06:35:39 -0600 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050325 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: burndvd instead of growisofs? 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: Thu, 31 Mar 2005 12:36:08 -0000 Is anyone working on a 'burndvd'? I have to use growisofs to burn dvd's in FreeBSD, which means I need a port, so the base system doesn't burn dvd's. It's no crisis, but wouldn't it be nice if FreeBSD could burn dvd's without a port, without atapicam, etc? Anyway, I guess this goes in the feature request bucket. I'm no coder or else I'd send source code instead of this email, but I do have several DVD burners at my disposal for testing. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 19:56:29 2005 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 C3ECD16A4CE for ; Wed, 30 Mar 2005 19:56:29 +0000 (GMT) Received: from skutsje.san.webweaving.org (skutsje.san.webweaving.org [209.132.96.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id F04B043D2D for ; Wed, 30 Mar 2005 19:56:22 +0000 (GMT) (envelope-from dirkx@webweaving.org) Received: from skutsje.san.webweaving.org (skutsje.san.webweaving.org [209.132.96.45] (may be forged))j2UJuMLA077322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Mar 2005 11:56:22 -0800 (PST) (envelope-from dirkx@webweaving.org) Received: from localhost (dirkx@localhost)j2UJuM8J077319; Wed, 30 Mar 2005 11:56:22 -0800 (PST) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: skutsje.san.webweaving.org: dirkx owned process doing -bs Date: Wed, 30 Mar 2005 11:56:22 -0800 (PST) From: Dirk-Willem van Gulik X-X-Sender: dirkx@skutsje.san.webweaving.org To: zean zean In-Reply-To: Message-ID: <20050330115132.N76928@skutsje.san.webweaving.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Thu, 31 Mar 2005 12:46:40 +0000 cc: freebsd-hackers@freebsd.org Subject: Re: the best form to wait the finish of execution of a child... 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, 30 Mar 2005 19:56:29 -0000 On Wed, 30 Mar 2005, zean zean wrote: > while(childpid != wait(&status)) > Any aid to obtain the best way is very welcome. If you are waiting for a specific child temrimatingin see 'waitpid(); (or wait4() - "man wait4") -- that safes you the while() loop. It allows you to listen for just the child you want. If you just want to -know- if a child dies but simply allow your program to continue then install a signal handler on SIGCHLD. The best book I personally found is to get is "Advanced Programming in the UNIX Environment" by Richard Stevens. Dw From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 07:18:13 2005 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 A07DF16A4CE; Thu, 31 Mar 2005 07:18:13 +0000 (GMT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBA8043D46; Thu, 31 Mar 2005 07:18:12 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])j2V7I7A6011750; Thu, 31 Mar 2005 17:18:07 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j2V7I3Mq020502; Thu, 31 Mar 2005 17:18:04 +1000 Date: Thu, 31 Mar 2005 17:17:58 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: David Schultz In-Reply-To: <20050330130051.GA4416@VARK.MIT.EDU> Message-ID: <20050331155418.F20400@delplex.bde.org> References: <423C15C5.6040902@fsn.hu> <20050327133059.3d68a78c@Magellan.Leidinger.net> <20050327162839.2fafa6aa@Magellan.Leidinger.net> <5bbfe7d405032823232103d537@mail.gmail.com> <424A23A8.5040109@ec.rr.com><20050330130051.GA4416@VARK.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Thu, 31 Mar 2005 12:46:40 +0000 cc: Peter Jeremy cc: hackers@freebsd.org cc: jason henson cc: bde@freebsd.org Subject: Re: Fwd: 5-STABLE kernel build with icc broken 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: Thu, 31 Mar 2005 07:18:13 -0000 On Wed, 30 Mar 2005, David Schultz wrote: > On Wed, Mar 30, 2005, Peter Jeremy wrote: >> On Tue, 2005-Mar-29 22:57:28 -0500, jason henson wrote: >>> Later in that thread they discuss skipping the restore state to make >>> things faster. The minimum buffer size they say this will be good for >>> is between 2-4k. Does this make sense, or am I showing my ignorance? >>> >>> http://leaf.dragonflybsd.org/mailarchive/kernel/2004-04/msg00264.html >> >> Yes. There are a variety of options for saving/restoring FPU state: >> a) save FPU state on kernel entry >> b) save FPU state on a context switch (or if the kernel wants the FPU) >> c) only save FPU state if a different process (or the kernel) wants the FPU >> 1) restore FPU on kernel exit >> 2) restore FPU state if a process wants the FPU. >> >> a and 1 are the most obvious - that's the way the integer registers are >> handled. >> >> I thought FreeBSD used to be c2 but it seems it has been changed to b2 >> since I looked last. No, it always used b2. I never got around to implementing c2. Linux used to implement c2 on i386's, but I think it switched (to b2?) to optimize (or at least simplify) the SMP case. >> Based on the mail above, it looks like Dfly was changed from 1 to 2 >> (I'm not sure if it's 'a' or 'c' on save). 'a' seems to be too inefficient to ever use. '1' makes sense if it rarely happens and/or the kernel can often use the FPU more than once per entry (which it probably shouldn't), but it gives complications like the ones for SMP, especially in FreeBSD where the kernel can be preempted. Saving FP state as needed is simplest but can be slow. My Athlon-with- SSE-extensions pagecopy and pagezero routines use the FPU (XMM) but their FP state save isn't slow because only 1 or 2 XMM registers needs to be saved. E.g., the saving part of sse_pagezero_for_some_athlons() is: pushfl # Also have to save %eflags. cli # Switch %eflags as needed to safely use FPU. movl %cr0,%eax # Also have to save %cr0. clts # Switch %cr0 as needed to use FPU. subl $16,%esp # Space to save some FP state. movups %xmm0,(%esp) # Save some FP state. Only this much needed. >> On the i386 (and probably most other CPUs), you can place the FPU into >> am "unavailable" state. This means that any attempt to use it will >> trigger a trap. The kernel will then restore FPU state and return. >> On a normal system call, if the FPU hasn't been used, the kernel will >> see that it's still in an "unavailable" state and can avoid saving the >> state. (On an i386, "unavailable" state is achieved by either setting >> CR0_TS or CR0_EM). This means you avoid having to always restore FPU >> state at the expense of an additional trap if the process actually >> uses the FPU. I remember that you (Peter) did extensive benchmarks of this. I still think fully lazy switching (c2) is the best general method. Maybe FP state should be loaded in advance based on FPU affinity. It might be good for CPU affinity to depend on FPU use (prfer not to switch threads away from a CPU if they own that CPU via its FPU). > This is basically what FreeBSD does on i386 and amd64. (As a > disclaimer, I haven't read the code very carefully, so I might be > missing some of the details.) Upon taking a trap for a process > that has never used the FPU before, we save the FPU state for the > last process to use the FPU, then load a fresh FPU state. On We don't save the FPU state for the last thread then (c2 behaviour) since we have already saved it it when we switched away from it. npxdna() panics if we haven't done that. Except rev.1.131 added bogus code (apparently to debug or hide bugs in the other changes in rev.1.131) that breaks the panic in the fpcurthread == curthread case. > subsequent context switches, the FPU state for processes that have > already used the FPU gets loaded before entering user mode, I > think. I haven't studied the code in enough detail to know what No, that doesn't happen. Instead, cpu_switch() has called npxsave() on the context switch away from the thread. npxsave() arranges for a trap on the next use of the FPU, and we don't do anything more with the FPU context of the thread until the thread tries to use the FPU (in userland). Then we take the trap and load the saved context in npxdna(). > happens for SMP, where a process could be scheduled on a different > processor before its FPU state is saved on the first processor. There is no difference for SMP, but there would be large complicated differences if we did fully lazy saving. npxdna() would have to do something like sending an IPI to the thread that owns the FPU if that thread could be different from curthread. This would be slow, but might be worth doing if it didn't happen much and if lazy fully lazy context switching were a significant advantage. I think it could be arranged to not happen much, but the advantage is insignificant. BTW, David and I recently found a bug in the context switching in the fxsr case, at least on Athlon-XP's and AMD64's. At least the AMD64 is documented to not save/restore the last instruction pointers and opcode in fxsave/fxrstor unless the processor considers save/restore to be necessary (which is if there is an unmasked exception). But this behaviour is inconsistent with what is needed for actually saving and restoring the FP state on context switches. The bug can be seen in gdb -- the pointers and opcode tend to be always 0, but sometimes there is an unmasked exception and then the pointers sometimes get set correctly for the thread that caused the exception, and they get set to different garbage than 0 for other threads. The garbage is more obvious when it is read using fnstenv or fsave directly in userland. These instructions are not optimized like fxsave, so they show the actual pointers and opcode. Since context switches rarely actually switch the pointers and opcode, the actual values tend to be wrong after context switches. Bruce From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 11:40:56 2005 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 0924C16A4FA; Thu, 31 Mar 2005 11:40:56 +0000 (GMT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55FD043D60; Thu, 31 Mar 2005 11:40:55 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])j2VBemA6010844; Thu, 31 Mar 2005 21:40:48 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) j2VBekMq021730; Thu, 31 Mar 2005 21:40:47 +1000 Date: Thu, 31 Mar 2005 21:40:40 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Peter Jeremy In-Reply-To: <20050331104635.GH71384@cirb503493.alcatel.com.au> Message-ID: <20050331210931.S2670@epsplex.bde.org> References: <20050327133059.3d68a78c@Magellan.Leidinger.net> <20050327162839.2fafa6aa@Magellan.Leidinger.net> <5bbfe7d405032823232103d537@mail.gmail.com> <424A23A8.5040109@ec.rr.com><20050330130051.GA4416@VARK.MIT.EDU> <20050331104635.GH71384@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Thu, 31 Mar 2005 12:46:40 +0000 cc: David Schultz cc: hackers@freebsd.org cc: jason henson cc: bde@freebsd.org Subject: Re: Fwd: 5-STABLE kernel build with icc broken 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: Thu, 31 Mar 2005 11:40:56 -0000 On Thu, 31 Mar 2005, Peter Jeremy wrote: > On Thu, 2005-Mar-31 17:17:58 +1000, Bruce Evans wrote: >> I still >> think fully lazy switching (c2) is the best general method. > > I think it depends on the FP workload. It's a definite win if there > is exactly one FP thread - in this case the FPU state never needs to > be saved (and you could even optimise away the DNA trap by clearing > the TS and EM bits if the switched-to curthread is fputhread). I think stopping the trap would be the usual method (not sure what Linux did), but to collect statistics for determining affinity you would want to take the trap anyway. > The worst case is two (or more) FP-intensive threads - in this case, > lazy switching is of no benefit. The DNA trap overheads mean that > the performance is worse than just saving/restoring the FP state > during a context switch. > > My guess is that the current generation workstation is closer to the > second case - current generation graphical bloatware uses a lot of > FP for rendering, not to mention that the idle task has a reasonable > chance of being an FP-intensive distributed computing task (setiathome > or similar). It's probably time to do some more measuring (I'm not > offering just now, I have lots of other things on my TODO list). Bloatware might be so hoggish that it rarely makes context switches :-). Context switches for interrupts increase the problem though, as would using FP more in the kernel. >> BTW, David and I recently found a bug in the context switching in the >> fxsr case, at least on Athlon-XP's and AMD64's. > > I gather this is not noticable unless the application is doing its > own FPU save/restore. Is there a solution or work-around? It's most noticeable for debugging, and if you worry about leaking thread context. Fortunately, the last-instruction pointers won't have real user data in them unless the application encodes it there intentionally. I can't see any efficent solution or workaround. The kernel should do a full save/restore for processes being debugged. For applications, the bug seems to be larger. Even if they know about the amd behaviour and do a full save/restore because they need it, it won't work because the kernel doesn't preserve the state across context switches. Applications like vmware might care more than most. I forgot to mention that we couldn't find anything in intel manuals about this behaviour, so it might be completely amd-specific. Also, the instruction pointers are fundamentally broken for 64-bit CPUs, since although they are 64 bits, they have the segment selector encoded in their top 32 bits, so they are not really different from the 32:32 selector:pointer format for the non-fxsr case. Their format is specified by SSE2 so 64-bit extensions would have to be elsewhere, but amd64 doesn't seem to extend them. Bruce From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 12:51:39 2005 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 A472816A4CE for ; Thu, 31 Mar 2005 12:51:39 +0000 (GMT) Received: from mail21.sea5.speakeasy.net (mail21.sea5.speakeasy.net [69.17.117.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B52F43D54 for ; Thu, 31 Mar 2005 12:51:39 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 9930 invoked from network); 31 Mar 2005 12:51:38 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 31 Mar 2005 12:51:36 -0000 Received: from [192.168.0.15] (osx.baldwin.cx [192.168.0.15]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j2VCpQGJ024411; Thu, 31 Mar 2005 07:51:26 -0500 (EST) (envelope-from jhb@FreeBSD.org) In-Reply-To: <424B7A2D.5060902@alphaque.com> References: <42334057.5070705@gmx.net> <42492F0B.3040704@alphaque.com> <424B7A2D.5060902@alphaque.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Baldwin Date: Thu, 31 Mar 2005 07:51:25 -0500 To: Dinesh Nair X-Mailer: Apple Mail (2.619.2) X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: freebsd-hackers@FreeBSD.org cc: freebsd-acpi@FreeBSD.org Subject: Re: enable acpi 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: Thu, 31 Mar 2005 12:51:39 -0000 On Mar 30, 2005, at 11:18 PM, Dinesh Nair wrote: > > acpi related, but on freebsd 4.11 (cvsupped and built on 24 march). > > i've compiled with device acpica in the kernel, but i get sporadic page > faults as attached. > > i do know that acpica is experimental and that LINT does warn of kernel > panics and machine hangs. however i was wondering if anyone has got > this > working succesfully on any machine. The problem is that the taskqueue_swi in 4.x doesn't have a thread context that can be slept on via tsleep(). The fix would be to create a kthread in which to run the ACPI tasks. 4.x already has one such kthread for the taskqueue_thread taskqueue that you could use as a reference if you wish to do this yourself. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 13:12:42 2005 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 6F47B16A4CE for ; Thu, 31 Mar 2005 13:12:42 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8A5B43D45 for ; Thu, 31 Mar 2005 13:12:41 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id j2VDCQRD049051; Thu, 31 Mar 2005 15:12:28 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <424BF6E3.4060801@DeepCore.dk> Date: Thu, 31 Mar 2005 15:10:59 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anderson References: <424BEE9B.4020004@centtech.com> In-Reply-To: <424BEE9B.4020004@centtech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.7 cc: freebsd-hackers@freebsd.org Subject: Re: burndvd instead of growisofs? 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: Thu, 31 Mar 2005 13:12:42 -0000 Eric Anderson wrote: > Is anyone working on a 'burndvd'? I have to use growisofs to burn=20 > dvd's in FreeBSD, which means I need a port, so the base system doesn't= =20 > burn dvd's. It's no crisis, but wouldn't it be nice if FreeBSD could=20 > burn dvd's without a port, without atapicam, etc? >=20 >=20 > Anyway, I guess this goes in the feature request bucket. I'm no coder = > or else I'd send source code instead of this email, but I do have=20 > several DVD burners at my disposal for testing. I have it on my TODO list to add DVD support to burncd, but so far I=20 havn't gotten down to it :) --=20 -S=F8ren From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 13:15:37 2005 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 5ADE816A4CE; Thu, 31 Mar 2005 13:15:37 +0000 (GMT) Received: from melusine.cuivre.fr.eu.org (melusine.cuivre.fr.eu.org [82.225.155.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81D8743D62; Thu, 31 Mar 2005 13:15:36 +0000 (GMT) (envelope-from thomas@FreeBSD.ORG) Received: by melusine.cuivre.fr.eu.org (Postfix, from userid 1000) id B38A62C3D3; Thu, 31 Mar 2005 15:15:30 +0200 (CEST) Date: Thu, 31 Mar 2005 15:15:30 +0200 From: Thomas Quinot To: Scott Long Message-ID: <20050331131530.GC98903@melusine.cuivre.fr.eu.org> References: <424BCDAA.40604@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <424BCDAA.40604@samsco.org> X-message-flag: WARNING! Using Outlook can damage your computer. User-Agent: Mutt/1.5.8i cc: hackers@freebsd.org cc: sos@freebsd.org Subject: Re: ATAPICAM for ATA-MKIII 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: Thu, 31 Mar 2005 13:15:37 -0000 * Scott Long, 2005-03-31 : > Attached are patches for atapicam for ATA-MKIII. I've only done light > testing, but they seem to work as expected. They work both as a module > and compiled into the kernel. Thanks Scott, this is immensely helpful. I'll try to test and commit that this weekend. Thomas. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 13:16:19 2005 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 6B23616A4CE for ; Thu, 31 Mar 2005 13:16:19 +0000 (GMT) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED5EE43D46 for ; Thu, 31 Mar 2005 13:16:18 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j2VDGDZH037116; Thu, 31 Mar 2005 07:16:13 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <424BF802.1080406@centtech.com> Date: Thu, 31 Mar 2005 07:15:46 -0600 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050325 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-15?Q?S=F8ren_Schmidt?= References: <424BEE9B.4020004@centtech.com> <424BF6E3.4060801@DeepCore.dk> In-Reply-To: <424BF6E3.4060801@DeepCore.dk> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit cc: freebsd-hackers@freebsd.org Subject: Re: burndvd instead of growisofs? 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: Thu, 31 Mar 2005 13:16:19 -0000 Søren Schmidt wrote: > Eric Anderson wrote: > >> Is anyone working on a 'burndvd'? I have to use growisofs to burn >> dvd's in FreeBSD, which means I need a port, so the base system >> doesn't burn dvd's. It's no crisis, but wouldn't it be nice if >> FreeBSD could burn dvd's without a port, without atapicam, etc? >> >> >> Anyway, I guess this goes in the feature request bucket. I'm no coder >> or else I'd send source code instead of this email, but I do have >> several DVD burners at my disposal for testing. > > > I have it on my TODO list to add DVD support to burncd, but so far I > havn't gotten down to it :) Ok, cool! Well, let me know if there's anything I can do to help. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 13:16:48 2005 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 C0A9716A4CE; Thu, 31 Mar 2005 13:16:48 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 616B643D4C; Thu, 31 Mar 2005 13:16:48 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j2VDGg7m011441; Thu, 31 Mar 2005 08:16:42 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j2VDGghe011440; Thu, 31 Mar 2005 08:16:42 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Thu, 31 Mar 2005 08:16:42 -0500 From: David Schultz To: Christoph Hellwig Message-ID: <20050331131642.GA11383@VARK.MIT.EDU> Mail-Followup-To: Christoph Hellwig , David Leimbach , babkin@FreeBSD.ORG, mohamed aslan , FreeBSD Hackers References: <319cceca0503281001792baf39@mail.gmail.com> <42485A54.9000101@freebsdbrasil.com.br> <319cceca05032811484cb1a95b@mail.gmail.com> <42487982.30909@freebsdbrasil.com.br> <319cceca05032907411014a218@mail.gmail.com> <424B6137.15A5940A@verizon.net> <5bbfe7d405033018504af3140d@mail.gmail.com> <20050331122013.GA11100@VARK.MIT.EDU> <20050331122503.GA15904@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050331122503.GA15904@infradead.org> cc: mohamed aslan cc: David Leimbach cc: babkin@FreeBSD.ORG cc: FreeBSD Hackers Subject: Re: organization 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: Thu, 31 Mar 2005 13:16:48 -0000 On Thu, Mar 31, 2005, Christoph Hellwig wrote: > On Thu, Mar 31, 2005 at 07:20:13AM -0500, David Schultz wrote: > > On Wed, Mar 30, 2005, David Leimbach wrote: > > > > Yes, procfs rules! > > > > > > Procfs is from linux? > > > > > > I thought it was from Plan 9... along with rfork :). > > > > Nope. It was first implemented by Sun's Roger Faulkner in SVR4, > > well before Linux or Plan 9 existed. Actually, someone wrote a > > prototype for Unix years earlier than raf, but I don't remember > > who. > > procfs comes from v8 (research) unix, a direct predecessor of Plan 9, > way before SVR4. That's the prototype I was talking about, but I believe it was not an official part of version 8 (to the extent that anything was). It certainly never made it to System V. Do you recall who wrote the prototype? From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 13:48:12 2005 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 3CA8A16A4CE for ; Thu, 31 Mar 2005 13:48:12 +0000 (GMT) Received: from comsys.ntu-kpi.kiev.ua (comsys.ntu-kpi.kiev.ua [195.245.194.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F5DF43D66 for ; Thu, 31 Mar 2005 13:48:06 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from pm514-9.comsys.ntu-kpi.kiev.ua (pm514-9.comsys.ntu-kpi.kiev.ua [10.18.54.109]) (authenticated bits=0)j2VDpsiX060502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Mar 2005 16:51:55 +0300 (EEST) Received: by pm514-9.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1000) id 17D48B4; Thu, 31 Mar 2005 16:47:43 +0300 (EEST) Date: Thu, 31 Mar 2005 16:47:42 +0300 From: Andrey Simonenko To: Ganbold Message-ID: <20050331134742.GA600@pm514-9.comsys.ntu-kpi.kiev.ua> References: <6.2.0.14.2.20050331203318.031f2050@202.179.0.80> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.0.14.2.20050331203318.031f2050@202.179.0.80> User-Agent: Mutt/1.4.2.1i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on comsys.ntu-kpi.kiev.ua X-Virus-Scanned: ClamAV 0.82/791/Sun Mar 27 00:26:49 2005 on comsys.ntu-kpi.kiev.ua X-Virus-Status: Clean cc: freebsd-hackers@freebsd.org Subject: Re: subtracting days from localtime problem 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: Thu, 31 Mar 2005 13:48:12 -0000 On Thu, Mar 31, 2005 at 08:53:12PM +0900, Ganbold wrote: > I have problem subtracting days from current date using test program. > We have daylight saving occured on 2AM of March 26, 2005. > As you can see below, there is missing March 26th line from program output. > And all lines after 27th March are wrong. > Instead of 25th March it should be 26th March, 24th March should be 25th > March and so on. > > Can somebody tell me why is this happening? How can I correct this > problem? The problem is in tm_isdst field, which is 1, for current day March 31. You can see the problem in action, if you output not only date, but also time and tm_isdst for new date. To fix this problem set tm_isdst to -1 before mktime() function call, and again output date together with time and see difference. You can set tm_isdst to 0 and see the difference, and carefully read documentation for tm_isdst in SUSv3, for example. If you want to do such manipulations with time using standard library functions, then it will not be very easy, because of TZ changes, the problem you got is only one of many. ps: comp.unix.programmer would be a better place for such questions. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 13:49:49 2005 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 6B26C16A4CE; Thu, 31 Mar 2005 13:49:49 +0000 (GMT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC5CA43D39; Thu, 31 Mar 2005 13:49:48 +0000 (GMT) SRS0+4645612789ec337a2d11+585+infradead.org+hch@pentafluge.srs.infradead.org) Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DH03Q-0004VD-5u; Thu, 31 Mar 2005 14:49:48 +0100 Date: Thu, 31 Mar 2005 14:49:48 +0100 From: Christoph Hellwig To: Christoph Hellwig , David Leimbach , babkin@FreeBSD.ORG, mohamed aslan , FreeBSD Hackers Message-ID: <20050331134948.GA17104@infradead.org> References: <319cceca0503281001792baf39@mail.gmail.com> <42485A54.9000101@freebsdbrasil.com.br> <319cceca05032811484cb1a95b@mail.gmail.com> <42487982.30909@freebsdbrasil.com.br> <319cceca05032907411014a218@mail.gmail.com> <424B6137.15A5940A@verizon.net> <5bbfe7d405033018504af3140d@mail.gmail.com> <20050331122013.GA11100@VARK.MIT.EDU> <20050331122503.GA15904@infradead.org> <20050331131642.GA11383@VARK.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050331131642.GA11383@VARK.MIT.EDU> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Subject: Re: organization 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: Thu, 31 Mar 2005 13:49:49 -0000 On Thu, Mar 31, 2005 at 08:16:42AM -0500, David Schultz wrote: > > procfs comes from v8 (research) unix, a direct predecessor of Plan 9, > > way before SVR4. > > That's the prototype I was talking about, but I believe it was not > an official part of version 8 (to the extent that anything was). > It certainly never made it to System V. Do you recall who wrote the > prototype? Not sure I'd call V8 a prototype ;-) See: T. J. Killian, `Processes as Files' USENIX Summer Conference Proceedings, June 1984, Salt Lake City, UT, USA for the glory details From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 13:55:04 2005 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 045CA16A4CE for ; Thu, 31 Mar 2005 13:55:04 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DFD843D46 for ; Thu, 31 Mar 2005 13:55:03 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j2VDtCh3023957; Thu, 31 Mar 2005 05:55:14 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j2VDt6fo023956; Thu, 31 Mar 2005 05:55:06 -0800 (PST) (envelope-from www) Date: Thu, 31 Mar 2005 05:55:06 -0800 (PST) Message-Id: <200503311355.j2VDt6fo023956@marlena.vvi.at> To: ganbold@micom.mng.net From: "ALeine" cc: freebsd-hackers@freebsd.org Subject: Re: subtracting days from localtime problem 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: Thu, 31 Mar 2005 13:55:04 -0000 ganbold@micom.mng.net wrote: > I have problem subtracting days from current date using test > program. We have daylight saving occured on 2AM of March 26, 2005. > As you can see below, there is missing March 26th line from > program output. > > And all lines after 27th March are wrong. > Instead of 25th March it should be 26th March, 24th March should > be 25th March and so on. > > Can somebody tell me why is this happening? How can I correct > this problem? You should set the tm_isdst to -1 before making the call to mktime(3) in order to make mktime(3) try to figure out whether Daylight Savings Time is in effect or not. See man 3 mktime for details. So, your getDate() function should look something like this: char * getDate(int day) { struct tm *t; time_t now; char date[12]; char *localdate; time_t p; now = time(NULL); t = localtime(&now); t->tm_mday -= day; t->tm_hour = t->tm_min = t->tm_sec = 0; /* make mktime(3) figure out whether DST is in effect */ t->tm_isdst = -1; p = mktime(t); if (p == (time_t)-1) printf ("mktime failed\n"); snprintf(date,11,"%d-%.2d-%.2d", t->tm_year + 1900, t->tm_mon + 1, t->tm_mday); if ((localdate=my_alloc(date)) == NULL) { fprintf(stderr, "Allocation error!\n"); exit(2); } printf("Date: %s\n",localdate); return localdate; } ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 14:29:38 2005 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 797E916A4CE for ; Thu, 31 Mar 2005 14:29:38 +0000 (GMT) Received: from dutch10.digitalus.nl (dutch10.digitalus.nl [81.173.33.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7AF943D54 for ; Thu, 31 Mar 2005 14:29:37 +0000 (GMT) (envelope-from webmaster@shizukana.net) Received: from www.shizukana.net (localhost.localdomain [127.0.0.1]) by dutch10.digitalus.nl (8.12.10/8.12.10) with ESMTP id j2VETW0g014727 for ; Thu, 31 Mar 2005 16:29:32 +0200 Received: from 84.26.82.135 (SquirrelMail authenticated user webmaster@shizukana.net); by www.shizukana.net with HTTP; Thu, 31 Mar 2005 16:29:32 +0200 (CEST) Message-ID: <1301.84.26.82.135.1112279372.squirrel@84.26.82.135> Date: Thu, 31 Mar 2005 16:29:32 +0200 (CEST) From: "Nexohrion (JeanPaul) (Webmaster AT Shizukana.net)" To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: FreeBSD 5.3-CURRENT 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: Thu, 31 Mar 2005 14:29:38 -0000 Hi, I have a problem with a installation of FreeBSD 5.3-CURRENT I installed on my desktop without any problem. But now I want to install freebsd on my server When I want to do it thru ftp I have to configure it first, well i let him find the dhcp, and he gets the ip address of my dhcp (router) when I am installing it connects to the ftp server, He says he's looking up the hostname, Then he says he's logging in, and after 5 minutes he stops with an error: Couldn't open FTP connection to ftp3.freebsd.org User name okay, need password. and if i want to connect to a other ftp like ftp1.freebsd.org it says it can't reslove the dns. I have to reboot my system before I can re-use the network There is nothing wrong with the network settings because the settings are the same like my desktop (except the ip) I had windows 2003 Enterprise on it before, and had no problems with the network card it is an 3C905B-TX Fast Etherlink XL PCI and it's connected on the driver: xl: How can I fix this? regards, Nexohrion (JeanPaul) From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 16:41:07 2005 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 2E2EC16A4CE; Thu, 31 Mar 2005 16:41:07 +0000 (GMT) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1155143D55; Thu, 31 Mar 2005 16:41:06 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j2VGf4BB039151; Thu, 31 Mar 2005 10:41:04 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <424C2804.2020505@centtech.com> Date: Thu, 31 Mar 2005 10:40:36 -0600 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050325 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Quinot References: <424BCDAA.40604@samsco.org> <20050331131530.GC98903@melusine.cuivre.fr.eu.org> In-Reply-To: <20050331131530.GC98903@melusine.cuivre.fr.eu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Scott Long cc: hackers@freebsd.org cc: sos@freebsd.org Subject: Re: ATAPICAM for ATA-MKIII 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: Thu, 31 Mar 2005 16:41:07 -0000 Thomas Quinot wrote: > * Scott Long, 2005-03-31 : > > >>Attached are patches for atapicam for ATA-MKIII. I've only done light >>testing, but they seem to work as expected. They work both as a module >>and compiled into the kernel. > > > Thanks Scott, this is immensely helpful. I'll try to test and commit > that this weekend. So far all works well under -current as of this morning. I just burnt a DVD with it just fine. Great work! Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 19:12:10 2005 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 7B5AE16A4CE for ; Thu, 31 Mar 2005 19:12:10 +0000 (GMT) Received: from mail22.sea5.speakeasy.net (mail22.sea5.speakeasy.net [69.17.117.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E82443D31 for ; Thu, 31 Mar 2005 19:12:10 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 14514 invoked from network); 31 Mar 2005 19:12:09 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail22.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 31 Mar 2005 19:12:07 -0000 Received: from hydrogen.funkthat.com (atmzeb@localhost.funkthat.com [127.0.0.1])j2VJC6GH020449; Thu, 31 Mar 2005 11:12:06 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id j2VJC56o020448; Thu, 31 Mar 2005 11:12:05 -0800 (PST) Date: Thu, 31 Mar 2005 11:12:05 -0800 From: John-Mark Gurney To: ticso@cicely.de Message-ID: <20050331191205.GJ37984@funkthat.com> Mail-Followup-To: ticso@cicely.de, Wilko Bulte , freebsd-hackers@freebsd.org References: <20050331014311.GA96606@freebie.xs4all.nl> <20050331103614.GL33677@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050331103614.GL33677@cicely12.cicely.de> 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 cc: Wilko Bulte cc: freebsd-hackers@freebsd.org Subject: Re: So, who makes this one run FreeBSD? ;-) 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: Thu, 31 Mar 2005 19:12:10 -0000 Bernd Walter wrote this message on Thu, Mar 31, 2005 at 12:36 +0200: > But considered the small price distance to the smallest Soekris, > which runs FreeBSD, only the size and supply power is an interesting > point. Or you can look at the TS-7200 from http://www.embeddedarm.com/ . It's smaller than a Soekris, and is slightly larger than the PC-104 form factor.. Right now I have it netbooting, but I need to figure out why I have some ethernet issues... The code is in p4, though if people are really interested, I can generate a patch... -- 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 Thu Mar 31 20:11:26 2005 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 937BA16A4CE for ; Thu, 31 Mar 2005 20:11:26 +0000 (GMT) Received: from mail.revolutionsp.com (ganymede.revolutionsp.com [64.246.0.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39CF543D5E for ; Thu, 31 Mar 2005 20:11:26 +0000 (GMT) (envelope-from security@revolutionsp.com) Received: from mail.revolutionsp.com (localhost [127.0.0.1]) by mail.revolutionsp.com (Postfix) with ESMTP id B5C1215C95 for ; Thu, 31 Mar 2005 14:10:27 -0600 (CST) Received: from 81.84.174.37 (SquirrelMail authenticated user security@revolutionsp.com) by mail.revolutionsp.com with HTTP; Thu, 31 Mar 2005 14:10:27 -0600 (CST) Message-ID: <49328.81.84.174.37.1112299827.squirrel@mail.revolutionsp.com> In-Reply-To: References: <61910.81.84.174.37.1112123946.squirrel@mail.revolutionsp.com> Date: Thu, 31 Mar 2005 14:10:27 -0600 (CST) From: "H. S." To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: A few thoughts.. 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: Thu, 31 Mar 2005 20:11:26 -0000 > On Tue, 29 Mar 2005, H. S. wrote: > >> My "USERNAME" account doesn't have access to /sbin/dmesg, but I uploaded >> a /sbin/dmesg from a 5.2.1-RELEASE to a 5.3-STABLE box, and then I could >> have access to this system information. The same goes for systat , >> vmstat, and all these commands that (most people think) shouldn't be >> available for regular users. > > dmesg is implemented as an unprivileged program that uses an unprivileged > sysctl to retrieve the message buffer, kern.msgbuf. You can set the > sysctl security.bsd.unprivileged_read_msgbuf to 0 to block unprivileged > reading of the buffer. > Very nice, I didn't know this MIB! Thanks for the tip :-) >> Shouldn't this information be protected at kernel level? Am I missing >> something I can do about this ? Because this method works with >> everything that ressembles permissions in order to hide system >> information that can be obtained without root privileges. > > In essense, yes. Historically, system information was retrieved by > programs using /dev/mem, which required privilege. In that scenario, > deleting or removing set{ug}id from /sbin/dmesg (et al) removed the > ability to retrieve the information for an unprivileged user. Changes > were made to limit the use of privileged programs, which represent a > substantially risky approach (privileged code rather than a controlled > interface), FreeBSD has generally moved to exporting system information > using the sysctl MIB, which generally doesn't require privilege. Some > system export MIB entries make use of access control to limit the export > of system information -- for example, we export process information for > use by ps(1) using sysctl, but the sysctls in question will check whether > the user has the right to retrieve information on specific processes (such > as with jail, or security.bsd.see_other_uids=0). > > However, this approach has not been taken universally with sysctls, > because it adds moderate complexity to the implementation, and adding > restrictions to many of the MIB entries isn't useful in most environments. > Using the MAC Framework, it's possibel to construct a module that would > restrict access to a broad range of sysctls -- however, this also prevents > calls like gethostname() from succeeding, so this approach also would have > to be taken cautiously. > I've just begun trying to understand MAC. Is it possible to block this or that sysctl MIB to users using MAC? MAC is very complex, I had no idea.I thought it was mostly about ACLs, but after a bit of reading, now I know I was wrong. > Robert N M Watson > > _______________________________________________ > 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 Thu Mar 31 20:38:36 2005 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 4233E16A4CE for ; Thu, 31 Mar 2005 20:38:36 +0000 (GMT) Received: from siue.dnsalias.net (cv517-237.cv.siue.edu [146.163.219.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id E828C43D7B for ; Thu, 31 Mar 2005 20:38:35 +0000 (GMT) (envelope-from grimw@siue.dnsalias.net) Received: by siue.dnsalias.net (Postfix, from userid 1001) id 22562C120; Thu, 31 Mar 2005 14:38:26 -0600 (CST) Date: Thu, 31 Mar 2005 14:38:26 -0600 From: William Michael Grim To: hackers@freebsd.org Message-ID: <20050331203826.GA31110@siue.dnsalias.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: 4BSD Scheduler Problem on 5.3 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: Thu, 31 Mar 2005 20:38:36 -0000 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello. I keep having kernel panics every couple weeks on my system. It occurs in the sched_switch() function. There are several other statements in the backtrace involving "??"; what are those? I have attached the dump output and system info to this email. Any feedback would be helpful. Thanks so much for your help. -- William Michael Grim Student, Southern Illinois University at Edwardsville Unix Network Administrator, SIUE, Computer Science dept. Phone: (217) 341-6552 Email: wgrim@siue.edu --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dump.output" Good dump found on device /dev/aacd0s1b Architecture: i386 Architecture version: 1 Dump length: 1073676288B (1023 MB) Blocksize: 512 Dumptime: Tue Feb 1 00:27:24 2005 Hostname: mania.cs.siue.edu Versionstring: FreeBSD 5.3-RELEASE #2: Tue Nov 16 22:58:39 CST 2004 unix@mania.cs.siue.edu:/usr/obj/usr/src/sys/MANIA Panicstring: page fault Bounds: 0 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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-marcel-freebsd". (no debugging symbols found)...0xc04e7c7a in doadump () (kgdb) bt #0 0xc04e7c7a in doadump () #1 0xc04e8273 in boot () #2 0xc04e85c9 in panic () #3 0xc064d850 in trap_fatal () #4 0xc064d583 in trap_pfault () #5 0xc064d199 in trap () #6 0xc063d2ba in calltrap () #7 0xc04d0018 in exit1 () #8 0xc0516b69 in ttwakeup () #9 0xc05157cc in ttymodem () #10 0xc05194b7 in ptcopen () #11 0xc04b0b76 in spec_open () #12 0xc04b08bb in spec_vnoperate () #13 0xc05464f5 in vn_open_cred () #14 0xc05460da in vn_open () #15 0xc05401f3 in kern_open () #16 0xc054010c in open () #17 0xc064db63 in syscall () #18 0xc063d30f in Xint0x80_syscall () #19 0x0000002f in ?? () #20 0x0807002f in ?? () #21 0xbfbf002f in ?? () #22 0xffffffff in ?? () #23 0x280d1c2d in ?? () #24 0xbfbfe2d8 in ?? () #25 0xef5eed74 in ?? () #26 0x280d3860 in ?? () #27 0x280d1c4a in ?? () #28 0x283395ec in ?? () #29 0x00000005 in ?? () #30 0x0000000c in ?? () #31 0x00000002 in ?? () #32 0x282c2517 in ?? () #33 0x0000001f in ?? () #34 0x00000292 in ?? () #35 0xbfbfe27c in ?? () #36 0x0000002f in ?? () #37 0xffffffff in ?? () #38 0xffffffff in ?? () #39 0x00000000 in ?? () #40 0x00000000 in ?? () #41 0x110c8000 in ?? () #42 0xc6cb5388 in ?? () #43 0xc814a960 in ?? () #44 0xef5eeb00 in ?? () #45 0xef5eeae8 in ?? () #46 0xc1e7c7d0 in ?? () #47 0xc04f88ab in sched_switch () (kgdb) q Previous frame inner to this frame (corrupt stack?) --a8Wt8u1KmwUX3Y2C-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 21:07:34 2005 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 DABB116A4CE for ; Thu, 31 Mar 2005 21:07:34 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02AD243D45 for ; Thu, 31 Mar 2005 21:07:34 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0)j2VL7Nsf054361 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 31 Mar 2005 23:07:25 +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 j2VL6mhs015849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Mar 2005 23:06:48 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j2VL6lkV005201; Thu, 31 Mar 2005 23:06:47 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j2VL6lrg005200; Thu, 31 Mar 2005 23:06:47 +0200 (CEST) (envelope-from ticso) Date: Thu, 31 Mar 2005 23:06:47 +0200 From: Bernd Walter To: ticso@cicely.de, Wilko Bulte , freebsd-hackers@freebsd.org Message-ID: <20050331210646.GI2072@cicely12.cicely.de> References: <20050331014311.GA96606@freebie.xs4all.nl> <20050331103614.GL33677@cicely12.cicely.de> <20050331191205.GJ37984@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050331191205.GJ37984@funkthat.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=no version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0029] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de Subject: Re: So, who makes this one run FreeBSD? ;-) 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: Thu, 31 Mar 2005 21:07:35 -0000 On Thu, Mar 31, 2005 at 11:12:05AM -0800, John-Mark Gurney wrote: > Bernd Walter wrote this message on Thu, Mar 31, 2005 at 12:36 +0200: > > But considered the small price distance to the smallest Soekris, > > which runs FreeBSD, only the size and supply power is an interesting > > point. > > Or you can look at the TS-7200 from http://www.embeddedarm.com/ . It's > smaller than a Soekris, and is slightly larger than the PC-104 form > factor.. Right now I have it netbooting, but I need to figure out why > I have some ethernet issues... The code is in p4, though if people > are really interested, I can generate a patch... It costs more then the Soekris 4526-20 and is only slightly smaller in size. And the 4526 doesn't need regulated power plus has onboard ata flash. But this is still an interesting board after all - especially as it has USB ports and lot of GPIO, which I need sometimes. USB on Soekris require add-on hardware our pricier boards. How stable is FreeBSD on ARMv9 already? I didn't even know that it is running yet. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 22:33:51 2005 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 3959016A4CF for ; Thu, 31 Mar 2005 22:33:51 +0000 (GMT) Received: from mail22.sea5.speakeasy.net (mail22.sea5.speakeasy.net [69.17.117.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id C61AB43D41 for ; Thu, 31 Mar 2005 22:33:50 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 21115 invoked from network); 31 Mar 2005 22:33:50 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail22.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 31 Mar 2005 22:33:49 -0000 Received: from hydrogen.funkthat.com (cxinax@localhost.funkthat.com [127.0.0.1])j2VMXmGH025928; Thu, 31 Mar 2005 14:33:48 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id j2VMXmEI025927; Thu, 31 Mar 2005 14:33:48 -0800 (PST) Date: Thu, 31 Mar 2005 14:33:48 -0800 From: John-Mark Gurney To: ticso@cicely.de Message-ID: <20050331223347.GK37984@funkthat.com> Mail-Followup-To: ticso@cicely.de, Wilko Bulte , freebsd-hackers@freebsd.org References: <20050331014311.GA96606@freebie.xs4all.nl> <20050331103614.GL33677@cicely12.cicely.de> <20050331191205.GJ37984@funkthat.com> <20050331210646.GI2072@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050331210646.GI2072@cicely12.cicely.de> 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 cc: Wilko Bulte cc: freebsd-hackers@freebsd.org Subject: Re: So, who makes this one run FreeBSD? ;-) 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: Thu, 31 Mar 2005 22:33:51 -0000 Bernd Walter wrote this message on Thu, Mar 31, 2005 at 23:06 +0200: > On Thu, Mar 31, 2005 at 11:12:05AM -0800, John-Mark Gurney wrote: > > Bernd Walter wrote this message on Thu, Mar 31, 2005 at 12:36 +0200: > > > But considered the small price distance to the smallest Soekris, > > > which runs FreeBSD, only the size and supply power is an interesting > > > point. > > > > Or you can look at the TS-7200 from http://www.embeddedarm.com/ . It's > > smaller than a Soekris, and is slightly larger than the PC-104 form > > factor.. Right now I have it netbooting, but I need to figure out why > > I have some ethernet issues... The code is in p4, though if people > > are really interested, I can generate a patch... > > It costs more then the Soekris 4526-20 and is only slightly smaller in > size. plus has dual mini-pci.. while the TS-7200 only has PC-104 (basicly ISA).. > And the 4526 doesn't need regulated power plus has onboard ata flash. also looks like it supports PoE, which the TS-7200 doesn't... Right now I'm using a breadboarded LM7805 for power, but I am going to build a daughter card for this project, and so I'm going to throw a switching power supply on it.. so the regulated requirement isn't such a big deal.. also, it doesn't need as much power either.. TS says only 1 AMP at 5V is necessary... I haven't measured it yet though... > But this is still an interesting board after all - especially as it has > USB ports and lot of GPIO, which I need sometimes. > USB on Soekris require add-on hardware our pricier boards. > How stable is FreeBSD on ARMv9 already? > I didn't even know that it is running yet. So far it's been fine.. There may be issues with optimized crossbuilt worlds from i386... But I can boot multiuser mode, and it runs all the scripts and everything to come up... As I mentioned the ethernet is a bit flaky... For some reason, some packets have the underrun and carrier loss bit set on them.. This is the case on packets around 80 bytes in size (like reverse dns packets for 192.168.0.1, but not 192.168.0.10), and may be a timing issue that I'm not familar with... But nfs root boots fine... I do plan on figuring it out... USB doesn't work yet, it does probe, but causes issues.. and even though they say it's USB 2.0, it's only for electrical... No ehci controler.. the USB controller is ohci, and so only supports up to full speed usb (12Mb/s)... Also, this work isn't directly sponsored by TS, so it doesn't have any drivers for their other boards, like the RTC, serial or lcd + keypad parts that NetBSD does... The real reason why I'm using the TS-7200 is because it had on board AC'97 and I2S support (they aren't exposed to headers so I plan on soldering my own wires to the chip)... Which soekris definately doesn't have... :) dmesg from my last boot is at: http://people.freebsd.org/~jmg/dmesg.ts7200 As you can see, no RTC.. :) 18 Mar 15:36:25 ntpdate[241]: step time server 192.168.0.30 offset 1111188933.058709 sec -- 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 Thu Mar 31 22:55:33 2005 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 67A9216A4CE for ; Thu, 31 Mar 2005 22:55:33 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F1D843D58 for ; Thu, 31 Mar 2005 22:55:32 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0)j2VMtMsf056797 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 1 Apr 2005 00:55:24 +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 j2VMsjhs016465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 00:54:45 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j2VMsirD006457; Fri, 1 Apr 2005 00:54:44 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j2VMsiNJ006456; Fri, 1 Apr 2005 00:54:44 +0200 (CEST) (envelope-from ticso) Date: Fri, 1 Apr 2005 00:54:44 +0200 From: Bernd Walter To: ticso@cicely.de, Wilko Bulte , freebsd-hackers@freebsd.org Message-ID: <20050331225443.GM2072@cicely12.cicely.de> References: <20050331014311.GA96606@freebie.xs4all.nl> <20050331103614.GL33677@cicely12.cicely.de> <20050331191205.GJ37984@funkthat.com> <20050331210646.GI2072@cicely12.cicely.de> <20050331223347.GK37984@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050331223347.GK37984@funkthat.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-0.0 required=3.0 tests=BAYES_40 autolearn=no version=2.64 X-Spam-Report: * -0.0 BAYES_40 BODY: Bayesian spam probability is 40 to 44% * [score: 0.4092] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de Subject: Re: So, who makes this one run FreeBSD? ;-) 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: Thu, 31 Mar 2005 22:55:33 -0000 On Thu, Mar 31, 2005 at 02:33:48PM -0800, John-Mark Gurney wrote: > Bernd Walter wrote this message on Thu, Mar 31, 2005 at 23:06 +0200: > > On Thu, Mar 31, 2005 at 11:12:05AM -0800, John-Mark Gurney wrote: > > > Bernd Walter wrote this message on Thu, Mar 31, 2005 at 12:36 +0200: > > > > But considered the small price distance to the smallest Soekris, > > > > which runs FreeBSD, only the size and supply power is an interesting > > > > point. > > > > > > Or you can look at the TS-7200 from http://www.embeddedarm.com/ . It's > > > smaller than a Soekris, and is slightly larger than the PC-104 form > > > factor.. Right now I have it netbooting, but I need to figure out why > > > I have some ethernet issues... The code is in p4, though if people > > > are really interested, I can generate a patch... > > > > It costs more then the Soekris 4526-20 and is only slightly smaller in > > size. > > plus has dual mini-pci.. while the TS-7200 only has PC-104 (basicly ISA).. Both have their pro's. PC-104 ist definitively cheaper to add custom hardware to, but also slower. > > And the 4526 doesn't need regulated power plus has onboard ata flash. > > also looks like it supports PoE, which the TS-7200 doesn't... Right > now I'm using a breadboarded LM7805 for power, but I am going to build > a daughter card for this project, and so I'm going to throw a switching > power supply on it.. so the regulated requirement isn't such a big deal.. > also, it doesn't need as much power either.. TS says only 1 AMP at 5V > is necessary... I haven't measured it yet though... 1A is a lot to handle with a linar regulator, but this may include power to additional hardware - e.g. USB ports. > > But this is still an interesting board after all - especially as it has > > USB ports and lot of GPIO, which I need sometimes. > > USB on Soekris require add-on hardware our pricier boards. > > How stable is FreeBSD on ARMv9 already? > > I didn't even know that it is running yet. > > So far it's been fine.. There may be issues with optimized crossbuilt > worlds from i386... But I can boot multiuser mode, and it runs all the > scripts and everything to come up... That's great. > As I mentioned the ethernet is a bit flaky... For some reason, some > packets have the underrun and carrier loss bit set on them.. This is > the case on packets around 80 bytes in size (like reverse dns packets > for 192.168.0.1, but not 192.168.0.10), and may be a timing issue that > I'm not familar with... But nfs root boots fine... Well that's just a bug with lot of hope to get fixed. > I do plan on figuring it out... USB doesn't work yet, it does probe, > but causes issues.. and even though they say it's USB 2.0, it's only > for electrical... No ehci controler.. the USB controller is ohci, and > so only supports up to full speed usb (12Mb/s)... I personally use USB on such systems for attaching custom hardware. Full speed is fine for that. Since you say it's OHCI there is hope and I know you are familar with USB host controllers. It's OK to claim a full/low speed only device beeing USB 2.0. High speed isn't mandandory for 2.0. > Also, this work isn't directly sponsored by TS, so it doesn't have any > drivers for their other boards, like the RTC, serial or lcd + keypad > parts that NetBSD does... At least the documentation is good - and between the lines I read that NetBSD support the board too. > The real reason why I'm using the TS-7200 is because it had on board > AC'97 and I2S support (they aren't exposed to headers so I plan on > soldering my own wires to the chip)... Which soekris definately doesn't > have... :) The Soekris CPUs have lots of features that arn't wired. But it's hopeless since the CPUs are BGA. > dmesg from my last boot is at: http://people.freebsd.org/~jmg/dmesg.ts7200 I don't know where to put it performancewise to x86 systems. Does it feel slow on ssh? e.g. how long does it take to log in? > As you can see, no RTC.. :) > 18 Mar 15:36:25 ntpdate[241]: step time server 192.168.0.30 offset 1111188933.058709 sec A matter of time :) -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 23:07:01 2005 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 6B67516A4CE for ; Thu, 31 Mar 2005 23:07:01 +0000 (GMT) Received: from mail22.sea5.speakeasy.net (mail22.sea5.speakeasy.net [69.17.117.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AABF43D45 for ; Thu, 31 Mar 2005 23:07:01 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 14773 invoked from network); 31 Mar 2005 23:07:01 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 31 Mar 2005 23:06:59 -0000 Received: from [10.50.41.231] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j2VN6iQU028069; Thu, 31 Mar 2005 18:06:54 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-hackers@FreeBSD.org Date: Thu, 31 Mar 2005 17:16:52 -0500 User-Agent: KMail/1.6.2 References: <20050331203826.GA31110@siue.dnsalias.net> In-Reply-To: <20050331203826.GA31110@siue.dnsalias.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <200503311716.52034.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: William Michael Grim Subject: Re: 4BSD Scheduler Problem on 5.3 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: Thu, 31 Mar 2005 23:07:01 -0000 On Thursday 31 March 2005 03:38 pm, William Michael Grim wrote: > Hello. > > I keep having kernel panics every couple weeks on my system. It occurs in > the sched_switch() function. There are several other statements in the > backtrace involving "??"; what are those? > > I have attached the dump output and system info to this email. Any > feedback would be helpful. > > Thanks so much for your help. The real trace ends with Xint0x80_syscall(). The rest after that is garbage memory. Your real problem is in exit1() or ttywakeup(). Since ttywakeup() doesn't call exit1() (AFAIK), the exit1() frame is probably bogus (gdb doesn't grok trapframes maybe?) and the real bug is a NULL pointer deref in ttywakeup(). Perhaps it's a bug in the ptc driver? (ptcopen is in the trace). What is the ptc driver anyway? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 23:56:22 2005 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 CE65A16A4CE; Thu, 31 Mar 2005 23:56:22 +0000 (GMT) Received: from pd2mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8207043D2F; Thu, 31 Mar 2005 23:56:22 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd2mr5so.prod.shaw.ca (pd2mr5so-qfe3.prod.shaw.ca [10.0.141.8]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IE8008C4QH0HV50@l-daemon>; Thu, 31 Mar 2005 16:55:48 -0700 (MST) Received: from pn2ml1so.prod.shaw.ca ([10.0.121.145]) by pd2mr5so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IE800IPRQH0TR10@pd2mr5so.prod.shaw.ca>; Thu, 31 Mar 2005 16:55:48 -0700 (MST) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IE800L8QQGZ7C@l-daemon>; Thu, 31 Mar 2005 16:55:48 -0700 (MST) Date: Thu, 31 Mar 2005 15:55:37 -0800 From: Colin Percival In-reply-to: <20050331111625.GA13338@zoopee.org> To: Tom Alsberg Message-id: <424C8DF9.2060905@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <20050331111625.GA13338@zoopee.org> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050326) cc: FreeBSD Hackers List cc: freebsd-stable@freebsd.org Subject: Re: MNT_NOEXEC on root filesystem with diskless PXE boot? 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: Thu, 31 Mar 2005 23:56:23 -0000 Tom Alsberg wrote: > Perhaps this should go to -STABLE, I just couldn't be sure. It will get more attention on freebsd-stable@, so I'm CCing that list. > We are trying out FreeBSD 5.4-PRERELEASE on diskless clients. I > noticed one problem, being that when setting the LD_LIBRARY_PATH > (or for that matter, LD_PRELOAD, and LD_LIBMAP_DISABLE) environment > variables, nothing will run, as /libexec/ld-elf.so.1 complains: > > Cannot execute objects on / > > According to the sources, this was added in 5.4, and will happen > if / is mounted noexec. Yes, that's quite correct -- although I can't imagine how a bug which caused / to be labelled as "noexec" managed to avoid causing major problems until now. I don't know anything about NFS, but hopefully someone on -stable will be able to work out what's going on from the rest of your email (quoted below). Colin Percival > In this case, / is mounted by the BTX PXE loader over NFS (from a > FreeBSD 5.3 server, right now). "mount" does not show the noexec > flag. However, with the attached little C program I verified that > statfs really returns this flag (0x00000006). > > Now, I see that on FreeBSD 5.3 diskless clients this flag is also > returned on / - just it happened that nobody looked at it until > the change in rtld.c of FreeBSD 5.4: > > if (fs.f_flags & MNT_NOEXEC) { > _rtld_error("Cannot execute objects on %s\n", fs.f_mntonname); > close(fd); > return NULL; > } > > I didn't yet understand (didn't check much) - why does statfs report > the MNT_NOEXEC flag on the / filesystem (and only the / filesystem, > when it's mounted from NFS by the bootloader - not any other > NFS filesystems)? BTW, this happens also with NetApp as the NFS > server - just to rule out any possibility of relation here. > > Ideas appreciated, > -- Tom > > > > ------------------------------------------------------------------------ > > #include > #include > #include > #include > > > int main(int argc, char *argv[]) > { > if (argc != 2) { > fprintf(stderr, "invalid number of arguments"); > return -1; > } > > struct statfs stbuf; > > if (statfs(argv[1], &stbuf) != 0) { > perror("fstatfs"); > return -1; > } > > printf("FLAGS: 0x%08X\n", stbuf.f_flags); > if (stbuf.f_flags & MNT_NOEXEC) > printf("MNT_NOEXEC\n"); > > return 0; > } From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 1 00:10:34 2005 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 8AAEB16A4CE for ; Fri, 1 Apr 2005 00:10:34 +0000 (GMT) Received: from mail.nativenerds.com (host-70-0-111-24.midco.net [24.111.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEE2D43D55 for ; Fri, 1 Apr 2005 00:10:33 +0000 (GMT) (envelope-from estover@nativenerds.com) Received: from red (host-14-37-230-24.midco.net [24.230.37.14]) j310MKZT078878 for ; Thu, 31 Mar 2005 17:22:20 -0700 (MST) (envelope-from estover@nativenerds.com) From: Ed Stover To: freebsd-hackers@freebsd.org Content-Type: text/plain Organization: Native Nerds Date: Thu, 31 Mar 2005 17:11:54 -0700 Message-Id: <1112314314.50219.4.camel@red.nativenerds.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on mail.nativenerds.com Subject: build fails courierpassd-1.1.0-RC1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: estover@nativenerds.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2005 00:10:34 -0000 I have been trying to compile courierpassd-1.1.0-RC1 on FreeBSD4.11 I have courier-authlib-0.51 from packages. from my make of courierpassd-1.1.0-RC1 gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c courierpassd.c In file included from courierpassd.c:38: courierpassd.h:24: courierauth.h: No such file or directory courierpassd.h:25: courierauthdebug.h: No such file or directory any ideas? or has any one got a mysql+qmail+vpopmail setup that allows users to change there passwords from Squirrelmail? From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 1 01:06:34 2005 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 30AEB16A4CE; Fri, 1 Apr 2005 01:06:34 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id C544E43D48; Fri, 1 Apr 2005 01:06:33 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 2333746B17; Thu, 31 Mar 2005 20:06:33 -0500 (EST) Date: Fri, 1 Apr 2005 01:03:14 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: John Baldwin In-Reply-To: <200503311716.52034.jhb@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@FreeBSD.org cc: William Michael Grim Subject: Re: 4BSD Scheduler Problem on 5.3 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: Fri, 01 Apr 2005 01:06:34 -0000 On Thu, 31 Mar 2005, John Baldwin wrote: > On Thursday 31 March 2005 03:38 pm, William Michael Grim wrote: > > Hello. > > > > I keep having kernel panics every couple weeks on my system. It occurs in > > the sched_switch() function. There are several other statements in the > > backtrace involving "??"; what are those? > > > > I have attached the dump output and system info to this email. Any > > feedback would be helpful. > > > > Thanks so much for your help. > > The real trace ends with Xint0x80_syscall(). The rest after that is > garbage memory. Your real problem is in exit1() or ttywakeup(). Since > ttywakeup() doesn't call exit1() (AFAIK), the exit1() frame is probably > bogus (gdb doesn't grok trapframes maybe?) and the real bug is a NULL > pointer deref in ttywakeup(). Perhaps it's a bug in the ptc driver? > (ptcopen is in the trace). What is the ptc driver anyway? I think we have a race in -STABLE relating to tty wakeups and open/close/device teardown. I've seen a panic relating to sio during a tty close on RELENG_5 about 5-6 months ago, but was unable to get a dump. Scott has since fixed dumps with twe, but I've not yet been able to get the bug to recur. I'll give it another try. Robert N M Watson From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 1 01:08:40 2005 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 927BF16A4CE for ; Fri, 1 Apr 2005 01:08:40 +0000 (GMT) Received: from mail26.sea5.speakeasy.net (mail26.sea5.speakeasy.net [69.17.117.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 271B543D53 for ; Fri, 1 Apr 2005 01:08:40 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 4074 invoked from network); 1 Apr 2005 01:08:39 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail26.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 1 Apr 2005 01:08:38 -0000 Received: from hydrogen.funkthat.com (gnmrgr@localhost.funkthat.com [127.0.0.1])j3118cGH029778; Thu, 31 Mar 2005 17:08:39 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id j3118cbj029777; Thu, 31 Mar 2005 17:08:38 -0800 (PST) Date: Thu, 31 Mar 2005 17:08:38 -0800 From: John-Mark Gurney To: ticso@cicely.de Message-ID: <20050401010838.GL37984@funkthat.com> Mail-Followup-To: ticso@cicely.de, Wilko Bulte , freebsd-hackers@freebsd.org References: <20050331014311.GA96606@freebie.xs4all.nl> <20050331103614.GL33677@cicely12.cicely.de> <20050331191205.GJ37984@funkthat.com> <20050331210646.GI2072@cicely12.cicely.de> <20050331223347.GK37984@funkthat.com> <20050331225443.GM2072@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050331225443.GM2072@cicely12.cicely.de> 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 cc: Wilko Bulte cc: freebsd-hackers@freebsd.org Subject: Re: So, who makes this one run FreeBSD? ;-) 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: Fri, 01 Apr 2005 01:08:40 -0000 Bernd Walter wrote this message on Fri, Apr 01, 2005 at 00:54 +0200: > On Thu, Mar 31, 2005 at 02:33:48PM -0800, John-Mark Gurney wrote: > > Bernd Walter wrote this message on Thu, Mar 31, 2005 at 23:06 +0200: > > > And the 4526 doesn't need regulated power plus has onboard ata flash. > > > > also looks like it supports PoE, which the TS-7200 doesn't... Right > > now I'm using a breadboarded LM7805 for power, but I am going to build > > a daughter card for this project, and so I'm going to throw a switching > > power supply on it.. so the regulated requirement isn't such a big deal.. > > also, it doesn't need as much power either.. TS says only 1 AMP at 5V > > is necessary... I haven't measured it yet though... > > 1A is a lot to handle with a linar regulator, but this may include > power to additional hardware - e.g. USB ports. Yeh, I haven't measured it, and was looking at doing that, but it'll be over a week before I can get more useful power requirements... > > > But this is still an interesting board after all - especially as it has > > > USB ports and lot of GPIO, which I need sometimes. > > > USB on Soekris require add-on hardware our pricier boards. > > > How stable is FreeBSD on ARMv9 already? > > > I didn't even know that it is running yet. > > > > So far it's been fine.. There may be issues with optimized crossbuilt > > worlds from i386... But I can boot multiuser mode, and it runs all the > > scripts and everything to come up... > > That's great. > > > As I mentioned the ethernet is a bit flaky... For some reason, some > > packets have the underrun and carrier loss bit set on them.. This is > > the case on packets around 80 bytes in size (like reverse dns packets > > for 192.168.0.1, but not 192.168.0.10), and may be a timing issue that > > I'm not familar with... But nfs root boots fine... > > Well that's just a bug with lot of hope to get fixed. > > > I do plan on figuring it out... USB doesn't work yet, it does probe, > > but causes issues.. and even though they say it's USB 2.0, it's only > > for electrical... No ehci controler.. the USB controller is ohci, and > > so only supports up to full speed usb (12Mb/s)... > > I personally use USB on such systems for attaching custom hardware. > Full speed is fine for that. > Since you say it's OHCI there is hope and I know you are familar with > USB host controllers. :) hehe, I think I still have the OHCI specs.. It sees the hub, but hangs when I plug a device in.... > It's OK to claim a full/low speed only device beeing USB 2.0. > High speed isn't mandandory for 2.0. > > > Also, this work isn't directly sponsored by TS, so it doesn't have any > > drivers for their other boards, like the RTC, serial or lcd + keypad > > parts that NetBSD does... > > At least the documentation is good - and between the lines I read that > NetBSD support the board too. Well, there isn't much documentation, but the support people have been helpful so far, but I haven't pinged them about the USB or ethernet issues yet... It doesn't help when NetBSD defines it one way in the headers (incorrectly), but then uses hard coded values in the source which are correct, and never uses the defines in the headers... > > The real reason why I'm using the TS-7200 is because it had on board > > AC'97 and I2S support (they aren't exposed to headers so I plan on > > soldering my own wires to the chip)... Which soekris definately doesn't > > have... :) > > The Soekris CPUs have lots of features that arn't wired. > But it's hopeless since the CPUs are BGA. I haven't looked at the specs for the chips that Soekris uses, but as you mention, BGA's can't just have a wired layed done on the pin.. :) > > dmesg from my last boot is at: http://people.freebsd.org/~jmg/dmesg.ts7200 > > I don't know where to put it performancewise to x86 systems. > Does it feel slow on ssh? > e.g. how long does it take to log in? I haven't ssh'd in yet (since reverse is broken on 192.168.0.? addresses), but it did seem to take a minute or more to create the host dsa key... I'll let you know this evening.. > > As you can see, no RTC.. :) > > 18 Mar 15:36:25 ntpdate[241]: step time server 192.168.0.30 offset 1111188933.058709 sec > > A matter of time :) If I by the board.. :) It is somewhat anoying that the board doesn't include an RTC on 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 Fri Apr 1 03:15:21 2005 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 70AEB16A4CE; Fri, 1 Apr 2005 03:15:21 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 115B543D58; Fri, 1 Apr 2005 03:15:21 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) j313FH0e056125; Thu, 31 Mar 2005 19:15:17 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id j313FGLn056122; Thu, 31 Mar 2005 19:15:16 -0800 (PST) (envelope-from dillon) Date: Thu, 31 Mar 2005 19:15:16 -0800 (PST) From: Matthew Dillon Message-Id: <200504010315.j313FGLn056122@apollo.backplane.com> To: Bruce Evans References: <423C15C5.6040902@fsn.hu> <20050327133059.3d68a78c@Magellan.Leidinger.net> <20050327162839.2fafa6aa@Magellan.Leidinger.net> <5bbfe7d405032823232103d537@mail.gmail.com> <20050331155418.F20400@delplex.bde.org> cc: Peter Jeremy cc: David Schultz cc: hackers@freebsd.org cc: jason henson cc: bde@freebsd.org Subject: Re: Fwd: 5-STABLE kernel build with icc broken 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: Fri, 01 Apr 2005 03:15:21 -0000 All I really did was implement a comment that DG had made many years ago in the PCB structure about making the FPU save area a pointer rather then hardwiring it into the PCB. This greatly reduces the complexity of work required to allow the kernel to 'borrow' the FPU. It basically allows the kernel to 'stack' save contexts rather then swap-out save contexts. The result is that the cross-over point for the copy size where the FPU becomes economical is a much lower value (~2K rather then ~4-8K). The FPU overhead differences between DFly and FreeBSD for bcopy only matters for buffers between 2K and 16K in size. After that the copy itself overshadows the FPU setup overhead. In DFly the kernel must still check to see whether userland has used the FPU and save the state before it reuses the FPU in the kernel. We don't bother to restore the state, we simply allow userland to take another fault (the idea being that if userland is making several I/O calls into the kernel in a batch, the FPU state is only saved once). Once the kernel has done this and adjusted the FPU save area it can use the FPU at a whim, even though blocking conditions, and then just throw away the FPU context when it is done. We could theoretically stack multiple kernel FPU contexts through this mechanism but I don't see much advantage to it so I don't... I have a lockout bit so if the kernel is already using the FPU and takes e.g. a preemptive interrupt, it doesn't go and use the FPU within that preemption. The use of the XMM registers is a cpu optimization. Modern CPUs, especially AMD Athlon and Opterons, are more efficient with 128 bit moves then with 64 bit moves. I experimented with all sorts of configurations, including the use of special data caching instructions, but they had so many special cases and degenerate conditions that I found that simply using straight XMM instructions, reading as big a glob as possible, then writing the glob, was by far the best solution. The key for fast block copying is to not issue any memory writes other then those related directly to the data being copied. This avoids unnecessary RAS cycles which would otherwise kill copying performance. In tests I found that copying multi-page blocks in a single loop was far more efficient then copying data page-by-page precisely because page-by-page copying was too complex to be able to avoid extranious writes to memory unrelated to the target buffer inbetween each page copy. -Matt From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 1 08:15:51 2005 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 C8A0316A4CE for ; Fri, 1 Apr 2005 08:15:51 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5908B43D46 for ; Fri, 1 Apr 2005 08:15:51 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j318G2h3037435; Fri, 1 Apr 2005 00:16:03 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j318FtcY037434; Fri, 1 Apr 2005 00:15:55 -0800 (PST) (envelope-from www) Date: Fri, 1 Apr 2005 00:15:55 -0800 (PST) Message-Id: <200504010815.j318FtcY037434@marlena.vvi.at> To: ganbold@micom.mng.net From: "ALeine" cc: freebsd-hackers@freebsd.org Subject: Re: subtracting days from localtime problem 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: Fri, 01 Apr 2005 08:15:51 -0000 ganbold@micom.mng.net wrote: > One more question, what will happen next time when > time goes back in October? > Does following line correct it as same as now? > > /* make mktime(3) figure out whether DST is in effect */ > t->tm_isdst = -1; Yes, it will work correctly. You can see what happens by setting now to 1131131131 (where you currently have now = time(NULL)). It's not an April Fools' Day joke, that just happens to be an appropriate time in November. :-) I also noticed a number of bugs in your code that you may want to fix: - memory leak: you are allocating memory with my_alloc(), but then you neither free(3) it nor keep track of it. You should remove my_alloc() and just create a buffer in main() and then pass it by reference to functions that need to modify its contents. - with my_alloc() you basically reinvented strdup(3), see man 3 strdup for details. You do not need strdup(3) for what you want to achieve, just pass the buffer from main() by reference and then use snprintf(3) to modify its contents. - snprintf(3) handles the size argument correctly, meaning that you should specify the full size of the string since at most size-1 characters are written with guaranteed NULL termination, see man 3 snprintf for details. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 1 09:15:47 2005 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 0829D16A4CE for ; Fri, 1 Apr 2005 09:15:47 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA8AC43D46 for ; Fri, 1 Apr 2005 09:15:46 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j319Fwh3037975; Fri, 1 Apr 2005 01:16:00 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j319Fpwf037974; Fri, 1 Apr 2005 01:15:51 -0800 (PST) (envelope-from www) Date: Fri, 1 Apr 2005 01:15:51 -0800 (PST) Message-Id: <200504010915.j319Fpwf037974@marlena.vvi.at> Content-Type: multipart/mixed; boundary="----------=_1112346951-37973-0" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) From: "ALeine" To: ganbold@micom.mng.net cc: freebsd-hackers@freebsd.org Subject: Re: subtracting days from localtime problem 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: Fri, 01 Apr 2005 09:15:47 -0000 This is a multi-part message in MIME format... ------------=_1112346951-37973-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary I attached an example which shows the DST related changes this year. I just couldn't resist writing something where I get to use rare values such as 1112345678 and 1131131131 in a meaningful way. :-) ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net ------------=_1112346951-37973-0 Content-Type: text/plain; name="dst_2005.c" Content-Disposition: inline; filename="dst_2005.c" Content-Transfer-Encoding: 8bit /*- * Copyright (c) 2005 ALeine * All rights reserved. * * Imported into CVS repository at exactly 1112345678 seconds * since the Epoch. * * $Id: dst_2005.c,v 1.1.1.1 2005/04/01 08:54:38 aleine Exp $ * */ #include #include void get_date_string_x_days_from_time(char *, size_t, int, time_t); void get_date_string_x_days_before_time(char *, size_t, int, time_t); int main(void) { time_t now; int last_day; int day_offset; char date_string[32]; now = time(NULL); /* Uncomment the following line to see what happens on 01-Apr-2005 */ /* now = 1112345678; */ /* Uncomment the following line to see what happens on 04-Nov-2005 */ /* now = 1131131131; */ fprintf(stderr, "Reference date and time: %s\n", ctime(&now)); last_day = 32; for (day_offset = 1; day_offset < last_day; day_offset++) { get_date_string_x_days_before_time(date_string, sizeof(date_string), day_offset, now); printf("%3d day%c before reference date: %s\n", day_offset, (day_offset > 1 ? 's' : ' '), date_string); } return 0; } void get_date_string_x_days_before_time(char *date_string, size_t size, int day_offset, time_t time) { get_date_string_x_days_from_time(date_string, size, -day_offset, time); } void get_date_string_x_days_from_time(char *date_string, size_t size, int day_offset, time_t time) { struct tm *tm_p; tm_p = localtime(&time); tm_p->tm_mday += day_offset; tm_p->tm_hour = tm_p->tm_min = tm_p->tm_sec = 0; /* make mktime(3) figure out whether DST is in effect */ tm_p->tm_isdst = -1; time = mktime(tm_p); if (time == ((time_t) - 1)) printf("mktime(3) failed\n"); snprintf(date_string, size, "%d-%.2d-%.2d [DST: %d]", tm_p->tm_year + 1900, tm_p->tm_mon + 1, tm_p->tm_mday, tm_p->tm_isdst); } ------------=_1112346951-37973-0-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 1 12:13:14 2005 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 ABCF216A4CE for ; Fri, 1 Apr 2005 12:13:14 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id E09B943D48 for ; Fri, 1 Apr 2005 12:13:13 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id F0A0F1F08C for ; Fri, 1 Apr 2005 14:13:12 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id D30B1696A; Fri, 1 Apr 2005 14:13:12 +0200 (CEST) Date: Fri, 1 Apr 2005 14:13:12 +0200 From: Marc Olzheim To: freebsd-hackers@freebsd.org Message-ID: <20050401121312.GA98797@stack.nl> References: <20050330181208.GA64275@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline In-Reply-To: <20050330181208.GA64275@stack.nl> X-Operating-System: FreeBSD hammer.stack.nl 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Subject: Re: Making gcc "-Wformat" more verbose 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: Fri, 01 Apr 2005 12:13:14 -0000 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 30, 2005 at 08:12:08PM +0200, Marc Olzheim wrote: > Please have a look at it and tell me whether this could be useful for > FreeBSD or whether that's a bridge too far... >=20 > The patch is at > http://www.stack.nl/~marcolz/FreeBSD/gcc-printf.patch.txt >=20 > Besides that, you'll need to include the inttypes.h at > http://www.stack.nl/~marcolz/FreeBSD/inttypes.h instead of > /usr/include/inttypes.h >=20 > If you want to compile the kernel with it, make sure to turn of > -Werror... (Or install into somewhere else then /usr/libexec and use > CFLAGS=3D-B to gcc to try it out. I modified it, so that you need to supply -Wformat-pre-promo in addition to -Wformat to get the extra output... Marc --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCTTrYezjnobFOgrERAkTdAKCx1xA6mCMlQvlyKpROVUEI/46bMQCdHJin Lf1KIJ0D38mxUhJ1+zyb/OA= =uSzV -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 1 13:20:34 2005 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 0DC0C16A4CE; Fri, 1 Apr 2005 13:20:34 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 519FC43D39; Fri, 1 Apr 2005 13:20:33 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])j31DKGHn002523; Fri, 1 Apr 2005 23:20:16 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j31DKCMq000829; Fri, 1 Apr 2005 23:20:13 +1000 Date: Fri, 1 Apr 2005 23:20:12 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Matthew Dillon In-Reply-To: <200504010315.j313FGLn056122@apollo.backplane.com> Message-ID: <20050401215011.R24396@delplex.bde.org> References: <423C15C5.6040902@fsn.hu> <20050327133059.3d68a78c@Magellan.Leidinger.net> <5bbfe7d405032823232103d537@mail.gmail.com> <424A23A8.5040109@ec.rr.com><20050330130051.GA4416@VARK.MIT.EDU> <200504010315.j313FGLn056122@apollo.backplane.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 01 Apr 2005 13:29:14 +0000 cc: Peter Jeremy cc: David Schultz cc: hackers@freebsd.org cc: jason henson cc: bde@freebsd.org Subject: Re: Fwd: 5-STABLE kernel build with icc broken 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: Fri, 01 Apr 2005 13:20:34 -0000 On Thu, 31 Mar 2005, Matthew Dillon wrote: I didn't mean to get into the kernel's use of the FPU, but... > All I really did was implement a comment that DG had made many years > ago in the PCB structure about making the FPU save area a pointer rather > then hardwiring it into the PCB. ISTR writing something like that. dg committed most of my early work since I didn't have commit access at the time. >... > The use of the XMM registers is a cpu optimization. Modern CPUs, > especially AMD Athlon and Opterons, are more efficient with 128 bit > moves then with 64 bit moves. I experimented with all sorts of > configurations, including the use of special data caching instructions, > but they had so many special cases and degenerate conditions that > I found that simply using straight XMM instructions, reading as big > a glob as possible, then writing the glob, was by far the best solution. Are you sure about that? The amd64 optimization manual says (essentially) that big globs are bad, and my benchmarks confirm this. The best glob size is 128 bits according to my benchmarks. This can be obtained using 2 64-bit reads of 64-bit registers followed by 2 64-bit writes of these registers, or by read-write of a single 128-bit register. The 64-bit registers can be either MMX or integer registers on 64-bit systems, but the 128-registers must be XMM on all systems. I get identical speeds of 12.9GB/sec (+-0.1GB/sec) on a fairly old and slow Athlon64 system for copying 16K (fully cached) through MMX and XMM 128 bits at a time using the following instructions: # MMX: # XMM movq (%0),%mm0 movdqa (%0),%xmm0 movq 8(%0),%mm1 movdqa %xmm0,(%1) movq %mm0,(%1) ... # unroll same amount movq %mm1,8(%1) ... # unroll to copy 64 bytes per iteration Unfortunately (since I want to avoid using both MMX and XMM), I haven't managed to make copying through 64-integer registers work as well. Copying 128 bits at a time using 2 pairs of movq's through integer registers gives only 7.9GB/sec. movq through MMX is never that slow. However, movdqu through xmm is even slower (7.4GB/sec). The fully cached case is too unrepresentative of normal use, and normal (partially cached) use is hard to bencmark, so I normally benchmark the fully uncached case. For that, movnt* is best for benchmarks but not for general use, and it hardly matters which registers are used. > The key for fast block copying is to not issue any memory writes other > then those related directly to the data being copied. This avoids > unnecessary RAS cycles which would otherwise kill copying performance. > In tests I found that copying multi-page blocks in a single loop was > far more efficient then copying data page-by-page precisely because > page-by-page copying was too complex to be able to avoid extranious > writes to memory unrelated to the target buffer inbetween each page copy. By page-by-page, do you mean prefetch a page at a time into the L1 cache? I've noticed strange loss (apparently) from extraneous reads or writes more for benchmarks that do just (very large) writes. An at least old Celerons and AthlonXPs, the writes go straight to the L1/L2 caches (unless you use movntq on AthlonXP's). The caches are flushed to main memory some time later, apparently not very well since some pages take more than twice as long to write as others (as seen by the writer filling the caches), and the slow case happens enough to affect the average write speed by up to 50%. This problem can be reduced by putting memory bank bits in the page colors. This is hard to get right even for the simple unrepresentative case of large writes. Bruce From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 1 17:10:01 2005 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 ACE0716A4CE for ; Fri, 1 Apr 2005 17:10:01 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id B33BD43D2F for ; Fri, 1 Apr 2005 17:10:00 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru (8.13.0/vak/3.0) id j31H6wck070617 for freebsd-hackers@freebsd.org.checked; Fri, 1 Apr 2005 21:06:58 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from [144.206.181.94] (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru (8.13.0/vak/3.0) with ESMTP id j31H6Zcw070612; Fri, 1 Apr 2005 21:06:35 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <424D7F8C.9060604@cronyx.ru> Date: Fri, 01 Apr 2005 21:06:20 +0400 From: Roman Kurakin User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mohamed aslan References: <319cceca0503281001792baf39@mail.gmail.com> In-Reply-To: <319cceca0503281001792baf39@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: organization 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: Fri, 01 Apr 2005 17:10:01 -0000 mohamed aslan wrote: >hi guys >it's my first post here, BTW i was a linux hacker and linux kernel >mailing list member for 3 years. > > I am driver developer, and I work with both Linux and FreeBSD. It is usual for me to changed OS I am working with a several times a day. What can I say, both source trees have some organization problems. Personally I prefer BSD one and more dislike Linux one. IMHO this is matter of taste. By the way is this your first feeling or you have some experience with BSD hacking? (e.q. try to start programming using other language or other environment, the first feeling would be the same) rik >and i've a comment here , i think the freebsd kernel source files >aren't well organized as linux ones. >_______________________________________________ >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 Fri Apr 1 18:06:07 2005 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 CE6F416A4CE; Fri, 1 Apr 2005 18:06:07 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 532E143D39; Fri, 1 Apr 2005 18:06:07 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) j31I4F0e059406; Fri, 1 Apr 2005 10:04:15 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id j31I4Ens059405; Fri, 1 Apr 2005 10:04:14 -0800 (PST) (envelope-from dillon) Date: Fri, 1 Apr 2005 10:04:14 -0800 (PST) From: Matthew Dillon Message-Id: <200504011804.j31I4Ens059405@apollo.backplane.com> To: Bruce Evans References: <423C15C5.6040902@fsn.hu> <20050327133059.3d68a78c@Magellan.Leidinger.net> <5bbfe7d405032823232103d537@mail.gmail.com> <424A23A8.5040109@ec.rr.com><20050330130051.GA4416@VARK.MIT.EDU> <200504010315.j313FGLn056122@apollo.backplane.com> <20050401215011.R24396@delplex.bde.org> cc: Peter Jeremy cc: David Schultz cc: hackers@freebsd.org cc: jason henson cc: bde@freebsd.org Subject: Re: Fwd: 5-STABLE kernel build with icc broken 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: Fri, 01 Apr 2005 18:06:08 -0000 :> The use of the XMM registers is a cpu optimization. Modern CPUs, :> especially AMD Athlon and Opterons, are more efficient with 128 bit :> moves then with 64 bit moves. I experimented with all sorts of :> configurations, including the use of special data caching instructions, :> but they had so many special cases and degenerate conditions that :> I found that simply using straight XMM instructions, reading as big :> a glob as possible, then writing the glob, was by far the best solution. : :Are you sure about that? The amd64 optimization manual says (essentially) :that big globs are bad, and my benchmarks confirm this. The best glob size :is 128 bits according to my benchmarks. This can be obtained using 2 :... : :Unfortunately (since I want to avoid using both MMX and XMM), I haven't :managed to make copying through 64-integer registers work as well. :Copying 128 bits at a time using 2 pairs of movq's through integer :registers gives only 7.9GB/sec. movq through MMX is never that slow. :However, movdqu through xmm is even slower (7.4GB/sec). : :The fully cached case is too unrepresentative of normal use, and normal :(partially cached) use is hard to bencmark, so I normally benchmark :the fully uncached case. For that, movnt* is best for benchmarks but :not for general use, and it hardly matters which registers are used. Yah, I'm pretty sure. I tested the fully cached (L1), partially cached (L2), and the fully uncached cases. I don't have a logic analyzer but what I think is happening is that the cpu's write buffer is messing around with the reads and causing extra RAS cycles to occur. I also tested using various combinations of movdqa, movntdq, and prefetcha. carefully arranged non-temporal and/or prefetch instructions were much faster for the uncached case, but much, MUCH slower for the partially cached (L2) or fully (L1) cached case, making them unsuitable for a generic copy. I am rather miffed that AMD screwed up the non-temporal instructions so badly. I also think there might be some odd instruction pipeline effects that skew the results when only one or two instructions are between the load into an %xmm register and the store from the same register. I tried using 2, 4, and 8 XMM registers. 8 XMM registers seemed to work the best. Of course, I primarily tested on an Athlon 64 3200+, so YMMV. (One of the first Athlon 64's, so it has a 1MB L2 cache). :> The key for fast block copying is to not issue any memory writes other :> then those related directly to the data being copied. This avoids :> unnecessary RAS cycles which would otherwise kill copying performance. :> In tests I found that copying multi-page blocks in a single loop was :> far more efficient then copying data page-by-page precisely because :> page-by-page copying was too complex to be able to avoid extranious :> writes to memory unrelated to the target buffer inbetween each page copy. : :By page-by-page, do you mean prefetch a page at a time into the L1 :cache? No, I meant that copying taking, e.g. a vm_page_t array and doing page-by-page mappings copying in 4K chunks seems to be a lot slower then doing a linear mapping of the entire vm_page_t array and doing one big copy. Literally the same code, just rearranged a bit. Just writing to the stack in between each page was enough to throw it off. :I've noticed strange loss (apparently) from extraneous reads or writes :more for benchmarks that do just (very large) writes. An at least old :Celerons and AthlonXPs, the writes go straight to the L1/L2 caches :(unless you use movntq on AthlonXP's). The caches are flushed to main :memory some time later, apparently not very well since some pages take :more than twice as long to write as others (as seen by the writer :filling the caches), and the slow case happens enough to affect the :average write speed by up to 50%. This problem can be reduced by :putting memory bank bits in the page colors. This is hard to get right :even for the simple unrepresentative case of large writes. : :Bruce I've seen the same effects and come to the same conclusion. The copy code I eventually settled on was this (taken from my i386/bcopy.s). It isn't as fast as using movntdq for the fully uncached case, but it seems to perform in the system the best because the data tends to be accessed and in the cache by someone in real life (e.g. source data tends to be in the cache even if the device driver doesn't touch the target data). I wish AMD had made movntdq work the same as movdqa for the case where the data was already in the cache, then movntdq would have been the clear winner. The prefetchnta I have commented out seemed to improve performance, but it requires 3dNOW and I didn't want to NOT have an MMX copy mode for cpu's with MMX but without 3dNOW. Prefetching less then 128 bytes did not help, and prefetching greater then 128 bytes (e.g. 256(%esi)) seemed to cause extra RAS cycles. It was unbelievably finicky, not at all what I expected. [ mmx_save_block does a 2048 check on the length and the FPU setup and kernel fpu lock bit ] ENTRY(asm_xmm_bcopy) MMX_SAVE_BLOCK(asm_generic_bcopy) cmpl %esi,%edi /* if (edi < esi) fwd copy ok */ jb 1f addl %ecx,%esi cmpl %esi,%edi /* if (edi < esi + count) do bkwrds copy */ jb 10f subl %ecx,%esi 1: movl %esi,%eax /* skip xmm if the data is not aligned */ andl $15,%eax jnz 5f movl %edi,%eax andl $15,%eax jz 3f jmp 5f SUPERALIGN_TEXT 2: movdqa (%esi),%xmm0 movdqa 16(%esi),%xmm1 movdqa 32(%esi),%xmm2 movdqa 48(%esi),%xmm3 movdqa 64(%esi),%xmm4 movdqa 80(%esi),%xmm5 movdqa 96(%esi),%xmm6 movdqa 112(%esi),%xmm7 /*prefetchnta 128(%esi) 3dNOW */ addl $128,%esi /* * movdqa or movntdq can be used. */ movdqa %xmm0,(%edi) movdqa %xmm1,16(%edi) movdqa %xmm2,32(%edi) movdqa %xmm3,48(%edi) movdqa %xmm4,64(%edi) movdqa %xmm5,80(%edi) movdqa %xmm6,96(%edi) movdqa %xmm7,112(%edi) addl $128,%edi 3: subl $128,%ecx jae 2b addl $128,%ecx jz 6f jmp 5f [ fall through to loop to handle blocks less then 128 bytes ] SUPERALIGN_TEXT 4: movq (%esi),%mm0 movq 8(%esi),%mm1 movq 16(%esi),%mm2 movq 24(%esi),%mm3 ... 10: [ backwards copy code ... ] -Matt Matthew Dillon From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 1 18:18:54 2005 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 699E116A4CE; Fri, 1 Apr 2005 18:18:54 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B5BE43D31; Fri, 1 Apr 2005 18:18:54 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) j31IIA0e059472; Fri, 1 Apr 2005 10:18:10 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id j31IIAM3059471; Fri, 1 Apr 2005 10:18:10 -0800 (PST) (envelope-from dillon) Date: Fri, 1 Apr 2005 10:18:10 -0800 (PST) From: Matthew Dillon Message-Id: <200504011818.j31IIAM3059471@apollo.backplane.com> To: Bruce Evans References: <423C15C5.6040902@fsn.hu> <20050327133059.3d68a78c@Magellan.Leidinger.net> <5bbfe7d405032823232103d537@mail.gmail.com> <424A23A8.5040109@ec.rr.com><20050330130051.GA4416@VARK.MIT.EDU> <200504010315.j313FGLn056122@apollo.backplane.com> <20050401215011.R24396@delplex.bde.org> cc: Peter Jeremy cc: David Schultz cc: hackers@freebsd.org cc: jason henson cc: bde@freebsd.org Subject: Re: Fwd: 5-STABLE kernel build with icc broken 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: Fri, 01 Apr 2005 18:18:54 -0000 Here is the core of the FPU setup and restoration code for the kernel bcopy in DragonFly, from i386/bcopy.s. DragonFly uses the TD_SAVEFPU-is-a-pointer method that was outlined in the original comment in the FreeBSD code. I further enhance the algorithm to guarentee that the FPU is in a sane state (does not require any further initialization other then a clts) if userland has NOT used it. However, there are definitely some race cases that must be considered (see the comments). The on-fault handling in DragonFly is stackable (which further simplifies the whole mess of on-fault vs non-on-fault copying code) and the DFly bcopy just sets up the frame for it whether or not the onfault handling is actually needed. This could be further optimized, but I had already spent at least a month on it and had to move on to other things. In particular, the setting of CR0_TS and the restoration of TD_SAVEFPU could be moved to the syscall-return code, so multiple in-kernel bcopy operations could be issued without any further FPU setup or teardown. -Matt /* * RACES/ALGORITHM: * * If gd_npxthread is not NULL we must save the application's * current FP state to the current save area and then NULL * out gd_npxthread to interlock against new interruptions * changing the FP state further. * * If gd_npxthread is NULL the FP unit is in a known 'safe' * state and may be used once the new save area is installed. * * race(1): If an interrupt occurs just prior to calling fxsave * all that happens is that fxsave gets a npxdna trap, restores * the app's environment, and immediately traps, restores, * and saves it again. * * race(2): No interrupt can safely occur after we NULL-out * npxthread until we fninit, because the kernel assumes that * the FP unit is in a safe state when npxthread is NULL. It's * more convenient to use a cli sequence here (it is not * considered to be in the critical path), but a critical * section would also work. * * race(3): The FP unit is in a known state (because npxthread * was either previously NULL or we saved and init'd and made * it NULL). This is true even if we are preempted and the * preempting thread uses the FP unit, because it will be * fninit's again on return. ANY STATE WE SAVE TO THE FPU MAY * BE DESTROYED BY PREEMPTION WHILE NPXTHREAD IS NULL! However, * an interrupt occuring inbetween clts and the setting of * gd_npxthread may set the TS bit again and cause the next * npxdna() to panic when it sees a non-NULL gd_npxthread. * * We can safely set TD_SAVEFPU to point to a new uninitialized * save area and then set GD_NPXTHREAD to non-NULL. If an * interrupt occurs after we set GD_NPXTHREAD, all that happens * is that the safe FP state gets saved and restored. We do not * need to fninit again. * * We can safely clts after setting up the new save-area, before * installing gd_npxthread, even if we get preempted just after * calling clts. This is because the FP unit will be in a safe * state while gd_npxthread is NULL. Setting gd_npxthread will * simply lock-in that safe-state. Calling clts saves * unnecessary trap overhead since we are about to use the FP * unit anyway and don't need to 'restore' any state prior to * that first use. */ #define MMX_SAVE_BLOCK(missfunc) \ cmpl $2048,%ecx ; \ jb missfunc ; \ movl MYCPU,%eax ; /* EAX = MYCPU */ \ btsl $1,GD_FPU_LOCK(%eax) ; \ jc missfunc ; \ pushl %ebx ; \ pushl %ecx ; \ movl GD_CURTHREAD(%eax),%edx ; /* EDX = CURTHREAD */ \ movl TD_SAVEFPU(%edx),%ebx ; /* save app save area */\ addl $TDPRI_CRIT,TD_PRI(%edx) ; \ cmpl $0,GD_NPXTHREAD(%eax) ; \ je 100f ; \ fxsave 0(%ebx) ; /* race(1) */ \ movl $0,GD_NPXTHREAD(%eax) ; /* interlock intr */ \ clts ; \ fninit ; /* race(2) */ \ 100: ; \ leal GD_SAVEFPU(%eax),%ecx ; \ movl %ecx,TD_SAVEFPU(%edx) ; \ clts ; \ movl %edx,GD_NPXTHREAD(%eax) ; /* race(3) */ \ subl $TDPRI_CRIT,TD_PRI(%edx) ; /* crit_exit() */ \ cmpl $0,GD_REQFLAGS(%eax) ; \ je 101f ; \ cmpl $TDPRI_CRIT,TD_PRI(%edx) ; \ jge 101f ; \ call lwkt_yield_quick ; \ /* note: eax,ecx,edx destroyed */ \ 101: ; \ movl (%esp),%ecx ; \ movl $mmx_onfault,(%esp) ; /* * When restoring the application's FP state we must first clear * npxthread to prevent further saves, then restore the pointer * to the app's save area. We do not have to (and should not) * restore the app's FP state now. Note that we do not have to * call fninit because our use of the FP guarentees that it is in * a 'safe' state (at least for kernel use). * * NOTE: it is not usually safe to mess with CR0 outside of a * critical section, because TS may get set by a preemptive * interrupt. However, we *can* race a load/set-ts/store against * an interrupt doing the same thing. */ #define MMX_RESTORE_BLOCK \ addl $4,%esp ; \ MMX_RESTORE_BLOCK2 #define MMX_RESTORE_BLOCK2 \ movl MYCPU,%ecx ; \ movl GD_CURTHREAD(%ecx),%edx ; \ movl $0,GD_NPXTHREAD(%ecx) ; \ movl %ebx,TD_SAVEFPU(%edx) ; \ smsw %ax ; \ popl %ebx ; \ orb $CR0_TS,%al ; \ lmsw %ax ; \ movl $0,GD_FPU_LOCK(%ecx) From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 1 18:38:41 2005 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 EDFF616A4CE for ; Fri, 1 Apr 2005 18:38:41 +0000 (GMT) Received: from mail26.sea5.speakeasy.net (mail26.sea5.speakeasy.net [69.17.117.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88D2A43D58 for ; Fri, 1 Apr 2005 18:38:41 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 13684 invoked from network); 1 Apr 2005 18:38:41 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 1 Apr 2005 18:38:40 -0000 Received: from [10.50.41.231] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j31IcX0j034575; Fri, 1 Apr 2005 13:38:34 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-hackers@FreeBSD.org Date: Fri, 1 Apr 2005 11:20:27 -0500 User-Agent: KMail/1.6.2 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <200504011120.27285.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: William Michael Grim cc: Poul-Henning Kamp cc: Robert Watson Subject: Re: 4BSD Scheduler Problem on 5.3 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: Fri, 01 Apr 2005 18:38:42 -0000 On Thursday 31 March 2005 08:03 pm, Robert Watson wrote: > On Thu, 31 Mar 2005, John Baldwin wrote: > > On Thursday 31 March 2005 03:38 pm, William Michael Grim wrote: > > > Hello. > > > > > > I keep having kernel panics every couple weeks on my system. It occurs > > > in the sched_switch() function. There are several other statements in > > > the backtrace involving "??"; what are those? > > > > > > I have attached the dump output and system info to this email. Any > > > feedback would be helpful. > > > > > > Thanks so much for your help. > > > > The real trace ends with Xint0x80_syscall(). The rest after that is > > garbage memory. Your real problem is in exit1() or ttywakeup(). Since > > ttywakeup() doesn't call exit1() (AFAIK), the exit1() frame is probably > > bogus (gdb doesn't grok trapframes maybe?) and the real bug is a NULL > > pointer deref in ttywakeup(). Perhaps it's a bug in the ptc driver? > > (ptcopen is in the trace). What is the ptc driver anyway? > > I think we have a race in -STABLE relating to tty wakeups and > open/close/device teardown. I've seen a panic relating to sio during a > tty close on RELENG_5 about 5-6 months ago, but was unable to get a dump. > Scott has since fixed dumps with twe, but I've not yet been able to get > the bug to recur. I'll give it another try. Sounds very plausible. Does Poul-Henning have any ideas? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 1 18:52:43 2005 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 95DB016A4CE; Fri, 1 Apr 2005 18:52:43 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7BAC43D39; Fri, 1 Apr 2005 18:52:42 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.3/8.13.1) with ESMTP id j31Iqc6o089198; Fri, 1 Apr 2005 20:52:38 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: John Baldwin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 01 Apr 2005 11:20:27 CDT." <200504011120.27285.jhb@FreeBSD.org> Date: Fri, 01 Apr 2005 20:52:38 +0200 Message-ID: <89197.1112381558@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: William Michael Grim cc: freebsd-hackers@FreeBSD.org cc: Robert Watson Subject: Re: 4BSD Scheduler Problem on 5.3 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: Fri, 01 Apr 2005 18:52:43 -0000 In message <200504011120.27285.jhb@FreeBSD.org>, John Baldwin writes: >> I think we have a race in -STABLE relating to tty wakeups and >> open/close/device teardown. I've seen a panic relating to sio during a >> tty close on RELENG_5 about 5-6 months ago, but was unable to get a dump. >> Scott has since fixed dumps with twe, but I've not yet been able to get >> the bug to recur. I'll give it another try. > >Sounds very plausible. Does Poul-Henning have any ideas? Is this before or after my tty changes ? There is a general nastyness about ttys/sessions/exit which I have never really felt comfortable about. My hope is that I have solved it by refcounting the tty structure. So if this is before my changes: "Yeah, known (but rare) issue)" If after my changes: "D**N!" -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 1 19:07:51 2005 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 2EE4916A4CE; Fri, 1 Apr 2005 19:07:51 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9DCD43D46; Fri, 1 Apr 2005 19:07:50 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 44DF646B16; Fri, 1 Apr 2005 14:07:50 -0500 (EST) Date: Fri, 1 Apr 2005 19:04:29 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <89197.1112381558@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@FreeBSD.org cc: William Michael Grim cc: John Baldwin Subject: Re: 4BSD Scheduler Problem on 5.3 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: Fri, 01 Apr 2005 19:07:51 -0000 On Fri, 1 Apr 2005, Poul-Henning Kamp wrote: > In message <200504011120.27285.jhb@FreeBSD.org>, John Baldwin writes: > > >> I think we have a race in -STABLE relating to tty wakeups and > >> open/close/device teardown. I've seen a panic relating to sio during a > >> tty close on RELENG_5 about 5-6 months ago, but was unable to get a dump. > >> Scott has since fixed dumps with twe, but I've not yet been able to get > >> the bug to recur. I'll give it another try. > > > >Sounds very plausible. Does Poul-Henning have any ideas? > > Is this before or after my tty changes ? > > There is a general nastyness about ttys/sessions/exit which I have never > really felt comfortable about. My hope is that I have solved it by > refcounting the tty structure. > > So if this is before my changes: "Yeah, known (but rare) issue)" > > If after my changes: "D**N!" The instance of the panic I saw was in RELENG_5 in January when using a serial console. Here's a copy of the e-mail I sent to stable@ when it occurred. It's a little weak on the debugging side because I couldn't get a dump and didn't have a kernel with symbols easily on hand, but my reading was that there was a race relating to open/close and device events. Robert N M Watson Date: Sun, 23 Jan 2005 16:51:14 +0000 (GMT) From: Robert Watson To: stable@FreeBSD.org Cc: imp@FreeBSD.org Subject: NULL pointer deref in sioopen() suggests a close/open race on sio device? Ran into the following panic on a 5-STABLE box this morning, which occurred after hitting Ctrl-D to close a login session on a serial console (ttyd0 at 9600 bps): login: Jan 23 10:43:27 fledge login: 2 LOGIN FAILURES ON ttyd0 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x1c fault code = supervisor write, page not present instruction pointer = 0x8:0xc051537b stack pointer = 0x10:0xe7345988 frame pointer = 0x10:0xe7345994 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 45092 (getty) [thread pid 45092 tid 100201 ] Stopped at knote+0x27: cmpxchgl %ecx,0x1c(%edx) db> show pcpu cpuid = 0 curthread = 0xc290d190: pid 45092 "getty" curpcb = 0xe7345da0 fpcurthread = 0xc290d190: pid 45092 "getty" idlethread = 0xc22644b0: pid 11 "idle" APIC ID = 0 currentldt = 0x30 db> trace Tracing pid 45092 tid 100201 td 0xc290d190 knote(c264e098,0,0,c290d190,e73459c4) at knote+0x27 ttwwakeup(c264e000) at ttwwakeup+0xc8 comstart(c264e000) at comstart+0x385 comparam(c264e000,c264e0a4,c264e000,3,0) at comparam+0x253 sioopen(c079f060,3,2000,c290d190,c078e6a0) at sioopen+0x1df spec_open(e7345a84,e7345b40,c058d585,e7345a84,180) at spec_open+0x2b6 spec_vnoperate(e7345a84) at spec_vnoperate+0x13 vn_open_cred(e7345be4,e7345ce4,c08,c2261d80,0) at vn_open_cred+0x419 vn_open(e7345be4,e7345ce4,c08,0,c4289b58) at vn_open+0x1e kern_open(c290d190,804f8e0,0,3,bfbfee18) at kern_open+0xe3 open(c290d190,e7345d14,3,0,292) at open+0x18 syscall(2f,2f,2f,804f8e0,0) at syscall+0x27b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (5, FreeBSD ELF32, open), eip = 0x280d155b, esp = 0xbfbfedec, ebp = 0xbfbfee18 --- The ps list is a bit boring, but the primary interesting thing is that it looks like the close was going on in one thread just about when the sio swi was scheduled to run also: db> ps pid proc uarea uid ppid pgrp flag stat wmesg wchan cmd 45092 c6762388 e7387000 0 1 1 0004000 [CPU 0] getty ... 132 c235954c e4fbf000 0 0 0 000020c [RUNQ] swi5: clock sio I didn't have a kernel with debugging symbols on-hand, but the above address in knote() is a cmpxchg early in the function, which means it's likely the conditional call to mtx_lock() hitting a NULL mutex pointer for kl_lock. This in turn suggests that something has called ttyrel/tty_close on the TTY in a race with the open, or otherwise NULL'd that pointer via knlist_destroy(). Anyone have any pointers on this one? The TTY code is not my forte... Robert N M Watson From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 1 20:15:57 2005 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 3413416A4CE for ; Fri, 1 Apr 2005 20:15:57 +0000 (GMT) Received: from siue.dnsalias.net (cv517-237.cv.siue.edu [146.163.219.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DC4643D41 for ; Fri, 1 Apr 2005 20:15:56 +0000 (GMT) (envelope-from grimw@siue.dnsalias.net) Received: by siue.dnsalias.net (Postfix, from userid 1001) id F2885C120; Fri, 1 Apr 2005 14:15:51 -0600 (CST) Date: Fri, 1 Apr 2005 14:15:51 -0600 From: William Michael Grim To: hackers@freebsd.org Message-ID: <20050401201551.GA39457@siue.dnsalias.net> References: <200504011120.27285.jhb@FreeBSD.org> <89197.1112381558@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89197.1112381558@critter.freebsd.dk> User-Agent: Mutt/1.4.2.1i Subject: Re: 4BSD Scheduler Problem on 5.3 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: Fri, 01 Apr 2005 20:15:57 -0000 I'm not sure if it's before or after your changes, Poul-Henning. If there is a newer -RELEASE I can upgrade too, I will do that. I don't really want to upgrade to -STABLE, but I will also do that to relieve the issue if necessary. Just give me a recommendation on to either update RELEASE beyond -p1 or to go ahead and update to -STABLE. I appreciate the help all of you have been. Thanks much. On Fri, Apr 01, 2005 at 08:52:38PM +0200, Poul-Henning Kamp wrote: > In message <200504011120.27285.jhb@FreeBSD.org>, John Baldwin writes: > > >> I think we have a race in -STABLE relating to tty wakeups and > >> open/close/device teardown. I've seen a panic relating to sio during a > >> tty close on RELENG_5 about 5-6 months ago, but was unable to get a dump. > >> Scott has since fixed dumps with twe, but I've not yet been able to get > >> the bug to recur. I'll give it another try. > > > >Sounds very plausible. Does Poul-Henning have any ideas? > > Is this before or after my tty changes ? > > There is a general nastyness about ttys/sessions/exit which I have > never really felt comfortable about. My hope is that I have solved > it by refcounting the tty structure. > > So if this is before my changes: "Yeah, known (but rare) issue)" > > If after my changes: "D**N!" > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -- William Michael Grim Student, Southern Illinois University at Edwardsville Unix Network Administrator, SIUE, Computer Science dept. Phone: (217) 341-6552 Email: wgrim@siue.edu From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 2 04:09:44 2005 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 5787C16A4CF for ; Sat, 2 Apr 2005 04:09:44 +0000 (GMT) Received: from ns2.alphaque.com (ns2.alphaque.com [202.75.47.153]) by mx1.FreeBSD.org (Postfix) with SMTP id B73B643D39 for ; Sat, 2 Apr 2005 04:09:42 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: (qmail 76806 invoked by uid 0); 2 Apr 2005 04:09:41 -0000 Received: from lucifer.net-gw.com (HELO prophet.alphaque.com) (202.75.47.153) by lucifer.net-gw.com with SMTP; 2 Apr 2005 04:09:41 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by prophet.alphaque.com (8.13.3/8.13.3) with ESMTP id j323cPaM002316; Sat, 2 Apr 2005 11:38:25 +0800 (MYT) (envelope-from dinesh@alphaque.com) Message-ID: <424E13B1.4090607@alphaque.com> Date: Sat, 02 Apr 2005 11:38:25 +0800 From: Dinesh Nair User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050326 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <42334057.5070705@gmx.net> <42492F0B.3040704@alphaque.com> <424B7A2D.5060902@alphaque.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------030409040900090609060302" cc: freebsd-hackers@freebsd.org cc: freebsd-acpi@freebsd.org Subject: Re: enable acpi 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: Sat, 02 Apr 2005 04:09:44 -0000 This is a multi-part message in MIME format. --------------030409040900090609060302 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit On 03/31/05 20:51 John Baldwin said the following: > The problem is that the taskqueue_swi in 4.x doesn't have a thread > context that can be slept on via tsleep(). The fix would be to create a > kthread in which to run the ACPI tasks. 4.x already has one such > kthread for the taskqueue_thread taskqueue that you could use as a > reference if you wish to do this yourself. thanx for the pointer, john. with your explanation, the fix was simple. since applying this, it's not paniced in over 24 hours of continuous running. patch attached. i'll also raise a PR for this. -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.alphaque.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ --------------030409040900090609060302 Content-Type: text/plain; name="sys::dev::acpica::Osd::OsdSchedule.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sys::dev::acpica::Osd::OsdSchedule.c.patch" --- sys/dev/acpica/Osd/OsdSchedule.c.orig Thu Mar 31 00:35:42 2005 +++ sys/dev/acpica/Osd/OsdSchedule.c Fri Apr 1 13:55:00 2005 @@ -192,7 +192,7 @@ TASK_INIT(&at->at_task, pri, AcpiOsExecuteQueue, at); #if __FreeBSD_version < 500000 - taskqueue_enqueue(taskqueue_swi, (struct task *)at); + taskqueue_enqueue(taskqueue_thread, (struct task *)at); #else taskqueue_enqueue(taskqueue_acpi, (struct task *)at); #endif --------------030409040900090609060302-- From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 2 06:50:54 2005 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 21E5116A4CE for ; Sat, 2 Apr 2005 06:50:54 +0000 (GMT) Received: from meisai.numachi.com (meisai.numachi.com [198.175.254.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 3CDB243D1D for ; Sat, 2 Apr 2005 06:50:53 +0000 (GMT) (envelope-from reichert@numachi.com) Received: (qmail 22520 invoked from network); 2 Apr 2005 06:50:52 -0000 Received: from natto.numachi.com (198.175.254.216) by meisai.numachi.com with SMTP; 2 Apr 2005 06:50:52 -0000 Received: (qmail 55289 invoked by uid 1001); 2 Apr 2005 06:50:52 -0000 Date: Sat, 2 Apr 2005 01:50:52 -0500 From: Brian Reichert To: freebsd-hackers@freebsd.org Message-ID: <20050402065052.GT44514@numachi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.8i Subject: which Wifi cards can be used for a WAP? 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: Sat, 02 Apr 2005 06:50:54 -0000 I'm looking at the impressive list of wireless network cards supported by FreeBSD here: http://www.freebsd.org/releases/5.3R/hardware-i386.html#WLAN But, I have the specific interest of building an 802.11g WAP. I seem to recall lore that not all Wifi cards could be used this way (something about needing to be able to run in ad-hoc mode, or some such.) Is my memory faulty, or can any old 802.11g Wifi card be pressed into service? I'm specifically looking into various PCI-based cards, if that affects anyone's advice... (If someone can recomment a better forum for the question; I'll accept advice on that matter, too. :) Of course, any specific advice about good antenna, good driver/throughput, etc, would also be accepted gleefully... -- Brian Reichert 55 Crystal Ave. #286 Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 2 06:06:00 2005 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 CABAC16A4CE; Sat, 2 Apr 2005 06:06:00 +0000 (GMT) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64CD143D46; Sat, 2 Apr 2005 06:06:00 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-184-204.dsl.snfc21.pacbell.net [64.171.184.204])j3265Inr018431; Sat, 2 Apr 2005 01:05:19 -0500 Message-ID: <424E363B.2010506@root.org> Date: Fri, 01 Apr 2005 22:05:47 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dinesh Nair References: <42334057.5070705@gmx.net> <42492F0B.3040704@alphaque.com> <424B7A2D.5060902@alphaque.com> <424E13B1.4090607@alphaque.com> In-Reply-To: <424E13B1.4090607@alphaque.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 02 Apr 2005 12:49:13 +0000 cc: freebsd-hackers@freebsd.org cc: freebsd-acpi@freebsd.org Subject: Re: enable acpi 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: Sat, 02 Apr 2005 06:06:01 -0000 Dinesh Nair wrote: > On 03/31/05 20:51 John Baldwin said the following: > >> The problem is that the taskqueue_swi in 4.x doesn't have a thread >> context that can be slept on via tsleep(). The fix would be to create >> a kthread in which to run the ACPI tasks. 4.x already has one such >> kthread for the taskqueue_thread taskqueue that you could use as a >> reference if you wish to do this yourself. > > > thanx for the pointer, john. with your explanation, the fix was simple. > since applying this, it's not paniced in over 24 hours of continuous > running. patch attached. i'll also raise a PR for this. Don't bother, I already committed it. -- Nate From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 2 10:49:57 2005 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 396A516A4CE; Sat, 2 Apr 2005 10:49:57 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F45E43D45; Sat, 2 Apr 2005 10:49:56 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])j32AnkHn024764; Sat, 2 Apr 2005 20:49:46 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) j32AnfMq016606; Sat, 2 Apr 2005 20:49:42 +1000 Date: Sat, 2 Apr 2005 20:49:41 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Matthew Dillon In-Reply-To: <200504011804.j31I4Ens059405@apollo.backplane.com> Message-ID: <20050402191529.Q1235@epsplex.bde.org> References: <423C15C5.6040902@fsn.hu> <20050327133059.3d68a78c@Magellan.Leidinger.net> <5bbfe7d405032823232103d537@mail.gmail.com> <424A23A8.5040109@ec.rr.com><20050330130051.GA4416@VARK.MIT.EDU> <200504010315.j313FGLn056122@apollo.backplane.com> <200504011804.j31I4Ens059405@apollo.backplane.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sat, 02 Apr 2005 12:49:13 +0000 cc: Peter Jeremy cc: David Schultz cc: hackers@FreeBSD.org cc: jason henson cc: bde@FreeBSD.org Subject: Re: Fwd: 5-STABLE kernel build with icc broken 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: Sat, 02 Apr 2005 10:49:57 -0000 On Fri, 1 Apr 2005, Matthew Dillon wrote: > :> The use of the XMM registers is a cpu optimization. Modern CPUs, > :> especially AMD Athlon and Opterons, are more efficient with 128 bit > :> moves then with 64 bit moves. I experimented with all sorts of > :> configurations, including the use of special data caching instructions, > :> but they had so many special cases and degenerate conditions that > :> I found that simply using straight XMM instructions, reading as big > :> a glob as possible, then writing the glob, was by far the best solution. > : > :Are you sure about that? The amd64 optimization manual says (essentially) This is in 25112.PDF section 5.16 ("Interleave Loads and Stores", with 128 bits of loads followed by 128 bits of stores). > :that big globs are bad, and my benchmarks confirm this. The best glob size > :is 128 bits according to my benchmarks. This can be obtained using 2 > :... > : > :Unfortunately (since I want to avoid using both MMX and XMM), I haven't > :managed to make copying through 64-integer registers work as well. > :Copying 128 bits at a time using 2 pairs of movq's through integer > :registers gives only 7.9GB/sec. movq through MMX is never that slow. > :However, movdqu through xmm is even slower (7.4GB/sec). I forgot many of my earlier conclusions when I wrote the above. The speeds between 7.4GB/sec and 12.9GB/sec for the fully (L1) cached case are almost irrelevant. They basically just tell how well we have used the instruction bandwidth. Plain movsq uses it better and gets 15.9GB/sec. I believe 15.9GB/sec is from saturating the L1 cache. The CPU is an Athlon64 and its clock frequency is 1994 MHz, and I think the max L1 cache bandwidth is with a 16-byte load and store per cycle; 16*1994*10^6 is 15.95GB/sec (disk manufacturers GB's). Plain movsq is best here for many other cases too... > : > :The fully cached case is too unrepresentative of normal use, and normal > :(partially cached) use is hard to bencmark, so I normally benchmark > :the fully uncached case. For that, movnt* is best for benchmarks but > :not for general use, and it hardly matters which registers are used. > > Yah, I'm pretty sure. I tested the fully cached (L1), partially > cached (L2), and the fully uncached cases. I don't have a logic By the partially cached case, I meant the case where some of the source and/or target addresses are in the L1 or L2 cache, but you don't really the chance that they are there (or should be there after the copy), so you can only guess the best strategy. > analyzer but what I think is happening is that the cpu's write buffer > is messing around with the reads and causing extra RAS cycles to occur. > I also tested using various combinations of movdqa, movntdq, and > prefetcha. Somehow I'm only seeing small variations from different strategies now, with all tests done in userland on an Athlon64 system (and on athlonXP systems for reference). Using XMM or MMX can be twice as fast on the AthlonXPs, but movsq is absolutely the fastest in many cases on the Athlon64, and is < 5% slower than the fastest in all cases (except for the fully uncached case since it can't do nontemporal stores), so it is the best general method. >... > I also think there might be some odd instruction pipeline effects > that skew the results when only one or two instructions are between > the load into an %xmm register and the store from the same register. > I tried using 2, 4, and 8 XMM registers. 8 XMM registers seemed to > work the best. I'm getting only small variations from different load/store patterns. > > Of course, I primarily tested on an Athlon 64 3200+, so YMMV. (One > of the first Athlon 64's, so it has a 1MB L2 cache). My test system is very similar: %%% CPU: AMD Athlon(tm) 64 Processor 3400+ (1994.33-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0xf48 Stepping = 8 Features=0x78bfbff AMD Features=0xe0500800 L1 2MB data TLB: 8 entries, fully associative L1 2MB instruction TLB: 8 entries, fully associative L1 4KB data TLB: 32 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB unified TLB: 0 entries, disabled/not present L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative %%% > The prefetchnta I have commented out seemed to improve performance, > but it requires 3dNOW and I didn't want to NOT have an MMX copy mode > for cpu's with MMX but without 3dNOW. Prefetching less then 128 bytes > did not help, and prefetching greater then 128 bytes (e.g. 256(%esi)) > seemed to cause extra RAS cycles. It was unbelievably finicky, not at > all what I expected. Prefetching is showing some very good effects here, but there are MD complications: - the Athlon[32] optimization manual says that block prefetch is sometimes better than prefetchnta, and gives examples. The reason is that you can schedule the block prefetch. - alc@ and/or the Athlon64 optimization manual say that prefetchnta now works better. - testing shows that prefetchnta does work better on my Athlon64 in some cases, but in the partially cached case (source in the L2 cache) it reduces the bandwidth by almost a factor of 2: %%% copyH: 2562223788 B/s ( 390253 us) (778523741 tsc) (movntps) copyI: 1269129646 B/s ( 787875 us) (1571812294 tsc) (movntps with prefetchnta) copyJ: 2513196704 B/s ( 397866 us) (793703852 tsc) (movntps with block prefetch) copyN: 2562020272 B/s ( 390284 us) (778737276 tsc) (movntq) copyO: 1279569209 B/s ( 781447 us) (1559037466 tsc) (movntq with prefetchnta) copyP: 2561869298 B/s ( 390307 us) (778732346 tsc) (movntq with block prefetch) %%% The machine has PC2700 memory so we can hope for a copy bandwidth of nearly 2.7GB/sec for repeatedly copying a buffer of size 160K as the benchmark does, since the buffer should stay in the L2 cache. We actually get 2.5+GB/sec here and for all bzero benchmarks using movnt*, but when we use prefetchnta we get about half this, and not much more than for the fully uncached case (1.2GB/sec). The corresponding speeds for the fully uncached case (copying 1600K) are: %%% copyH: 1061395711 B/s ( 941613 us) (1879293692 tsc) (movntps) copyI: 1246904647 B/s ( 801524 us) (1599118394 tsc) (movntps with prefetchnta) copyJ: 1227740822 B/s ( 814035 us) (1624787631 tsc) (movntps with block prefetch) copyN: 1049642023 B/s ( 952157 us) (1900292204 tsc) (movntq) copyO: 1247088242 B/s ( 801406 us) (1598888249 tsc) (movntq with prefetchnta) copyP: 1226714585 B/s ( 814716 us) (1625985669 tsc) (movntq with block prefetch) %%% For the fully uncached case, the speeds for simple copying methods are all about 0.64GB/sec on this machine, and sophisticated methods that don't use nontemporal writes only improve this to 0.68GB/sec. Bruce From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 2 16:28:43 2005 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 910C916A4CE for ; Sat, 2 Apr 2005 16:28:43 +0000 (GMT) Received: from meisai.numachi.com (meisai.numachi.com [198.175.254.6]) by mx1.FreeBSD.org (Postfix) with SMTP id B747243D48 for ; Sat, 2 Apr 2005 16:28:42 +0000 (GMT) (envelope-from reichert@numachi.com) Received: (qmail 32583 invoked from network); 2 Apr 2005 16:28:42 -0000 Received: from natto.numachi.com (198.175.254.216) by meisai.numachi.com with SMTP; 2 Apr 2005 16:28:42 -0000 Received: (qmail 57909 invoked by uid 1001); 2 Apr 2005 16:28:42 -0000 Date: Sat, 2 Apr 2005 11:28:42 -0500 From: Brian Reichert To: freebsd-hackers@freebsd.org Message-ID: <20050402162842.GU44514@numachi.com> References: <20050402065052.GT44514@numachi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050402065052.GT44514@numachi.com> User-Agent: Mutt/1.5.8i Subject: Re: which Wifi cards can be used for a WAP? 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: Sat, 02 Apr 2005 16:28:43 -0000 On Sat, Apr 02, 2005 at 01:50:52AM -0500, Brian Reichert wrote: > I'm looking at the impressive list of wireless network cards supported > by FreeBSD here: > > http://www.freebsd.org/releases/5.3R/hardware-i386.html#WLAN > > But, I have the specific interest of building an 802.11g WAP. I > seem to recall lore that not all Wifi cards could be used this way > (something about needing to be able to run in ad-hoc mode, or some > such.) The ath(4) manpage speaks of a 'hostap' mode, but the manpage confuses me. First, it says: The driver may also be configured to operate in hostap mode. In this mode a host may function as an access point (base station). Then: Access points are different than operating in IBSS mode. They operate in BSS mode. So, I'm confused, which mode does a WAP need to be in, 'BSS' or 'hostap'? Quickie research on this 'hostap' mode (which I'd never heard of until I began this research) seems to be what I need, but the verbiage in the ath(4) manpage is throwing me... Anyway, a survey of the manpages for various WiFi drivers supporting 'hostap' mode seems to sum up as such: wi(4) Cards based on the Intersil PRISM chips, but I don't think any of them support 802.11g. at(4) I guess everything listed here, with a URL to an up-to-date list: In case anyone's following the same rabbit trail I am, on that search page, if I select: WLAN Product: PCI I get a huge list of PCI cards, and which 802.11 bands they support. (The search page won't let me exclude those cards that don't support 802.11g, but that subset it tiny.) That narrows my search, at this time, to 17 PCI cards supporting 802.11g. I'm currently assuming that anything on this list is indeed supported by FreeBSD's ath(4) driver. Please feel free to disabuse me of that notion... -- Brian Reichert 55 Crystal Ave. #286 Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 2 17:16:36 2005 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 AD8B316A4CE for ; Sat, 2 Apr 2005 17:16:36 +0000 (GMT) Received: from meisai.numachi.com (meisai.numachi.com [198.175.254.6]) by mx1.FreeBSD.org (Postfix) with SMTP id F1E5343D48 for ; Sat, 2 Apr 2005 17:16:35 +0000 (GMT) (envelope-from reichert@numachi.com) Received: (qmail 32997 invoked from network); 2 Apr 2005 17:16:35 -0000 Received: from natto.numachi.com (198.175.254.216) by meisai.numachi.com with SMTP; 2 Apr 2005 17:16:35 -0000 Received: (qmail 58167 invoked by uid 1001); 2 Apr 2005 17:16:35 -0000 Date: Sat, 2 Apr 2005 12:16:35 -0500 From: Brian Reichert To: freebsd-hackers@freebsd.org Message-ID: <20050402171635.GV44514@numachi.com> References: <20050402065052.GT44514@numachi.com> <20050402162842.GU44514@numachi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050402162842.GU44514@numachi.com> User-Agent: Mutt/1.5.8i Subject: Re: which Wifi cards can be used for a WAP? 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: Sat, 02 Apr 2005 17:16:36 -0000 On Sat, Apr 02, 2005 at 11:28:42AM -0500, Brian Reichert wrote: > I guess everything listed here, with a URL to an up-to-date list: > > In perusing many of these cards specs, I see many of them offer a 'turbo mode' of 108 Mbps. - Is this something magically supported by the hardware? By that, I mean: if I use a compatible WiFi card in a laptop, they'll just negotiate the higher rate, and as such the kernel driver has no impact? - I'm seeing 'turbo 802.11g' vs. 'Super G'. I haven't found any thing that tells me if these are synonyms, or if they are incompatable unofficial extansions of a spec. Does anyone here know? -- Brian Reichert 55 Crystal Ave. #286 Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 2 17:26:15 2005 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 4A13D16A4CF for ; Sat, 2 Apr 2005 17:26:15 +0000 (GMT) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4D5B43D41 for ; Sat, 2 Apr 2005 17:26:14 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (wlan033219.uni-rostock.de [139.30.33.219]) by hydra.bec.de (Postfix) with ESMTP id 1E76535707 for ; Sat, 2 Apr 2005 19:26:11 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1001) id 51FD37CF8; Sat, 2 Apr 2005 19:23:55 +0200 (CEST) Date: Sat, 2 Apr 2005 19:23:55 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20050402172355.GA1069@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20050402065052.GT44514@numachi.com> <20050402162842.GU44514@numachi.com> <20050402171635.GV44514@numachi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050402171635.GV44514@numachi.com> User-Agent: Mutt/1.5.9i Subject: Re: which Wifi cards can be used for a WAP? 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: Sat, 02 Apr 2005 17:26:15 -0000 On Sat, Apr 02, 2005 at 12:16:35PM -0500, Brian Reichert wrote: > In perusing many of these cards specs, I see many of them offer a > 'turbo mode' of 108 Mbps. That's a vendor-specific mode. I strongly advice you _against_ using it, it's using at least one additional channel and only adds speed for very short distances. If you follow the common recommendation of leaving one channel before and after the active channel, you end up using at least 5 channels for turbo mode compared to three for normal, it's not worth the trouble. Joerg From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 2 17:27:28 2005 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 3F26B16A4CE for ; Sat, 2 Apr 2005 17:27:28 +0000 (GMT) Received: from meisai.numachi.com (meisai.numachi.com [198.175.254.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 7CDF343D5D for ; Sat, 2 Apr 2005 17:27:27 +0000 (GMT) (envelope-from reichert@numachi.com) Received: (qmail 33076 invoked from network); 2 Apr 2005 17:27:26 -0000 Received: from natto.numachi.com (198.175.254.216) by meisai.numachi.com with SMTP; 2 Apr 2005 17:27:26 -0000 Received: (qmail 58229 invoked by uid 1001); 2 Apr 2005 17:27:26 -0000 Date: Sat, 2 Apr 2005 12:27:26 -0500 From: Brian Reichert To: freebsd-hackers@freebsd.org Message-ID: <20050402172726.GW44514@numachi.com> References: <20050402065052.GT44514@numachi.com> <20050402162842.GU44514@numachi.com> <20050402171635.GV44514@numachi.com> <20050402172355.GA1069@britannica.bec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050402172355.GA1069@britannica.bec.de> User-Agent: Mutt/1.5.8i Subject: Re: which Wifi cards can be used for a WAP? 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: Sat, 02 Apr 2005 17:27:28 -0000 On Sat, Apr 02, 2005 at 07:23:55PM +0200, Joerg Sonnenberger wrote: > That's a vendor-specific mode. I strongly advice you _against_ using it, > it's using at least one additional channel and only adds speed for very > short distances. If you follow the common recommendation of leaving one > channel before and after the active channel, you end up using at least > 5 channels for turbo mode compared to three for normal, it's not worth > the trouble. Ok, cool; thanks... > Joerg -- Brian Reichert 55 Crystal Ave. #286 Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 2 17:33:06 2005 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 0599F16A4CE for ; Sat, 2 Apr 2005 17:33:06 +0000 (GMT) Received: from meisai.numachi.com (meisai.numachi.com [198.175.254.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 3731F43D1D for ; Sat, 2 Apr 2005 17:33:05 +0000 (GMT) (envelope-from reichert@numachi.com) Received: (qmail 33105 invoked from network); 2 Apr 2005 17:33:04 -0000 Received: from natto.numachi.com (198.175.254.216) by meisai.numachi.com with SMTP; 2 Apr 2005 17:33:04 -0000 Received: (qmail 58270 invoked by uid 1001); 2 Apr 2005 17:33:04 -0000 Date: Sat, 2 Apr 2005 12:33:04 -0500 From: Brian Reichert To: freebsd-hackers@freebsd.org Message-ID: <20050402173304.GX44514@numachi.com> References: <20050402065052.GT44514@numachi.com> <20050402162842.GU44514@numachi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050402162842.GU44514@numachi.com> User-Agent: Mutt/1.5.8i Subject: Re: which Wifi cards can be used for a WAP? 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: Sat, 02 Apr 2005 17:33:06 -0000 On Sat, Apr 02, 2005 at 11:28:42AM -0500, Brian Reichert wrote: > I guess everything listed here, with a URL to an up-to-date list: > > Another feature of some cards that I haven't found a clear picture of: Some cards have an antenna built right onto the card, and others seem to come with a remote antenna that hangs off of a six-foot (or so) cable. The vendors' arguments for the cable arrangment is that it allows for a more optimal placement of the antenna, but other lore suggests that the cable itself introduces loss of signal. Does anyone have a concrete opinion on this, or can point me in the right direction for some research? -- Brian Reichert 55 Crystal Ave. #286 Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 2 21:46:18 2005 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 330A816A4CE for ; Sat, 2 Apr 2005 21:46:18 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD22943D41 for ; Sat, 2 Apr 2005 21:46:17 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.89] ([66.127.85.89]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j32LkGms017053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Apr 2005 13:46:17 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <424F12E9.30804@errno.com> Date: Sat, 02 Apr 2005 13:47:21 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Reichert References: <20050402065052.GT44514@numachi.com> <20050402162842.GU44514@numachi.com> In-Reply-To: <20050402162842.GU44514@numachi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: which Wifi cards can be used for a WAP? 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: Sat, 02 Apr 2005 21:46:18 -0000 Brian Reichert wrote: > On Sat, Apr 02, 2005 at 01:50:52AM -0500, Brian Reichert wrote: > >>I'm looking at the impressive list of wireless network cards supported >>by FreeBSD here: >> >> http://www.freebsd.org/releases/5.3R/hardware-i386.html#WLAN >> >>But, I have the specific interest of building an 802.11g WAP. I >>seem to recall lore that not all Wifi cards could be used this way >>(something about needing to be able to run in ad-hoc mode, or some >>such.) > > > The ath(4) manpage speaks of a 'hostap' mode, but the manpage > confuses me. > > First, it says: > > The driver may also be configured to operate in hostap mode. In > this mode a host may function as an access point (base station). > > Then: > > Access points are different than operating in IBSS mode. They > operate in BSS mode. > > So, I'm confused, which mode does a WAP need to be in, 'BSS' or > 'hostap'? A "Wireless Access Point" is in charge of a "BSS network". The ath driver does this with a host-based implementation (as opposed to a device-based/firmware-based implementation). Numerous other devices are designed to be used tis way too as doing things on the host reduces vendors cost. > > Quickie research on this 'hostap' mode (which I'd never heard of > until I began this research) seems to be what I need, but the > verbiage in the ath(4) manpage is throwing me... > > Anyway, a survey of the manpages for various WiFi drivers supporting > 'hostap' mode seems to sum up as such: > > wi(4) > Cards based on the Intersil PRISM chips, but I don't think > any of them support 802.11g. > > at(4) > I guess everything listed here, with a URL to an up-to-date list: > > > > In case anyone's following the same rabbit trail I am, on that > search page, if I select: > > WLAN Product: PCI > > I get a huge list of PCI cards, and which 802.11 bands they > support. (The search page won't let me exclude those cards that > don't support 802.11g, but that subset it tiny.) > > That narrows my search, at this time, to 17 PCI cards supporting > 802.11g. I'm currently assuming that anything on this list is > indeed supported by FreeBSD's ath(4) driver. > > Please feel free to disabuse me of that notion... > For 5.3 I believe the only cards you can use to create an 11g ap are those that use the ath driver. However you should beware as the 5.3 ath support is significantly out of date wrt the code in current. I would not suggest using 5.3 to build an 11g ap; only current. Sam From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 2 21:57:27 2005 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 D5ABB16A4CE for ; Sat, 2 Apr 2005 21:57:27 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90D4543D2F for ; Sat, 2 Apr 2005 21:57:27 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.89] ([66.127.85.89]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j32LvRms017099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Apr 2005 13:57:27 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <424F1587.8060105@errno.com> Date: Sat, 02 Apr 2005 13:58:31 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Reichert References: <20050402065052.GT44514@numachi.com> <20050402162842.GU44514@numachi.com> <20050402171635.GV44514@numachi.com> In-Reply-To: <20050402171635.GV44514@numachi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: which Wifi cards can be used for a WAP? 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: Sat, 02 Apr 2005 21:57:28 -0000 Brian Reichert wrote: > On Sat, Apr 02, 2005 at 11:28:42AM -0500, Brian Reichert wrote: > >> I guess everything listed here, with a URL to an up-to-date list: >> >> > > > In perusing many of these cards specs, I see many of them offer a > 'turbo mode' of 108 Mbps. > > - Is this something magically supported by the hardware? By that, > I mean: if I use a compatible WiFi card in a laptop, they'll just > negotiate the higher rate, and as such the kernel driver has no > impact? Turbo mode is an Atheros-specific thing that bonds two channels to double the effective bandwidth. I know of no other vendor that implements it. There are various techniques for increasing the effective bandwidth of an 802.11 medium; none are standardized (yet). > > - I'm seeing 'turbo 802.11g' vs. 'Super G'. I haven't found any > thing that tells me if these are synonyms, or if they are > incompatable unofficial extansions of a spec. Does anyone here > know? > SuperG is a label for a number of different features that are implemented as Atheros-specific protocol extensions. Other vendors can implement most of them (Atheros has released the details of these extensions) but it's unlikely you'll find many vendors picking them up. I have code that implements most of SuperG (only compression is missing) but haven't committed any of these yet (not sure when I'll do this and/or if all warrant going in FreeBSD). Turbo 11g is the use of Atheros Turbo mode in the 2.4GHz band. This is only possible on channel 6 as you need to bond two channels and is permitted only when non-Turbo-capable stations are detected. Consequently it's really only useful in the 2.4 band in a private environment. OTOH you can operate in 11a (5GHz) with more freedom and SuperG can easily get you transfer rates upwards of 60 Mb/s. Sam From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 2 22:04:34 2005 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 E390016A4CE for ; Sat, 2 Apr 2005 22:04:34 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id A78E943D46 for ; Sat, 2 Apr 2005 22:04:34 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.89] ([66.127.85.89]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j32M4Tms017181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Apr 2005 14:04:31 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <424F172E.9070201@errno.com> Date: Sat, 02 Apr 2005 14:05:34 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joerg Sonnenberger References: <20050402065052.GT44514@numachi.com> <20050402162842.GU44514@numachi.com> <20050402171635.GV44514@numachi.com> <20050402172355.GA1069@britannica.bec.de> In-Reply-To: <20050402172355.GA1069@britannica.bec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: which Wifi cards can be used for a WAP? 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: Sat, 02 Apr 2005 22:04:35 -0000 Joerg Sonnenberger wrote: > On Sat, Apr 02, 2005 at 12:16:35PM -0500, Brian Reichert wrote: > >>In perusing many of these cards specs, I see many of them offer a >>'turbo mode' of 108 Mbps. > > > That's a vendor-specific mode. I strongly advice you _against_ using it, > it's using at least one additional channel and only adds speed for very > short distances. If you follow the common recommendation of leaving one > channel before and after the active channel, you end up using at least > 5 channels for turbo mode compared to three for normal, it's not worth > the trouble. This is misleading. First turbo mode can only be used in the 2.4G band on channel 6 and does not impact operation on channels 1 and 11. Any channels in between already suffer from normal (i.e. non-turbo) use because the channel spread in the 2.4 band means traffic is visible if you use the in-between channels. Further, turbo mode (as part of SuperG) requires that the AP detect non-turbo capable stations and disable turbo use when such stations are present. As to whether or not to use it; I said in another note that it's really most useful in the 5Ghz band where there's more available spectrum and channel spread eliminates any possible interference. Sam