From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 25 03:26:35 2005 Return-Path: X-Original-To: FreeBSD-hackers@freebsd.org 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 3EF8816A41F for ; Sun, 25 Sep 2005 03:26:35 +0000 (GMT) (envelope-from frank@exit.com) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id D981E43D48 for ; Sun, 25 Sep 2005 03:26:34 +0000 (GMT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.13.4/8.13.3) with ESMTP id j8P3QZMt066281 for ; Sat, 24 Sep 2005 20:26:35 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (localhost [127.0.0.1]) by realtime.exit.com (8.13.4/8.13.3) with ESMTP id j8P3QYPU039559 for ; Sat, 24 Sep 2005 20:26:34 -0700 (PDT) (envelope-from frank@exit.com) Received: (from frank@localhost) by realtime.exit.com (8.13.4/8.13.4/Submit) id j8P3QY5Z039558 for FreeBSD-hackers@freebsd.org; Sat, 24 Sep 2005 20:26:34 -0700 (PDT) (envelope-from frank@exit.com) X-Authentication-Warning: realtime.exit.com: frank set sender to frank@exit.com using -f From: Frank Mayhar To: FreeBSD-hackers@freebsd.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Exit Consulting Date: Sat, 24 Sep 2005 20:26:33 -0700 Message-Id: <1127618793.38683.9.camel@realtime.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port X-Virus-Scanned: ClamAV 0.86.2/1099/Fri Sep 23 13:29:28 2005 on tinker.exit.com X-Virus-Status: Clean Cc: Subject: Oddity in libufs. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: frank@exit.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2005 03:26:35 -0000 I've been using libufs as the I/O mechanism for my (heavy) modification of sysutils/ffsrecov. It's working to my needs and now I'm poking at other bits and pieces to maybe get it suitable for release into the wild. I just looked at cgread() to see what it does and noticed that there seems to be a redundant line: . . if (c >= fs->fs_ncg) { return (0); } ccg = fsbtodb(fs, cgtod(fs, c)) * disk->d_bsize; if (bread(disk, fsbtodb(fs, cgtod(fs, c)), disk->d_cgunion.d_buf, . . That assignment up there looks redundant, as ccg is never used. I suspect that it's a relic of an old lseek()/read() pair that's long gone. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 25 10:31:53 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 3639D16A41F for ; Sun, 25 Sep 2005 10:31:53 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: from web35703.mail.mud.yahoo.com (web35703.mail.mud.yahoo.com [66.163.179.157]) by mx1.FreeBSD.org (Postfix) with SMTP id B1B2543D49 for ; Sun, 25 Sep 2005 10:31:52 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: (qmail 68096 invoked by uid 60001); 25 Sep 2005 10:31:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ls56Pa2q/+wjgtRIZcbR9801GEIeUHFTKy7CkDBRYfIqiuV2tfKyGseXkb/kxK+aePodksws+ANrBEfWaLWzR03RPptv3rv38Z/KPO2h2Db0fRqqVEj7bLdVvtRHdjkuwfIzlHH/meR+xarYICHmIewG6uri3WsOVycJiLQ6etY= ; Message-ID: <20050925103151.68094.qmail@web35703.mail.mud.yahoo.com> Received: from [202.79.62.15] by web35703.mail.mud.yahoo.com via HTTP; Sun, 25 Sep 2005 03:31:51 PDT Date: Sun, 25 Sep 2005 03:31:51 -0700 (PDT) From: kamal kc To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: kernel hack X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2005 10:31:53 -0000 does anybody know what is the best way to start kernel hack. Any references to any web page would be appreciated __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 25 11:01:01 2005 Return-Path: X-Original-To: FreeBSD-hackers@freebsd.org 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 02B1116A41F for ; Sun, 25 Sep 2005 11:01:01 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43C4C43D49 for ; Sun, 25 Sep 2005 11:00:59 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from flame.pc (patr530-a133.otenet.gr [212.205.215.133]) by kane.otenet.gr (8.13.4/8.13.4/Debian-1) with ESMTP id j8PB0axC024086; Sun, 25 Sep 2005 14:00:36 +0300 Received: from flame.pc (flame [127.0.0.1]) by flame.pc (8.13.4/8.13.4) with ESMTP id j8PB06et000928; Sun, 25 Sep 2005 14:00:06 +0300 (EEST) (envelope-from keramida@linux.gr) Received: (from keramida@localhost) by flame.pc (8.13.4/8.13.4/Submit) id j8PB054n000927; Sun, 25 Sep 2005 14:00:05 +0300 (EEST) (envelope-from keramida@linux.gr) Date: Sun, 25 Sep 2005 14:00:05 +0300 From: Giorgos Keramidas To: Frank Mayhar Message-ID: <20050925110005.GB819@flame.pc> References: <1127618793.38683.9.camel@realtime.exit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1127618793.38683.9.camel@realtime.exit.com> Cc: FreeBSD-hackers@freebsd.org Subject: Re: Oddity in libufs. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2005 11:01:01 -0000 On 2005-09-24 20:26, Frank Mayhar wrote: > I've been using libufs as the I/O mechanism for my (heavy) modification > of sysutils/ffsrecov. It's working to my needs and now I'm poking at > other bits and pieces to maybe get it suitable for release into the > wild. I just looked at cgread() to see what it does and noticed that > there seems to be a redundant line: > > . > . > if (c >= fs->fs_ncg) { > return (0); > } > ccg = fsbtodb(fs, cgtod(fs, c)) * disk->d_bsize; > if (bread(disk, fsbtodb(fs, cgtod(fs, c)), disk->d_cgunion.d_buf, > . > . > > That assignment up there looks redundant, as ccg is never used. I > suspect that it's a relic of an old lseek()/read() pair that's long > gone. It's probably easy to verify that without this assignment 'ccg' is an unused var: - Comment it out - Rebuild with an elevated WARNS level if a warning about 'unused ccg var' is printed, then you are certain that ccg was only used for the assignment. From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 25 11:08:29 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 2367316A41F; Sun, 25 Sep 2005 11:08:29 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id C42B743D49; Sun, 25 Sep 2005 11:08:28 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id F253846BA4; Sun, 25 Sep 2005 07:08:27 -0400 (EDT) Date: Sun, 25 Sep 2005 12:08:27 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: jason@hudson-trading.com In-Reply-To: Message-ID: <20050925115912.H11229@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, mikep@hudson-trading.com, freebsd-amd64@freebsd.org, Rob Watt Subject: Re: freebsd-5.4-stable panics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2005 11:08:29 -0000 On Fri, 23 Sep 2005, Jason Carroll wrote: 5B > There seem to be 2 types of crashes we see with pretty different stack > traces. What I'll call a type 1 crash, I believe, is often caused by > one of the triggers I mention above. A type 2 crash appears to happen > spontaneously after the machine has been running for a while. > > I poked around using kgdb in a core file from a type 2 crash, and it > appeared the system hung closing sockets (specifically cleaning up > multicast state i think) while cleaning up one of our multicast > applications (note the trace through sys_exit). There's no reason this > application should have been exiting unless it encountered some kind of > error. > > I'm attaching: > dmesg.txt > kernel-conf.txt (kernel config file) > type1-core.txt (a kgdb bt from a type1/triggered crash) > type2-core.txt (a kgdb bt from a type2/spontaneous crash) > > I'm happy to dig for more information, recompile with different options, > apply patches, or do anything else that might help get this problem > diagnosed and fixed! Hi there Jason! Sounds nasty. It's possible the two panics are related, especially if they involve a race in the multicast code, which could result in treading on other kernel memory, potentially leading to the thread related panic. My leaning would be that they are unrelated, but since we may be able to eliminate the multicast one (see below), that would be a good starting point. In the 6.x branch, quite a bit of work has been done to improve locking in the multicast code, and several important races have been fixed relating to IP multicast. These races tended to turn up on the following sorts of situations: (1) Multi-threaded appplications changing the multicast properties, such as membership, or a particular socket in parallel. (2) Changes to multicast membership during high multicast I/O load on the socket. For example, adding or deleting multicast groups on socket on CPU 0 while a packet is delivered to the same socket on CPU 1. (3) Removal of real or synthetic interfaces involved in active multicast, such as removal of pccards, vlans, etc during multicast I/O, or with sockets bound to the interfaces. These changes are not currently scheduled for a backport to 5.x, because they change the kernel network device driver API and ABI, requiring changes to and recompiling of third party device drivers. A subset could be backported, subject to some limitations, but it would be good to confirm whether these changes actually affect the problems you're seeing before working through that. All the changes should appear in the most recent snapshot, BETA5. Make sure to turn off extra kernel debugging features, such as WITNESS, INVARIANTS, and user space malloc debugging, if you start running into performance problems -- they have a big performance impact, although can be quite helpful in testing. Normally we turn these off during the release candidate portion of the release cycle. There are some other known stability nits in 6.x which are being worked on, but in general the network stack stability is higher in 6.x than 5.x when it comes to multicast due to the work I reference above. If you run into any stability problems relating to the file system, set debug.mpsafevfs=0 in loader.conf -- there are a few bug fixes relating to running out of disk space or hitting quota limits that are fixed in HEAD, but not yet backported to 6.x. Thanks, Robert N M Watson From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 25 12:24:51 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 A0D8F16A41F for ; Sun, 25 Sep 2005 12:24:51 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id DC90043D49 for ; Sun, 25 Sep 2005 12:24:48 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 25 Sep 2005 13:24:47 +0100 (BST) Date: Sun, 25 Sep 2005 13:24:47 +0100 From: David Malone To: kamal kc Message-ID: <20050925122447.GA5489@walton.maths.tcd.ie> References: <20050925103151.68094.qmail@web35703.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050925103151.68094.qmail@web35703.mail.mud.yahoo.com> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: freebsd-hackers@freebsd.org Subject: Re: kernel hack X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2005 12:24:51 -0000 On Sun, Sep 25, 2005 at 03:31:51AM -0700, kamal kc wrote: > does anybody know what is the best way > to start kernel hack. It isn't quite clear what you mean, but presuming you mean "make a change to the FreeBSD kernel that you use" then: 1) First learn how to recompile your kernel. You can get details from the FreeBSD handbook (http://www.freebsd.org/handbook/). 2) Look under /usr/src/sys for the kernel source code. The main bit is in /usr/src/sys/kern, networking lives under /usr/src/sys/net* and so on. 3) Change the code you want and then recompie the kernel. Remember to keep an old kernel around incase you make a mistake. David. From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 25 16:29:19 2005 Return-Path: X-Original-To: FreeBSD-hackers@freebsd.org 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 4F62D16A41F for ; Sun, 25 Sep 2005 16:29:19 +0000 (GMT) (envelope-from frank@exit.com) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id E777C43D53 for ; Sun, 25 Sep 2005 16:29:18 +0000 (GMT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.13.4/8.13.3) with ESMTP id j8PGTLdw076924; Sun, 25 Sep 2005 09:29:21 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (localhost [127.0.0.1]) by realtime.exit.com (8.13.4/8.13.3) with ESMTP id j8PGTH0b045485; Sun, 25 Sep 2005 09:29:17 -0700 (PDT) (envelope-from frank@exit.com) Received: (from frank@localhost) by realtime.exit.com (8.13.4/8.13.4/Submit) id j8PGTGsQ045484; Sun, 25 Sep 2005 09:29:16 -0700 (PDT) (envelope-from frank@exit.com) X-Authentication-Warning: realtime.exit.com: frank set sender to frank@exit.com using -f From: Frank Mayhar To: Giorgos Keramidas In-Reply-To: <20050925110005.GB819@flame.pc> References: <1127618793.38683.9.camel@realtime.exit.com> <20050925110005.GB819@flame.pc> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Exit Consulting Date: Sun, 25 Sep 2005 09:29:15 -0700 Message-Id: <1127665755.45346.2.camel@realtime.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port X-Virus-Scanned: ClamAV 0.86.2/1102/Sun Sep 25 07:04:56 2005 on tinker.exit.com X-Virus-Status: Clean Cc: FreeBSD-hackers@freebsd.org Subject: Re: Oddity in libufs. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: frank@exit.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2005 16:29:19 -0000 On Sun, 2005-09-25 at 14:00 +0300, Giorgos Keramidas wrote: > On 2005-09-24 20:26, Frank Mayhar wrote: > > That assignment up there looks redundant, as ccg is never used. I > > suspect that it's a relic of an old lseek()/read() pair that's long > > gone. > It's probably easy to verify that without this assignment 'ccg' is an > unused var: Um, yeah. I was pointing it out mostly so that a committer could check it out and perhaps remove the line in question... -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 25 17:16:29 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 CF71616A420 for ; Sun, 25 Sep 2005 17:16:29 +0000 (GMT) (envelope-from stsp@stsp.in-berlin.de) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB55143D48 for ; Sun, 25 Sep 2005 17:16:27 +0000 (GMT) (envelope-from stsp@stsp.in-berlin.de) X-Envelope-From: stsp@stsp.in-berlin.de X-Envelope-To: Received: from dice.bliss.lan (e178184157.adsl.alicedsl.de [85.178.184.157]) (authenticated bits=0) by einhorn.in-berlin.de (8.12.10/8.12.10/Debian-4) with ESMTP id j8PHGOu1016381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 25 Sep 2005 19:16:25 +0200 Received: by dice.bliss.lan (nbSMTP-1.01-cvs) for uid 1001 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) stsp@stsp.in-berlin.de; Sun, 25 Sep 2005 19:16:25 +0200 (CEST) Date: Sun, 25 Sep 2005 19:16:19 +0200 From: Stefan Sperling To: freebsd-hackers@freebsd.org Message-ID: <20050925171619.GA1670@dice.bliss.lan> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Spam-Score: (0.205) AWL,BAYES_50,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 Subject: Re: kernel hack X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2005 17:16:29 -0000 Sorry, this went to -current by accident, but should have gone here... ----- Forwarded message from Stefan Sperling ----- Date: Sun, 25 Sep 2005 18:35:53 +0200 From: Stefan Sperling To: kamal kc Cc: freebsd-current@freebsd.org Subject: Re: kernel hack On Sun, Sep 25, 2005 at 03:31:51AM -0700, kamal kc wrote: > does anybody know what is the best way > to start kernel hack. IMHO, the best way to start kernel hacking is to invest an awful lot of time into reading books. I presume you know C _really_ well already :) And by really well I also mean you know what is wrong about C! Any modern book on writing device drivers should be a good starting point. It does not really matter which UNIX-derivative the book is about. Hint: There are a lot of these books about Linux. Read programmer's datasheets, preferably for devices you own, and learn how to talk to registers from C. ftp.alsa-project.org has datasheets for sound cards, for example. Make sure you also learn about multi-threading (mutexes, semaphores etc). A lot of kernels are multi-threaded these days. A very good overview of the FreeBSD kernel is given in "The Design and Implementation of the FreeBSD Operating System", by Mr. McKusick and Mr. Neville-Neil. Read all of it. Having learned about drivers and multi-threading beforehand helps a lot. > Any references to any web page would > be appreciated Get books, it's worth it! You really don't want to read this much material on your monitor! (Unless you have a 28" TFT of course ;). Plus books are often much better written, easier to understand, and a lot more detailed than tutorials on the web. http://www.NetBSD.org/Documentation also has an interesting kernel section to get you started before your books arrive :) -- stefan http://stsp.in-berlin.de PGP Key: 0xF59D25F0 ----- End forwarded message ----- -- stefan http://stsp.in-berlin.de PGP Key: 0xF59D25F0 From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 26 02:12:02 2005 Return-Path: X-Original-To: FreeBSD-hackers@freebsd.org 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 2C8AB16A41F for ; Mon, 26 Sep 2005 02:12:02 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7824443D48 for ; Mon, 26 Sep 2005 02:12:00 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from flame.pc (patr530-a042.otenet.gr [212.205.215.42]) by rosebud.otenet.gr (8.13.4/8.13.4/Debian-1) with ESMTP id j8Q2BfE6009077; Mon, 26 Sep 2005 05:11:42 +0300 Received: from flame.pc (flame [127.0.0.1]) by flame.pc (8.13.4/8.13.4) with ESMTP id j8Q2BABb002608; Mon, 26 Sep 2005 05:11:10 +0300 (EEST) (envelope-from keramida@linux.gr) Received: (from keramida@localhost) by flame.pc (8.13.4/8.13.4/Submit) id j8Q2B9wU002607; Mon, 26 Sep 2005 05:11:09 +0300 (EEST) (envelope-from keramida@linux.gr) Date: Mon, 26 Sep 2005 05:11:09 +0300 From: Giorgos Keramidas To: Frank Mayhar Message-ID: <20050926021109.GA2576@flame.pc> References: <1127618793.38683.9.camel@realtime.exit.com> <20050925110005.GB819@flame.pc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050925110005.GB819@flame.pc> Cc: FreeBSD-hackers@freebsd.org Subject: Re: Oddity in libufs. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 02:12:02 -0000 On 2005-09-25 14:00, Giorgos Keramidas wrote: > On 2005-09-24 20:26, Frank Mayhar wrote: > > I've been using libufs as the I/O mechanism for my (heavy) modification > > of sysutils/ffsrecov. It's working to my needs and now I'm poking at > > other bits and pieces to maybe get it suitable for release into the > > wild. I just looked at cgread() to see what it does and noticed that > > there seems to be a redundant line: > > > > . > > . > > if (c >= fs->fs_ncg) { > > return (0); > > } > > ccg = fsbtodb(fs, cgtod(fs, c)) * disk->d_bsize; > > if (bread(disk, fsbtodb(fs, cgtod(fs, c)), disk->d_cgunion.d_buf, > > . > > . > > > > That assignment up there looks redundant, as ccg is never used. I > > suspect that it's a relic of an old lseek()/read() pair that's long > > gone. > > It's probably easy to verify that without this assignment 'ccg' is an > unused var: > > - Comment it out > - Rebuild with an elevated WARNS level > > if a warning about 'unused ccg var' is printed, then you are certain > that ccg was only used for the assignment. FWIW, libufs built with the following patch seems to pass at least a build test fine, even with WARNS=6 %%% Index: cgroup.c =================================================================== RCS file: /home/ncvs/src/lib/libufs/cgroup.c,v retrieving revision 1.3 diff -u -r1.3 cgroup.c --- cgroup.c 9 Jun 2003 09:32:29 -0000 1.3 +++ cgroup.c 26 Sep 2005 02:09:07 -0000 @@ -55,14 +55,12 @@ cgread1(struct uufsd *disk, int c) { struct fs *fs; - off_t ccg; fs = &disk->d_fs; if (c >= fs->fs_ncg) { return (0); } - ccg = fsbtodb(fs, cgtod(fs, c)) * disk->d_bsize; if (bread(disk, fsbtodb(fs, cgtod(fs, c)), disk->d_cgunion.d_buf, fs->fs_bsize) == -1) { ERROR(disk, "unable to read cylinder group"); %%% From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 26 04:23:41 2005 Return-Path: X-Original-To: FreeBSD-hackers@freebsd.org 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 0639D16A41F for ; Mon, 26 Sep 2005 04:23:41 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B51E43D48 for ; Mon, 26 Sep 2005 04:23:40 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id j8Q4NGpN045830; Sun, 25 Sep 2005 21:23:16 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id j8Q4NF4O045829; Sun, 25 Sep 2005 21:23:15 -0700 (PDT) (envelope-from jmg) Date: Sun, 25 Sep 2005 21:23:15 -0700 From: John-Mark Gurney To: Frank Mayhar Message-ID: <20050926042315.GA716@funkthat.com> Mail-Followup-To: Frank Mayhar , FreeBSD-hackers@freebsd.org References: <1127618793.38683.9.camel@realtime.exit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1127618793.38683.9.camel@realtime.exit.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 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: Oddity in libufs. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2005 04:23:41 -0000 Frank Mayhar wrote this message on Sat, Sep 24, 2005 at 20:26 -0700: > I've been using libufs as the I/O mechanism for my (heavy) modification > of sysutils/ffsrecov. It's working to my needs and now I'm poking at Well, I've recently rewrote ffsrecov in python, and have put up a preliminary copy up at: http://people.freebsd.org/~jmg/ffsrecov/ -- 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 Sep 26 08:48:42 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 BEC3B16A41F for ; Mon, 26 Sep 2005 08:48:42 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.ntu-kpi.kiev.ua (comsys.ntu-kpi.kiev.ua [195.245.194.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07C2443D49 for ; Mon, 26 Sep 2005 08:48:40 +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) by comsys.ntu-kpi.kiev.ua (8.12.10/8.12.10) with ESMTP id j8Q8vAhw006235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2005 11:57:11 +0300 (EEST) Received: by pm514-9.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1000) id 6E7441A3; Mon, 26 Sep 2005 11:45:50 +0300 (EEST) Date: Mon, 26 Sep 2005 11:45:50 +0300 From: Andrey Simonenko To: Sebastien Message-ID: <20050926084550.GA444@pm514-9.comsys.ntu-kpi.kiev.ua> References: <200509201949.53951.sebastien.bourdeauducq@gmail.com> <20050921080533.GA255@pm514-9.comsys.ntu-kpi.kiev.ua> <200509241706.47995.sebastien.bourdeauducq@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509241706.47995.sebastien.bourdeauducq@gmail.com> User-Agent: Mutt/1.4.2.1i X-Spam-Status: No, score=-4.5 required=5.0 tests=ALL_TRUSTED,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/1096/Wed Sep 21 10:08:33 2005 on comsys.ntu-kpi.kiev.ua X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: Filesystem access from a KLD causes "vrele: negative ref cnt" panic X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 08:48:42 -0000 On Sat, Sep 24, 2005 at 05:06:47PM +0200, Sebastien wrote: > > > Should not rootvnode get reference, when fd_rdir or fd_cdir > > begins to point to it? Try to VREF() it. > > No change. > It is hard to say something not seeing and understanding the complete source code. But since fdinit() which is called from fork1() and fdfree() which is called from exit1() get and release reference on vnodes fd_cdir and fd_rdir point to, you need to follow this semantics. From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 26 17:05:44 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 A3E1A16A41F for ; Mon, 26 Sep 2005 17:05:44 +0000 (GMT) (envelope-from freebsd@redry.net) Received: from luke.segpub.com.au (luke.segpub.com.au [64.49.254.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23FCE43D48 for ; Mon, 26 Sep 2005 17:05:43 +0000 (GMT) (envelope-from freebsd@redry.net) Received: (qmail 38027 invoked by uid 89); 27 Sep 2005 03:05:43 +1000 Received: by simscan 1.1.0 ppid: 38001, pid: 38019, t: 0.8151s scanners: clamav: 0.86.1/m:33/d:984 spam: 3.0.4 Received: from unknown (HELO ?192.168.1.33?) (213.202.164.201) by 0 with SMTP; 27 Sep 2005 03:05:42 +1000 Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-hackers@freebsd.org From: eoghan Date: Mon, 26 Sep 2005 18:05:41 +0100 X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on luke.segpub.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.4 Subject: mysql port install X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 17:05:44 -0000 Hello Im having a problem getting mysql (version 4.1.14) to work. Im installing from ports, which was updated today. Each time i try #>mysql is get: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) mysql.sock isnt in /tmp/ which is a problem. The manual and searches say that this means the server usually isnt running, so type mysqld to start it. But i just get command not found. The only reference to mysqld is in /usr/local/man/man1/mysql.1.gz I was wondering if someone had any luck getting this port installed? Im using freeBSD 5.3 by the way. Thanks Eoghan From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 26 17:58:07 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 D58A016A420 for ; Mon, 26 Sep 2005 17:58:07 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 154EF43D49 for ; Mon, 26 Sep 2005 17:58:04 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.233] (Not Verified[10.50.41.233]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 26 Sep 2005 14:14:01 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org, frank@exit.com Date: Mon, 26 Sep 2005 13:50:01 -0400 User-Agent: KMail/1.8 References: <1127618793.38683.9.camel@realtime.exit.com> In-Reply-To: <1127618793.38683.9.camel@realtime.exit.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509261350.02589.jhb@FreeBSD.org> Cc: Subject: Re: Oddity in libufs. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 17:58:08 -0000 On Saturday 24 September 2005 11:26 pm, Frank Mayhar wrote: > I've been using libufs as the I/O mechanism for my (heavy) modification > of sysutils/ffsrecov. It's working to my needs and now I'm poking at > other bits and pieces to maybe get it suitable for release into the > wild. I just looked at cgread() to see what it does and noticed that > there seems to be a redundant line: > > . > . > if (c >= fs->fs_ncg) { > return (0); > } > ccg = fsbtodb(fs, cgtod(fs, c)) * disk->d_bsize; > if (bread(disk, fsbtodb(fs, cgtod(fs, c)), > disk->d_cgunion.d_buf, > . > . > > That assignment up there looks redundant, as ccg is never used. I > suspect that it's a relic of an old lseek()/read() pair that's long > gone. The person you probably want to ask is jmallett@. I can't find anything in cvs annotate or in the p4 depot to give history on how that got there. On the face of it, it looks like it shouldn't cause any harm to just remove ccg. -- 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 Sep 26 18:15:26 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 1C43B16A42A for ; Mon, 26 Sep 2005 18:15:26 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D69143D48 for ; Mon, 26 Sep 2005 18:15:25 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: sYrXKE9Ehk5uuWh+ITYiXA== Received: from mp-217-136-202.daxnet.no ([193.217.136.202] verified) by mailfe06.swip.net (CommuniGate Pro SMTP 4.3.4) with ESMTP id 451306960 for freebsd-hackers@freebsd.org; Mon, 26 Sep 2005 19:30:43 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Mon, 26 Sep 2005 19:31:45 +0200 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509261931.46052.hselasky@c2i.net> Subject: bus-dma question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 18:15:26 -0000 Hi, I see something suspicious on Amd64, when allocating small blocks of DMA-able memory: bus_dmamap_load_callback: 0x0000000000caf200 ^^^^ this is physical address QH(0xffffff0000caf200) at 0x00caf200: ^^^^ this is kernel address Shouldn't kernel addresses always be different from physical addresses ? When allocating larger blocks of memory I get, for example: bus_dmamap_load_callback: 0x000000003bc50000 which seems correct. --HPS From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 26 19:29:51 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 1B5A916A41F for ; Mon, 26 Sep 2005 19:29:51 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A72943D5A for ; Mon, 26 Sep 2005 19:29:50 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.233] (Not Verified[10.50.41.233]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 26 Sep 2005 15:45:46 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org, hselasky@c2i.net Date: Mon, 26 Sep 2005 15:25:05 -0400 User-Agent: KMail/1.8 References: <200509261931.46052.hselasky@c2i.net> In-Reply-To: <200509261931.46052.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509261525.06653.jhb@FreeBSD.org> Cc: Subject: Re: bus-dma question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 19:29:51 -0000 On Monday 26 September 2005 01:31 pm, Hans Petter Selasky wrote: > Hi, > > I see something suspicious on Amd64, when allocating small blocks of > DMA-able memory: > > bus_dmamap_load_callback: 0x0000000000caf200 > ^^^^ this is physical address > > QH(0xffffff0000caf200) at 0x00caf200: > ^^^^ this is kernel address > > Shouldn't kernel addresses always be different from physical addresses ? No. Especially not on archs like alpha, ia64, amd64, and sparc64 where part of KVA is direct-mapped to physical memory either in hardware (alpha's K0Seg) or via software (ia64, amd64, and sparc64). > When allocating larger blocks of memory I get, for example: > > bus_dmamap_load_callback: 0x000000003bc50000 > > which seems correct. > > --HPS > _______________________________________________ > 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" -- 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 Sep 26 20:04:12 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 1599116A41F for ; Mon, 26 Sep 2005 20:04:12 +0000 (GMT) (envelope-from freebsd@redry.net) Received: from luke.segpub.com.au (luke.segpub.com.au [64.49.254.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 760A443D5E for ; Mon, 26 Sep 2005 20:04:10 +0000 (GMT) (envelope-from freebsd@redry.net) Received: (qmail 80025 invoked by uid 89); 27 Sep 2005 06:04:09 +1000 Received: by simscan 1.1.0 ppid: 79995, pid: 80011, t: 0.7055s scanners: clamav: 0.86.1/m:33/d:984 spam: 3.0.4 Received: from unknown (HELO ?192.168.1.33?) (213.202.164.201) by 0 with SMTP; 27 Sep 2005 06:04:09 +1000 In-Reply-To: <6.2.3.4.2.20050926123752.0352ad60@cobalt.antimatter.net> References: <6.2.3.4.2.20050926123752.0352ad60@cobalt.antimatter.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: eoghan Date: Mon, 26 Sep 2005 21:04:05 +0100 To: Glenn Dawson X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on luke.segpub.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-hackers@freebsd.org Subject: Re: mysql port install X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 20:04:12 -0000 On 26 Sep 2005, at 20:40, Glenn Dawson wrote: > Make sure you have mysqld_enable"YES" in your /etc/rc.conf and then > use > /usr/local/etc/rc.d/mysql-server.sh start > to start the server. (you may nee to copy mysql-server.sh from > mysql-server.sh.sample first) Hi Glenn Thanks! However, I get: #>/usr/local/etc/rc.d/mysql-server.sh start This: not found #> I have checked the dir and mysql-server.sh is there. Any ideas? Thanks Eoghan From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 26 20:39:51 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 A8FAC16A41F for ; Mon, 26 Sep 2005 20:39:51 +0000 (GMT) (envelope-from sico@loquefaltaba.com) Received: from mail.loquefaltaba.com (78.Red-213-96-97.staticIP.rima-tde.net [213.96.97.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD0C343D58 for ; Mon, 26 Sep 2005 20:39:50 +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 9F7BDC389; Mon, 26 Sep 2005 22:39:48 +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 51869-06; Mon, 26 Sep 2005 22:39:37 +0200 (CEST) Received: from [192.168.0.100] (unknown [192.168.0.100]) by mail.loquefaltaba.com (Postfix) with ESMTP id 18165C1EE; Mon, 26 Sep 2005 22:39:37 +0200 (CEST) Message-ID: <43385C88.30505@loquefaltaba.com> Date: Mon, 26 Sep 2005 22:39:36 +0200 From: David Barbero User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: eoghan References: <6.2.3.4.2.20050926123752.0352ad60@cobalt.antimatter.net> In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at loquefaltaba.com Cc: freebsd-hackers@freebsd.org, Glenn Dawson Subject: Re: mysql port install X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 20:39:51 -0000 eoghan wrote: > On 26 Sep 2005, at 20:40, Glenn Dawson wrote: > >> Make sure you have mysqld_enable"YES" in your /etc/rc.conf and then use >> /usr/local/etc/rc.d/mysql-server.sh start >> to start the server. (you may nee to copy mysql-server.sh from >> mysql-server.sh.sample first) > > > Hi Glenn > Thanks! However, I get: > #>/usr/local/etc/rc.d/mysql-server.sh start > This: not found > #> > I have checked the dir and mysql-server.sh is there. > Any ideas? > Thanks > Eoghan > > > _______________________________________________ > 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" that port you have installed exactly? Sight to see that exit gives pkg_info |grep mysql if you don't see mysql-server-4.x.x, you don't install the correct port. Regards. From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 26 23:11:41 2005 Return-Path: X-Original-To: FreeBSD-hackers@freebsd.org 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 B603F16A41F for ; Mon, 26 Sep 2005 23:11:41 +0000 (GMT) (envelope-from frank@exit.com) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id A016B43D48 for ; Mon, 26 Sep 2005 23:11:39 +0000 (GMT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.13.4/8.13.3) with ESMTP id j8QNBd3S009486; Mon, 26 Sep 2005 16:11:39 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (localhost [127.0.0.1]) by realtime.exit.com (8.13.4/8.13.3) with ESMTP id j8QNBcoe010476; Mon, 26 Sep 2005 16:11:38 -0700 (PDT) (envelope-from frank@exit.com) Received: (from frank@localhost) by realtime.exit.com (8.13.4/8.13.4/Submit) id j8QNBcuI010475; Mon, 26 Sep 2005 16:11:38 -0700 (PDT) (envelope-from frank@exit.com) X-Authentication-Warning: realtime.exit.com: frank set sender to frank@exit.com using -f From: Frank Mayhar To: John-Mark Gurney In-Reply-To: <20050926042315.GA716@funkthat.com> References: <1127618793.38683.9.camel@realtime.exit.com> <20050926042315.GA716@funkthat.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Exit Consulting Date: Mon, 26 Sep 2005 16:11:38 -0700 Message-Id: <1127776298.10212.1.camel@realtime.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port X-Virus-Scanned: ClamAV 0.86.2/1102/Sun Sep 25 07:04:56 2005 on tinker.exit.com X-Virus-Status: Clean Cc: FreeBSD-hackers@freebsd.org Subject: Re: Oddity in libufs. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: frank@exit.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 23:11:41 -0000 On Sun, 2005-09-25 at 21:23 -0700, John-Mark Gurney wrote: > Frank Mayhar wrote this message on Sat, Sep 24, 2005 at 20:26 -0700: > > I've been using libufs as the I/O mechanism for my (heavy) modification > > of sysutils/ffsrecov. It's working to my needs and now I'm poking at > > Well, I've recently rewrote ffsrecov in python, and have put up a > preliminary copy up at: > http://people.freebsd.org/~jmg/ffsrecov/ Sigh. Of _course_ you have. Where were you in June when I was begging for this? (Er, and, why python, of all things?) -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 27 03:08:35 2005 Return-Path: X-Original-To: FreeBSD-hackers@freebsd.org 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 82E5A16A41F for ; Tue, 27 Sep 2005 03:08:35 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD5D043D4C for ; Tue, 27 Sep 2005 03:08:34 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id j8R384V2077832; Mon, 26 Sep 2005 20:08:04 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id j8R383aU077831; Mon, 26 Sep 2005 20:08:03 -0700 (PDT) (envelope-from jmg) Date: Mon, 26 Sep 2005 20:08:03 -0700 From: John-Mark Gurney To: Frank Mayhar Message-ID: <20050927030803.GB716@funkthat.com> Mail-Followup-To: Frank Mayhar , FreeBSD-hackers@freebsd.org References: <1127618793.38683.9.camel@realtime.exit.com> <20050926042315.GA716@funkthat.com> <1127776298.10212.1.camel@realtime.exit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1127776298.10212.1.camel@realtime.exit.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 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: Oddity in libufs. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Sep 2005 03:08:35 -0000 Frank Mayhar wrote this message on Mon, Sep 26, 2005 at 16:11 -0700: > On Sun, 2005-09-25 at 21:23 -0700, John-Mark Gurney wrote: > > Frank Mayhar wrote this message on Sat, Sep 24, 2005 at 20:26 -0700: > > > I've been using libufs as the I/O mechanism for my (heavy) modification > > > of sysutils/ffsrecov. It's working to my needs and now I'm poking at > > > > Well, I've recently rewrote ffsrecov in python, and have put up a > > preliminary copy up at: > > http://people.freebsd.org/~jmg/ffsrecov/ > > Sigh. Of _course_ you have. Where were you in June when I was begging > for this? busy doing other stuff... (and not having a HD failure, and then a failure of the backup disk, which somehow managed to shift the blocks containing the root inode and a few inodes after it 8 bytes, yes bytes, later in the disk)... which got/made me rewrite ffsrecov... > (Er, and, why python, of all things?) Well, partly because python makes it easier to be an interactive recovery utility... Like my backup disk, I don't know how it happened but inodes 2 through 16 (the only ones allocated in the first cg) for some reason were shifted 8 bytes later on the disk... w/ C, that'd of been very difficult to fix, but using interactive python it made it easy: import block import ffsrecov b = block.Block(open('/dev/da0')) f = ffsrecov.FFS(b) print repr(f['/']) # hmmm, root inode is messed up inodeblk = f.getblock(f.ino_to_fsba(2)) print repr(inodeblk[:512]) # print out the first sector inodeblk = inodeblk[8:] # drop the first 8 bytes tmpinodes = [ ffsrecov.FFSInode(fs, i, inodeblk[i * 256: (i + 1) * 256]) for i in range(2, 17) ] # generate inodes filter(lambda x: f.inodes.__setitem__(x.ino, x), tmpinodes) # put them in the cache (f.inodes is a WeakValueDictionary) print f['/'] # wow, things are much better! print map(None, f['/']) # now I can see the other file entries It lets me do things like make use of the WeakValueDictionary for inodes (cache the inode as long as the program keeps a reference to it), along with garbage collection... plus, I don't ever have to worry about messing up pointers and getting a crash (which I had in my earlier version of ffsrecov)... also, it only took me a weekend to write... The real big thing is that I don't have to worry about the differences between ufs1_daddr_t and ufs2_daddr_t, and w/ the classes, lets me treat inodes from both UFS1 and UFS2 exactly the same... -- 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 Sep 27 09:39:12 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 1A75416A41F for ; Tue, 27 Sep 2005 09:39:12 +0000 (GMT) (envelope-from steve.rieger@tbwachiat.com) Received: from up-south.com (cpe-24-29-149-124.nyc.res.rr.com [24.29.149.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8D7B43D48 for ; Tue, 27 Sep 2005 09:39:11 +0000 (GMT) (envelope-from steve.rieger@tbwachiat.com) Received: from [10.20.4.142] (nyhost250.pool.tbwachiat.com [208.244.205.250]) by up-south.com (Postfix) with ESMTP id 31D5244262F; Tue, 27 Sep 2005 05:39:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Steve Rieger Date: Tue, 27 Sep 2005 05:39:10 -0400 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.734) Subject: FATAL: erealloc(): Unable to allocate 577925121 bytes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2005 09:39:12 -0000 hi all this is causing me major headaches. when trying to d/l the following file 1 www www 551M Sep 16 13:23 20050818002.zip via apache1.3.33/php 4.3.11, i get that in the logs i thought it was because i dont have enough swap so i did cat /etc/rc.conf mdconfig -a -t vnode -f /usr/swap1 -u 1 && swapon /dev/md1 mdconfig -a -t vnode -f /usr/swap2 -u 2 && swapon /dev/md2 mdconfig -a -t vnode -f /usr/swap3 -u 3 && swapon /dev/md3 mdconfig -a -t vnode -f /usr/swap4 -u 4 && swapon /dev/md4 %swapinfo Device 1K-blocks Used Avail Capacity /dev/da0s1b 4194304 0 4194304 0% /dev/md2 262144 0 262144 0% /dev/md3 262144 0 262144 0% /dev/md4 262144 0 262144 0% /dev/md5 262144 0 262144 0% /dev/md6 1048576 0 1048576 0% Total 6291456 0 6291456 0% which means i have more than enough swap and a show of top proves it last pid: 1275; load averages: 0.24, 0.19, 0.16 up 0 +00:34:42 05:31:19 73 processes: 1 running, 72 sleeping CPU states: % user, % nice, % system, % interrupt, % idle Mem: 38M Active, 25M Inact, 54M Wired, 46M Cache, 61M Buf, 3348M Free Swap: 6143M Total, 6143M Free i set the following in the local dir in htaccess php_value upload_max_filesize 300M php_value memory_limit 947M php_value max_input_time 120 php_value max_execution_time 120 php_value post_max_size 947M i want 1 gig to be the limit of downloads. note this is on freebsd 5.4 custom kernel with smp. and yes i can scp these large files, as far as i can see i am not doing anything wrong, then why cant i download a 551 MB file anything under say 450 MB works great. Steve Rieger steve.rieger@tbwachiat.com Cell 646-335-8915 Office 212 804 1131 Fax 212 804 1200 AIM chozrim Yahoo riegersteve From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 26 19:42:33 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 23F7916A41F for ; Mon, 26 Sep 2005 19:42:33 +0000 (GMT) (envelope-from glenn@antimatter.net) Received: from cobalt.antimatter.net (cobalt.antimatter.net [69.55.224.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BF8043D75 for ; Mon, 26 Sep 2005 19:42:27 +0000 (GMT) (envelope-from glenn@antimatter.net) Received: from glenn-mobile.antimatter.net (cpe-66-27-86-22.san.res.rr.com [66.27.86.22]) (authenticated bits=0) by cobalt.antimatter.net (8.13.4/8.13.4) with ESMTP id j8QJgQM4001818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2005 12:42:27 -0700 X-MailKey: purple frogs are falling from the sky Message-Id: <6.2.3.4.2.20050926123752.0352ad60@cobalt.antimatter.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 26 Sep 2005 12:40:58 -0700 To: eoghan , freebsd-hackers@freebsd.org From: Glenn Dawson In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Tue, 27 Sep 2005 11:35:46 +0000 Cc: Subject: Re: mysql port install X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 19:42:33 -0000 At 10:05 AM 9/26/2005, eoghan wrote: >Hello >Im having a problem getting mysql (version 4.1.14) to work. Im >installing from ports, which was updated today. Each time i try #>mysql >is get: ERROR 2002 (HY000): Can't connect to local MySQL server >through socket '/tmp/mysql.sock' (2) >mysql.sock isnt in /tmp/ which is a problem. The manual and searches >say that this means the server usually isnt running, so type mysqld >to start it. But i just get command not found. The only reference to >mysqld is in /usr/local/man/man1/mysql.1.gz >I was wondering if someone had any luck getting this port installed? >Im using freeBSD 5.3 by the way. Make sure you have mysqld_enable"YES" in your /etc/rc.conf and then use /usr/local/etc/rc.d/mysql-server.sh start to start the server. (you may nee to copy mysql-server.sh from mysql-server.sh.sample first) -Glenn >Thanks >Eoghan >_______________________________________________ >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 Sep 26 20:07:51 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 EF33416A41F for ; Mon, 26 Sep 2005 20:07:51 +0000 (GMT) (envelope-from kdk@daleco.biz) Received: from ezekiel.daleco.biz (southernuniform.com [66.76.92.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 793C743D48 for ; Mon, 26 Sep 2005 20:07:51 +0000 (GMT) (envelope-from kdk@daleco.biz) Received: from [192.168.2.2] ([69.27.149.254]) by ezekiel.daleco.biz (8.13.1/8.13.1) with ESMTP id j8QK6j38091514; Mon, 26 Sep 2005 15:07:05 -0500 (CDT) (envelope-from kdk@daleco.biz) Message-ID: <433854BA.1000302@daleco.biz> Date: Mon, 26 Sep 2005 15:06:18 -0500 From: Kevin Kinsey User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.11) Gecko/20050923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: eoghan References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 27 Sep 2005 11:35:46 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: mysql port install X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 20:07:52 -0000 eoghan wrote: > Hello > Im having a problem getting mysql (version 4.1.14) to work. This isn't hackers@ material. See my reply posted to you and to questions@.... Kevin Kinsey From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 26 20:18:52 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 30CBE16A41F; Mon, 26 Sep 2005 20:18:52 +0000 (GMT) (envelope-from glenn@antimatter.net) Received: from cobalt.antimatter.net (cobalt.antimatter.net [69.55.224.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8C0943D49; Mon, 26 Sep 2005 20:18:51 +0000 (GMT) (envelope-from glenn@antimatter.net) Received: from glenn-mobile.antimatter.net (cpe-66-27-86-22.san.res.rr.com [66.27.86.22]) (authenticated bits=0) by cobalt.antimatter.net (8.13.4/8.13.4) with ESMTP id j8QKIo0a003038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2005 13:18:51 -0700 X-MailKey: purple frogs are falling from the sky Message-Id: <6.2.3.4.2.20050926131354.05b98e40@cobalt.antimatter.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 26 Sep 2005 13:17:22 -0700 To: eoghan From: Glenn Dawson In-Reply-To: References: <6.2.3.4.2.20050926123752.0352ad60@cobalt.antimatter.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Tue, 27 Sep 2005 11:35:46 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: mysql port install X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 20:18:52 -0000 At 01:04 PM 9/26/2005, eoghan wrote: >On 26 Sep 2005, at 20:40, Glenn Dawson wrote: >>Make sure you have mysqld_enable"YES" in your /etc/rc.conf and then >>use >>/usr/local/etc/rc.d/mysql-server.sh start >>to start the server. (you may nee to copy mysql-server.sh from >>mysql-server.sh.sample first) > >Hi Glenn >Thanks! However, I get: >#>/usr/local/etc/rc.d/mysql-server.sh start >This: not found >#> >I have checked the dir and mysql-server.sh is there. >Any ideas? Can you share the contents or your mysql-server.sh? Also, I'm cc'ing this over to freebsd-questions@ which is a more appropriate list for this, lets continue on that list. -Glenn >Thanks >Eoghan > > >_______________________________________________ >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 Sep 27 17:48:21 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 BF6E216A41F for ; Tue, 27 Sep 2005 17:48:21 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2865843D5C for ; Tue, 27 Sep 2005 17:48:19 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru (8.13.0/vak/3.0) id j8RHjH4b091256 for freebsd-hackers@freebsd.org.checked; Tue, 27 Sep 2005 21:45:17 +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 j8RHhLO0091214; Tue, 27 Sep 2005 21:43:21 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <433984C9.2040403@cronyx.ru> Date: Tue, 27 Sep 2005 21:43:37 +0400 From: Roman Kurakin User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: LOR #55 fix proposal (kern_descrip.c patch) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2005 17:48:21 -0000 Hi, It seems that the LOR #55 (http://sources.zabbadoz.net/freebsd/lor.html#055) could be fixed by following patch. I need testers and reviewers of it since I want to commit it. I do not see a reason why not to extend action of FILEDESC_LOCK. (http://www.cronyx.ru/~rik/freebsd/lor055/lor55.pch) Index: kern_descrip.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_descrip.c,v retrieving revision 1.280 diff -u -r1.280 kern_descrip.c --- kern_descrip.c 26 Aug 2005 11:16:39 -0000 1.280 +++ kern_descrip.c 27 Sep 2005 17:31:57 -0000 @@ -2275,7 +2275,6 @@ fdused(fdp, indx); if (fp != NULL) FILE_LOCK(fp); - FILEDESC_UNLOCK(fdp); /* * We now own the reference to fp that the ofiles[] array @@ -2283,6 +2282,9 @@ */ if (fp != NULL) fdrop_locked(fp, td); + + FILEDESC_UNLOCK(fdp); + return (0); default: Best regards, rik From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 27 19:43:47 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 5650C16A41F; Tue, 27 Sep 2005 19:43:47 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id C93DA43D48; Tue, 27 Sep 2005 19:43:46 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id C782746B13; Tue, 27 Sep 2005 15:43:45 -0400 (EDT) Date: Tue, 27 Sep 2005 20:43:45 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Rob Watt In-Reply-To: <20050927140535.G50334@daemon.mistermishap.net> Message-ID: <20050927203128.S61419@fledge.watson.org> References: <20050925115912.H11229@fledge.watson.org> <20050927140535.G50334@daemon.mistermishap.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@FreeBSD.org, mikep@hudson-trading.com, freebsd-amd64@FreeBSD.org, Jason Carroll Subject: Re: freebsd-5.4-stable panics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2005 19:43:47 -0000 On Tue, 27 Sep 2005, Rob Watt wrote: > Thanks for your quick response and suggestions. We have now experienced > an additional type of crash. Type 3 is from 6.0-BETA5, it did not enter > the debugger at all and we could not generate a core. Is this an SMP box? If so, could you try compiling options KDB_STOP_NMI into your kernel -- you'll also need to set debug.kdb.stop_cpus_with_nmi=1 in either loader.conf or at runtime with sysctls. This will probably become the default at some point -- in the mean time, the default when entering the debugger on one CPU is to generate an IPI to the other CPUs telling them "go into the debugger". This works fine unless the CPU has interrupts disabled, such as if it's holding a spin lock in the scheduler, in which case the system will deadlock because that CPU won't acknowledge the IPI. With the above option, a non-maskable interrupt is used to signal the other CPUs into the debugger, which gets into the debugger much more reliably. The trap information you've provided indicates that it is likely a data NULL pointer dereference in the kernel (faulting address is a small increment above NULL). The instruction pointer looks valid -- if you have a debugging copy of the kernel, could you load it into gdb and show me what line number / piece of code it's in? you can use "l *ffffffff803b88ca" to generate that, even without a live debugger session or core. If you can get into DDB with the above, generally good starting point debugging information (ideally gathered with a serial console) is: trace # current thread trace show pcpu # current CPU data show pcpu 0 # CPU 0 data show pcpu 1 # CPU 1 data ... # Any other CPUs ps # process listing show lockedvnods # VFS locking information If you have WITNESS compiled in, also: show alllocks > Unfortunately the 6-BETA crash was completely different from everything > we've seen so far. The panic was related to a page fault and 'top' was > the active process. We are trying again to run our tests on 6.0, but if > we keep encountering other bugs, then those other bugs may prevent us > from determining if multicast is the problem. Let's see if we can get whatever this first bug you're hitting is fixed and see if we can get to the next original problems. > We also ran our applications in 5-STABLE without reading from or writing > to disk (ie we ran the multicast data streams on a remote machine, and > we told our listener/rebroadcaster apps not to write to disk). In this > configuration we were able to run for 4 days without crashing. A few > hours before the crash we had introduced disk activity (bonnie in a > constant loop with 1G test file size). This crash was a type 1, and we > were not able to save a core. The longest we had gone before without a > crash was 6 hours, so it is possible that either load, or disk activity > help trigger the bugs we have seen. I'm heading off on a vacation for two days, and will be offline for that period, but if we can't easily get through solving 6.x problems on the host, I can backport a subset of the multicast fixes to 5.x and we can see if that fixes things up. It may make sense to do this anyway, but I may not have an opportunity to go through the development and testing on that until after 6.0 is out the door. > files attached: > kernel-conf.txt (6.0 kernel) > type3-core.txt (copy of panic output to console) > > We will update you with more info from our 6.0 tests when we have it. > > We are in a bind right now. All modern hardware (ie emt64/amd64) only > seems to work with versions of freebsd that aren't stable when running > our applications. Many vendors do not even sell server hardware that is > purely i386. We never encountered these types of problems on freebsd > 4.x, and many of our 120+ i386 class machines that are running 4.x are > showing their age and need to be replaced. Assuming that the problems we > are experiencing are purely related to ths OS, we now don't have an OS > to run on the newer hardware we've been buying. We really need to find a > way to patch these problems or find a version of freebsd that supports > our platform and is stable. Obviously we appreciate the hard work that > all of you on the freebsd team do, and we are happy to do whatever we > can to help squash these bugs. Hopefully we can get this fixed up as soon as possible. Do you have a testbed or set of test hosts set up so you can non-disruptively test change sets, btw? Thanks, Robert N M Watson From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 27 21:32:02 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 6718C16A41F; Tue, 27 Sep 2005 21:32:02 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C40A43D5A; Tue, 27 Sep 2005 21:32:01 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 2D79C46B0D; Tue, 27 Sep 2005 17:32:01 -0400 (EDT) Date: Tue, 27 Sep 2005 22:32:01 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Rob Watt In-Reply-To: Message-ID: <20050927222624.R34322@fledge.watson.org> References: <20050925115912.H11229@fledge.watson.org> <20050927140535.G50334@daemon.mistermishap.net> <20050927203128.S61419@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Rob Watt , mikep@hudson-trading.com, freebsd-amd64@freebsd.org, freebsd-hackers@freebsd.org, Jason Carroll Subject: Re: freebsd-5.4-stable panics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2005 21:32:02 -0000 On Tue, 27 Sep 2005, Rob Watt wrote: > this is the piece of code that was referenced by the ip: > > (gdb) l *0xffffffff803b88ca > 0xffffffff803b88ca is in nfsrv_lookup (/usr/src/sys/nfsserver/nfs_serv.c:670). > 665 NFSD_UNLOCK(); > 666 mtx_lock(&Giant); /* VFS */ > 667 if (dirp) > 668 vrele(dirp); > 669 NDFREE(&nd, NDF_ONLY_PNBUF); > 670 if (ndp->ni_startdir) > 671 vrele(ndp->ni_startdir); > 672 if (ndp->ni_vp) > 673 vput(ndp->ni_vp); > 674 mtx_unlock(&Giant); /* VFS */ > > we are not running nfsd (although we do use nfs and nfsiod), and none of > our processes should have been accessing nfs. Our processes are run from > an nfs mount but do not access any nfs mounted files. That code is in the NFS server lookup code, so should be called as a result of a lookup by a remote client. If the NFS server is not in use on the machine, this is most likely this is a quirk of gdb and instruction pointers, a run-time kernel/compile-time kernel mismatch, or something really nasty. ndp should really never be NULL there, as it's used frequently prior to that point. Let's hope for one of the former few options. >> Do you have a testbed or set of test hosts set up so you can >> non-disruptively test change sets, btw? > > yes we have 3 dual dual-core machines and 1 dual single-core machine > that we can use to test with. Great. As mentioned I'll be offline for about the next 48 hours, but back after then. If we can get a nice clean crash out of this, would really be best. If it's top panicking, it could well be due to a bug in the process monitoring code, in kern_proc. We've run into bugs a few times there in the past, generally associated with threading or races in process creation/teardown, in which partially initialized (or torn down) processes are accessed by another thread and are in an unexpected state. Thanks, Robert N M Watson From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 28 07:04:16 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 BFACF16A41F; Wed, 28 Sep 2005 07:04:16 +0000 (GMT) (envelope-from bu7cher@yandex.ru) Received: from mail.rdu.kirov.ru (ns.rdu.kirov.ru [217.9.151.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE53C43D49; Wed, 28 Sep 2005 07:04:13 +0000 (GMT) (envelope-from bu7cher@yandex.ru) Received: from kirov.so-cdu.ru (kirov [172.21.81.1]) by mail.rdu.kirov.ru (Postfix) with ESMTP id 209D2FEB4; Wed, 28 Sep 2005 11:04:12 +0400 (MSD) Received: from kirov.so-cdu.ru (localhost [127.0.0.1]) by rdu.kirov.ru (Postfix) with SMTP id 0CE6315C85; Wed, 28 Sep 2005 11:04:12 +0400 (MSD) Received: by rdu.kirov.ru (Postfix, from userid 1014) id C70FF15C82; Wed, 28 Sep 2005 11:04:11 +0400 (MSD) Received: from [172.21.81.52] (elsukov.kirov.so-cdu.ru [172.21.81.52]) by rdu.kirov.ru (Postfix) with ESMTP id 9712915C79; Wed, 28 Sep 2005 11:04:11 +0400 (MSD) Message-ID: <433A406B.3000300@yandex.ru> Date: Wed, 28 Sep 2005 11:04:11 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.0.6 (FreeBSD/20050716) MIME-Version: 1.0 To: ipfw@freebsd.org, hackers@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: nonprivileged access to ipfw X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bu7cher@yandex.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2005 07:04:16 -0000 Hi All! I want a nonprivileged access to ipfw (without sudo, suid and etc..). But RAW sockets restrict this. I have an one idea - a pseudo device /dev/ipfw. I think that realisation of this feature is not difficult task. Now i have some questions. 1. I think correctly about following? * adding cdevsw declaration with ipfw_ioctl implementation; * adding make_dev into ipfw initialization function (on MOD_LOAD event); * adding destroy_dev (on MOD_UNLOAD); * adding needed functionaly into /sbin/ipfw. 2. About ipfw_ioctl implemetation: I can pack an ioctl params into sockopt structure and directly call ipfw_ctl function. It's ok? 3. About ioctl requests - What symbol I should place into definition of ioctl request? On what it depends? For example: #define DIOCCLRSTATES _IOWR('D', 18, struct pfioc_state_kill) >>-----------------------------^ 4. I can define only two ioctl requests, for example: IPFWIOCSCMD _IOW('x', 0, struct sockopt_like_struct) IPFWIOCGCMD _IOR('x', 1, struct sockopt_like_struct) and pass IP_FW_XXX sockoption's into sockopt_like_struct member, or I should define two definition (set/get) for each IP_FW_XXX option? Thanks and sorry for my english :( -- WBR, Andrey V. Elsukov From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 28 07:40:05 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 40B3B16A41F for ; Wed, 28 Sep 2005 07:40:05 +0000 (GMT) (envelope-from nsrashmi@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id D775243D4C for ; Wed, 28 Sep 2005 07:40:04 +0000 (GMT) (envelope-from nsrashmi@gmail.com) Received: by xproxy.gmail.com with SMTP id t14so1354105wxc for ; Wed, 28 Sep 2005 00:40:04 -0700 (PDT) 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:content-disposition; b=i96XbI/uOUYhbYZBwrj4/p1lqdDLr2z8XKtTOvbPdRNMja6N56+TkHQmipCuWszGbYDIlbaRpbCKqpeIhbxTwBgndM/EWobJ2JtMcZXSdYA/8EaQkzawfy08bJmJHmXH/5wtXWxlAuRaVY4iCNV1pEEdV9NaWV+oGZClb//nHO8= Received: by 10.70.37.9 with SMTP id k9mr3284833wxk; Wed, 28 Sep 2005 00:40:04 -0700 (PDT) Received: by 10.70.15.12 with HTTP; Wed, 28 Sep 2005 00:40:03 -0700 (PDT) Message-ID: <9f99931605092800402dd1db9a@mail.gmail.com> Date: Wed, 28 Sep 2005 13:10:03 +0530 From: rashmi ns To: bugi@lists.redbrick.dcu.ie, freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: (no subject) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rashmi ns List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2005 07:40:05 -0000 Hello All , I was trying to add a new ioctl cnd like #define HDLCMODE _IOR('6',0xF,int) From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 28 07:51:33 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 8DAD416A422 for ; Wed, 28 Sep 2005 07:51:33 +0000 (GMT) (envelope-from nsrashmi@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2807A43D48 for ; Wed, 28 Sep 2005 07:51:33 +0000 (GMT) (envelope-from nsrashmi@gmail.com) Received: by xproxy.gmail.com with SMTP id t14so1355117wxc for ; Wed, 28 Sep 2005 00:51:32 -0700 (PDT) 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:references; b=N+yNo7aX2JoOW5NA7tpbECXOmPvt+bCL2QqJ7ddbEWKM6GhwHayqrwzCkDvkeYJyL7NoUZcx3YQpRzMxXWuwiS+Ry45qof5SEbKKrk8TNgex2ZOOZ++pti6JxIC/GgBEEXRnynjtZS5IzBav6Ow8Dg0lWLLIyTZ7F2n2xnJ5z9Y= Received: by 10.70.52.15 with SMTP id z15mr3312104wxz; Wed, 28 Sep 2005 00:45:20 -0700 (PDT) Received: by 10.70.15.12 with HTTP; Wed, 28 Sep 2005 00:45:20 -0700 (PDT) Message-ID: <9f9993160509280045586fb14d@mail.gmail.com> Date: Wed, 28 Sep 2005 13:15:20 +0530 From: rashmi ns To: bugi@lists.redbrick.dcu.ie, freebsd-hackers@freebsd.org In-Reply-To: <9f99931605092800402dd1db9a@mail.gmail.com> MIME-Version: 1.0 References: <9f99931605092800402dd1db9a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rashmi ns List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2005 07:51:33 -0000 Hello All , I was trying to add a new ioctl cnd like #define HDLCMODE _IOR('6',0xF,int) when i try to uprintf the data which was sent from the user-space in the device-driver-ioctl-routine i'll get a different value than which is passed= . Can anybody please tell me why this is happening . I pass the address of integer from the user space as third arg to the ioctl call . thanks and regards, Rashmi.N.S From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 28 08:10:47 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 5A9F516A41F for ; Wed, 28 Sep 2005 08:10:47 +0000 (GMT) (envelope-from nsrashmi@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB60F43D48 for ; Wed, 28 Sep 2005 08:10:46 +0000 (GMT) (envelope-from nsrashmi@gmail.com) Received: by xproxy.gmail.com with SMTP id t14so1356793wxc for ; Wed, 28 Sep 2005 01:10:46 -0700 (PDT) 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; b=X3s7rX3o5ED8O1+o++TUzoVhC8kCbRWrUkZl1TMFfSatoyk/GTzCG/WfnGgWGQiY+Ruvq34c8b6MxfJf9YbbP186Lk1DyM9UWfxyBc5fUuV4q2qlxwoQ5dAynMJQydtviG1mvcBfH7puaxMMgtX2dmJEujbW5fZedh//UNXY6gs= Received: by 10.70.11.20 with SMTP id 20mr1450615wxk; Wed, 28 Sep 2005 01:10:46 -0700 (PDT) Received: by 10.70.15.12 with HTTP; Wed, 28 Sep 2005 01:10:46 -0700 (PDT) Message-ID: <9f999316050928011010542946@mail.gmail.com> Date: Wed, 28 Sep 2005 13:40:46 +0530 From: rashmi ns To: bugi@lists.redbrick.dcu.ie, freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: IOCTL :Facing problems while acccessing data from kernel space X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rashmi ns List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2005 08:10:48 -0000 > Hello All , Sorry for resending the message many times !!!. I was trying to add a new ioctl command like > #define HDLCMODE _IOR('6',0xF,int) > when i trying to uprintf the data which was sent from the user-space in > the device-driver-ioctl-routine i'll get a different value than which was > passed. Can anybody please tell me why this is happening . I pass the > address of an integer where data is stored from the user space as third a= rg > to the ioctl call . > Thanks and regards, > Rashmi.N.S > > From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 28 09:48:20 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 E1E2716A41F for ; Wed, 28 Sep 2005 09:48:20 +0000 (GMT) (envelope-from corecode@fs.ei.tum.de) Received: from stella.fs.ei.tum.de (stella.fs.ei.tum.de [129.187.54.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6EEB743D49 for ; Wed, 28 Sep 2005 09:48:15 +0000 (GMT) (envelope-from corecode@fs.ei.tum.de) Received: from localhost (localhost [127.0.0.1]) by localhost.fs.ei.tum.de (Postfix) with ESMTP id 183CA8DDA5; Wed, 28 Sep 2005 11:48:14 +0200 (CEST) Received: from stella.fs.ei.tum.de ([127.0.0.1]) by localhost (stella [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28600-01-3; Wed, 28 Sep 2005 11:48:13 +0200 (CEST) Received: from [10.150.180.180] (r180180.olydorf.swh.mhn.de [10.150.180.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by stella.fs.ei.tum.de (Postfix) with ESMTP id A777D8DD8C; Wed, 28 Sep 2005 11:48:13 +0200 (CEST) Message-ID: <433A66DD.7010305@fs.ei.tum.de> Date: Wed, 28 Sep 2005 11:48:13 +0200 From: Simon 'corecode' Schubert User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050912) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rashmi ns References: <9f999316050928011010542946@mail.gmail.com> In-Reply-To: <9f999316050928011010542946@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at fs.ei.tum.de Cc: freebsd-hackers@freebsd.org, bugi@lists.redbrick.dcu.ie Subject: Re: IOCTL :Facing problems while acccessing data from kernel space X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2005 09:48:21 -0000 rashmi ns wrote: >>#define HDLCMODE _IOR('6',0xF,int) >>when i trying to uprintf the data which was sent from the user-space in >>the device-driver-ioctl-routine i'll get a different value than which was >>passed. Can anybody please tell me why this is happening . I pass the >>address of an integer where data is stored from the user space as third arg >>to the ioctl call . maybe you should show how you do it in kernel. I suspect you try to access it as an int* as well, which is wrong. The kernel already does take care of this for you. Just write the integer you want to pass into the data area and you're done. cheers simon -- Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\ Work - Mac +++ space for low $$$ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 27 14:53:12 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 B527F16A41F for ; Tue, 27 Sep 2005 14:53:12 +0000 (GMT) (envelope-from neuhauser@sigpipe.cz) Received: from isis.sigpipe.cz (fw.sigpipe.cz [62.245.70.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE78443D5D for ; Tue, 27 Sep 2005 14:53:10 +0000 (GMT) (envelope-from neuhauser@sigpipe.cz) Received: by isis.sigpipe.cz (Postfix, from userid 1001) id 2430C1F87BF1; Tue, 27 Sep 2005 16:53:09 +0200 (CEST) Date: Tue, 27 Sep 2005 16:53:09 +0200 From: Roman Neuhauser To: Steve Rieger Message-ID: <20050927145308.GA3854@isis.sigpipe.cz> Mail-Followup-To: Steve Rieger , freebsd-hackers@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Mailman-Approved-At: Wed, 28 Sep 2005 11:24:03 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: FATAL: erealloc(): Unable to allocate 577925121 bytes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2005 14:53:12 -0000 # steve.rieger@tbwachiat.com / 2005-09-27 05:39:10 -0400: > when trying to d/l the following file > > 1 www www 551M Sep 16 13:23 20050818002.zip > > via apache1.3.33/php 4.3.11, i get that in the logs > i thought it was because i dont have enough swap so i did [...] See ulimit(1), search for "ulimit" in sh(1), and please, ask this kind of questions on, well, questions@. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 27 21:22:49 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 1B19916A41F for ; Tue, 27 Sep 2005 21:22:49 +0000 (GMT) (envelope-from rob.watt@gmail.com) Received: from qproxy.gmail.com (qproxy.gmail.com [72.14.204.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 044D543D49 for ; Tue, 27 Sep 2005 21:22:47 +0000 (GMT) (envelope-from rob.watt@gmail.com) Received: by qproxy.gmail.com with SMTP id p26so571367qbb for ; Tue, 27 Sep 2005 14:22:47 -0700 (PDT) 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:content-disposition:references; b=pujMs4qCjkfwsZidk3mlHs6rtSWC3THUcsHT0wqgFeYF50eI0LoJ0zZF9fR4FxtPnkcaQxliAjoHkUvFPmgdaqOYfKEkewO9IYc4Yk2jFyP9L1Wx8N61aWGwxgK7lKhw2UtrdFP3rR8pOBoqQ7Up8qfhNZ3rqIMvsndYKT4Qnk8= Received: by 10.64.249.12 with SMTP id w12mr692492qbh; Tue, 27 Sep 2005 14:22:47 -0700 (PDT) Received: by 10.64.209.3 with HTTP; Tue, 27 Sep 2005 14:22:47 -0700 (PDT) Message-ID: Date: Tue, 27 Sep 2005 17:22:47 -0400 From: Rob Watt To: Robert Watson In-Reply-To: <20050927203128.S61419@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050925115912.H11229@fledge.watson.org> <20050927140535.G50334@daemon.mistermishap.net> <20050927203128.S61419@fledge.watson.org> X-Mailman-Approved-At: Wed, 28 Sep 2005 11:24:03 +0000 Cc: Rob Watt , mikep@hudson-trading.com, freebsd-amd64@freebsd.org, freebsd-hackers@freebsd.org, Jason Carroll Subject: Re: freebsd-5.4-stable panics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rob Watt List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2005 21:22:49 -0000 On 9/27/05, Robert Watson wrote: > > On Tue, 27 Sep 2005, Rob Watt wrote: > > > Is this an SMP box? If so, could you try compiling options KDB_STOP_NMI > into your kernel -- you'll also need to set debug.kdb.stop_cpus_with_nmi= =3D1 > in either loader.conf or at runtime with sysctls. This is a dual-core dual 275 processor box. I have compiled the nmi options into the kernel and we are now using that to test. > > The trap information you've provided indicates that it is likely a data > NULL pointer dereference in the kernel (faulting address is a small > increment above NULL). The instruction pointer looks valid -- if you hav= e > a debugging copy of the kernel, could you load it into gdb and show me > what line number / piece of code it's in? you can use "l > *ffffffff803b88ca" to generate that, even without a live debugger session > this is the piece of code that was referenced by the ip: (gdb) l *0xffffffff803b88ca 0xffffffff803b88ca is in nfsrv_lookup (/usr/src/sys/nfsserver/nfs_serv.c:67= 0). 665 NFSD_UNLOCK(); 666 mtx_lock(&Giant); /* VFS */ 667 if (dirp) 668 vrele(dirp); 669 NDFREE(&nd, NDF_ONLY_PNBUF); 670 if (ndp->ni_startdir) 671 vrele(ndp->ni_startdir); 672 if (ndp->ni_vp) 673 vput(ndp->ni_vp); 674 mtx_unlock(&Giant); /* VFS */ we are not running nfsd (although we do use nfs and nfsiod), and none of our processes should have been accessing nfs. Our processes are run from an nfs mount but do not access any nfs mounted files. > > Do you have a testbed or set of test hosts set up so you can > non-disruptively test change sets, btw? > yes we have 3 dual dual-core machines and 1 dual single-core machine that we can use to test with. Thanks! - Rob Watt From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 27 19:12:44 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 F0D9F16A44F; Tue, 27 Sep 2005 19:12:43 +0000 (GMT) (envelope-from rob@hudson-trading.com) Received: from daemon.mistermishap.net (167-49.nyc.dsl.access.net [166.84.167.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21AE843D73; Tue, 27 Sep 2005 19:12:32 +0000 (GMT) (envelope-from rob@hudson-trading.com) Received: from daemon.mistermishap.net (localhost.mistermishap.net [127.0.0.1]) by daemon.mistermishap.net (8.12.9/8.12.9) with ESMTP id j8RJCVmU051464; Tue, 27 Sep 2005 15:12:31 -0400 (EDT) (envelope-from rob@hudson-trading.com) Received: from localhost (rob@localhost) by daemon.mistermishap.net (8.12.9/8.12.9/Submit) with ESMTP id j8RJCVuO051461; Tue, 27 Sep 2005 15:12:31 -0400 (EDT) X-Authentication-Warning: daemon.mistermishap.net: rob owned process doing -bs Date: Tue, 27 Sep 2005 15:12:31 -0400 (EDT) From: Rob Watt X-X-Sender: rob@daemon.mistermishap.net To: Robert Watson In-Reply-To: <20050925115912.H11229@fledge.watson.org> Message-ID: <20050927140535.G50334@daemon.mistermishap.net> References: <20050925115912.H11229@fledge.watson.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-779721010-1127845675=:50334" X-Mailman-Approved-At: Wed, 28 Sep 2005 12:50:04 +0000 Cc: Rob Watt , freebsd-hackers@FreeBSD.org, mikep@hudson-trading.com, freebsd-amd64@FreeBSD.org, Jason Carroll Subject: Re: freebsd-5.4-stable panics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2005 19:12:44 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-779721010-1127845675=:50334 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Sun, 25 Sep 2005, Robert Watson wrote: > > On Fri, 23 Sep 2005, Jason Carroll wrote: > 5B > > There seem to be 2 types of crashes we see with pretty different stack > > traces. What I'll call a type 1 crash, I believe, is often caused by > > one of the triggers I mention above. A type 2 crash appears to happen > > spontaneously after the machine has been running for a while. > > > > I poked around using kgdb in a core file from a type 2 crash, and it > > appeared the system hung closing sockets (specifically cleaning up > > multicast state i think) while cleaning up one of our multicast > > applications (note the trace through sys_exit). There's no reason this > > application should have been exiting unless it encountered some kind of > > error. > > Sounds nasty. It's possible the two panics are related, especially if > they involve a race in the multicast code, which could result in treading > on other kernel memory, potentially leading to the thread related panic. > My leaning would be that they are unrelated, but since we may be able to > eliminate the multicast one (see below), that would be a good starting > point. > > There are some other known stability nits in 6.x which are being worked > on, but in general the network stack stability is higher in 6.x than 5.x > when it comes to multicast due to the work I reference above. If you run > into any stability problems relating to the file system, set > debug.mpsafevfs=0 in loader.conf -- there are a few bug fixes relating to > running out of disk space or hitting quota limits that are fixed in HEAD, > but not yet backported to 6.x. Robert, Thanks for your quick response and suggestions. We have now experienced an additional type of crash. Type 3 is from 6.0-BETA5, it did not enter the debugger at all and we could not generate a core. Unfortunately the 6-BETA crash was completely different from everything we've seen so far. The panic was related to a page fault and 'top' was the active process. We are trying again to run our tests on 6.0, but if we keep encountering other bugs, then those other bugs may prevent us from determining if multicast is the problem. We also ran our applications in 5-STABLE without reading from or writing to disk (ie we ran the multicast data streams on a remote machine, and we told our listener/rebroadcaster apps not to write to disk). In this configuration we were able to run for 4 days without crashing. A few hours before the crash we had introduced disk activity (bonnie in a constant loop with 1G test file size). This crash was a type 1, and we were not able to save a core. The longest we had gone before without a crash was 6 hours, so it is possible that either load, or disk activity help trigger the bugs we have seen. files attached: kernel-conf.txt (6.0 kernel) type3-core.txt (copy of panic output to console) We will update you with more info from our 6.0 tests when we have it. We are in a bind right now. All modern hardware (ie emt64/amd64) only seems to work with versions of freebsd that aren't stable when running our applications. Many vendors do not even sell server hardware that is purely i386. We never encountered these types of problems on freebsd 4.x, and many of our 120+ i386 class machines that are running 4.x are showing their age and need to be replaced. Assuming that the problems we are experiencing are purely related to ths OS, we now don't have an OS to run on the newer hardware we've been buying. We really need to find a way to patch these problems or find a version of freebsd that supports our platform and is stable. Obviously we appreciate the hard work that all of you on the freebsd team do, and we are happy to do whatever we can to help squash these bugs. - Rob Watt --0-779721010-1127845675=:50334 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="kernel-conf.txt" Content-Transfer-Encoding: BASE64 Content-Description: Content-Disposition: ATTACHMENT; FILENAME="kernel-conf.txt" Iw0KIyBHRU5FUklDIC0tIEdlbmVyaWMga2VybmVsIGNvbmZpZ3VyYXRpb24g ZmlsZSBmb3IgRnJlZUJTRC9hbWQ2NA0KIw0KIyBGb3IgbW9yZSBpbmZvcm1h dGlvbiBvbiB0aGlzIGZpbGUsIHBsZWFzZSByZWFkIHRoZSBoYW5kYm9vayBz ZWN0aW9uIG9uDQojIEtlcm5lbCBDb25maWd1cmF0aW9uIEZpbGVzOg0KIw0K IyAgICBodHRwOi8vd3d3LkZyZWVCU0Qub3JnL2RvYy9lbl9VUy5JU084ODU5 LTEvYm9va3MvaGFuZGJvb2sva2VybmVsY29uZmlnLWNvbmZpZy5odG1sDQoj DQojIFRoZSBoYW5kYm9vayBpcyBhbHNvIGF2YWlsYWJsZSBsb2NhbGx5IGlu IC91c3Ivc2hhcmUvZG9jL2hhbmRib29rDQojIGlmIHlvdSd2ZSBpbnN0YWxs ZWQgdGhlIGRvYyBkaXN0cmlidXRpb24sIG90aGVyd2lzZSBhbHdheXMgc2Vl IHRoZQ0KIyBGcmVlQlNEIFdvcmxkIFdpZGUgV2ViIHNlcnZlciAoaHR0cDov L3d3dy5GcmVlQlNELm9yZy8pIGZvciB0aGUNCiMgbGF0ZXN0IGluZm9ybWF0 aW9uLg0KIw0KIyBBbiBleGhhdXN0aXZlIGxpc3Qgb2Ygb3B0aW9ucyBhbmQg bW9yZSBkZXRhaWxlZCBleHBsYW5hdGlvbnMgb2YgdGhlDQojIGRldmljZSBs aW5lcyBpcyBhbHNvIHByZXNlbnQgaW4gdGhlIC4uLy4uL2NvbmYvTk9URVMg YW5kIE5PVEVTIGZpbGVzLg0KIyBJZiB5b3UgYXJlIGluIGRvdWJ0IGFzIHRv IHRoZSBwdXJwb3NlIG9yIG5lY2Vzc2l0eSBvZiBhIGxpbmUsIGNoZWNrIGZp cnN0DQojIGluIE5PVEVTLg0KIw0KIyAkRnJlZUJTRDogc3JjL3N5cy9hbWQ2 NC9jb25mL0dFTkVSSUMsdiAxLjQyMS4yLjExLjIuMSAyMDA1LzA0LzA5IDE3 OjI4OjM3IGtlbnNtaXRoIEV4cCAkDQoNCm1hY2hpbmUJCWFtZDY0DQpjcHUJ CUhBTU1FUg0KaWRlbnQJCUNVU1RPTQ0KDQojIFRvIHN0YXRpY2FsbHkgY29t cGlsZSBpbiBkZXZpY2Ugd2lyaW5nIGluc3RlYWQgb2YgL2Jvb3QvZGV2aWNl LmhpbnRzDQojaGludHMJCSJHRU5FUklDLmhpbnRzIgkJIyBEZWZhdWx0IHBs YWNlcyB0byBsb29rIGZvciBkZXZpY2VzLg0KbWFrZW9wdGlvbnMgICAgIERF QlVHPS1nDQpvcHRpb25zICAgICAgICAgS0RCDQpvcHRpb25zICAgICAgICAg RERCDQpvcHRpb25zICAgICAgICAgQlJFQUtfVE9fREVCVUdHRVINCm9wdGlv bnMgICAgICAgICBJTlZBUklBTlRTDQpvcHRpb25zICAgICAgICAgSU5WQVJJ QU5UX1NVUFBPUlQNCm9wdGlvbnMgICAgICAgICBXSVRORVNTDQpvcHRpb25z ICAgICAgICAgV0lUTkVTU19TS0lQU1BJTg0KI21ha2VvcHRpb25zICAgICBD T1BURkxBR1M9Ii1PIC1mcmVuYW1lLXJlZ2lzdGVycyAtcGlwZSINCg0KI29w dGlvbnMgICAgICAgIFNDSEVEX1VMRSAgICAgICAgICAgICAgICMgVUxFIHNj aGVkdWxlcg0Kb3B0aW9ucyAJU0NIRURfNEJTRAkJIyA0QlNEIHNjaGVkdWxl cg0Kb3B0aW9ucyAJSU5FVAkJCSMgSW50ZXJORVR3b3JraW5nDQpvcHRpb25z IAlJTkVUNgkJCSMgSVB2NiBjb21tdW5pY2F0aW9ucyBwcm90b2NvbHMNCm9w dGlvbnMgCUZGUwkJCSMgQmVya2VsZXkgRmFzdCBGaWxlc3lzdGVtDQpvcHRp b25zIAlTT0ZUVVBEQVRFUwkJIyBFbmFibGUgRkZTIHNvZnQgdXBkYXRlcyBz dXBwb3J0DQpvcHRpb25zIAlVRlNfQUNMCQkJIyBTdXBwb3J0IGZvciBhY2Nl c3MgY29udHJvbCBsaXN0cw0Kb3B0aW9ucyAJVUZTX0RJUkhBU0gJCSMgSW1w cm92ZSBwZXJmb3JtYW5jZSBvbiBiaWcgZGlyZWN0b3JpZXMNCm9wdGlvbnMg CU1EX1JPT1QJCQkjIE1EIGlzIGEgcG90ZW50aWFsIHJvb3QgZGV2aWNlDQpv cHRpb25zIAlORlNDTElFTlQJCSMgTmV0d29yayBGaWxlc3lzdGVtIENsaWVu dA0Kb3B0aW9ucyAJTkZTU0VSVkVSCQkjIE5ldHdvcmsgRmlsZXN5c3RlbSBT ZXJ2ZXINCm9wdGlvbnMgCU5GU19ST09UCQkjIE5GUyB1c2FibGUgYXMgLywg cmVxdWlyZXMgTkZTQ0xJRU5UDQpvcHRpb25zIAlOVEZTCQkJIyBOVCBGaWxl IFN5c3RlbQ0Kb3B0aW9ucyAJTVNET1NGUwkJCSMgTVNET1MgRmlsZXN5c3Rl bQ0Kb3B0aW9ucyAJQ0Q5NjYwCQkJIyBJU08gOTY2MCBGaWxlc3lzdGVtDQpv cHRpb25zIAlQUk9DRlMJCQkjIFByb2Nlc3MgZmlsZXN5c3RlbSAocmVxdWly ZXMgUFNFVURPRlMpDQpvcHRpb25zIAlQU0VVRE9GUwkJIyBQc2V1ZG8tZmls ZXN5c3RlbSBmcmFtZXdvcmsNCm9wdGlvbnMgCUdFT01fR1BUCQkjIEdVSUQg UGFydGl0aW9uIFRhYmxlcy4NCm9wdGlvbnMgCUNPTVBBVF80MwkJIyBOZWVk ZWQgYnkgQ09NUEFUX0xJTlVYMzINCm9wdGlvbnMgCUNPTVBBVF9JQTMyCQkj IENvbXBhdGlibGUgd2l0aCBpMzg2IGJpbmFyaWVzDQpvcHRpb25zIAlDT01Q QVRfRlJFRUJTRDQJCSMgQ29tcGF0aWJsZSB3aXRoIEZyZWVCU0Q0DQpvcHRp b25zICAgICAgICAgQ09NUEFUX0ZSRUVCU0Q1ICAgICAgICAgIyBDb21wYXRp YmxlIHdpdGggRnJlZUJTRDUNCm9wdGlvbnMgCUNPTVBBVF9MSU5VWDMyCQkj IENvbXBhdGlibGUgd2l0aCBpMzg2IGxpbnV4IGJpbmFyaWVzIA0Kb3B0aW9u cyAJU0NTSV9ERUxBWT01MDAwCSAgICAgICAgIyBEZWxheSAoaW4gbXMpIGJl Zm9yZSBwcm9iaW5nIFNDU0kNCm9wdGlvbnMgCUtUUkFDRQkJCSMga3RyYWNl KDEpIHN1cHBvcnQNCm9wdGlvbnMgCVNZU1ZTSE0JCQkjIFNZU1Ytc3R5bGUg c2hhcmVkIG1lbW9yeQ0Kb3B0aW9ucyAJU1lTVk1TRwkJCSMgU1lTVi1zdHls ZSBtZXNzYWdlIHF1ZXVlcw0Kb3B0aW9ucyAJU1lTVlNFTQkJCSMgU1lTVi1z dHlsZSBzZW1hcGhvcmVzDQpvcHRpb25zIAlfS1BPU0lYX1BSSU9SSVRZX1ND SEVEVUxJTkcgIyBQT1NJWCBQMTAwM18xQiByZWFsLXRpbWUgZXh0ZW5zaW9u cw0Kb3B0aW9ucyAJS0JEX0lOU1RBTExfQ0RFVgkjIGluc3RhbGwgYSBDREVW IGVudHJ5IGluIC9kZXYNCm9wdGlvbnMgCUFIQ19SRUdfUFJFVFRZX1BSSU5U CSMgUHJpbnQgcmVnaXN0ZXIgYml0ZmllbGRzIGluIGRlYnVnDQoJCQkJCSMg b3V0cHV0LiAgQWRkcyB+MTI4ayB0byBkcml2ZXIuDQpvcHRpb25zIAlBSERf UkVHX1BSRVRUWV9QUklOVAkjIFByaW50IHJlZ2lzdGVyIGJpdGZpZWxkcyBp biBkZWJ1Zw0KCQkJCQkjIG91dHB1dC4gIEFkZHMgfjIxNWsgdG8gZHJpdmVy Lg0Kb3B0aW9ucyAJQURBUFRJVkVfR0lBTlQJCSMgR2lhbnQgbXV0ZXggaXMg YWRhcHRpdmUuDQpvcHRpb25zICAgICAgICAgUFJFRU1QVElPTiAgICAgICAg ICAgICAgIyBFbmFibGUga2VybmVsIHRocmVhZCBwcmVlbXB0aW9uDQoNCg0K b3B0aW9ucyAJU01QDQoNCiMgV29ya2Fyb3VuZHMgZm9yIHNvbWUga25vd24t dG8tYmUtYnJva2VuIGNoaXBzZXRzIChuVmlkaWEgbkZvcmNlMy1Qcm8xNTAp DQpkZXZpY2UJCWF0cGljCQkjIDgyNTlBIGNvbXBhdGFiaWxpdHkNCg0KIyBF bmFibGluZyBOT19NSVhFRF9NT0RFIGdpdmVzIGEgcGVyZm9ybWFuY2UgaW1w cm92ZW1lbnQgb24gc29tZSBtb3RoZXJib2FyZHMNCiMgYnV0IGRvZXMgbm90 IHdvcmsgd2l0aCBzb21lIGJvYXJkcyAobW9zdGx5IG5WaWRpYSBjaGlwc2V0 IGJhc2VkKS4NCiNvcHRpb25zIAlOT19NSVhFRF9NT0RFCSMgRG9uJ3QgcGVu YWxpemUgd29ya2luZyBjaGlwc2V0cw0KDQojIExpbnV4IDMyLWJpdCBBQkkg c3VwcG9ydA0Kb3B0aW9ucyAJTElOUFJPQ0ZTCQkjIENhbm5vdCBiZSBhIG1v ZHVsZSB5ZXQuDQoNCiMgQnVzIHN1cHBvcnQuICBEbyBub3QgcmVtb3ZlIGlz YSwgZXZlbiBpZiB5b3UgaGF2ZSBubyBpc2Egc2xvdHMNCmRldmljZQkJYWNw aQ0KZGV2aWNlCQlpc2ENCmRldmljZQkJcGNpDQoNCiMgRmxvcHB5IGRyaXZl cw0KZGV2aWNlCQlmZGMNCg0KIyBBVEEgYW5kIEFUQVBJIGRldmljZXMNCmRl dmljZQkJYXRhDQpkZXZpY2UJCWF0YWRpc2sJCSMgQVRBIGRpc2sgZHJpdmVz DQpkZXZpY2UJCWF0YXJhaWQJCSMgQVRBIFJBSUQgZHJpdmVzDQpkZXZpY2UJ CWF0YXBpY2QJCSMgQVRBUEkgQ0RST00gZHJpdmVzDQpkZXZpY2UJCWF0YXBp ZmQJCSMgQVRBUEkgZmxvcHB5IGRyaXZlcw0KZGV2aWNlCQlhdGFwaXN0CQkj IEFUQVBJIHRhcGUgZHJpdmVzDQpvcHRpb25zIAlBVEFfU1RBVElDX0lECSMg U3RhdGljIGRldmljZSBudW1iZXJpbmcNCg0KIyBTQ1NJIENvbnRyb2xsZXJz DQpkZXZpY2UJCWFoYwkJIyBBSEEyOTQwIGFuZCBvbmJvYXJkIEFJQzd4eHgg ZGV2aWNlcw0KZGV2aWNlCQlhaGQJCSMgQUhBMzkzMjAvMjkzMjAgYW5kIG9u Ym9hcmQgQUlDNzl4eCBkZXZpY2VzDQojZGV2aWNlCQlhbWQJCSMgQU1EIDUz Qzk3NCAoVGVrcmFtIERDLTM5MChUKSkNCiNkZXZpY2UJCWlzcAkJIyBRbG9n aWMgZmFtaWx5DQojZGV2aWNlIAlpc3BmdwkJIyBGaXJtd2FyZSBmb3IgUUxv Z2ljIEhCQXMtIG5vcm1hbGx5IGEgbW9kdWxlDQojZGV2aWNlCQltcHQJCSMg TFNJLUxvZ2ljIE1QVC1GdXNpb24NCiNkZXZpY2UJCW5jcgkJIyBOQ1IvU3lt YmlvcyBMb2dpYw0KI2RldmljZQkJc3ltCQkjIE5DUi9TeW1iaW9zIExvZ2lj IChuZXdlciBjaGlwc2V0cyArIHRob3NlIG9mIGBuY3InKQ0KI2RldmljZQkJ dHJtCQkjIFRla3JhbSBEQzM5NVUvVVcvRiBEQzMxNVUgYWRhcHRlcnMNCg0K I2RldmljZQkJYWR2CQkjIEFkdmFuc3lzIFNDU0kgYWRhcHRlcnMNCiNkZXZp Y2UJCWFkdwkJIyBBZHZhbnN5cyB3aWRlIFNDU0kgYWRhcHRlcnMNCmRldmlj ZQkJYWljCQkjIEFkYXB0ZWMgMTVbMDEyXXggU0NTSSBhZGFwdGVycywgQUlD LTZbMjNdNjAuDQojZGV2aWNlCQlidAkJIyBCdXNsb2dpYy9NeWxleCBNdWx0 aU1hc3RlciBTQ1NJIGFkYXB0ZXJzDQoNCg0KIyBTQ1NJIHBlcmlwaGVyYWxz DQpkZXZpY2UJCXNjYnVzCQkjIFNDU0kgYnVzIChyZXF1aXJlZCBmb3IgU0NT SSkNCmRldmljZQkJY2gJCSMgU0NTSSBtZWRpYSBjaGFuZ2Vycw0KZGV2aWNl CQlkYQkJIyBEaXJlY3QgQWNjZXNzIChkaXNrcykNCmRldmljZQkJc2EJCSMg U2VxdWVudGlhbCBBY2Nlc3MgKHRhcGUgZXRjKQ0KZGV2aWNlCQljZAkJIyBD RA0KZGV2aWNlCQlwYXNzCQkjIFBhc3N0aHJvdWdoIGRldmljZSAoZGlyZWN0 IFNDU0kgYWNjZXNzKQ0KZGV2aWNlCQlzZXMJCSMgU0NTSSBFbnZpcm9ubWVu dGFsIFNlcnZpY2VzIChhbmQgU0FGLVRFKQ0KDQojIFJBSUQgY29udHJvbGxl cnMgaW50ZXJmYWNlZCB0byB0aGUgU0NTSSBzdWJzeXN0ZW0NCiNkZXZpY2UJ CWFtcgkJIyBBTUkgTWVnYVJBSUQNCiNkZXZpY2UJCWFyY21zcgkJIyBBcmVj YSBTQVRBIElJIFJBSUQNCiNkZXZpY2UJCWNpc3MJCSMgQ29tcGFxIFNtYXJ0 IFJBSUQgNSoNCiNkZXZpY2UJCWRwdAkJIyBEUFQgU21hcnRjYWNoZSBJSUks IElWIC0gU2VlIE5PVEVTIGZvciBvcHRpb25zDQojZGV2aWNlCQlpaXIJCSMg SW50ZWwgSW50ZWdyYXRlZCBSQUlEDQojZGV2aWNlCQlpcHMJCSMgSUJNIChB ZGFwdGVjKSBTZXJ2ZVJBSUQNCiNkZXZpY2UJCW1seQkJIyBNeWxleCBBY2Nl bGVSQUlEL2VYdHJlbWVSQUlEDQojZGV2aWNlCQl0d2EJCSMgM3dhcmUgOTAw MCBzZXJpZXMgUEFUQS9TQVRBIFJBSUQNCg0KIyBSQUlEIGNvbnRyb2xsZXJz DQpkZXZpY2UJCWFhYwkJIyBBZGFwdGVjIEZTQSBSQUlEDQpkZXZpY2UJCWFh Y3AJCSMgU0NTSSBwYXNzdGhyb3VnaCBmb3IgYWFjIChyZXF1aXJlcyBDQU0p DQojZGV2aWNlCQlpZGEJCSMgQ29tcGFxIFNtYXJ0IFJBSUQNCiNkZXZpY2UJ CW1seAkJIyBNeWxleCBEQUM5NjAgZmFtaWx5DQojWFhYIHBvaW50ZXIvaW50 IHdhcm5pbmdzDQojZGV2aWNlCQlwc3QJCSMgUHJvbWlzZSBTdXBlcnRyYWsg U1g2MDAwDQojZGV2aWNlCQl0d2UJCSMgM3dhcmUgQVRBIFJBSUQNCg0KIyBh dGtiZGMwIGNvbnRyb2xzIGJvdGggdGhlIGtleWJvYXJkIGFuZCB0aGUgUFMv MiBtb3VzZQ0KZGV2aWNlCQlhdGtiZGMJCSMgQVQga2V5Ym9hcmQgY29udHJv bGxlcg0KZGV2aWNlCQlhdGtiZAkJIyBBVCBrZXlib2FyZA0KZGV2aWNlCQlw c20JCSMgUFMvMiBtb3VzZQ0KDQpkZXZpY2UJCXZnYQkJIyBWR0EgdmlkZW8g Y2FyZCBkcml2ZXINCg0KZGV2aWNlCQlzcGxhc2gJCSMgU3BsYXNoIHNjcmVl biBhbmQgc2NyZWVuIHNhdmVyIHN1cHBvcnQNCg0KIyBzeXNjb25zIGlzIHRo ZSBkZWZhdWx0IGNvbnNvbGUgZHJpdmVyLCByZXNlbWJsaW5nIGFuIFNDTyBj b25zb2xlDQpkZXZpY2UJCXNjDQoNCiMgUENDQVJEIChQQ01DSUEpIHN1cHBv cnQNCiMgUENNQ0lBIGFuZCBjYXJkYnVzIGJyaWRnZSBzdXBwb3J0DQojZGV2 aWNlCQljYmIJCSMgY2FyZGJ1cyAoeWVudGEpIGJyaWRnZQ0KI2RldmljZQkJ cGNjYXJkCQkjIFBDIENhcmQgKDE2LWJpdCkgYnVzDQojZGV2aWNlCQljYXJk YnVzCQkjIENhcmRCdXMgKDMyLWJpdCkgYnVzDQoNCiMgU2VyaWFsIChDT00p IHBvcnRzDQpkZXZpY2UJCXNpbwkJIyA4MjUwLCAxNls0NV01MCBiYXNlZCBz ZXJpYWwgcG9ydHMNCg0KIyBQYXJhbGxlbCBwb3J0DQpkZXZpY2UJCXBwYw0K ZGV2aWNlCQlwcGJ1cwkJIyBQYXJhbGxlbCBwb3J0IGJ1cyAocmVxdWlyZWQp DQpkZXZpY2UJCWxwdAkJIyBQcmludGVyDQojZGV2aWNlCQlwbGlwCQkjIFRD UC9JUCBvdmVyIHBhcmFsbGVsDQpkZXZpY2UJCXBwaQkJIyBQYXJhbGxlbCBw b3J0IGludGVyZmFjZSBkZXZpY2UNCiNkZXZpY2UJCXZwbwkJIyBSZXF1aXJl cyBzY2J1cyBhbmQgZGENCg0KIyBJZiB5b3UndmUgZ290IGEgImR1bWIiIHNl cmlhbCBvciBwYXJhbGxlbCBQQ0kgY2FyZCB0aGF0IGlzDQojIHN1cHBvcnRl ZCBieSB0aGUgcHVjKDQpIGdsdWUgZHJpdmVyLCB1bmNvbW1lbnQgdGhlIGZv bGxvd2luZw0KIyBsaW5lIHRvIGVuYWJsZSBpdCAoY29ubmVjdHMgdG8gdGhl IHNpbyBhbmQvb3IgcHBjIGRyaXZlcnMpOg0KI2RldmljZQkJcHVjDQoNCiMg UENJIEV0aGVybmV0IE5JQ3MuDQojZGV2aWNlCQlkZQkJIyBERUMvSW50ZWwg REMyMXg0eCAoYGBUdWxpcCcnKQ0KZGV2aWNlCQllbQkJIyBJbnRlbCBQUk8v MTAwMCBhZGFwdGVyIEdpZ2FiaXQgRXRoZXJuZXQgQ2FyZA0KI2RldmljZQkJ aXhnYgkJIyBJbnRlbCBQUk8vMTBHYkUgRXRoZXJuZXQgQ2FyZA0KI2Rldmlj ZQkJdHhwCQkjIDNDb20gM2NSOTkwIChgYFR5cGhvb24nJykNCiNkZXZpY2UJ CXZ4CQkjIDNDb20gM2M1OTAsIDNjNTk1IChgYFZvcnRleCcnKQ0KDQojIFBD SSBFdGhlcm5ldCBOSUNzIHRoYXQgdXNlIHRoZSBjb21tb24gTUlJIGJ1cyBj b250cm9sbGVyIGNvZGUuDQojIE5PVEU6IEJlIHN1cmUgdG8ga2VlcCB0aGUg J2RldmljZSBtaWlidXMnIGxpbmUgaW4gb3JkZXIgdG8gdXNlIHRoZXNlIE5J Q3MhDQpkZXZpY2UJCW1paWJ1cwkJIyBNSUkgYnVzIHN1cHBvcnQNCiNkZXZp Y2UJCWJmZQkJIyBCcm9hZGNvbSBCQ000NDB4IDEwLzEwMCBFdGhlcm5ldA0K ZGV2aWNlCQliZ2UJCSMgQnJvYWRjb20gQkNNNTcweHggR2lnYWJpdCBFdGhl cm5ldA0KI2RldmljZQkJZGMJCSMgREVDL0ludGVsIDIxMTQzIGFuZCB2YXJp b3VzIHdvcmthbGlrZXMNCmRldmljZQkJZnhwCQkjIEludGVsIEV0aGVyRXhw cmVzcyBQUk8vMTAwQiAoODI1NTcsIDgyNTU4KQ0KI2RldmljZQkJbGdlCQkj IExldmVsIDEgTFhUMTAwMSBnaWdhYml0IEV0aGVybmV0DQojZGV2aWNlCQlu Z2UJCSMgTmF0U2VtaSBEUDgzODIwIGdpZ2FiaXQgRXRoZXJuZXQNCiNkZXZp Y2UJCXBjbgkJIyBBTUQgQW03OUM5N3ggUENJIDEwLzEwMCAocHJlY2VkZW5j ZSBvdmVyICdsbmMnKQ0KI2RldmljZQkJcmUJCSMgUmVhbFRlayA4MTM5Qysv ODE2OS84MTY5Uy84MTEwUw0KI2RldmljZQkJcmwJCSMgUmVhbFRlayA4MTI5 LzgxMzkNCiNkZXZpY2UJCXNmCQkjIEFkYXB0ZWMgQUlDLTY5MTUgKGBgU3Rh cmZpcmUnJykNCiNkZXZpY2UJCXNpcwkJIyBTaWxpY29uIEludGVncmF0ZWQg U3lzdGVtcyBTaVMgOTAwL1NpUyA3MDE2DQojZGV2aWNlCQlzawkJIyBTeXNL b25uZWN0IFNLLTk4NHggJiBTSy05ODJ4IGdpZ2FiaXQgRXRoZXJuZXQNCiNk ZXZpY2UJCXN0ZQkJIyBTdW5kYW5jZSBTVDIwMSAoRC1MaW5rIERGRS01NTBU WCkNCiNkZXZpY2UJCXRpCQkjIEFsdGVvbiBOZXR3b3JrcyBUaWdvbiBJL0lJ IGdpZ2FiaXQgRXRoZXJuZXQNCiNkZXZpY2UJCXRsCQkjIFRleGFzIEluc3Ry dW1lbnRzIFRodW5kZXJMQU4NCiNkZXZpY2UJCXR4CQkjIFNNQyBFdGhlclBv d2VyIElJICg4M2MxNzAgYGBFUElDJycpDQojZGV2aWNlCQl2Z2UJCSMgVklB IFZUNjEyeCBnaWdhYml0IEV0aGVybmV0DQojZGV2aWNlCQl2cgkJIyBWSUEg UmhpbmUsIFJoaW5lIElJDQojZGV2aWNlCQl3YgkJIyBXaW5ib25kIFc4OUM4 NDBGDQojZGV2aWNlCQl4bAkJIyAzQ29tIDNjOTB4IChgYEJvb21lcmFuZycn LCBgYEN5Y2xvbmUnJykNCg0KIyBJU0EgRXRoZXJuZXQgTklDcy4gIHBjY2Fy ZCBOSUNzIGluY2x1ZGVkLg0KI2RldmljZQkJY3MJCSMgQ3J5c3RhbCBTZW1p Y29uZHVjdG9yIENTODl4MCBOSUMNCiMgJ2RldmljZSBlZCcgcmVxdWlyZXMg J2RldmljZSBtaWlidXMnDQojIFhYWCBrdnRvcCBicm9rZW5uZXNzLCBwb2lu dGVyL2ludCB3YXJuaW5ncw0KI2RldmljZQkJZWQJCSMgTkVbMTJdMDAwLCBT TUMgVWx0cmEsIDNjNTAzLCBEUzgzOTAgY2FyZHMNCiNkZXZpY2UJCWV4CQkj IEludGVsIEV0aGVyRXhwcmVzcyBQcm8vMTAgYW5kIFByby8xMCsNCiNkZXZp Y2UJCWVwCQkjIEV0aGVybGluayBJSUkgYmFzZWQgY2FyZHMNCiNkZXZpY2UJ CWZlCQkjIEZ1aml0c3UgTUI4Njk2eCBiYXNlZCBjYXJkcw0KIyBYWFgga3Z0 b3AgYnJva2VubmVzcywgcG9pbnRlci9pbnQgd2FybmluZ3MNCiNkZXZpY2UJ CWxuYwkJIyBORTIxMDAsIE5FMzItVkwgTGFuY2UgRXRoZXJuZXQgY2FyZHMN CiNkZXZpY2UJCXNuCQkjIFNNQydzIDkwMDAgc2VyaWVzIG9mIEV0aGVybmV0 IGNoaXBzDQojZGV2aWNlCQl4ZQkJIyBYaXJjb20gcGNjYXJkIEV0aGVybmV0 DQoNCiMgV2lyZWxlc3MgTklDIGNhcmRzDQojZGV2aWNlCQl3bGFuCQkjIDgw Mi4xMSBzdXBwb3J0DQojZGV2aWNlCQlhbgkJIyBBaXJvbmV0IDQ1MDAvNDgw MCA4MDIuMTEgd2lyZWxlc3MgTklDcy4NCiNkZXZpY2UJCWF3aQkJIyBCYXlT dGFjayA2NjAgYW5kIG90aGVycw0KI2RldmljZQkJd2kJCSMgV2F2ZUxBTi9J bnRlcnNpbC9TeW1ib2wgODAyLjExIHdpcmVsZXNzIE5JQ3MuDQoNCiMgUHNl dWRvIGRldmljZXMuDQpkZXZpY2UJCWxvb3AJCSMgTmV0d29yayBsb29wYmFj aw0KZGV2aWNlCQltZW0JCSMgTWVtb3J5IGFuZCBrZXJuZWwgbWVtb3J5IGRl dmljZXMNCmRldmljZQkJaW8JCSMgSS9PIGRldmljZQ0KZGV2aWNlCQlyYW5k b20JCSMgRW50cm9weSBkZXZpY2UNCmRldmljZQkJZXRoZXIJCSMgRXRoZXJu ZXQgc3VwcG9ydA0KZGV2aWNlCQlzbAkJIyBLZXJuZWwgU0xJUA0KZGV2aWNl CQlwcHAJCSMgS2VybmVsIFBQUA0KZGV2aWNlCQl0dW4JCSMgUGFja2V0IHR1 bm5lbC4NCmRldmljZQkJcHR5CQkjIFBzZXVkby10dHlzICh0ZWxuZXQgZXRj KQ0KZGV2aWNlCQltZAkJIyBNZW1vcnkgImRpc2tzIg0KZGV2aWNlCQlnaWYJ CSMgSVB2NiBhbmQgSVB2NCB0dW5uZWxpbmcNCmRldmljZQkJZmFpdGgJCSMg SVB2Ni10by1JUHY0IHJlbGF5aW5nICh0cmFuc2xhdGlvbikNCg0KIyBUaGUg YGJwZicgZGV2aWNlIGVuYWJsZXMgdGhlIEJlcmtlbGV5IFBhY2tldCBGaWx0 ZXIuDQojIEJlIGF3YXJlIG9mIHRoZSBhZG1pbmlzdHJhdGl2ZSBjb25zZXF1 ZW5jZXMgb2YgZW5hYmxpbmcgdGhpcyENCiMgTm90ZSB0aGF0ICdicGYnIGlz IHJlcXVpcmVkIGZvciBESENQLg0KZGV2aWNlCQlicGYJCSMgQmVya2VsZXkg cGFja2V0IGZpbHRlcg0KDQojIFVTQiBzdXBwb3J0DQpkZXZpY2UJCXVoY2kJ CSMgVUhDSSBQQ0ktPlVTQiBpbnRlcmZhY2UNCmRldmljZQkJb2hjaQkJIyBP SENJIFBDSS0+VVNCIGludGVyZmFjZQ0KI2RldmljZQkJZWhjaQkJIyBFSENJ IFBDSS0+VVNCIGludGVyZmFjZSAoVVNCIDIuMCkNCmRldmljZQkJdXNiCQkj IFVTQiBCdXMgKHJlcXVpcmVkKQ0KI2RldmljZQkJdWRicAkJIyBVU0IgRG91 YmxlIEJ1bGsgUGlwZSBkZXZpY2VzDQpkZXZpY2UJCXVnZW4JCSMgR2VuZXJp Yw0KZGV2aWNlCQl1aGlkCQkjICJIdW1hbiBJbnRlcmZhY2UgRGV2aWNlcyIN CmRldmljZQkJdWtiZAkJIyBLZXlib2FyZA0KZGV2aWNlCQl1bHB0CQkjIFBy aW50ZXINCmRldmljZQkJdW1hc3MJCSMgRGlza3MvTWFzcyBzdG9yYWdlIC0g UmVxdWlyZXMgc2NidXMgYW5kIGRhDQpkZXZpY2UJCXVtcwkJIyBNb3VzZQ0K I2RldmljZQkJdXJpbwkJIyBEaWFtb25kIFJpbyA1MDAgTVAzIHBsYXllcg0K I2RldmljZQkJdXNjYW5uZXIJIyBTY2FubmVycw0KIyBVU0IgRXRoZXJuZXQs IHJlcXVpcmVzIG1paQ0KI2RldmljZQkJYXVlCQkjIEFETXRlayBVU0IgRXRo ZXJuZXQNCiNkZXZpY2UJCWF4ZQkJIyBBU0lYIEVsZWN0cm9uaWNzIFVTQiBF dGhlcm5ldA0KI2RldmljZQkJY2RjZQkJIyBHZW5lcmljIFVTQiBvdmVyIEV0 aGVybmV0DQojZGV2aWNlCQljdWUJCSMgQ0FUQyBVU0IgRXRoZXJuZXQNCiNk ZXZpY2UJCWt1ZQkJIyBLYXdhc2FraSBMU0kgVVNCIEV0aGVybmV0DQojZGV2 aWNlCQlydWUJCSMgUmVhbFRlayBSVEw4MTUwIFVTQiBFdGhlcm5ldA0KDQoj IEZpcmVXaXJlIHN1cHBvcnQNCiNkZXZpY2UJCWZpcmV3aXJlCSMgRmlyZVdp cmUgYnVzIGNvZGUNCiNkZXZpY2UJCXNicAkJIyBTQ1NJIG92ZXIgRmlyZVdp cmUgKFJlcXVpcmVzIHNjYnVzIGFuZCBkYSkNCiNkZXZpY2UJCWZ3ZQkJIyBF dGhlcm5ldCBvdmVyIEZpcmVXaXJlIChub24tc3RhbmRhcmQhKQ0KDQpvcHRp b25zICAgICAgICAgSVBGSVJFV0FMTA0Kb3B0aW9ucyAgICAgICAgIElQRklS RVdBTExfVkVSQk9TRQ0KDQo= --0-779721010-1127845675=:50334 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="type3-crash.txt" Content-Transfer-Encoding: BASE64 Content-Description: Content-Disposition: attachment; filename="type3-crash.txt" a2VybmVsIHRyYXAgMTIgd2l0aCBpbnRlcnJ1cHRzIGRpc2FibGVkDQoNCmZh dGFsIHRyYXAgMTI6IHBhZ2UgZmF1bHQgd2hpbGUgaW4ga2VybmVsIG1vZGUN CmNwdWlkPTM7IGFwaWNpZD0wMw0KZmF1bHQgdmlydHVhbCBhZGRyZXNzICAg PSAwMw0KZmF1bHQgY29kZSAgICAgICAgICAgICAgPSBzdXBlcnZpc29yIHJl YWQsIHBhZ2Ugbm90IHByZXNlbnQNCmluc3RydWN0aW9uIHBvaW50ZXIgICAg ID0gMHg4OmZmZmZmZmZmODAzYjg4Y2ENCnN0YWNrIHBvaW50ZXIgICAgICAg ICAgID0gMHgxMDpmZmZmZmZmZmI2NjM5NDkwDQpmcmFtZSBwb2ludGVyICAg ICAgICAgICA9IDB4MTA6ZmZmZmZmZmZiNjYzOTRmMA0KY29kZSBzZWdtZW50 ICAgICAgICAgICAgPSBiYXNlIDB4MDsgbGltaXQgMHhmZmZmZiwgdHlwZT0w eDFiDQogICAgICAgICAgICAgICAgICAgICAgICA9IERQTD0wLCBwcmVzIDEs IGxvbmcgMSwgZGVmMzI9MCwgZ3JhbiAxDQpwcm9jZXNzb3IgZWZsYWdzICAg ICAgICA9IHJlc3VtZSwgSU9QTD0wDQpjdXJyZW50IHByb2Nlc3MgICAgICAg ICA9IDQ4NjI4ICh0b3ApDQoNCmRpZCBub3QgZW50ZXIgRERCIG9yIGdlbmVy YXRlIGNvcmUgZmlsZQ0K --0-779721010-1127845675=:50334-- From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 28 17:13:35 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 B385716A41F for ; Wed, 28 Sep 2005 17:13:35 +0000 (GMT) (envelope-from bgd@secure-host.tv) Received: from mail.secure-host.tv (mail.secure-host.tv [82.197.129.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B7FE43D48 for ; Wed, 28 Sep 2005 17:13:35 +0000 (GMT) (envelope-from bgd@secure-host.tv) Received: by mail.secure-host.tv (Postfix, from userid 1001) id B974B3C2E8; Wed, 28 Sep 2005 19:13:34 +0200 (CEST) Date: Wed, 28 Sep 2005 19:13:34 +0200 From: Bogdan Taru To: freebsd-hackers@freebsd.org Message-ID: <20050928171334.GA70500@icomag.de> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: [bgd@level5.de: invalid geometry for >1TB] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2005 17:13:35 -0000 Hi hackers, tryin' to install 4.11 or 5.x on a Dell box with a Perc 3/Di Raid controller (with 5x 300GB scsis). I get 'invalid geometry' when running sysinstall/fdisk on the 'disk', the geometry presented being: 145815 cyl / 255 heads / 63 sectors I tried to press 'A' for allocate the whole disk, and after several more warnings it did that, but now the 'free' space in the list has a big minus value as 'Offset'. Is that a problem? What should I do in order to get fbsd on this box? Change geometry? Any other hacks/workarounds? Thanks, bogdan From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 28 17:35:01 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 2240F16A41F for ; Wed, 28 Sep 2005 17:35:01 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4198643D6A for ; Wed, 28 Sep 2005 17:34:57 +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 j8SHYrJs008748; Wed, 28 Sep 2005 12:34:56 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <433AD437.8050803@centtech.com> Date: Wed, 28 Sep 2005 12:34:47 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.11) Gecko/20050914 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bogdan Taru References: <20050928171334.GA70500@icomag.de> In-Reply-To: <20050928171334.GA70500@icomag.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1102/Sun Sep 25 09:04:56 2005 on mh2.centtech.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: [bgd@level5.de: invalid geometry for >1TB] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2005 17:35:01 -0000 Bogdan Taru wrote: > Hi hackers, > > tryin' to install 4.11 or 5.x on a Dell box with a Perc 3/Di Raid > controller (with 5x 300GB scsis). I get 'invalid geometry' when running > sysinstall/fdisk on the 'disk', the geometry presented being: > > 145815 cyl / 255 heads / 63 sectors > > I tried to press 'A' for allocate the whole disk, and after several more > warnings it did that, but now the 'free' space in the list has a big minus > value as 'Offset'. Is that a problem? > > What should I do in order to get fbsd on this box? Change geometry? Any > other hacks/workarounds? Have you tried using gpt to partition it? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 28 17:45:08 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 EF95A16A41F for ; Wed, 28 Sep 2005 17:45:08 +0000 (GMT) (envelope-from bgd@secure-host.tv) Received: from mail.secure-host.tv (mail.secure-host.tv [82.197.129.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 970BE43D49 for ; Wed, 28 Sep 2005 17:45:06 +0000 (GMT) (envelope-from bgd@secure-host.tv) Received: by mail.secure-host.tv (Postfix, from userid 1001) id F286F3C103; Wed, 28 Sep 2005 19:45:04 +0200 (CEST) Date: Wed, 28 Sep 2005 19:45:04 +0200 From: Bogdan Taru To: Eric Anderson Message-ID: <20050928174504.GA70900@icomag.de> Mail-Followup-To: Eric Anderson , freebsd-hackers@freebsd.org References: <20050928171334.GA70500@icomag.de> <433AD437.8050803@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <433AD437.8050803@centtech.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: [bgd@level5.de: invalid geometry for >1TB] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2005 17:45:09 -0000 On Wed, Sep 28, 2005 at 12:34:47PM -0500, Eric Anderson wrote: > Bogdan Taru wrote: > > Hi hackers, > > > > tryin' to install 4.11 or 5.x on a Dell box with a Perc 3/Di Raid > >controller (with 5x 300GB scsis). I get 'invalid geometry' when running > >sysinstall/fdisk on the 'disk', the geometry presented being: > > > > 145815 cyl / 255 heads / 63 sectors > > > > I tried to press 'A' for allocate the whole disk, and after several more > >warnings it did that, but now the 'free' space in the list has a big minus > >value as 'Offset'. Is that a problem? > > > > What should I do in order to get fbsd on this box? Change geometry? Any > >other hacks/workarounds? > > Have you tried using gpt to partition it? Hm. What's gpt? bogdan From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 28 17:48:31 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 C069716A41F for ; Wed, 28 Sep 2005 17:48:31 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58CFB43D49 for ; Wed, 28 Sep 2005 17:48:31 +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 j8SHmUxW009013; Wed, 28 Sep 2005 12:48:30 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <433AD767.50107@centtech.com> Date: Wed, 28 Sep 2005 12:48:23 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.11) Gecko/20050914 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bogdan Taru References: <20050928171334.GA70500@icomag.de> <433AD437.8050803@centtech.com> <20050928174504.GA70900@icomag.de> In-Reply-To: <20050928174504.GA70900@icomag.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1102/Sun Sep 25 09:04:56 2005 on mh2.centtech.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: [bgd@level5.de: invalid geometry for >1TB] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2005 17:48:31 -0000 Bogdan Taru wrote: > On Wed, Sep 28, 2005 at 12:34:47PM -0500, Eric Anderson wrote: > >>Bogdan Taru wrote: >> >>> Hi hackers, >>> >>>tryin' to install 4.11 or 5.x on a Dell box with a Perc 3/Di Raid >>>controller (with 5x 300GB scsis). I get 'invalid geometry' when running >>>sysinstall/fdisk on the 'disk', the geometry presented being: >>> >>>145815 cyl / 255 heads / 63 sectors >>> >>>I tried to press 'A' for allocate the whole disk, and after several more >>>warnings it did that, but now the 'free' space in the list has a big minus >>>value as 'Offset'. Is that a problem? >>> >>>What should I do in order to get fbsd on this box? Change geometry? Any >>>other hacks/workarounds? >> >>Have you tried using gpt to partition it? > > > Hm. What's gpt? gpt stand for 'great and powerful tool'. Just kidding. From gpt(8): gpt -- GUID partition table maintenance utility check out the man page for details.. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 28 17:56:14 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 CB58816A420 for ; Wed, 28 Sep 2005 17:56:14 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF4D643D53 for ; Wed, 28 Sep 2005 17:56:11 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j8SHu9rf028148; Wed, 28 Sep 2005 12:56:10 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <433AD933.3060609@centtech.com> Date: Wed, 28 Sep 2005 12:56:03 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.11) Gecko/20050914 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roman Neuhauser References: <20050927145308.GA3854@isis.sigpipe.cz> In-Reply-To: <20050927145308.GA3854@isis.sigpipe.cz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1103/Wed Sep 28 11:48:20 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org, Steve Rieger Subject: Re: FATAL: erealloc(): Unable to allocate 577925121 bytes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2005 17:56:14 -0000 Roman Neuhauser wrote: > # steve.rieger@tbwachiat.com / 2005-09-27 05:39:10 -0400: > >>when trying to d/l the following file >> >>1 www www 551M Sep 16 13:23 20050818002.zip >> >>via apache1.3.33/php 4.3.11, i get that in the logs >>i thought it was because i dont have enough swap so i did > > > [...] > > See ulimit(1), search for "ulimit" in sh(1), and please, ask this > kind of questions on, well, questions@. > Or, alternatively, in /boot/loader.conf, set: kern.maxdsiz="something bigger" You could do your memory size plus a portion of your swap to total up to the size you need. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 28 19:00:22 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 9973916A41F for ; Wed, 28 Sep 2005 19:00:22 +0000 (GMT) (envelope-from ddg@yan.com.br) Received: from zeus.yan.com.br (zeus.yan.com.br [200.202.253.10]) by mx1.FreeBSD.org (Postfix) with SMTP id 8C2CC43D48 for ; Wed, 28 Sep 2005 19:00:19 +0000 (GMT) (envelope-from ddg@yan.com.br) Received: (qmail 6515 invoked by uid 1023); 28 Sep 2005 19:00:05 -0000 Received: from ddg@yan.com.br by zeus by uid 1023 with qmail-scanner-1.22 (uvscan: v4.1.60/v4366. fsecure: 4.11/3190/2003-09-23/2002-12-17. 2003-09-22/. Clear:RC:1(200.202.253.197):. Processed in 0.579164 secs); 28 Sep 2005 19:00:05 -0000 Received: from unknown (HELO ?192.168.1.1?) (daniel@dgnetwork.com.br@200.202.253.197) by zeus.yan.com.br with SMTP; 28 Sep 2005 19:00:04 -0000 Message-ID: <433AE838.4000606@yan.com.br> Date: Wed, 28 Sep 2005 16:00:08 -0300 From: =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: pt-br, pt MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: FreeBSD 5.4 AMD64 & MPD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ddg@yan.com.br List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2005 19:00:22 -0000 I installed MPD and it doesn't start, NETGRAPH is enable on kernel. # mpd Multi-link PPP for FreeBSD, by Archie L. Cobbs. Based on iij-ppp, by Toshiharu OHNO. mpd: pid 34373563800, version (null) mpd: caught fatal signal @ mpd: fatal error, exiting mpd: process 6126 terminated # Last lines in ktrace: 7108 mpd RET read 721/0x2d1 7108 mpd CALL close(0x3) 7108 mpd RET close 0 7108 mpd CALL socket(0x1,0x2,0) 7108 mpd RET socket 3 7108 mpd CALL fcntl(0x3,0x2,0x1) 7108 mpd RET fcntl 0 7108 mpd CALL connect(0x3,0x7fffffffda70,0x6a) 7108 mpd NAMI "/var/run/logpriv" 7108 mpd RET connect 0 7108 mpd CALL sendto(0x3,0x7fffffffdfd0,0x68,0,0,0) 7108 mpd GIO fd 3 wrote 104 bytes "<30>Sep 27 15:27:54 mpd: mpd: pid 7108, version 3.18 (root@host 15:16 27-Sep-2005)" 7108 mpd RET sendto 104/0x68 7108 mpd PSIG SIGSEGV SIG_DFL 7108 mpd NAMI "mpd.core" # Ifconfig: ng0: flags=8890 mtu 1500 Any idea ? -- Daniel Dias Gonçalves DGNET Network Solutions daniel@dgnetwork.com.br (37) 99824809 From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 28 23:28:54 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 B0B8816A41F for ; Wed, 28 Sep 2005 23:28:54 +0000 (GMT) (envelope-from MTaylor@bytecraft.com.au) Received: from wolf.bytecraft.au.com (wolf.bytecraft.au.com [203.39.118.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id B569A43D48 for ; Wed, 28 Sep 2005 23:28:52 +0000 (GMT) (envelope-from MTaylor@bytecraft.com.au) Received: from localhost (localhost [127.0.0.1]) by wolf.bytecraft.au.com (8.12.11/8.12.11) with ESMTP id j8SNSoUf004533 for ; Thu, 29 Sep 2005 09:28:50 +1000 (EST) (envelope-from MTaylor@bytecraft.com.au) Received: from wolf.bytecraft.au.com ([127.0.0.1]) by localhost (wolf.bytecraft.au.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03930-08 for ; Thu, 29 Sep 2005 09:28:49 +1000 (EST) Received: from svmarshal.bytecraft.au.com ([10.0.0.4]) by wolf.bytecraft.au.com (8.12.11/8.12.11) with ESMTP id j8SNSjYr004526 for ; Thu, 29 Sep 2005 09:28:45 +1000 (EST) (envelope-from MTaylor@bytecraft.com.au) Received: from svmailmel.bytecraft.internal (Not Verified[10.0.0.24]) by svmarshal.bytecraft.au.com with MailMarshal (v5, 0, 3, 78) id ; Thu, 29 Sep 2005 09:28:29 +1000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 29 Sep 2005 09:28:28 +1000 Message-ID: <04E232FDCD9FBE43857F7066CAD3C0F1053AD6@svmailmel.bytecraft.internal> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: System hang / extreme slowdown under MySQL Thread-Index: AcXEhFSS6WcTdzxPRtuyFmvGHT8HPA== From: "Murray Taylor" To: Subject: System hang / extreme slowdown under MySQL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2005 23:28:54 -0000 We are using MySQL on a FreeBSD box for one of our systems and recently after doing a number of application code changes to=20 support a new client the system experiecned what seemed to be=20 a total hang. It didnt crash per se, no log messages=20 were caught.... it just went mostly unresponsive. The data base is accessed via a set of TCL, C and web apps. The symptoms are no response to any of the programs, yet=20 things like switching virtual consoles etc work ok. But it is not possible to login... one can type 'root', see the characters echoed, press enter and get nothing.. If there is an open ssh session or open console session, one=20 could issue a single command, like 'ls', get the response, then say issue a 'ps' and only get the header line..... On one of the occasions as we fly in to reboot the box, one of the=20 users said that it _was working_ just V E R Y S L O W L Y.... like 3 web pages in 30 minutes. We did find some unclosed database queries in the TCL code that=20 have been fixed, but based on a sysctl that 'seems to be significant' we may not yet have found all our problems. The sysctl that we have picked is the one printed below and in particular the crosspoint PV ENTRY: / USED value. this is slowly but consistently increasing on this box, yet remains stable on all other FreeBSD boxes. THE QUESTIONs are:=20 Is this the correct sysctl to be monitoring? Is there a good description of the sysctl identified re relevance of the numbers to the actual system condition? Does anyone have any other ideas of things to look for that may=20 causing the hangs? The system is=20 FreeBSD svmysql1.dand07.au.bytecraft.au.com 4.10-RELEASE-p7 FreeBSD 4.10-RELEASE-p7 #3: Thu Apr 14 15:34:37 EST 2005 =20 Both the old system (Mysql 3.23) and the current one (mysql Ver 12.22 Distrib 4.0.22, for portbld-freebsd4.10 (i386)) are doing this. Tcl version is 8.4 vm.zone: ITEM SIZE LIMIT USED FREE REQUESTS PIPE: 160, 0, 13, 89, 2208898 SWAPMETA: 160, 233016, 0, 0, 0 unpcb: 160, 0, 13, 62, 18543 ripcb: 192, 12328, 0, 42, 5 syncache: 160, 15359, 0, 51, 1342401 tcpcb: 576, 12328, 539, 3059, 1341005 udpcb: 192, 12328, 3, 39, 9904 socket: 224, 12328, 556, 3064, 1369458 DIRHASH: 1024, 0, 652, 4, 767 KNOTE: 64, 0, 1, 127, 7589 VNODE: 192, 0, 33713, 101, 33713 NAMEI: 1024, 0, 0, 16, 11767321 VMSPACE: 192, 0, 39, 89, 585870 PROC: 416, 0, 72, 75, 585929 DP fakepg: 64, 0, 0, 0, 0 PV ENTRY: 28, 2281256, 78652, 445576, 435851412 MAP ENTRY: 48, 0, 1084, 829, 40997106 KMAP ENTRY: 48, 57423, 265, 119, 2234109 MAP: 108, 0, 7, 3, 7 VM OBJECT: 92, 0, 26533, 211, 15431058 --=20 A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? Murray Taylor Bytecraft Systems P: +61 3 8710 2555 F: +61 3 8710 2599 D: +61 3 9238 4275 E: mtaylor@bytecraft.com.au --------------------------------------------------------------- The information transmitted in this e-mail is for the exclusive use of the intended addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material.=20 E-mails may not be secure, may contain computer viruses and may be corrupted in transmission. Please carefully check this e-mail (and any attachment) accordingly. No warranties are given and no liability is accepted for any loss or damage caused by such matters. --------------------------------------------------------------- ***This Email has been scanned for Viruses by MailMarshal.*** From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 29 00:44:36 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 EE9FB16A41F for ; Thu, 29 Sep 2005 00:44:36 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EC9743D49 for ; Thu, 29 Sep 2005 00:44:35 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.31]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j8T0iObN098065 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 29 Sep 2005 10:14:30 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org, ddg@yan.com.br Date: Thu, 29 Sep 2005 10:14:19 +0930 User-Agent: KMail/1.8.2 References: <433AE838.4000606@yan.com.br> In-Reply-To: <433AE838.4000606@yan.com.br> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1392354.1A04Hk1dr0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200509291014.20754.doconnor@gsoft.com.au> X-Spam-Score: -2.82 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: Subject: Re: FreeBSD 5.4 AMD64 & MPD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 00:44:37 -0000 --nextPart1392354.1A04Hk1dr0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 29 September 2005 04:30, Daniel Dias Gon=E7alves wrote: > I installed MPD and it doesn't start, NETGRAPH is enable on kernel. > > # mpd > Multi-link PPP for FreeBSD, by Archie L. Cobbs. > Based on iij-ppp, by Toshiharu OHNO. > mpd: pid 34373563800, version (null) > mpd: caught fatal signal @ ^- funky! :) > mpd: fatal error, exiting > mpd: process 6126 terminated > # > > Last lines in ktrace: Can you run it in GDB and get a backtrace? You may need to rebuild it with debugging symbols enabled to get anything=20 useful out of it. =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 --nextPart1392354.1A04Hk1dr0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDOzjk5ZPcIHs/zowRAgByAJ9vf7IQ9R/5gm4tjA5RuDX2MF01TACgmOq+ 4nGmkfdAZTEv2uQJXlUaQBE= =vwKY -----END PGP SIGNATURE----- --nextPart1392354.1A04Hk1dr0-- From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 29 01:11:33 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 1DAD216A41F for ; Thu, 29 Sep 2005 01:11:33 +0000 (GMT) (envelope-from aanton@spintech.ro) Received: from smtpx.spintech.ro (smtpx.spintech.ro [81.180.92.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id A502843D4C for ; Thu, 29 Sep 2005 01:11:32 +0000 (GMT) (envelope-from aanton@spintech.ro) Received: from laura-axiomeda (unknown [11.0.0.25]) by smtpx.spintech.ro (Postfix) with ESMTP id A17C13A4A8 for ; Thu, 29 Sep 2005 01:11:35 +0000 (UTC) X-Laura: version 0.0.1b10-frustratus proxied X-Laura-Remote-IP: 10.0.0.2 Received: from [10.0.0.2] (beastie [10.0.0.2]) by smtpx.spintech.ro (Postfix) with ESMTP id 26BD93A4A7 for ; Thu, 29 Sep 2005 01:11:35 +0000 (UTC) Message-ID: <433B3F41.8060004@spintech.ro> Date: Thu, 29 Sep 2005 04:11:29 +0300 From: Alin-Adrian Anton Organization: Spintech Security Systems User-Agent: Mozilla Thunderbird 1.0 (X11/20041229) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: journaling fs and large mailbox format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: aanton@spintech.ro List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 01:11:33 -0000 Dear Hackers, First of all thank you for your time and attention. I am in the position to implement a large-scale mail server and I will never go for anything else but FreeBSD (fixation?). It should be able to handle graceously 4000 e-mail accounts where a minimum of 50 Mb/mailbox would be a requirement. In the begining, it is desirable that users could use as much free space as available, so this implies some gigabytes/mailbox. I don't know if the mbox format can handle this, and I know Maildir cannot handle this on UFS2 standard install, no matter of soft-updates. (because it exhaustes the free nodes) So I currently have no solution for this stuff. I was wondering what is the status of Journaling File Systems on FreeBSD? Any which is usable and mature, with write access? XFS would fit amazingly well with Maildir, but.. I doubt it's anything else but readonly. So any suggestion would really help a lot. Thank's in advance. Yours Sincerely, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 29 03:36:19 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 913CC16A41F for ; Thu, 29 Sep 2005 03:36:19 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1272B43D4C for ; Thu, 29 Sep 2005 03:36:18 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.23] (andersonbox3.centtech.com [192.168.42.23]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j8T3ZHZE017838; Wed, 28 Sep 2005 22:35:17 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <433B60EE.4090207@centtech.com> Date: Wed, 28 Sep 2005 22:35:10 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.11) Gecko/20050914 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aanton@smtpx.spintech.ro References: <433B3F41.8060004@spintech.ro> In-Reply-To: <433B3F41.8060004@spintech.ro> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1104/Wed Sep 28 17:20:40 2005 on mh2.centtech.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: journaling fs and large mailbox format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 03:36:19 -0000 Alin-Adrian Anton wrote: > Dear Hackers, > > First of all thank you for your time and attention. > > I am in the position to implement a large-scale mail server and I > will never go for anything else but FreeBSD (fixation?). > > It should be able to handle graceously 4000 e-mail accounts where a > minimum of 50 Mb/mailbox would be a requirement. In the begining, it is > desirable that users could use as much free space as available, so this > implies some gigabytes/mailbox. > > I don't know if the mbox format can handle this, and I know Maildir > cannot handle this on UFS2 standard install, no matter of soft-updates. > (because it exhaustes the free nodes) So I currently have no solution > for this stuff. I'm not sure how you came to this conclusion, or what the history is, but I see no reason why UFS2 would have any adverse affects on maildir format mail system. You can set the number of inodes to be created to a higher number when using newfs on the filesystem, so if you believe that is an issue, you should be able to tweak it to your needs. mbox starts to break down on large mailboxes with many messages. 50mb may or may not be in that range, but maildir is much better for performance. > I was wondering what is the status of Journaling File Systems on > FreeBSD? Any which is usable and mature, with write access? XFS would > fit amazingly well with Maildir, but.. I doubt it's anything else but > readonly. Not sure how journaling would help you much here, except for meta-data consistancy, which soft-updates gives you, and fsck times. > So any suggestion would really help a lot. Thank's in advance. A quick note - run the mail area on a RAID array, preferrably a RAID0+1 (or 10 depending on who you ask). Disks are nearly always a bottleneck, so if you can keep your random read/writes fast, the whole system will feel snappy. You might try posting this to freebsd-isp@, since many people there have much larger installations running than this, and can probably provide some good hints. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 29 03:47:54 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 4E4EB16A41F for ; Thu, 29 Sep 2005 03:47:54 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id E41AC43D48 for ; Thu, 29 Sep 2005 03:47:53 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j8T3lAfU023387; Wed, 28 Sep 2005 21:47:11 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 28 Sep 2005 21:47:49 -0600 (MDT) Message-Id: <20050928.214749.111484152.imp@bsdimp.com> To: nsrashmi@gmail.com From: "M. Warner Losh" In-Reply-To: <9f9993160509280045586fb14d@mail.gmail.com> References: <9f99931605092800402dd1db9a@mail.gmail.com> <9f9993160509280045586fb14d@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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 28 Sep 2005 21:47:11 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, bugi@lists.redbrick.dcu.ie Subject: Re: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 03:47:54 -0000 In message: <9f9993160509280045586fb14d@mail.gmail.com> rashmi ns writes: : Hello All , : I was trying to add a new ioctl cnd like : #define HDLCMODE _IOR('6',0xF,int) : when i try to uprintf the data which was sent from the user-space in the : device-driver-ioctl-routine i'll get a different value than which is passed. : Can anybody please tell me why this is happening . I pass the address of : integer from the user space as third arg to the ioctl call . : thanks and regards, Remember that there's a level of indirection here. For the userland call, you'll have something like: int i = 10; ioctl (fd, HDLCMODE, &i); in the kernel, this translates into a call to the driver's ioctl routine: int fooioctl(struct cdev *tp, u_long cmd, void *data, int flag, struct thread *t) { switch (cmd) { case HDLCMODE: printf("this should be 10: %d\n", *(int *)data); break; } Warner From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 29 04:44:00 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 E29A916A41F for ; Thu, 29 Sep 2005 04:43:59 +0000 (GMT) (envelope-from apachexm@hotmail.com) Received: from hotmail.com (bay106-f9.bay106.hotmail.com [65.54.161.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id A69ED43D49 for ; Thu, 29 Sep 2005 04:43:59 +0000 (GMT) (envelope-from apachexm@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 28 Sep 2005 21:43:59 -0700 Message-ID: Received: from 65.54.161.203 by by106fd.bay106.hotmail.msn.com with HTTP; Thu, 29 Sep 2005 04:43:59 GMT X-Originating-IP: [65.54.161.203] X-Originating-Email: [apachexm@hotmail.com] X-Sender: apachexm@hotmail.com From: "Apache Xie" To: freebsd-hackers@freebsd.org Date: Thu, 29 Sep 2005 04:43:59 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 29 Sep 2005 04:43:59.0451 (UTC) FILETIME=[6862A2B0:01C5C4B0] Subject: How to use "offset" parameter in mmap() system call X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 04:44:00 -0000 Hi, I wrote a device driver, it supports mmap(), but I met some problems recently, it seems relate to the "offset" parameter in mmap() system call, what I want to get help are: How to use the offset parameter of mmap() correctly? Can it be used freely? My driver is a char device driver, when it is loaded, it allocates 64 MB contiguous physical memory using contigmalloc(), and I wrote my own memory management function to allocate memory blocks from this 64 MB memory. My driver can be used by several processes concurrently, each process allocates one block from the 64 MB memory, then mmap this block to user space. Each process is assigned a sequence number when it opens the device. For example, assume process X gets the sequence number 0, and allocates memory block 0-2MB, and process Y gets the sequence number 1, and allocates memory block 4-6MB, we use offset 0, size 2MB in process X on calling mmap() system call, and use offset 64MB, size 2MB in process Y on calling mmap() system call. In driver's _mmap() function, we check offset, when it is < 64MB, we know process X do the mmap, then we return physical address of memory block 0-2MB, when the offset is between 64MB and 128MB, we know process Y do the mmap, then we return physical address of memory block 4-6MB. In other word, the "offset" parameter in mmap() system call is just a indicator, we use it to compute the real offset in the 64MB memory to map the memory block the process allocated. My driver can support maximum 16 processes, so the "offset" parameter in mmap() system call can be set to near 16*64MB = 1GB. I wrote a test program, it does very simple thing: 1. open char device; 2. mmap driver's memory; 3. write to mmapped memory; 4. unmap driver's memory. It works fine when I run it manually many times, but after I put it in a while loop in a shell script, and run several scripts concurrently, I found sometimes the mapped user space address don't point to the correct memory block the process allocated in driver. We checked the physical address returned by my driver's _mmap() function, it is correct, but when I sent the mapped user space address back to kernel and use pmap_extract() to get the physical address, it is wrong, it may be another block in the 64MB memory. For example, process X allocate 0-2MB, the mapped user space address is pX, process Y allocate 4-6MB, the mapped user space address is pY, but when pX and pY is sent back to kernel, pmap_extract(pX) is 4-6MB, pmap_extract(pY) is 0-2MB, this is very strange. Below is the simple shell script which shows the error: #!/bin/sh while true do ./my_test_program done I checked some driver codes in the kernel which support mmap(), it seems in many driver, "offset" is used as indicator too, they use "offset" to find the correct memory block and return it's physical address too. But in my driver, the "offset" parameter the user process used in the mmap() system call can be very large, even the mapped memory block is always in the 64 MB contiguous physical memory. But we can compute the real offset correctly. I am not familiar with FreeBSD kernel, but I find "offset" is used by kernel too, so, I am not sure if offset can be set to the very large value as my driver do. Any help is welcomed, thanks! _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 28 17:08:36 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 F314816A41F for ; Wed, 28 Sep 2005 17:08:35 +0000 (GMT) (envelope-from bgd@secure-host.tv) Received: from mail.secure-host.tv (mail.secure-host.tv [82.197.129.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB3F143D55 for ; Wed, 28 Sep 2005 17:08:35 +0000 (GMT) (envelope-from bgd@secure-host.tv) Received: by mail.secure-host.tv (Postfix, from userid 1001) id E82713C286; Wed, 28 Sep 2005 19:08:33 +0200 (CEST) Date: Wed, 28 Sep 2005 19:08:33 +0200 From: Bogdan Taru To: freebsd-hackers@freebsd.org Message-ID: <20050928170833.GE22200@level5.de> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Thu, 29 Sep 2005 11:54:53 +0000 Subject: invalid geometry for >1TB X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2005 17:08:36 -0000 Hi hackers, tryin' to install 4.11 or 5.x on a Dell box with a Perc 3/Di Raid controller (with 5x 300GB scsis). I get 'invalid geometry' when running sysinstall/fdisk on the 'disk', the geometry presented being: 145815 cyl / 255 heads / 63 sectors I tried to press 'A' for allocate the whole disk, and after several more warnings it did that, but now the 'free' space in the list has a big minus value as 'Offset'. Is that a problem? What should I do in order to get fbsd on this box? Change geometry? Any other hacks/workarounds? Thanks, bogdan From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 28 18:08:50 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 DBA8D16A41F; Wed, 28 Sep 2005 18:08:49 +0000 (GMT) (envelope-from rob@hudson-trading.com) Received: from daemon.mistermishap.net (167-49.nyc.dsl.access.net [166.84.167.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30F0843D48; Wed, 28 Sep 2005 18:08:48 +0000 (GMT) (envelope-from rob@hudson-trading.com) Received: from daemon.mistermishap.net (localhost.mistermishap.net [127.0.0.1]) by daemon.mistermishap.net (8.12.9/8.12.9) with ESMTP id j8SI8mmU056728; Wed, 28 Sep 2005 14:08:48 -0400 (EDT) (envelope-from rob@hudson-trading.com) Received: from localhost (rob@localhost) by daemon.mistermishap.net (8.12.9/8.12.9/Submit) with ESMTP id j8SI8lMN056725; Wed, 28 Sep 2005 14:08:48 -0400 (EDT) X-Authentication-Warning: daemon.mistermishap.net: rob owned process doing -bs Date: Wed, 28 Sep 2005 14:08:47 -0400 (EDT) From: Rob Watt X-X-Sender: rob@daemon.mistermishap.net To: Robert Watson In-Reply-To: <20050927222624.R34322@fledge.watson.org> Message-ID: <20050928134724.P56436@daemon.mistermishap.net> References: <20050925115912.H11229@fledge.watson.org> <20050927140535.G50334@daemon.mistermishap.net> <20050927203128.S61419@fledge.watson.org> <20050927222624.R34322@fledge.watson.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1529708662-1127930927=:56436" X-Mailman-Approved-At: Thu, 29 Sep 2005 11:54:53 +0000 Cc: Rob Watt , mikep@hudson-trading.com, freebsd-hackers@FreeBSD.org, freebsd-amd64@FreeBSD.org, Jason Carroll Subject: Re: freebsd-5.4-stable panics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2005 18:08:50 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1529708662-1127930927=:56436 Content-Type: TEXT/PLAIN; charset=US-ASCII Robert, On Tue, 27 Sep 2005, Robert Watson wrote: > Great. As mentioned I'll be offline for about the next 48 hours, but back > after then. If we can get a nice clean crash out of this, would really be > best. If it's top panicking, it could well be due to a bug in the process > monitoring code, in kern_proc. We've run into bugs a few times there in > the past, generally associated with threading or races in process > creation/teardown, in which partially initialized (or torn down) processes > are accessed by another thread and are in an unexpected state. We re-compiled the kernel with 'options KDB_STOP_NMI', and were able to get a much more full analysis of what was happening on the 6-BETA5 crash. We crashed in top again, and it does look like we may have hit a kern_proc bug. in the attached file type3-core.txt you can see that it hits an exception in: 0xffffffff802b897a is in fill_kinfo_thread (/usr/src/sys/kern/kern_proc.c:736). 731 } 732 733 kg = td->td_ksegrp; 734 735 /* things in the KSE GROUP */ 736 kp->ki_estcpu = kg->kg_estcpu; 737 kp->ki_slptime = kg->kg_slptime; 738 kp->ki_pri.pri_user = kg->kg_user_pri; 739 kp->ki_pri.pri_class = kg->kg_pri_class; 740 (kgdb) frame 8 #8 0xffffffff802b897a in fill_kinfo_thread (td=0xffffff0063311260, kp=0xffffffffb62d8510) at /usr/src/sys/kern/kern_proc.c:733 733 kg = td->td_ksegrp; (kgdb) p kg->kg_estcpu Cannot access memory at address 0x173 (kgdb) p td->td_ksegrp $1 = (struct ksegrp *) 0x0 (kgdb) p kp->ki_estcpu $2 = 0 (kgdb) p kg $4 = (struct ksegrp *) 0x12b it seems that kg is an invalid pointer. We have started our tests again without running top. Hope you have a great vacation. - Rob Watt --0-1529708662-1127930927=:56436 Content-Type: APPLICATION/octet-stream; name="type3-core.txt" Content-Transfer-Encoding: BASE64 Content-Description: Content-Disposition: attachment; filename="type3-core.txt" VW5yZWFkIHBvcnRpb24gb2YgdGhlIGtlcm5lbCBtZXNzYWdlIGJ1ZmZlcjoK a2VybmVsIHRyYXAgMTIgd2l0aCBpbnRlcnJ1cHRzIGRpc2FibGVkCgoKRmF0 YWwgdHJhcCAxMjogcGFnZSBmYXVsdCB3aGlsZSBpbiBrZXJuZWwgbW9kZQpj cHVpZCA9IDM7IGFwaWMgaWQgPSAwMwpmYXVsdCB2aXJ0dWFsIGFkZHJlc3Mg ICA9IDB4NDgKZmF1bHQgY29kZSAgICAgICAgICAgICAgPSBzdXBlcnZpc29y IHJlYWQsIHBhZ2Ugbm90IHByZXNlbnQKaW5zdHJ1Y3Rpb24gcG9pbnRlciAg ICAgPSAweDg6MHhmZmZmZmZmZjgwMmI4OTdhCnN0YWNrIHBvaW50ZXIgICAg ICAgICAgID0gMHgxMDoweGZmZmZmZmZmYjYyZDg0OTAKZnJhbWUgcG9pbnRl ciAgICAgICAgICAgPSAweDEwOjB4ZmZmZmZmZmZiNjJkODRmMApjb2RlIHNl Z21lbnQgICAgICAgICAgICA9IGJhc2UgMHgwLCBsaW1pdCAweGZmZmZmLCB0 eXBlIDB4MWIKICAgICAgICAgICAgICAgICAgICAgICAgPSBEUEwgMCwgcHJl cyAxLCBsb25nIDEsIGRlZjMyIDAsIGdyYW4gMQogICAgICAgICAgICAgICAg ICAgICAgICBwcm9jZXNzb3IgZWZsYWdzICAgICAgICA9IHJlc3VtZSwgSU9Q TCA9IDAKICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVudCBwcm9jZXNz ICAgICAgICAgPSAyOTgxMCAodG9wKQogICAgICAgICAgICAgICAgICAgICAg ICBMb2NrZWQgdm5vZGVzCgoweGZmZmZmZjAwM2E0YmM5YjA6IHRhZyB1ZnMs IHR5cGUgVlJFRwogICAgdXNlY291bnQgMSwgd3JpdGVjb3VudCAxLCByZWZj b3VudCA4MDY5IG1vdW50ZWRoZXJlIDAKICAgIGZsYWdzICgpCiAgICB2X29i amVjdCAweGZmZmZmZjAwY2ZiNWZkMjAgcmVmIDAgcGFnZXMgMzIyNjgKICAg ICBsb2NrIHR5cGUgdWZzOiBFWENMIChjb3VudCAxKSBieSB0aHJlYWQgMHhm ZmZmZmYwMDczMWFmNGMwIChwaWQgMjk4MDkpCiAgICAgICBpbm8gMjA0NjY2 OTksIG9uIGRldiBhYWNkMHMxZQpQcm9jZXNzIDI5ODEwICh0b3ApIHRocmVh ZCAweGZmZmZmZjAwNGFmZmNiZTAgKDEwMDA5NykKZXhjbHVzaXZlIHNsZWVw IG11dGV4IHByb2Nlc3MgbG9jayByID0gMCAoMHhmZmZmZmYwMDRhYTlmMGMw KSBsb2NrZWQgQCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3Byb2MuYzo4OTAK c2hhcmVkIHN4IGFsbHByb2MgciA9IDAgKDB4ZmZmZmZmZmY4MDY0MzRlMCkg bG9ja2VkIEAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9wcm9jLmM6MjI5CmV4 Y2x1c2l2ZSBzeCBzeXNjdGwgbG9jayByID0gMCAoMHhmZmZmZmZmZjgwNjQz ZDAwKSBsb2NrZWQgQCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3N5c2N0bC5j OjEzNDIKZXhjbHVzaXZlIHNsZWVwIG11dGV4IEdpYW50IHIgPSAwICgweGZm ZmZmZmZmODA2NDMzNjApIGxvY2tlZCBAIC91c3Ivc3JjL3N5cy9rZXJuL2tl cm5fc3lzY3RsLmM6MTI4MApQcm9jZXNzIDI1MDU3IChkYXRhcGxheSkgdGhy ZWFkIDB4ZmZmZmZmMDAxNTZmYjI2MCAoMTAwMDkxKQpleGNsdXNpdmUgc2xl ZXAgbXV0ZXggaW5wICh1ZHBpbnApIHIgPSAwICgweGZmZmZmZjAwYTgyNmI5 MzgpIGxvY2tlZCBAIC91c3Ivc3JjL3N5cy9uZXRpbmV0L3VkcF91c3JyZXEu Yzo3NjIKRHVtcGluZyAzNzU5IE1CICgyIGNodW5rcykKY2h1bmsgMDogMU1C ICgxNTUgcGFnZXMpIC4uLiBvawpjaHVuayAxOiAzNzU5TUIgKDk2MjI4OCBw YWdlcykgMzc0MyAzNzI3IDM3MTEgMzY5NSAzNjc5IDM2NjMgMzY0NyAzNjMx IDM2MTUgMzU5OSAzNTgzIDM1NjcgMzU1MSAzNTM1IDM1MTkgMzUwMyAzNDg3 IDM0NzEgMzQ1NSAzNDM5IDM0MjMgMzQwNyAzMzkxIDMzNzUgMzM1OSAzMzQz IDMzMjcgMzMxMSAzMjk1IDMyNzkgMzI2MyAzMjQ3IDMyMzEgMzIxNSAzMTk5 IDMxODMgMzE2NyAzMTUxIDMxMzUgMzExOSAzMTAzIDMwODcgMzA3MSAzMDU1 IDMwMzkgMzAyMyAzMDA3IDI5OTEgMjk3NSAyOTU5IDI5NDMgMjkyNyAyOTEx IDI4OTUgMjg3OSAyODYzIDI4NDcgMjgzMSAyODE1IDI3OTkgMjc4MyAyNzY3 IDI3NTEgMjczNSAyNzE5IDI3MDMgMjY4NyAyNjcxIDI2NTUgMjYzOSAyNjIz IDI2MDcgMjU5MSAyNTc1IDI1NTkgMjU0MyAyNTI3IDI1MTEgMjQ5NSAyNDc5 IDI0NjMgMjQ0NyAyNDMxIDI0MTUgMjM5OSAyMzgzIDIzNjcgMjM1MSAyMzM1 IDIzMTkgMjMwMyAyMjg3IDIyNzEgMjI1NSAyMjM5IDIyMjMgMjIwNyAyMTkx IDIxNzUgMjE1OSAyMTQzIDIxMjcgMjExMSAyMDk1IDIwNzkgMjA2MyAyMDQ3 IDIwMzEgMjAxNSAxOTk5IDE5ODMgMTk2NyAxOTUxIDE5MzUgMTkxOSAxOTAz IDE4ODcgMTg3MSAxODU1IDE4MzkgMTgyMyAxODA3IDE3OTEgMTc3NSAxNzU5 IDE3NDMgMTcyNyAxNzExIDE2OTUgMTY3OSAxNjYzIDE2NDcgMTYzMSAxNjE1 IDE1OTkgMTU4MyAxNTY3IDE1NTEgMTUzNSAxNTE5IDE1MDMgMTQ4NyAxNDcx IDE0NTUgMTQzOSAxNDIzIDE0MDcgMTM5MSAxMzc1IDEzNTkgMTM0MyAxMzI3 IDEzMTEgMTI5NSAxMjc5IDEyNjMgMTI0NyAxMjMxIDEyMTUgMTE5OSAxMTgz IDExNjcgMTE1MSAxMTM1IDExMTkgMTEwMyAxMDg3IDEwNzEgMTA1NSAxMDM5 IDEwMjMgMTAwNyA5OTEgOTc1IDk1OSA5NDMgOTI3IDkxMSA4OTUgODc5IDg2 MyA4NDcgODMxIDgxNSA3OTkgNzgzIDc2NyA3NTEgNzM1IDcxOSA3MDMgNjg3 IDY3MSA2NTUgNjM5IDYyMyA2MDcgNTkxIDU3NSA1NTkgNTQzIDUyNyA1MTEg NDk1IDQ3OSA0NjMgNDQ3IDQzMSA0MTUgMzk5IDM4MyAzNjcgMzUxIDMzNSAz MTkgMzAzIDI4NyAyNzEgMjU1IDIzOSAyMjMgMjA3IDE5MSAxNzUgMTU5IDE0 MyAxMjcgMTExIDk1IDc5IDYzIDQ3IDMxIDE1CgojMCAgZG9hZHVtcCAoKSBh dCBwY3B1Lmg6MTcyCjE3MiAgICAgcGNwdS5oOiBObyBzdWNoIGZpbGUgb3Ig ZGlyZWN0b3J5LgogICAgaW4gcGNwdS5oCihrZ2RiKSBidAojMCAgZG9hZHVt cCAoKSBhdCBwY3B1Lmg6MTcyCiMxICAweGZmZmZmZmZmODAxOTc2YjEgaW4g ZGJfZm5jYWxsIChkdW1teTE9MCwgZHVtbXkyPTAsIGR1bW15Mz0wLCBkdW1t eTQ9MHgwKQogICAgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9jb21tYW5kLmM6 NDg5CiMyICAweGZmZmZmZmZmODAxOTdiMDUgaW4gZGJfY29tbWFuZF9sb29w ICgpIGF0IC91c3Ivc3JjL3N5cy9kZGIvZGJfY29tbWFuZC5jOjM0OQojMyAg MHhmZmZmZmZmZjgwMTk5OTczIGluIGRiX3RyYXAgKHR5cGU9LTEyMzg1MzE0 NTYsIGNvZGU9MCkgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9tYWluLmM6MjIx CiM0ICAweGZmZmZmZmZmODAyZGI5YmUgaW4ga2RiX3RyYXAgKHR5cGU9MTIs IGNvZGU9MCwgdGY9MHhmZmZmZmZmZjgwNWUxZjAwKSBhdCAvdXNyL3NyYy9z eXMva2Vybi9zdWJyX2tkYi5jOjQ3MwojNSAgMHhmZmZmZmZmZjgwNDJjMWJl IGluIHRyYXBfZmF0YWwgKGZyYW1lPTB4ZmZmZmZmZmZiNjJkODNlMCwgZXZh PTE4NDQ2NzQyOTc1NDU2MjAxNjk2KQogICAgYXQgL3Vzci9zcmMvc3lzL2Ft ZDY0L2FtZDY0L3RyYXAuYzo2NTYKIzYgIDB4ZmZmZmZmZmY4MDQyYzZmMyBp biB0cmFwIChmcmFtZT0KICAgIHt0Zl9yZGkgPSAwLCB0Zl9yc2kgPSAwLCB0 Zl9yZHggPSAyOTksIHRmX3JjeCA9IDkzODcyOCwgdGZfcjggPSAyNTA1OSwg dGZfcjkgPSAzMjk2LCB0Zl9yYXggPSAwLCB0Zl9yYnggPSAwLCB0Zl9yYnAg PSAtMTIzODUzMDgzMiwgdGZfcjEwID0gMSwgdGZfcjExID0gNDI5NDk2NzI5 NCwgdGZfcjEyID0gLTEyMzg1MzA4MDAsIHRmX3IxMyA9IDYsIHRmX3IxNCA9 IC0xMDk4MjU4OTc2NzY4LCB0Zl9yMTUgPSAtMTA5Nzg0NzQ2NzQyNCwgdGZf dHJhcG5vID0gMTIsIHRmX2FkZHIgPSA3MiwgdGZfZmxhZ3MgPSAtMTA5Nzcy Nzg2OTc4NCwgdGZfZXJyID0gMCwgdGZfcmlwID0gLTIxNDQ2MzA0MDYsIHRm X2NzID0gOCwgdGZfcmZsYWdzID0gNjU1NTksIHRmX3JzcCA9IC0xMjM4NTMw OTEyLCB0Zl9zcyA9IDE2fSkgYXQgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0 L3RyYXAuYzoyNDEKIzcgIDB4ZmZmZmZmZmY4MDQxYTBlYiBpbiBjYWxsdHJh cCAoKSBhdCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvZXhjZXB0aW9uLlM6 MTY4CiM4ICAweGZmZmZmZmZmODAyYjg5N2EgaW4gZmlsbF9raW5mb190aHJl YWQgKHRkPTB4ZmZmZmZmMDA2MzMxMTI2MCwga3A9MHhmZmZmZmZmZmI2MmQ4 NTEwKQogICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9wcm9jLmM6NzMz CiM5ICAweGZmZmZmZmZmODAyYjkyODYgaW4gc3lzY3RsX291dF9wcm9jIChw PTB4ZmZmZmZmMDA0YWE5ZjAwMCwgcmVxPTB4ZmZmZmZmZmZiNjJkOGEyMCwg ZmxhZ3M9MCkKICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJvYy5j Ojg4NgojMTAgMHhmZmZmZmZmZjgwMmI5NWMxIGluIHN5c2N0bF9rZXJuX3By b2MgKG9pZHA9MHgwLCBhcmcxPTB4MCwgYXJnMj0yOTksIHJlcT0weGZmZmZm ZmZmYjYyZDhhMjApCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3By b2MuYzoxMDc1CiMxMSAweGZmZmZmZmZmODAyYzdkMjAgaW4gc3lzY3RsX3Jv b3QgKG9pZHA9MHgwLCBhcmcxPTB4MCwgYXJnMj0wLCByZXE9MHhmZmZmZmZm ZmI2MmQ4YTIwKQogICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zeXNj dGwuYzoxMjQ4CiMxMiAweGZmZmZmZmZmODAyYzgxOWMgaW4gdXNlcmxhbmRf c3lzY3RsICh0ZD0weGZmZmZmZjAwNGFmZmNiZTAsIG5hbWU9MHhmZmZmZmZm ZmI2MmQ4YWYwLCBuYW1lbGVuPTMsCiAgICBvbGQ9MHg1OTYwMDAsIG9sZGxl bnA9MHg3ZmZmZmZmZmU0ZjgsIGlua2VybmVsPTAsIG5ldz0weDAsIG5ld2xl bj0wLCByZXR2YWw9MHhmZmZmZmZmZmI2MmQ4YWU4LCBmbGFncz0wKQogICAg YXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zeXNjdGwuYzoxMzQ3CiMxMyAw eGZmZmZmZmZmODAyYzgzMmQgaW4gX19zeXNjdGwgKHRkPTB4ZmZmZmZmMDA0 YWZmY2JlMCwgdWFwPTB4ZmZmZmZmZmZiNjJkOGJjMCkKICAgIGF0IC91c3Iv c3JjL3N5cy9rZXJuL2tlcm5fc3lzY3RsLmM6MTI4MgojMTQgMHhmZmZmZmZm ZjgwNDJjZjYyIGluIHN5c2NhbGwgKGZyYW1lPQogICAge3RmX3JkaSA9IDE0 MDczNzQ4ODM0ODUxMiwgdGZfcnNpID0gMywgdGZfcmR4ID0gNTg1NzI4MCwg dGZfcmN4ID0gMTQwNzM3NDg4MzQ4NDA4LCB0Zl9yOCA9IDAsIHRmX3I5ID0g MCwgdGZfcmF4ID0gMjAyLCB0Zl9yYnggPSA1ODUzMTg0LCB0Zl9yYnAgPSAw LCB0Zl9yMTAgPSAxLCB0Zl9yMTEgPSA1MTQsIHRmX3IxMiA9IDE0MDczNzQ4 ODM0ODUxMiwgdGZfcjEzID0gMTQwNzM3NDg4MzQ5MDQwLCB0Zl9yMTQgPSA1 Mjk1MzY4LCB0Zl9yMTUgPSAxNDA3Mzc0ODgzNDkwNDAsIHRmX3RyYXBubyA9 IDEyLCB0Zl9hZGRyID0gMzQzNzAxNjM1MzYsIHRmX2ZsYWdzID0gNDA5Niwg dGZfZXJyID0gMiwgdGZfcmlwID0gMzQzNzAyMTQ2MjAsIHRmX2NzID0gNDMs IHRmX3JmbGFncyA9IDUxNCwgdGZfcnNwID0gMTQwNzM3NDg4MzQ4MzYwLCB0 Zl9zcyA9IDM1fSkKICAgIGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC90 cmFwLmM6Nzk3CiMxNSAweGZmZmZmZmZmODA0MWEyODggaW4gWGZhc3Rfc3lz Y2FsbCAoKSBhdCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvZXhjZXB0aW9u LlM6MjcwCiMxNiAweDAwMDAwMDA4MDA5ZmRhZGMgaW4gPz8gKCkKUHJldmlv dXMgZnJhbWUgaW5uZXIgdG8gdGhpcyBmcmFtZSAoY29ycnVwdCBzdGFjaz8p Cgooa2dkYikgbCAqMHhmZmZmZmZmZjgwMmI4OTdhCjB4ZmZmZmZmZmY4MDJi ODk3YSBpcyBpbiBmaWxsX2tpbmZvX3RocmVhZCAoL3Vzci9zcmMvc3lzL2tl cm4va2Vybl9wcm9jLmM6NzM2KS4KNzMxICAgICAgICAgICAgICAgICAgICAg fQo3MzIKNzMzICAgICAgICAgICAgICAgICAgICAga2cgPSB0ZC0+dGRfa3Nl Z3JwOwo3MzQKNzM1ICAgICAgICAgICAgICAgICAgICAgLyogdGhpbmdzIGlu IHRoZSBLU0UgR1JPVVAgKi8KNzM2ICAgICAgICAgICAgICAgICAgICAga3At PmtpX2VzdGNwdSA9IGtnLT5rZ19lc3RjcHU7CjczNyAgICAgICAgICAgICAg ICAgICAgIGtwLT5raV9zbHB0aW1lID0ga2ctPmtnX3NscHRpbWU7CjczOCAg ICAgICAgICAgICAgICAgICAgIGtwLT5raV9wcmkucHJpX3VzZXIgPSBrZy0+ a2dfdXNlcl9wcmk7CjczOSAgICAgICAgICAgICAgICAgICAgIGtwLT5raV9w cmkucHJpX2NsYXNzID0ga2ctPmtnX3ByaV9jbGFzczsKNzQwCihrZ2RiKSBm cmFtZSA4CiM4ICAweGZmZmZmZmZmODAyYjg5N2EgaW4gZmlsbF9raW5mb190 aHJlYWQgKHRkPTB4ZmZmZmZmMDA2MzMxMTI2MCwga3A9MHhmZmZmZmZmZmI2 MmQ4NTEwKQogICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9wcm9jLmM6 NzMzCjczMyAgICAgICAgICAgICAgICAgICAgIGtnID0gdGQtPnRkX2tzZWdy cDsKKGtnZGIpIHAga2ctPmtnX2VzdGNwdQpDYW5ub3QgYWNjZXNzIG1lbW9y eSBhdCBhZGRyZXNzIDB4MTczCihrZ2RiKSBwIHRkLT50ZF9rc2VncnAKJDEg PSAoc3RydWN0IGtzZWdycCAqKSAweDAKKGtnZGIpIHAga3AtPmtpX2VzdGNw dQokMiA9IDAKKGtnZGIpIHAga2cKJDQgPSAoc3RydWN0IGtzZWdycCAqKSAw eDEyYgoKCgpPdXRwdXQgZnJvbSBkZGIgYmVmb3JlIGdlbmVyYXRpbmcgY29y ZSAoJ3Nob3cgbG9ja2Vkdm5vZHMnIAogIGFuZCAnc2hvdyBhbGxsb2Nrcycg b3V0cHV0IGlzIGluY2x1ZGVkIGFib3ZlIGF0IHN0YXJ0IG9mIGNvcmUgb3V0 cHV0KToKCj5zaG93IHBjcHUKY3B1aWQ9MwpjdXJyZW50IHRocmVhZCAgPSAw eGZmZmZmZjAwNGFmZmNiZTAgKDI5ODEwIHRvcCkKY3VycmVudCBwY2IgICAg ID0gMHhmZmZmZmZmZmI2MmQ4ZDEwCmZwY3VydGhyZWFkICAgICA9IG5vbmUK aWRsZSB0aHJlYWQgICAgID0gMHhmZmZmZmYwMGUzN2UzOTgwIHBpZCAxMSBp ZGxlIGNwdTMKc3BpbiBsb2NrcyBoZWxkID0gbm9uZQoKPnNob3cgcGNwdSAw CmNwdWlkPTAKY3VycmVudCB0aHJlYWQgID0gMHhmZmZmZmYwMDE1NmZiMjQw ICgyNTA1NyBkYXRhcGxheSkKY3VycmVudCBwY2IgICAgID0gMHhmZmZmZmZm ZmI2MjZhZDEwCmZwY3VydGhyZWFkICAgICA9IDB4ZmZmZmZmMDAxNTZmYjI0 MCAoMjUwNTcgZGF0YXBsYXkpCmlkbGUgdGhyZWFkICAgICA9IDB4ZmZmZmZm MDBlMzdlNWJlMCBwaWQgMTQgaWRsZSBjcHUwCnNwaW4gbG9ja3MgaGVsZCA9 IG5vbmUKCj5zaG93IHBjcHUgMQpjcHVpZD0xCmN1cnJlbnQgdGhyZWFkICA9 IDB4ZmZmZmZmMDA3MzFhZjRjMCAoMjk4MDkgYm9ubmllKQpjdXJyZW50IHBj YiAgICAgPSAweGZmZmZmZmZmYjZhNjdkMTAKZnBjdXJ0aHJlYWQgICAgID0g bm9uZQppZGxlIHRocmVhZCAgICAgPSAweGZmZmZmZjAwZTM3ZTUwMDAgcGlk IDEzIGlkbGUgY3B1MQpzcGluIGxvY2tzIGhlbGQgPSBub25lCgo+c2hvdyBw Y3B1IDIKY3B1aWQ9MgpjdXJyZW50IHRocmVhZCAgPSAweGZmZmZmZjAwYTk3 YWUwMDAgKDI1MDU5IGNxc2ZlZWQpCmN1cnJlbnQgcGNiICAgICA9IDB4ZmZm ZmZmZmZiNjlhOWQxMApmcGN1cnRocmVhZCAgICAgPSAweGZmZmZmZjAwYTk3 YWUwMDAgKDI1MDU5IGNxc2ZlZWQpCmlkbGUgdGhyZWFkICAgICA9IDB4ZmZm ZmZmMDBlMzdlM2JlMCBwaWQgMTIgaWRsZSBjcHUyCnNwaW4gbG9ja3MgaGVs ZCA9IG5vbmUKCg== --0-1529708662-1127930927=:56436 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="dmesg.6.0-BETA5" Content-Transfer-Encoding: BASE64 Content-Description: Content-Disposition: attachment; filename="dmesg.6.0-BETA5" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDUgVGhlIEZyZWVCU0QgUHJvamVjdC4N CkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwg MTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KCVRoZSBSZWdlbnRzIG9m IHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVz ZXJ2ZWQuDQpGcmVlQlNEIDYuMC1CRVRBNSAjMTogVHVlIFNlcCAyNyAxNzoz ODozMiBFRFQgMjAwNQ0KICAgIHJvb3RAcXVvdGV0ZXN0MjovdXNyL29iai91 c3Ivc3JjL3N5cy9MT0NBTC1ERUJVRy1OTUkNCldBUk5JTkc6IFdJVE5FU1Mg b3B0aW9uIGVuYWJsZWQsIGV4cGVjdCByZWR1Y2VkIHBlcmZvcm1hbmNlLg0K VGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFs aXR5IDANCkNQVTogRHVhbCBDb3JlIEFNRCBPcHRlcm9uKHRtKSBQcm9jZXNz b3IgMjc1ICgyMTkwLjA1LU1IeiBLOC1jbGFzcyBDUFUpDQogIE9yaWdpbiA9 ICJBdXRoZW50aWNBTUQiICBJZCA9IDB4MjBmMTIgIFN0ZXBwaW5nID0gMg0K ICBGZWF0dXJlcz0weDE3OGJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1Is UEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBT RTM2LENMRkxVU0gsTU1YLEZYU1IsU1NFLFNTRTIsSFRUPg0KICBGZWF0dXJl czI9MHgxPFNTRTM+DQogIEFNRCBGZWF0dXJlcz0weGUyNTAwODAwPFNZU0NB TEwsTlgsTU1YKyw8YjI1PixMTSwzRE5vdyssM0ROb3c+DQogIEh5cGVydGhy ZWFkaW5nOiAyIGxvZ2ljYWwgQ1BVcw0KcmVhbCBtZW1vcnkgID0gMzk0MjU4 MDIyNCAoMzc1OSBNQikNCmF2YWlsIG1lbW9yeSA9IDM4MDczOTk5MzYgKDM2 MzEgTUIpDQpBQ1BJIEFQSUMgVGFibGU6IDxBIE0gSSAgT0VNQVBJQyA+DQpG cmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERldGVjdGVkOiA0 IENQVXMNCiBjcHUwIChCU1ApOiBBUElDIElEOiAgMA0KIGNwdTEgKEFQKTog QVBJQyBJRDogIDENCiBjcHUyIChBUCk6IEFQSUMgSUQ6ICAyDQogY3B1MyAo QVApOiBBUElDIElEOiAgMw0KTUFEVDogRm9yY2luZyBhY3RpdmUtbG93IHBv bGFyaXR5IGFuZCBsZXZlbCB0cmlnZ2VyIGZvciBTQ0kNCmlvYXBpYzAgPFZl cnNpb24gMS4xPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQNCmlvYXBpYzEg PFZlcnNpb24gMS4xPiBpcnFzIDI0LTI3IG9uIG1vdGhlcmJvYXJkDQppb2Fw aWMyIDxWZXJzaW9uIDEuMT4gaXJxcyAyOC0zMSBvbiBtb3RoZXJib2FyZA0K YWNwaTA6IDxBIE0gSSBPRU1SU0RUPiBvbiBtb3RoZXJib2FyZA0KYWNwaTA6 IFBvd2VyIEJ1dHRvbiAoZml4ZWQpDQpwY2lfbGluazA6IDxBQ1BJIFBDSSBM aW5rIExOS0E+IGlycSAxMCBvbiBhY3BpMA0KcGNpX2xpbmsxOiA8QUNQSSBQ Q0kgTGluayBMTktCPiBpcnEgNSBvbiBhY3BpMA0KcGNpX2xpbmsyOiA8QUNQ SSBQQ0kgTGluayBMTktDPiBpcnEgMTEgb24gYWNwaTANCnBjaV9saW5rMzog PEFDUEkgUENJIExpbmsgTE5LRD4gaXJxIDkgb24gYWNwaTANClRpbWVjb3Vu dGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkg MTAwMA0KYWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQgMy41Nzk1NDVN SHo+IHBvcnQgMHgxMDA4LTB4MTAwYiBvbiBhY3BpMA0KY3B1MDogPEFDUEkg Q1BVPiBvbiBhY3BpMA0KYWNwaV90aHJvdHRsZTA6IDxBQ1BJIENQVSBUaHJv dHRsaW5nPiBvbiBjcHUwDQpjcHUxOiA8QUNQSSBDUFU+IG9uIGFjcGkwDQpj cHUyOiA8QUNQSSBDUFU+IG9uIGFjcGkwDQpjcHUzOiA8QUNQSSBDUFU+IG9u IGFjcGkwDQpwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4 Y2Y4LTB4Y2ZmIG9uIGFjcGkwDQpwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBw Y2liMA0KcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2Ug Ni4wIG9uIHBjaTANCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxDQpv aGNpMDogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBtZW0gMHhm ZWFmYzAwMC0weGZlYWZjZmZmIGlycSAxOSBhdCBkZXZpY2UgMC4wIG9uIHBj aTMNCm9oY2kwOiBbR0lBTlQtTE9DS0VEXQ0KdXNiMDogT0hDSSB2ZXJzaW9u IDEuMCwgbGVnYWN5IHN1cHBvcnQNCnVzYjA6IDxPSENJIChnZW5lcmljKSBV U0IgY29udHJvbGxlcj4gb24gb2hjaTANCnVzYjA6IFVTQiByZXZpc2lvbiAx LjANCnVodWIwOiBBTUQgT0hDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYg MS4wMC8xLjAwLCBhZGRyIDENCnVodWIwOiAzIHBvcnRzIHdpdGggMyByZW1v dmFibGUsIHNlbGYgcG93ZXJlZA0Kb2hjaTE6IDxPSENJIChnZW5lcmljKSBV U0IgY29udHJvbGxlcj4gbWVtIDB4ZmVhZmQwMDAtMHhmZWFmZGZmZiBpcnEg MTkgYXQgZGV2aWNlIDAuMSBvbiBwY2kzDQpvaGNpMTogW0dJQU5ULUxPQ0tF RF0NCnVzYjE6IE9IQ0kgdmVyc2lvbiAxLjAsIGxlZ2FjeSBzdXBwb3J0DQp1 c2IxOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2kx DQp1c2IxOiBVU0IgcmV2aXNpb24gMS4wDQp1aHViMTogQU1EIE9IQ0kgcm9v dCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxDQp1aHVi MTogMyBwb3J0cyB3aXRoIDMgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNCnBj aTM6IDxkaXNwbGF5LCBWR0E+IGF0IGRldmljZSA2LjAgKG5vIGRyaXZlciBh dHRhY2hlZCkNCmZ4cDA6IDxJbnRlbCA4MjU1MSBQcm8vMTAwIEV0aGVybmV0 PiBwb3J0IDB4YmMwMC0weGJjM2YgbWVtIDB4ZmVhZmIwMDAtMHhmZWFmYmZm ZiwweGZlYWEwMDAwLTB4ZmVhYmZmZmYgaXJxIDE4IGF0IGRldmljZSA4LjAg b24gcGNpMw0KbWlpYnVzMDogPE1JSSBidXM+IG9uIGZ4cDANCmlucGh5MDog PGk4MjU1NSAxMC8xMDAgbWVkaWEgaW50ZXJmYWNlPiBvbiBtaWlidXMwDQpp bnBoeTA6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBi YXNlVFgtRkRYLCBhdXRvDQpmeHAwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDpl MDo4MTozMTo4OToxYw0KaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2 aWNlIDcuMCBvbiBwY2kwDQppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjANCmF0 YXBjaTA6IDxBTUQgODExMSBVRE1BMTMzIGNvbnRyb2xsZXI+IHBvcnQgMHgx ZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYsMHhmZmEwLTB4ZmZh ZiBhdCBkZXZpY2UgNy4xIG9uIHBjaTANCmF0YTA6IDxBVEEgY2hhbm5lbCAw PiBvbiBhdGFwY2kwDQphdGExOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNp MA0KcGNpMDogPHNlcmlhbCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgNy4yIChu byBkcml2ZXIgYXR0YWNoZWQpDQpwY2kwOiA8YnJpZGdlPiBhdCBkZXZpY2Ug Ny4zIChubyBkcml2ZXIgYXR0YWNoZWQpDQpwY2liMjogPEFDUEkgUENJLVBD SSBicmlkZ2U+IGF0IGRldmljZSAxMC4wIG9uIHBjaTANCnBjaTI6IDxBQ1BJ IFBDSSBidXM+IG9uIHBjaWIyDQplbTA6IDxJbnRlbChSKSBQUk8vMTAwMCBO ZXR3b3JrIENvbm5lY3Rpb24sIFZlcnNpb24gLSAyLjEuNz4gcG9ydCAweDg4 ODAtMHg4OGJmIG1lbSAweGZjOGMwMDAwLTB4ZmM4ZGZmZmYsMHhmYzgwMDAw MC0weGZjODNmZmZmIGlycSAyNiBhdCBkZXZpY2UgMi4wIG9uIHBjaTINCmVt MDogRXRoZXJuZXQgYWRkcmVzczogMDA6MDQ6MjM6YmE6ZDA6NDINCmVtMDog IFNwZWVkOk4vQSAgRHVwbGV4Ok4vQQ0KZW0xOiA8SW50ZWwoUikgUFJPLzEw MDAgTmV0d29yayBDb25uZWN0aW9uLCBWZXJzaW9uIC0gMi4xLjc+IHBvcnQg MHg4YzAwLTB4OGMzZiBtZW0gMHhmYzhlMDAwMC0weGZjOGZmZmZmLDB4ZmM4 ODAwMDAtMHhmYzhiZmZmZiBpcnEgMjcgYXQgZGV2aWNlIDIuMSBvbiBwY2ky DQplbTE6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjA0OjIzOmJhOmQwOjQzDQpl bTE6ICBTcGVlZDpOL0EgIER1cGxleDpOL0ENCmVtMjogPEludGVsKFIpIFBS Ty8xMDAwIE5ldHdvcmsgQ29ubmVjdGlvbiwgVmVyc2lvbiAtIDIuMS43PiBw b3J0IDB4ODQ4MC0weDg0YmYgbWVtIDB4ZmM3ODAwMDAtMHhmYzc5ZmZmZiww eGZjNzQwMDAwLTB4ZmM3N2ZmZmYgaXJxIDI3IGF0IGRldmljZSAzLjAgb24g cGNpMg0KZW0yOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDowNDoyMzphZTo2MDow YQ0KZW0yOiAgU3BlZWQ6MTAwMCBNYnBzICBEdXBsZXg6RnVsbA0KZW0zOiA8 SW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBDb25uZWN0aW9uLCBWZXJzaW9u IC0gMi4xLjc+IHBvcnQgMHg4ODAwLTB4ODgzZiBtZW0gMHhmYzdhMDAwMC0w eGZjN2JmZmZmIGlycSAyNCBhdCBkZXZpY2UgMy4xIG9uIHBjaTINCmVtMzog RXRoZXJuZXQgYWRkcmVzczogMDA6MDQ6MjM6YWU6NjA6MGINCmVtMzogIFNw ZWVkOjEwMDAgTWJwcyAgRHVwbGV4OkZ1bGwNCmJnZTA6IDxCcm9hZGNvbSBC Q001NzA0QyBEdWFsIEdpZ2FiaXQgRXRoZXJuZXQsIEFTSUMgcmV2LiAweDIw MDM+IG1lbSAweGZjNmMwMDAwLTB4ZmM2Y2ZmZmYsMHhmYzZiMDAwMC0weGZj NmJmZmZmIGlycSAyNCBhdCBkZXZpY2UgOS4wIG9uIHBjaTINCm1paWJ1czE6 IDxNSUkgYnVzPiBvbiBiZ2UwDQpicmdwaHkwOiA8QkNNNTcwNCAxMC8xMDAv MTAwMGJhc2VUWCBQSFk+IG9uIG1paWJ1czENCmJyZ3BoeTA6ICAxMGJhc2VU LCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAw YmFzZVRYLCAxMDAwYmFzZVRYLUZEWCwgYXV0bw0KYmdlMDogRXRoZXJuZXQg YWRkcmVzczogMDA6ZTA6ODE6MzE6OGY6ODANCmJnZTE6IDxCcm9hZGNvbSBC Q001NzA0QyBEdWFsIEdpZ2FiaXQgRXRoZXJuZXQsIEFTSUMgcmV2LiAweDIw MDM+IG1lbSAweGZjNmYwMDAwLTB4ZmM2ZmZmZmYsMHhmYzZlMDAwMC0weGZj NmVmZmZmIGlycSAyNSBhdCBkZXZpY2UgOS4xIG9uIHBjaTINCm1paWJ1czI6 IDxNSUkgYnVzPiBvbiBiZ2UxDQpicmdwaHkxOiA8QkNNNTcwNCAxMC8xMDAv MTAwMGJhc2VUWCBQSFk+IG9uIG1paWJ1czINCmJyZ3BoeTE6ICAxMGJhc2VU LCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAw YmFzZVRYLCAxMDAwYmFzZVRYLUZEWCwgYXV0bw0KYmdlMTogRXRoZXJuZXQg YWRkcmVzczogMDA6ZTA6ODE6MzE6OGY6ODENCnBjaTA6IDxiYXNlIHBlcmlw aGVyYWwsIGludGVycnVwdCBjb250cm9sbGVyPiBhdCBkZXZpY2UgMTAuMSAo bm8gZHJpdmVyIGF0dGFjaGVkKQ0KcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJp ZGdlPiBhdCBkZXZpY2UgMTEuMCBvbiBwY2kwDQpwY2kxOiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liMw0KYWFjMDogPEFkYXB0ZWMgU0NTSSBSQUlEIDIyMzBT PiBtZW0gMHhmYjgwMDAwMC0weGZiZmZmZmZmLDB4ZjAwMDAwMDAtMHhmN2Zm ZmZmZiBpcnEgMjggYXQgZGV2aWNlIDMuMCBvbiBwY2kxDQphYWMwOiBbRkFT VF0NCmFhYzA6IEVuYWJsaW5nIDY0LWJpdCBhZGRyZXNzIHN1cHBvcnQNCmFh Y3AwOiA8U0NTSSBQYXNzdGhyb3VnaCBCdXM+IG9uIGFhYzANCmFhY3AxOiA8 U0NTSSBQYXNzdGhyb3VnaCBCdXM+IG9uIGFhYzANCnBjaTA6IDxiYXNlIHBl cmlwaGVyYWwsIGludGVycnVwdCBjb250cm9sbGVyPiBhdCBkZXZpY2UgMTEu MSAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KYWNwaV9idXR0b24wOiA8UG93ZXIg QnV0dG9uPiBvbiBhY3BpMA0KYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xs ZXIgKGk4MDQyKT4gcG9ydCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTANCmF0 a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwDQprYmQwIGF0 IGF0a2JkMA0KYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQ0Kc2lvMDogPDE2NTUw QS1jb21wYXRpYmxlIENPTSBwb3J0PiBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0 IGZsYWdzIDB4MTAgb24gYWNwaTANCnNpbzA6IHR5cGUgMTY1NTBBDQpzaW8x OiA8MTY1NTBBLWNvbXBhdGlibGUgQ09NIHBvcnQ+IHBvcnQgMHgyZjgtMHgy ZmYgaXJxIDMgb24gYWNwaTANCnNpbzE6IHR5cGUgMTY1NTBBDQpmZGMwOiA8 ZmxvcHB5IGRyaXZlIGNvbnRyb2xsZXIgKEZERSk+IHBvcnQgMHgzZjAtMHgz ZjUsMHgzZjcgaXJxIDYgZHJxIDIgb24gYWNwaTANCmZkYzA6IFtGQVNUXQ0K ZmQwOiA8MTQ0MC1LQiAzLjUiIGRyaXZlPiBvbiBmZGMwIGRyaXZlIDANCnBw YzA6IDxTdGFuZGFyZCBwYXJhbGxlbCBwcmludGVyIHBvcnQ+IHBvcnQgMHgz NzgtMHgzN2YgaXJxIDcgb24gYWNwaTANCnBwYzA6IEdlbmVyaWMgY2hpcHNl dCAoTklCQkxFLW9ubHkpIGluIENPTVBBVElCTEUgbW9kZQ0KcHBidXMwOiA8 UGFyYWxsZWwgcG9ydCBidXM+IG9uIHBwYzANCmxwdDA6IDxQcmludGVyPiBv biBwcGJ1czANCmxwdDA6IEludGVycnVwdC1kcml2ZW4gcG9ydA0KcHBpMDog PFBhcmFsbGVsIEkvTz4gb24gcHBidXMwDQpvcm0wOiA8SVNBIE9wdGlvbiBS T01zPiBhdCBpb21lbSAweGMwMDAwLTB4YzdmZmYsMHhjODAwMC0weGNjN2Zm LDB4Y2M4MDAtMHhjZDdmZiwweGNkODAwLTB4Y2VmZmYsMHhjZjAwMC0weGQw N2ZmLDB4ZDA4MDAtMHhkMTdmZiBvbiBpc2EwDQpzYzA6IDxTeXN0ZW0gY29u c29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMA0Kc2MwOiBWR0EgPDE2IHZp cnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPg0KdmdhMDogPEdlbmVyaWMg SVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4 YmZmZmYgb24gaXNhMA0KVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAg bXNlYw0KaXBmdzIgKCtpcHY2KSBpbml0aWFsaXplZCwgZGl2ZXJ0IGxvYWRh YmxlLCBydWxlLWJhc2VkIGZvcndhcmRpbmcgZGlzYWJsZWQsIGRlZmF1bHQg dG8gZGVueSwgbG9nZ2luZyB1bmxpbWl0ZWQNCmFjZDA6IENEUk9NIDxTT05Z IENELVJPTSBDRFU1MjE1LzdZUzE+IGF0IGF0YTEtbWFzdGVyIFVETUEzMw0K YWFjZDA6IDxSQUlEIDU+IG9uIGFhYzANCmFhY2QwOiAyMDk5MjJNQiAoNDI5 OTIwMjU2IHNlY3RvcnMpDQoocHJvYmU5OmFhY3AwOjA6MTA6MCk6IElOUVVJ UlkuIENEQjogMTIgMCAwIDAgMjQgMCANCihwcm9iZTk6YWFjcDA6MDoxMDow KTogSUxMRUdBTCBSRVFVRVNUIGFzYzo1NSwzDQoocHJvYmU5OmFhY3AwOjA6 MTA6MCk6IFJlc2VydmVkIEFTQy9BU0NRIHBhaXINCihwcm9iZTA6YWFjcDA6 MDowOjApOiBJTlFVSVJZLiBDREI6IDEyIDAgMCAwIDI0IDAgDQoocHJvYmUw OmFhY3AwOjA6MDowKTogSUxMRUdBTCBSRVFVRVNUIGFzYzo1NSwzDQoocHJv YmUwOmFhY3AwOjA6MDowKTogUmVzZXJ2ZWQgQVNDL0FTQ1EgcGFpcg0KKHBy b2JlMTphYWNwMDowOjE6MCk6IElOUVVJUlkuIENEQjogMTIgMCAwIDAgMjQg MCANCihwcm9iZTE6YWFjcDA6MDoxOjApOiBJTExFR0FMIFJFUVVFU1QgYXNj OjU1LDMNCihwcm9iZTE6YWFjcDA6MDoxOjApOiBSZXNlcnZlZCBBU0MvQVND USBwYWlyDQoocHJvYmUyOmFhY3AwOjA6MjowKTogSU5RVUlSWS4gQ0RCOiAx MiAwIDAgMCAyNCAwIA0KKHByb2JlMjphYWNwMDowOjI6MCk6IElMTEVHQUwg UkVRVUVTVCBhc2M6NTUsMw0KKHByb2JlMjphYWNwMDowOjI6MCk6IFJlc2Vy dmVkIEFTQy9BU0NRIHBhaXINCihwcm9iZTM6YWFjcDA6MDozOjApOiBJTlFV SVJZLiBDREI6IDEyIDAgMCAwIDI0IDAgDQoocHJvYmUzOmFhY3AwOjA6Mzow KTogSUxMRUdBTCBSRVFVRVNUIGFzYzo1NSwzDQoocHJvYmUzOmFhY3AwOjA6 MzowKTogUmVzZXJ2ZWQgQVNDL0FTQ1EgcGFpcg0KKHByb2JlNDphYWNwMDow OjQ6MCk6IElOUVVJUlkuIENEQjogMTIgMCAwIDAgMjQgMCANCihwcm9iZTQ6 YWFjcDA6MDo0OjApOiBJTExFR0FMIFJFUVVFU1QgYXNjOjU1LDMNCihwcm9i ZTQ6YWFjcDA6MDo0OjApOiBSZXNlcnZlZCBBU0MvQVNDUSBwYWlyDQoocHJv YmU1OmFhY3AwOjA6NTowKTogSU5RVUlSWS4gQ0RCOiAxMiAwIDAgMCAyNCAw IA0KKHByb2JlNTphYWNwMDowOjU6MCk6IElMTEVHQUwgUkVRVUVTVCBhc2M6 NTUsMw0KKHByb2JlNTphYWNwMDowOjU6MCk6IFJlc2VydmVkIEFTQy9BU0NR IHBhaXINCihwcm9iZTY6YWFjcDA6MDo2OjApOiBJTlFVSVJZLiBDREI6IDEy IDAgMCAwIDI0IDAgDQoocHJvYmU2OmFhY3AwOjA6NjowKTogSUxMRUdBTCBS RVFVRVNUIGFzYzo1NSwzDQoocHJvYmU2OmFhY3AwOjA6NjowKTogUmVzZXJ2 ZWQgQVNDL0FTQ1EgcGFpcg0KKHByb2JlNzphYWNwMDowOjg6MCk6IElOUVVJ UlkuIENEQjogMTIgMCAwIDAgMjQgMCANCihwcm9iZTc6YWFjcDA6MDo4OjAp OiBJTExFR0FMIFJFUVVFU1QgYXNjOjU1LDMNCihwcm9iZTc6YWFjcDA6MDo4 OjApOiBSZXNlcnZlZCBBU0MvQVNDUSBwYWlyDQoocHJvYmU4OmFhY3AwOjA6 OTowKTogSU5RVUlSWS4gQ0RCOiAxMiAwIDAgMCAyNCAwIA0KKHByb2JlODph YWNwMDowOjk6MCk6IElMTEVHQUwgUkVRVUVTVCBhc2M6NTUsMw0KKHByb2Jl ODphYWNwMDowOjk6MCk6IFJlc2VydmVkIEFTQy9BU0NRIHBhaXINCihwcm9i ZTEwOmFhY3AwOjA6MTE6MCk6IElOUVVJUlkuIENEQjogMTIgMCAwIDAgMjQg MCANCihwcm9iZTEwOmFhY3AwOjA6MTE6MCk6IElMTEVHQUwgUkVRVUVTVCBh c2M6NTUsMw0KKHByb2JlMTA6YWFjcDA6MDoxMTowKTogUmVzZXJ2ZWQgQVND L0FTQ1EgcGFpcg0KKHByb2JlMTE6YWFjcDA6MDoxMjowKTogSU5RVUlSWS4g Q0RCOiAxMiAwIDAgMCAyNCAwIA0KKHByb2JlMTE6YWFjcDA6MDoxMjowKTog SUxMRUdBTCBSRVFVRVNUIGFzYzo1NSwzDQoocHJvYmUxMTphYWNwMDowOjEy OjApOiBSZXNlcnZlZCBBU0MvQVNDUSBwYWlyDQoocHJvYmUxMjphYWNwMDow OjEzOjApOiBJTlFVSVJZLiBDREI6IDEyIDAgMCAwIDI0IDAgDQoocHJvYmUx MjphYWNwMDowOjEzOjApOiBJTExFR0FMIFJFUVVFU1QgYXNjOjU1LDMNCihw cm9iZTEyOmFhY3AwOjA6MTM6MCk6IFJlc2VydmVkIEFTQy9BU0NRIHBhaXIN Cihwcm9iZTEzOmFhY3AwOjA6MTQ6MCk6IElOUVVJUlkuIENEQjogMTIgMCAw IDAgMjQgMCANCihwcm9iZTEzOmFhY3AwOjA6MTQ6MCk6IElMTEVHQUwgUkVR VUVTVCBhc2M6NTUsMw0KKHByb2JlMTM6YWFjcDA6MDoxNDowKTogUmVzZXJ2 ZWQgQVNDL0FTQ1EgcGFpcg0KKHByb2JlMTQ6YWFjcDA6MDoxNTowKTogSU5R VUlSWS4gQ0RCOiAxMiAwIDAgMCAyNCAwIA0KKHByb2JlMTQ6YWFjcDA6MDox NTowKTogSUxMRUdBTCBSRVFVRVNUIGFzYzo1NSwzDQoocHJvYmUxNDphYWNw MDowOjE1OjApOiBSZXNlcnZlZCBBU0MvQVNDUSBwYWlyDQoocHJvYmUxNTph YWNwMTowOjA6MCk6IElOUVVJUlkuIENEQjogMTIgMCAwIDAgMjQgMCANCihw cm9iZTE1OmFhY3AxOjA6MDowKTogSUxMRUdBTCBSRVFVRVNUIGFzYzo1NSwz DQoocHJvYmUxNTphYWNwMTowOjA6MCk6IFJlc2VydmVkIEFTQy9BU0NRIHBh aXINCihwcm9iZTE2OmFhY3AxOjA6MTowKTogSU5RVUlSWS4gQ0RCOiAxMiAw IDAgMCAyNCAwIA0KKHByb2JlMTY6YWFjcDE6MDoxOjApOiBJTExFR0FMIFJF UVVFU1QgYXNjOjU1LDMNCihwcm9iZTE2OmFhY3AxOjA6MTowKTogUmVzZXJ2 ZWQgQVNDL0FTQ1EgcGFpcg0KKHByb2JlMTc6YWFjcDE6MDoyOjApOiBJTlFV SVJZLiBDREI6IDEyIDAgMCAwIDI0IDAgDQoocHJvYmUxNzphYWNwMTowOjI6 MCk6IElMTEVHQUwgUkVRVUVTVCBhc2M6NTUsMw0KKHByb2JlMTc6YWFjcDE6 MDoyOjApOiBSZXNlcnZlZCBBU0MvQVNDUSBwYWlyDQoocHJvYmUxODphYWNw MTowOjM6MCk6IElOUVVJUlkuIENEQjogMTIgMCAwIDAgMjQgMCANCihwcm9i ZTE4OmFhY3AxOjA6MzowKTogSUxMRUdBTCBSRVFVRVNUIGFzYzo1NSwzDQoo cHJvYmUxODphYWNwMTowOjM6MCk6IFJlc2VydmVkIEFTQy9BU0NRIHBhaXIN Cihwcm9iZTE5OmFhY3AxOjA6NDowKTogSU5RVUlSWS4gQ0RCOiAxMiAwIDAg MCAyNCAwIA0KKHByb2JlMTk6YWFjcDE6MDo0OjApOiBJTExFR0FMIFJFUVVF U1QgYXNjOjU1LDMNCihwcm9iZTE5OmFhY3AxOjA6NDowKTogUmVzZXJ2ZWQg QVNDL0FTQ1EgcGFpcg0KKHByb2JlMjA6YWFjcDE6MDo1OjApOiBJTlFVSVJZ LiBDREI6IDEyIDAgMCAwIDI0IDAgDQoocHJvYmUyMDphYWNwMTowOjU6MCk6 IElMTEVHQUwgUkVRVUVTVCBhc2M6NTUsMw0KKHByb2JlMjA6YWFjcDE6MDo1 OjApOiBSZXNlcnZlZCBBU0MvQVNDUSBwYWlyDQoocHJvYmUyMTphYWNwMTow OjY6MCk6IElOUVVJUlkuIENEQjogMTIgMCAwIDAgMjQgMCANCihwcm9iZTIx OmFhY3AxOjA6NjowKTogSUxMRUdBTCBSRVFVRVNUIGFzYzo1NSwzDQoocHJv YmUyMTphYWNwMTowOjY6MCk6IFJlc2VydmVkIEFTQy9BU0NRIHBhaXINCihw cm9iZTIyOmFhY3AxOjA6ODowKTogSU5RVUlSWS4gQ0RCOiAxMiAwIDAgMCAy NCAwIA0KKHByb2JlMjI6YWFjcDE6MDo4OjApOiBJTExFR0FMIFJFUVVFU1Qg YXNjOjU1LDMNCihwcm9iZTIyOmFhY3AxOjA6ODowKTogUmVzZXJ2ZWQgQVND L0FTQ1EgcGFpcg0KKHByb2JlMjM6YWFjcDE6MDo5OjApOiBJTlFVSVJZLiBD REI6IDEyIDAgMCAwIDI0IDAgDQoocHJvYmUyMzphYWNwMTowOjk6MCk6IElM TEVHQUwgUkVRVUVTVCBhc2M6NTUsMw0KKHByb2JlMjM6YWFjcDE6MDo5OjAp OiBSZXNlcnZlZCBBU0MvQVNDUSBwYWlyDQoocHJvYmUyNDphYWNwMTowOjEw OjApOiBJTlFVSVJZLiBDREI6IDEyIDAgMCAwIDI0IDAgDQoocHJvYmUyNDph YWNwMTowOjEwOjApOiBJTExFR0FMIFJFUVVFU1QgYXNjOjU1LDMNCihwcm9i ZTI0OmFhY3AxOjA6MTA6MCk6IFJlc2VydmVkIEFTQy9BU0NRIHBhaXINCihw cm9iZTI1OmFhY3AxOjA6MTE6MCk6IElOUVVJUlkuIENEQjogMTIgMCAwIDAg MjQgMCANCihwcm9iZTI1OmFhY3AxOjA6MTE6MCk6IElMTEVHQUwgUkVRVUVT VCBhc2M6NTUsMw0KKHByb2JlMjU6YWFjcDE6MDoxMTowKTogUmVzZXJ2ZWQg QVNDL0FTQ1EgcGFpcg0KKHByb2JlMjY6YWFjcDE6MDoxMjowKTogSU5RVUlS WS4gQ0RCOiAxMiAwIDAgMCAyNCAwIA0KKHByb2JlMjY6YWFjcDE6MDoxMjow KTogSUxMRUdBTCBSRVFVRVNUIGFzYzo1NSwzDQoocHJvYmUyNjphYWNwMTow OjEyOjApOiBSZXNlcnZlZCBBU0MvQVNDUSBwYWlyDQoocHJvYmUyNzphYWNw MTowOjEzOjApOiBJTlFVSVJZLiBDREI6IDEyIDAgMCAwIDI0IDAgDQoocHJv YmUyNzphYWNwMTowOjEzOjApOiBJTExFR0FMIFJFUVVFU1QgYXNjOjU1LDMN Cihwcm9iZTI3OmFhY3AxOjA6MTM6MCk6IFJlc2VydmVkIEFTQy9BU0NRIHBh aXINCihwcm9iZTI4OmFhY3AxOjA6MTQ6MCk6IElOUVVJUlkuIENEQjogMTIg MCAwIDAgMjQgMCANCihwcm9iZTI4OmFhY3AxOjA6MTQ6MCk6IElMTEVHQUwg UkVRVUVTVCBhc2M6NTUsMw0KKHByb2JlMjg6YWFjcDE6MDoxNDowKTogUmVz ZXJ2ZWQgQVNDL0FTQ1EgcGFpcg0KKHByb2JlMjk6YWFjcDE6MDoxNTowKTog SU5RVUlSWS4gQ0RCOiAxMiAwIDAgMCAyNCAwIA0KKHByb2JlMjk6YWFjcDE6 MDoxNTowKTogSUxMRUdBTCBSRVFVRVNUIGFzYzo1NSwzDQoocHJvYmUyOTph YWNwMTowOjE1OjApOiBSZXNlcnZlZCBBU0MvQVNDUSBwYWlyDQpTTVA6IEFQ IENQVSAjMSBMYXVuY2hlZCENClNNUDogQVAgQ1BVICMyIExhdW5jaGVkIQ0K U01QOiBBUCBDUFUgIzMgTGF1bmNoZWQhDQpUcnlpbmcgdG8gbW91bnQgcm9v dCBmcm9tIHVmczovZGV2L2FhY2QwczFhDQo= --0-1529708662-1127930927=:56436-- From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 28 22:13:33 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 1809816A41F for ; Wed, 28 Sep 2005 22:13:33 +0000 (GMT) (envelope-from fergus@cobbled.net) Received: from ni-mail1.dna.utvinternet.net (mail1.u.tv [194.46.8.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 763EB43D48 for ; Wed, 28 Sep 2005 22:13:31 +0000 (GMT) (envelope-from fergus@cobbled.net) Received: from mail.cobbled.net (unverified [194.46.136.88]) by ni-mail1.dna.utvinternet.net (Vircom SMTPRS 4.2.420.1) with ESMTP id ; Wed, 28 Sep 2005 23:13:26 +0100 X-Modus-BlackList: 194.46.136.88=OK;fergus@cobbled.net=OK X-Modus-Trusted: 194.46.136.88=YES Received: from eyore.cobbled.net (localhost [127.0.0.1]) by mail.cobbled.net (8.12.10/8.12.10) with ESMTP id j8SMDNTI000895; Wed, 28 Sep 2005 23:13:23 +0100 (BST) (envelope-from fergus@eyore.public.cobbled.net) Received: (from fergus@localhost) by eyore.cobbled.net (8.12.10/8.12.10/Submit) id j8SMDMYK000894; Wed, 28 Sep 2005 23:13:22 +0100 (BST) (envelope-from fergus) Date: Wed, 28 Sep 2005 23:13:22 +0100 From: n0g0013 To: rashmi ns Message-ID: <20050928221322.GB267@eyore.cobbled.net> Mail-Followup-To: rashmi ns , bugi@lists.redbrick.dcu.ie, freebsd-hackers@freebsd.org References: <9f999316050928011010542946@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9f999316050928011010542946@mail.gmail.com> X-Mailman-Approved-At: Thu, 29 Sep 2005 11:54:53 +0000 Cc: freebsd-hackers@freebsd.org, bugi@lists.redbrick.dcu.ie Subject: Re: [BUGI] IOCTL :Facing problems while acccessing data from kernel space X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2005 22:13:33 -0000 On 28.09-13:40, rashmi ns wrote: [ ... ] > I was trying to add a new ioctl command like > > #define HDLCMODE _IOR('6',0xF,int) > > when i trying to uprintf the data which was sent from the user-space in > > the device-driver-ioctl-routine i'll get a different value than which was > > passed. Can anybody please tell me why this is happening . I pass the > > address of an integer where data is stored from the user space as third arg > > to the ioctl call . i would guess that it's a simple typo and your pointer conversions are off somewhere. i.e. uprintf( "%d", (int*)data ) ; instead of uprintf( "%d", *(int*)data ) ; otherwise, use a debugger or post the code. -- t t w From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 29 02:10:23 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 E236C16A41F for ; Thu, 29 Sep 2005 02:10:22 +0000 (GMT) (envelope-from mwm-dated-1128823868.97bd69@mired.org) Received: from delight.idiom.com (outbound.idiom.com [216.240.47.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E1BB43D49 for ; Thu, 29 Sep 2005 02:10:22 +0000 (GMT) (envelope-from mwm-dated-1128823868.97bd69@mired.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id ACD031F9489 for ; Wed, 28 Sep 2005 19:10:21 -0700 (PDT) Received: from mired.org (mwm@idiom [216.240.32.1]) by idiom.com (8.12.11/8.12.11) with SMTP id j8T2AJ2T072337 for ; Wed, 28 Sep 2005 19:10:20 -0700 (PDT) (envelope-from mwm-dated-1128823868.97bd69@mired.org) Received: (qmail 35465 invoked by uid 1001); 29 Sep 2005 02:11:09 -0000 Received: by localhost.mired.org (tmda-sendmail, from uid 1001); Wed, 28 Sep 2005 22:11:08 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17211.19772.562587.908715@bhuda.mired.org> Date: Wed, 28 Sep 2005 22:11:08 -0400 To: aanton@smtpx.spintech.ro In-Reply-To: <433B3F41.8060004@spintech.ro> References: <433B3F41.8060004@spintech.ro> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" 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: Thu, 29 Sep 2005 11:54:53 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: journaling fs and large mailbox format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 02:10:23 -0000 In <433B3F41.8060004@spintech.ro>, Alin-Adrian Anton typed: > I am in the position to implement a large-scale mail server and I will > never go for anything else but FreeBSD (fixation?). How are users going to get to the mail? Web browsers? IMAP? POP? > I don't know if the mbox format can handle this, and I know Maildir > cannot handle this on UFS2 standard install, no matter of soft-updates. > (because it exhaustes the free nodes) So I currently have no solution > for this stuff. Large mailboxes in mbox format are a loss, because you have to rewrite all/most of the mailbox to make changes in it. In particular, a fetchmail process - read and delete the messages in chronological order - is an O(n**2) process. This applies to pretty much any mail format that stores all the messages in one file. The alternatives are things like mh and Mailder. Yes, those will have problems on UFS file systems that you build with the default parameters. That's because mail messages tend to be very small files - typically a few k - so a file system full of them is will have a very odd distribution of files sizes when compared to more usual file systems. The solution isn't to avoid Maildir/mh - the solution is to tune the file system for the expected usage. FreeBSD (and Unix in general) gives you lots of knobs to deal with things like this. Learn to use them. The default block and frag size are relatively large - 2K and 16K appear to be the defaults on 5.x. A quick look at my mail for 2005 shows 32,267 messages ranging from 280 bytes to 6+ meg, with a mean size of less than 8K. I'd go with 4k blocks and a 512 byte frag size - because that will give you four times as many inodes as the default parameters. 8K/1K is also tempting, but you'll probably want to specify -i 2048 to get the same number of inodes as you get with a 4K/512b file system. > I was wondering what is the status of Journaling File Systems on > FreeBSD? Any which is usable and mature, with write access? XFS would > fit amazingly well with Maildir, but.. I doubt it's anything else but > readonly. Neither journaling nor soft updates would solve the problem of running out of inodes. The only solution there is more inodes. XFS may be flexible enough to deal with file systems that far from the norm - but I wouldn't write a business plan based on it without checking first. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 29 03:56:33 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 19AD816A41F for ; Thu, 29 Sep 2005 03:56:33 +0000 (GMT) (envelope-from vvelox@vvelox.net) Received: from S2.cableone.net (s2.cableone.net [24.116.0.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id A380A43D48 for ; Thu, 29 Sep 2005 03:56:28 +0000 (GMT) (envelope-from vvelox@vvelox.net) Received: from vixen42.vulpes (unverified [24.119.122.41]) by S2.cableone.net (CableOne SMTP Service S2) with ESMTP id 31501747 for multiple; Wed, 28 Sep 2005 20:56:53 -0700 Date: Wed, 28 Sep 2005 23:01:03 -0500 From: "Z.C.B." To: aanton@spintech.ro Message-ID: <20050928230103.6a5f9aa5@vixen42.vulpes> In-Reply-To: <433B3F41.8060004@spintech.ro> References: <433B3F41.8060004@spintech.ro> X-Mailer: Sylpheed-Claws 1.9.14 (GTK+ 2.6.10; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-IP-stats: Incoming Last 0, First 133, in=202, out=0, spam=0 X-External-IP: 24.119.122.41 X-Abuse-Info: Send abuse complaints to abuse@cableone.net X-Mailman-Approved-At: Thu, 29 Sep 2005 11:54:53 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: journaling fs and large mailbox format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 03:56:33 -0000 =46rom personal experience on a smaller system(~1000 accounts and nearly all ways less than 45MB boxes) I would suggest avoiding mboxes all together. Maildir is all ways the way to go. For cleaning stuff out automatically and ect, maildir is much nicer as well. Also is this vnodes or inodes? See the tuning man pages. For vnodes, there are some sysctls. On Thu, 29 Sep 2005 04:11:29 +0300 Alin-Adrian Anton wrote: > Dear Hackers, >=20 > First of all thank you for your time and attention. >=20 > I am in the position to implement a large-scale mail server > and I will never go for anything else but FreeBSD (fixation?). >=20 > It should be able to handle graceously 4000 e-mail accounts > where a minimum of 50 Mb/mailbox would be a requirement. In the > begining, it is desirable that users could use as much free space > as available, so this implies some gigabytes/mailbox. >=20 > I don't know if the mbox format can handle this, and I know > Maildir cannot handle this on UFS2 standard install, no matter of > soft-updates. (because it exhaustes the free nodes) So I currently > have no solution for this stuff. >=20 > I was wondering what is the status of Journaling File > Systems on FreeBSD? Any which is usable and mature, with write > access? XFS would fit amazingly well with Maildir, but.. I doubt > it's anything else but readonly. >=20 > So any suggestion would really help a lot. Thank's in > advance. >=20 > =09 > Yours Sincerely, > --=20 > Alin-Adrian Anton > GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 > 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA >=20 > "It is dangerous to be right when the government is wrong." - > Voltaire From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 29 16:55:45 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 768AA16A41F for ; Thu, 29 Sep 2005 16:55:45 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6AED43D48 for ; Thu, 29 Sep 2005 16:55:43 +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 (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.4/8.13.3) with ESMTP id j8TGtcji021257 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 29 Sep 2005 18:55:38 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.4/8.13.3/Submit) id j8TGtcWc021256 for hackers@freebsd.org; Thu, 29 Sep 2005 18:55:38 +0200 (CEST) Date: Thu, 29 Sep 2005 18:55:38 +0200 From: Divacky Roman To: hackers@freebsd.org Message-ID: <20050929165538.GA20614@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.49 on 147.229.10.14 Cc: Subject: dev_lock() question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 16:55:45 -0000 Hi, dev_lock() looks this way: void dev_lock(void) { if (!mtx_initialized(&devmtx)) mtx_init(&devmtx, "cdev", NULL, MTX_DEF); mtx_lock(&devmtx); } I wonder why is the mtx_initialized checking necessary? shouldnt explicit initialization be sufficient? thnx for answer roman From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 29 17:08:26 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 D603B16A41F for ; Thu, 29 Sep 2005 17:08:26 +0000 (GMT) (envelope-from stas@core.310.ru) Received: from core.310.ru (core.310.ru [83.97.105.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02FA543D5F for ; Thu, 29 Sep 2005 17:08:25 +0000 (GMT) (envelope-from stas@core.310.ru) Received: from core.310.ru (localhost [127.0.0.1]) by core.310.ru (8.13.3/8.12.11) with ESMTP id j8TH4PJB011640; Thu, 29 Sep 2005 21:04:25 +0400 (MSD) (envelope-from stas@core.310.ru) Received: (from stas@localhost) by core.310.ru (8.13.3/8.12.11/Submit) id j8TH4PDR011639; Thu, 29 Sep 2005 21:04:25 +0400 (MSD) (envelope-from stas) Date: Thu, 29 Sep 2005 21:04:25 +0400 From: Stanislav Sedov To: Divacky Roman Message-ID: <20050929170425.GB3526@core.310.ru> References: <20050929165538.GA20614@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20050929165538.GA20614@stud.fit.vutbr.cz> User-Agent: Mutt/1.4.2.1i Cc: hackers@freebsd.org Subject: Re: dev_lock() question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 17:08:27 -0000 On Thu, Sep 29, 2005 at 06:55:38PM +0200, Divacky Roman wrote: > Hi, > > dev_lock() looks this way: > > void > dev_lock(void) > { > if (!mtx_initialized(&devmtx)) > mtx_init(&devmtx, "cdev", NULL, MTX_DEF); > mtx_lock(&devmtx); > } > > I wonder why is the mtx_initialized checking necessary? shouldnt explicit > initialization be sufficient? > > thnx for answer > > roman Moving "mtx_initialized()" check into mtx_init will decrease speed of other mutexes initialization. We must check if it's initialized here because of it's not permiited to pass already initialized mutex to mtx_init(). From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 29 18:07:02 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 55A6416A420; Thu, 29 Sep 2005 18:07:02 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B54F43D4C; Thu, 29 Sep 2005 18:07:01 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.233] (Not Verified[10.50.41.233]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Thu, 29 Sep 2005 14:23:02 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org, Poul-Henning Kamp Date: Thu, 29 Sep 2005 14:08:16 -0400 User-Agent: KMail/1.8 References: <20050929165538.GA20614@stud.fit.vutbr.cz> <20050929170425.GB3526@core.310.ru> In-Reply-To: <20050929170425.GB3526@core.310.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509291408.18098.jhb@FreeBSD.org> Cc: Divacky Roman , Stanislav Sedov Subject: Re: dev_lock() question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 18:07:02 -0000 On Thursday 29 September 2005 01:04 pm, Stanislav Sedov wrote: > On Thu, Sep 29, 2005 at 06:55:38PM +0200, Divacky Roman wrote: > > Hi, > > > > dev_lock() looks this way: > > > > void > > dev_lock(void) > > { > > if (!mtx_initialized(&devmtx)) > > mtx_init(&devmtx, "cdev", NULL, MTX_DEF); > > mtx_lock(&devmtx); > > } > > > > I wonder why is the mtx_initialized checking necessary? shouldnt explicit > > initialization be sufficient? > > > > thnx for answer > > > > roman > > Moving "mtx_initialized()" check into mtx_init will decrease speed of other > mutexes initialization. We must check if it's initialized here because of > it's not permiited to pass already initialized mutex to mtx_init(). Actually, you would think that it could be initialized either via an early SYSINIT() or in the init_mutexes() function in kern_mutex.c and thus not need the early check and avoid penalizing dev_lock(). phk, how early his dev_lock needed? -- 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 Sep 29 18:09:26 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 EA7FB16A41F; Thu, 29 Sep 2005 18:09:26 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11F7943D6E; Thu, 29 Sep 2005 18:09:24 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 429BC46B9D; Thu, 29 Sep 2005 14:09:24 -0400 (EDT) Date: Thu, 29 Sep 2005 19:09:24 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Rob Watt In-Reply-To: <20050928134724.P56436@daemon.mistermishap.net> Message-ID: <20050929185538.R61419@fledge.watson.org> References: <20050925115912.H11229@fledge.watson.org> <20050927140535.G50334@daemon.mistermishap.net> <20050927203128.S61419@fledge.watson.org> <20050927222624.R34322@fledge.watson.org> <20050928134724.P56436@daemon.mistermishap.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@FreeBSD.org, mikep@hudson-trading.com, freebsd-amd64@FreeBSD.org, Jason Carroll Subject: Re: freebsd-5.4-stable panics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 18:09:27 -0000 On Wed, 28 Sep 2005, Rob Watt wrote: > We re-compiled the kernel with 'options KDB_STOP_NMI', and were able to > get a much more full analysis of what was happening on the 6-BETA5 > crash. Great. > We crashed in top again, and it does look like we may have hit a > kern_proc bug. This sounds good, or at least, promising. > in the attached file type3-core.txt you can see that it hits an > exception in: > > 0xffffffff802b897a is in fill_kinfo_thread > (/usr/src/sys/kern/kern_proc.c:736). > 731 } > 732 > 733 kg = td->td_ksegrp; > 734 > 735 /* things in the KSE GROUP */ > 736 kp->ki_estcpu = kg->kg_estcpu; > 737 kp->ki_slptime = kg->kg_slptime; > 738 kp->ki_pri.pri_user = kg->kg_user_pri; > 739 kp->ki_pri.pri_class = kg->kg_pri_class; > 740 > (kgdb) frame 8 > #8 0xffffffff802b897a in fill_kinfo_thread (td=0xffffff0063311260, > kp=0xffffffffb62d8510) > at /usr/src/sys/kern/kern_proc.c:733 > 733 kg = td->td_ksegrp; > (kgdb) p kg->kg_estcpu > Cannot access memory at address 0x173 > (kgdb) p td->td_ksegrp > $1 = (struct ksegrp *) 0x0 > (kgdb) p kp->ki_estcpu > $2 = 0 > (kgdb) p kg > $4 = (struct ksegrp *) 0x12b > > it seems that kg is an invalid pointer. Could you dump the contents of *td and *td->td_proc for me? I'm quite interested to know what the value in td->td_proc->p_state is, among other things. If I could also have you generate a dump of the KSE group structures in td->td_proc->p_ksegrps and the threads in td->td_proc->p_threads. Could you tell me if the program named by p->p_comm is linked against a threading library? If it's a custom app, you may already know, and if not, you can run ldd on the application to see what it is linked against. Depending on how much time you have available, it might make sense for me to grab from you a copy of your source tree, compiled kernel with debug symbols, and core dump. > We have started our tests again without running top. > > Hope you have a great vacation. It was brief but very enjoyable, and quite disconnected :-). Thanks, Robert From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 29 18:11:01 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 1705016A41F for ; Thu, 29 Sep 2005 18:11:01 +0000 (GMT) (envelope-from reichert@numachi.com) Received: from meisai.numachi.com (meisai.numachi.com [198.175.254.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 8440D43D48 for ; Thu, 29 Sep 2005 18:11:00 +0000 (GMT) (envelope-from reichert@numachi.com) Received: (qmail 87508 invoked from network); 29 Sep 2005 18:10:41 -0000 Received: from natto.numachi.com (198.175.254.216) by meisai.numachi.com with SMTP; 29 Sep 2005 18:10:41 -0000 Received: (qmail 88741 invoked by uid 1001); 29 Sep 2005 18:10:55 -0000 Date: Thu, 29 Sep 2005 14:10:55 -0400 From: Brian Reichert To: freebsd-hackers@freebsd.org Message-ID: <20050929181055.GF74605@numachi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Subject: anyone using security/dropbear? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 18:11:01 -0000 I've tried using the dropbear client (0.46), built both from source and ports, and consistently get this message: dbclient: Warning: Reading the random source seems to have blocked. If you experience problems, you probably need to find a better entropy source. Googling for this diagnostic yields essentially no info, so I don't know if there's something weird about my FBSD install (4.11-R). Has anyone seen this before, or have any advice on the matter? -- 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 Thu Sep 29 18:14:15 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 E37A516A41F for ; Thu, 29 Sep 2005 18:14:15 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id A468C43D48 for ; Thu, 29 Sep 2005 18:14:15 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [70.30.70.180]) by elvis.mu.org (Postfix) with ESMTP id 834861A3C1F; Thu, 29 Sep 2005 11:14:15 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id EA762513C1; Thu, 29 Sep 2005 14:14:13 -0400 (EDT) Date: Thu, 29 Sep 2005 14:14:13 -0400 From: Kris Kennaway To: Brian Reichert Message-ID: <20050929181413.GA87227@xor.obsecurity.org> References: <20050929181055.GF74605@numachi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: <20050929181055.GF74605@numachi.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: anyone using security/dropbear? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 18:14:16 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 29, 2005 at 02:10:55PM -0400, Brian Reichert wrote: > I've tried using the dropbear client (0.46), built both from source and > ports, and consistently get this message: >=20 > dbclient: Warning: Reading the random source seems to have blocked. > If you experience problems, you probably need to find a better entropy > source. >=20 > Googling for this diagnostic yields essentially no info, so I don't > know if there's something weird about my FBSD install (4.11-R). >=20 > Has anyone seen this before, or have any advice on the matter? Check the source.. is it using /dev/urandom (which never blocks), or /dev/random (which I still don't think blocks, but may return short reads). Either way, it sounds like some level of application bug...it probably should be using the former source, but even if it's not, it shouldn't be blocking. Kris --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDPC71Wry0BWjoQKURAlMoAJ9M6Cfo3lvrlMpF/lE8rfhXZqH5rQCfa/Z4 cMsWmwDtqpHrYaKPMwYYkYM= =NVtY -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 29 18:14:41 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 6739B16A41F; Thu, 29 Sep 2005 18:14:41 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D1BF43D48; Thu, 29 Sep 2005 18:14:40 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 4AC3DBC74; Thu, 29 Sep 2005 18:14:39 +0000 (UTC) To: John Baldwin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 29 Sep 2005 14:08:16 EDT." <200509291408.18098.jhb@FreeBSD.org> Date: Thu, 29 Sep 2005 20:14:39 +0200 Message-ID: <15314.1128017679@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-hackers@freebsd.org, Divacky Roman , Stanislav Sedov Subject: Re: dev_lock() question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 18:14:41 -0000 In message <200509291408.18098.jhb@FreeBSD.org>, John Baldwin writes: >Actually, you would think that it could be initialized either via an early >SYSINIT() or in the init_mutexes() function in kern_mutex.c and thus not need >the early check and avoid penalizing dev_lock(). > >phk, how early his dev_lock needed? Far too early due to console madness (in syscons I belive). -- 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 Thu Sep 29 18:16:24 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 E19A516A41F for ; Thu, 29 Sep 2005 18:16:24 +0000 (GMT) (envelope-from reichert@numachi.com) Received: from meisai.numachi.com (meisai.numachi.com [198.175.254.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 4D69643D49 for ; Thu, 29 Sep 2005 18:16:24 +0000 (GMT) (envelope-from reichert@numachi.com) Received: (qmail 87585 invoked from network); 29 Sep 2005 18:16:08 -0000 Received: from natto.numachi.com (198.175.254.216) by meisai.numachi.com with SMTP; 29 Sep 2005 18:16:08 -0000 Received: (qmail 88811 invoked by uid 1001); 29 Sep 2005 18:16:23 -0000 Date: Thu, 29 Sep 2005 14:16:23 -0400 From: Brian Reichert To: Kris Kennaway Message-ID: <20050929181623.GG74605@numachi.com> References: <20050929181055.GF74605@numachi.com> <20050929181413.GA87227@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050929181413.GA87227@xor.obsecurity.org> User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@freebsd.org Subject: Re: anyone using security/dropbear? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 18:16:25 -0000 On Thu, Sep 29, 2005 at 02:14:13PM -0400, Kris Kennaway wrote: > Check the source.. is it using /dev/urandom (which never blocks), or > /dev/random (which I still don't think blocks, but may return short > reads). Either way, it sounds like some level of application bug...it > probably should be using the former source, but even if it's not, it > shouldn't be blocking. ktrace shows /dev/random, and indeed, very short reads. Let me try another maunal build, pushing it to /dev/urandom. Thanks for the quick feedback... > Kris -- 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 Thu Sep 29 18:21:40 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 3D40916A41F for ; Thu, 29 Sep 2005 18:21:40 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D108A43D49 for ; Thu, 29 Sep 2005 18:21:39 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.23] (andersonbox3.centtech.com [192.168.42.23]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j8TILco1030353 for ; Thu, 29 Sep 2005 13:21:38 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <433C30AB.2030409@centtech.com> Date: Thu, 29 Sep 2005 13:21:31 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.11) Gecko/20050914 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 X-Virus-Scanned: ClamAV 0.82/1104/Wed Sep 28 17:20:40 2005 on mh2.centtech.com X-Virus-Status: Clean Subject: ufsstat implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 18:21:40 -0000 I've been looking at the ufs code, and thinking about wedging in some statistic gathering pieces pretty much copied from the nfs code (and nfsstat) to provide nearly the same functionality. I realize that adding statistic gathering code would techinically reduce filesystem performance, so should I put a wrapper around the code pieces checking a sysctl, or use #ifdef's around it, or neither? Also - am I going about this the right way, or is there a better way to record these statistics? Thanks! Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 29 18:58:38 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 F07EE16A41F for ; Thu, 29 Sep 2005 18:58:38 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAE4043D62 for ; Thu, 29 Sep 2005 18:58:34 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from flame.pc (aris.bedc.ondsl.gr [62.103.39.226]) by rosebud.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j8TIwQXD031390; Thu, 29 Sep 2005 21:58:27 +0300 Received: from flame.pc (flame [127.0.0.1]) by flame.pc (8.13.4/8.13.4) with ESMTP id j8TIvo12015755; Thu, 29 Sep 2005 21:57:50 +0300 (EEST) (envelope-from keramida@linux.gr) Received: (from keramida@localhost) by flame.pc (8.13.4/8.13.4/Submit) id j8TIvnRt015754; Thu, 29 Sep 2005 21:57:49 +0300 (EEST) (envelope-from keramida@linux.gr) Date: Thu, 29 Sep 2005 21:57:49 +0300 From: Giorgos Keramidas To: Eric Anderson Message-ID: <20050929185749.GB15714@flame.pc> References: <433C30AB.2030409@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <433C30AB.2030409@centtech.com> Cc: freebsd-hackers@freebsd.org Subject: Re: ufsstat implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 18:58:39 -0000 On 2005-09-29 13:21, Eric Anderson wrote: > I've been looking at the ufs code, and thinking about wedging in some > statistic gathering pieces pretty much copied from the nfs code (and > nfsstat) to provide nearly the same functionality. > > I realize that adding statistic gathering code would techinically reduce > filesystem performance, so should I put a wrapper around the code pieces > checking a sysctl, or use #ifdef's around it, or neither? It would take running an implementation with and without ufsstats to see what the impact on filesystem performance is, so it seems to me the natural choise for early stages of development is an #ifdef that can easily be turned on/off and control where all of the code goes in or nothing at all :-) From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 29 18:59:19 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 701FD16A41F for ; Thu, 29 Sep 2005 18:59:19 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4492A43D6D for ; Thu, 29 Sep 2005 18:59:07 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.233] (Not Verified[10.50.41.233]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Thu, 29 Sep 2005 15:15:03 -0400 From: John Baldwin To: "Poul-Henning Kamp" Date: Thu, 29 Sep 2005 14:55:58 -0400 User-Agent: KMail/1.8 References: <15314.1128017679@critter.freebsd.dk> In-Reply-To: <15314.1128017679@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509291455.59914.jhb@FreeBSD.org> Cc: freebsd-hackers@FreeBSD.org, Divacky Roman , Stanislav Sedov Subject: Re: dev_lock() question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 18:59:19 -0000 On Thursday 29 September 2005 02:14 pm, Poul-Henning Kamp wrote: > In message <200509291408.18098.jhb@FreeBSD.org>, John Baldwin writes: > >Actually, you would think that it could be initialized either via an early > >SYSINIT() or in the init_mutexes() function in kern_mutex.c and thus not > > need the early check and avoid penalizing dev_lock(). > > > >phk, how early his dev_lock needed? > > Far too early due to console madness (in syscons I belive). So would mutex_init() work? It's called very early in the MD startup code right after things like curthread are initialized. If dev_lock() is called before mutex_init() it can't work right anyway as mtx_init() doesn't work until then. -- 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 Sep 29 19:36:56 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 F0A8916A41F; Thu, 29 Sep 2005 19:36:56 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 938AC43D49; Thu, 29 Sep 2005 19:36:56 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 53FE5BC74; Thu, 29 Sep 2005 19:36:54 +0000 (UTC) To: John Baldwin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 29 Sep 2005 14:55:58 EDT." <200509291455.59914.jhb@FreeBSD.org> Date: Thu, 29 Sep 2005 21:36:53 +0200 Message-ID: <15627.1128022613@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-hackers@FreeBSD.org, Divacky Roman , Stanislav Sedov Subject: Re: dev_lock() question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 19:36:57 -0000 In message <200509291455.59914.jhb@FreeBSD.org>, John Baldwin writes: >On Thursday 29 September 2005 02:14 pm, Poul-Henning Kamp wrote: >> In message <200509291408.18098.jhb@FreeBSD.org>, John Baldwin writes: >> >Actually, you would think that it could be initialized either via an early >> >SYSINIT() or in the init_mutexes() function in kern_mutex.c and thus not >> > need the early check and avoid penalizing dev_lock(). >> > >> >phk, how early his dev_lock needed? >> >> Far too early due to console madness (in syscons I belive). > >So would mutex_init() work? Havn't tried. It basically has to work right before the copyright is printed. -- 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 Thu Sep 29 19:58:20 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 45F4E16A41F for ; Thu, 29 Sep 2005 19:58:20 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.62]) by mx1.FreeBSD.org (Postfix) with SMTP id A950643D4C for ; Thu, 29 Sep 2005 19:58:19 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 44270 invoked by uid 399); 29 Sep 2005 19:58:18 -0000 Received: from mail1.fluidhosting.com (204.14.90.61) by mail2.fluidhosting.com with SMTP; 29 Sep 2005 19:58:18 -0000 Received: (qmail 19887 invoked by uid 399); 29 Sep 2005 19:58:18 -0000 Received: from localhost (HELO ?192.168.1.100?) (dougb@dougbarton.net@127.0.0.1) by localhost with SMTP; 29 Sep 2005 19:58:18 -0000 Message-ID: <433C4759.7010000@FreeBSD.org> Date: Thu, 29 Sep 2005 12:58:17 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050908) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Reichert References: <20050929181055.GF74605@numachi.com> <20050929181413.GA87227@xor.obsecurity.org> <20050929181623.GG74605@numachi.com> In-Reply-To: <20050929181623.GG74605@numachi.com> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Kris Kennaway Subject: Re: anyone using security/dropbear? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 19:58:20 -0000 Brian Reichert wrote: > On Thu, Sep 29, 2005 at 02:14:13PM -0400, Kris Kennaway wrote: > >>Check the source.. is it using /dev/urandom (which never blocks), or >>/dev/random (which I still don't think blocks, but may return short >>reads). Either way, it sounds like some level of application bug...it >>probably should be using the former source, but even if it's not, it >>shouldn't be blocking. > > > ktrace shows /dev/random, and indeed, very short reads. > > Let me try another maunal build, pushing it to /dev/urandom. Depending on why that program needs random bits, that could be a very bad idea. Take a look at the following page and see if it helps: http://people.freebsd.org/~dougb/randomness.html -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 29 20:36:39 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 51A7116A41F for ; Thu, 29 Sep 2005 20:36:39 +0000 (GMT) (envelope-from reichert@numachi.com) Received: from meisai.numachi.com (meisai.numachi.com [198.175.254.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 8138243D58 for ; Thu, 29 Sep 2005 20:36:36 +0000 (GMT) (envelope-from reichert@numachi.com) Received: (qmail 88961 invoked from network); 29 Sep 2005 20:36:20 -0000 Received: from natto.numachi.com (198.175.254.216) by meisai.numachi.com with SMTP; 29 Sep 2005 20:36:19 -0000 Received: (qmail 3516 invoked by uid 1001); 29 Sep 2005 20:36:35 -0000 Date: Thu, 29 Sep 2005 16:36:35 -0400 From: Brian Reichert To: Doug Barton Message-ID: <20050929203635.GI74605@numachi.com> References: <20050929181055.GF74605@numachi.com> <20050929181413.GA87227@xor.obsecurity.org> <20050929181623.GG74605@numachi.com> <433C4759.7010000@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <433C4759.7010000@FreeBSD.org> User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@freebsd.org, Kris Kennaway Subject: Re: anyone using security/dropbear? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 20:36:39 -0000 On Thu, Sep 29, 2005 at 12:58:17PM -0700, Doug Barton wrote: > Depending on why that program needs random bits, that could be a very bad > idea. Take a look at the following page and see if it helps: > > http://people.freebsd.org/~dougb/randomness.html A handy resource, thanks. As I mentioned in some private email on this matter, my short-term goal was to just get it working, to suss out the behavior of the CLI. If I adopt this tool, I'll certainly take all of these suggestions into account. (Again, to all: thank for the feedback!) > -- > > This .signature sanitized for your protection > -- 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 Thu Sep 29 20:51:49 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 9F48916A41F; Thu, 29 Sep 2005 20:51:49 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37CED43D48; Thu, 29 Sep 2005 20:51:49 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id C57E646BAC; Thu, 29 Sep 2005 16:51:48 -0400 (EDT) Date: Thu, 29 Sep 2005 21:51:48 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Rob Watt In-Reply-To: <20050929160945.A65402@daemon.mistermishap.net> Message-ID: <20050929212738.A34322@fledge.watson.org> References: <20050925115912.H11229@fledge.watson.org> <20050927140535.G50334@daemon.mistermishap.net> <20050927203128.S61419@fledge.watson.org> <20050927222624.R34322@fledge.watson.org> <20050928134724.P56436@daemon.mistermishap.net> <20050929185538.R61419@fledge.watson.org> <20050929160945.A65402@daemon.mistermishap.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@FreeBSD.org, mikep@hudson-trading.com, freebsd-amd64@FreeBSD.org, Jason Carroll Subject: Re: freebsd-5.4-stable panics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 20:51:49 -0000 On Thu, 29 Sep 2005, Rob Watt wrote: > On Thu, 29 Sep 2005, Robert Watson wrote: > >> Could you dump the contents of *td and *td->td_proc for me? I'm quite >> interested to know what the value in td->td_proc->p_state is, among other >> things. If I could also have you generate a dump of the KSE group >> structures in td->td_proc->p_ksegrps and the threads in >> td->td_proc->p_threads. > > I've attached a file with many of the values you have asked for. We > looked at some of the threads referenced by td->td_proc->p_threads, but > we weren't sure we were walking the list correctly. Do you have any tips > for walking those thread lists? > >> Could you tell me if the program named by p->p_comm is linked against a >> threading library? If it's a custom app, you may already know, and if >> not, you can run ldd on the application to see what it is linked >> against. > > The programs named by p->p_comm is linked against the pthreads library. This seems to be enough information to at least track this down a bit: td_ksegrp is NULL, rather than a corrupt value, which suggests that the thread is incompletely initialized. Other hints that this are the case are that td_critnest is 1 (as is set when it is allocated), and the state is TDS_INACTIVE. Some other fields are set though, such as td_oncpu, which is normally initialized to NOCPU. > (kgdb) p *td > $1 = {td_proc = 0xffffff004aa9f000, td_ksegrp = 0x0, td_plist = > {tqe_next = 0xff ffff00b4798000, > tqe_prev = 0xffffff00a97ae010}, td_kglist = {tqe_next = > 0xffffff00b4798000, > tqe_prev = 0xffffff00a97ae020}, td_slpq = {tqe_next = 0x0, tqe_prev > = 0xffff ff001fac7c10}, td_lockq = { > tqe_next = 0xffffff00a97ae000, tqe_prev = 0xffffffffb6797a70}, > td_runq = {tq e_next = 0x0, > tqe_prev = 0xffffffff80608180}, td_selq = {tqh_first = 0x0, tqh_last > = 0xfff fff00633112c0}, > td_sleepqueue = 0xffffff00382b0400, td_turnstile = 0xffffff00c1712900, > td_umtx q = 0xffffff00d1207080, > td_tid = 100253, td_flags = 16777216, td_inhibitors = 0, td_pflags = > 128, td_d upfd = 0, td_wchan = 0x0, > td_wmesg = 0x0, td_lastcpu = 2 '\002', td_oncpu = 2 '\002', > td_owepreempt = 0 '\0', td_locks = 0, > td_blocked = 0x0, td_ithd = 0x0, td_lockname = 0x0, td_contested = > {lh_first = > 0x0}, td_sleeplocks = 0x0, > td_intr_nesting_level = 0, td_pinned = 0, td_mailbox = 0x0, td_ucred = > 0xfffff f00ad18f200, > td_standin = 0x0, td_upcall = 0x0, td_sticks = 0, td_uuticks = 0, > td_usticks = > 0, td_intrval = 0, > td_oldsigmask = {__bits = {0, 0, 0, 0}}, td_sigmask = {__bits = > {4294967295, 4 294967295, 4294967295, > 4294967295}}, td_siglist = {__bits = {0, 0, 0, 0}}, td_generation > = 14, td _sigstk = {ss_sp = 0x0, > ss_size = 0, ss_flags = 0}, td_kflags = 0, td_xsig = 0, > td_profil_addr = 0, td_profil_ticks = 0, > td_base_pri = 182 '\uffff', td_priority = 182 '\uffff', td_pcb = > 0xffffffffb68 dcd10, td_state = TDS_INACTIVE, > td_retval = {1, 29309280}, td_slpcallout = {c_links = {sle = {sle_next > = 0x0}, > tqe = {tqe_next = 0x0, > tqe_prev = 0xffffff001fac7d80}}, c_time = 55907602, c_arg = > 0xffffff0063 311260, > c_func = 0xffffffff802e32a0 , c_mtx = 0x0, c_flags = > 16}, td _frame = 0xffffffffb68dcc40, > td_kstack_obj = 0xffffff0087f93d20, td_kstack = 18446744072477315072, > td_kstac k_pages = 4, > td_altkstack_obj = 0x0, td_altkstack = 0, td_altkstack_pages = 0, > td_critnest = 1, td_md = { > md_spinlock_count = 1, md_saved_flags = 582}, td_sched = > 0xffffff0063311488} I'm not familiar with the internals of the thread and KSE life cycle here, so I think we'll need to look to those more familiar with this to understand what of two things may be going on: (1) Is the fact that td_ksegrp != NULL an invariant for a connected thread, and that kern_proc is relying on that but the thread code is failing to implement it safely? (2) Is td_ksegrp sometimes left legitimately as NULL as part of the thread life cycle, and that kern_proc incorrectly assumes that it is never NULL when hooked up to a thread. This suggests a possible work-around of simply testing td_ksegrp for NULL in kern_proc in order to avoid this, while attempting to resolve whether an invariant is violated (or incorrectly assumed), which might require some serious thinking and a solution that is non-trivial. Something like the following might work in the mean time: Index: kern_proc.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_proc.c,v retrieving revision 1.231 diff -u -r1.231 kern_proc.c --- kern_proc.c 27 Sep 2005 18:03:15 -0000 1.231 +++ kern_proc.c 29 Sep 2005 20:50:33 -0000 @@ -882,6 +882,8 @@ } else { _PHOLD(p); FOREACH_THREAD_IN_PROC(p, td) { + if (td->td_ksegrp == NULL) + continue; fill_kinfo_thread(td, &kinfo_proc); PROC_UNLOCK(p); error = SYSCTL_OUT(req, (caddr_t)&kinfo_proc, I'm going to forward off your e-mail to the threads@ list and see if anyone there wants to talk some more about this. If you don't mind testing the above patch to see if this is a workable work-around, we may want to think about getting it committed in the mean time. Thanks, Robert N M Watson From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 29 21:28:53 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 81A0316A41F for ; Thu, 29 Sep 2005 21:28:53 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.62]) by mx1.FreeBSD.org (Postfix) with SMTP id 08DAD43D49 for ; Thu, 29 Sep 2005 21:28:52 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 11469 invoked by uid 399); 29 Sep 2005 21:28:52 -0000 Received: from mail1.fluidhosting.com (204.14.90.61) by mail2.fluidhosting.com with SMTP; 29 Sep 2005 21:28:52 -0000 Received: (qmail 49763 invoked by uid 399); 29 Sep 2005 21:28:51 -0000 Received: from localhost (HELO ?192.168.1.100?) (dougb@dougbarton.net@127.0.0.1) by localhost with SMTP; 29 Sep 2005 21:28:51 -0000 Message-ID: <433C5C8B.6000003@FreeBSD.org> Date: Thu, 29 Sep 2005 14:28:43 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050908) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Meyer References: <433B3F41.8060004@spintech.ro> <17211.19772.562587.908715@bhuda.mired.org> In-Reply-To: <17211.19772.562587.908715@bhuda.mired.org> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, aanton@smtpx.spintech.ro Subject: Re: journaling fs and large mailbox format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 21:28:53 -0000 Mike Meyer wrote: > The solution isn't to avoid Maildir/mh - the solution is to tune the > file system for the expected usage. FreeBSD (and Unix in general) > gives you lots of knobs to deal with things like this. Learn to use > them. > > The default block and frag size are relatively large - 2K and 16K > appear to be the defaults on 5.x. A quick look at my mail for 2005 > shows 32,267 messages ranging from 280 bytes to 6+ meg, with a mean > size of less than 8K. I'd go with 4k blocks and a 512 byte frag size - > because that will give you four times as many inodes as the default > parameters. 8K/1K is also tempting, but you'll probably want to > specify -i 2048 to get the same number of inodes as you get with a > 4K/512b file system. I agree generally with your thinking here, and wanted to add a little more analysis based on my experience. When I was facing a similar problem with a large authoritative name server installation, I got the advice to find the median file size, and tune the file system so that the block size was 2x the median file size (with the fragment size being 1/8th the block size of course). The reasoning behind this was that because the files I was working with could grow, it made sense to make sure that even if it grew the file could stay within one block. This is slightly wasteful of space (very slightly), but resulted in a much more efficient operation. In this situation, since any given file in a maildir directory is very unlikely to grow, it seems to me to make sense that the right way to tune the fs would be to find the median file size and make the block size large enough to handle files of that size. That should give you the right tradeoff between speed and efficiency. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 29 21:36:56 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 CFA9516A41F for ; Thu, 29 Sep 2005 21:36:56 +0000 (GMT) (envelope-from mwm-keyword-hackers.e471b2@mired.org) Received: from delight.idiom.com (outbound.idiom.com [216.240.47.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 764CE43D48 for ; Thu, 29 Sep 2005 21:36:56 +0000 (GMT) (envelope-from mwm-keyword-hackers.e471b2@mired.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id 2D296225761 for ; Thu, 29 Sep 2005 14:36:56 -0700 (PDT) Received: from mired.org (mwm@idiom [216.240.32.1]) by idiom.com (8.12.11/8.12.11) with SMTP id j8TLakvn038352 for ; Thu, 29 Sep 2005 14:36:50 -0700 (PDT) (envelope-from mwm-keyword-hackers.e471b2@mired.org) Received: (qmail 64759 invoked by uid 1001); 29 Sep 2005 21:37:32 -0000 Received: by localhost.mired.org (tmda-sendmail, from uid 1001); Thu, 29 Sep 2005 17:37:31 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17212.24219.445685.297552@bhuda.mired.org> Date: Thu, 29 Sep 2005 17:37:31 -0400 To: Doug Barton In-Reply-To: <433C5C8B.6000003@FreeBSD.org> References: <433B3F41.8060004@spintech.ro> <17211.19772.562587.908715@bhuda.mired.org> <433C5C8B.6000003@FreeBSD.org> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" 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 Cc: freebsd-hackers@FreeBSD.org, aanton@smtpx.spintech.ro Subject: Re: journaling fs and large mailbox format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 21:36:56 -0000 In <433C5C8B.6000003@FreeBSD.org>, Doug Barton typed: > Mike Meyer wrote: > > The solution isn't to avoid Maildir/mh - the solution is to tune the > > file system for the expected usage. FreeBSD (and Unix in general) > > gives you lots of knobs to deal with things like this. Learn to use > > them. > > > > The default block and frag size are relatively large - 2K and 16K > > appear to be the defaults on 5.x. A quick look at my mail for 2005 > > shows 32,267 messages ranging from 280 bytes to 6+ meg, with a mean > > size of less than 8K. I'd go with 4k blocks and a 512 byte frag size - > > because that will give you four times as many inodes as the default > > parameters. 8K/1K is also tempting, but you'll probably want to > > specify -i 2048 to get the same number of inodes as you get with a > > 4K/512b file system. > > In this situation, since any given file in a maildir directory is very > unlikely to grow, it seems to me to make sense that the right way to tune > the fs would be to find the median file size and make the block size large > enough to handle files of that size. That should give you the right tradeoff > between speed and efficiency. This seems very reasonable. The trick is figuring out what "the median file size" is. I grabbed my mail archive, but that's unlikely to be representative of most users. You either need to guess right, or make arrangements to reformat the file system using current dasa at regular intervals. Taking Doug's suggestion into account, and using the data I had, the correct answer would be an 8K/1K file system, possibly with "-i 2048" to double the number of inodes. However, I did see an interesting possibility. What do you do if the median file size is, for example, 4.1K? A 4K block won't hold your median file. But an 8K block wastes a lot of space. You might get a file with 0 blocks and 3 frags, assuming that UFS2 will do that, which doesn't seem good. If UFS2 won't do that, you get a lot of half-empty blocks, which likewise isn't good. The other option is a 4K block size, which means you get a lot of 1 block + 1 frag files. That seems optimal in this case. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 29 22:40:33 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 EC6B116A421 for ; Thu, 29 Sep 2005 22:40:33 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.62]) by mx1.FreeBSD.org (Postfix) with SMTP id 4C2A243D76 for ; Thu, 29 Sep 2005 22:40:25 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 59081 invoked by uid 399); 29 Sep 2005 22:40:22 -0000 Received: from mail1.fluidhosting.com (204.14.90.61) by mail2.fluidhosting.com with SMTP; 29 Sep 2005 22:40:22 -0000 Received: (qmail 34807 invoked by uid 399); 29 Sep 2005 22:40:22 -0000 Received: from localhost (HELO ?192.168.1.100?) (dougb@dougbarton.net@127.0.0.1) by localhost with SMTP; 29 Sep 2005 22:40:22 -0000 Message-ID: <433C6D51.8020409@FreeBSD.org> Date: Thu, 29 Sep 2005 15:40:17 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050908) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Meyer References: <433B3F41.8060004@spintech.ro> <17211.19772.562587.908715@bhuda.mired.org> <433C5C8B.6000003@FreeBSD.org> <17212.24219.445685.297552@bhuda.mired.org> In-Reply-To: <17212.24219.445685.297552@bhuda.mired.org> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, aanton@smtpx.spintech.ro Subject: Re: journaling fs and large mailbox format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 22:40:35 -0000 Mike Meyer wrote: > This seems very reasonable. The trick is figuring out what "the median > file size" is. I grabbed my mail archive, but that's unlikely to be > representative of most users. You either need to guess right, or make > arrangements to reformat the file system using current dasa at regular > intervals. Sorry if I wasn't explicit enough. I was suggesting that the user who submitted the original message actually measure this, and then yes, a newfs'ing of the file system will be necessary. Or you could of course create a new data disk, formatted to fit your specs, then copy the data over, etc. > Taking Doug's suggestion into account, and using the data I had, the > correct answer would be an 8K/1K file system, possibly with "-i 2048" to > double the number of inodes. I'm not convinced that increasing the number of inodes in this way would be the right way to go. The default is 4*, which is usually pretty reasonable. I imagine (although it's impossible to state conclusively without seeing the files), that the inode problem is a symptom, and that tuning the block size will fix the real problem. > However, I did see an interesting possibility. What do you do if the > median file size is, for example, 4.1K? You make the block size 8k. > A 4K block won't hold your median file. But an 8K block wastes a lot of > space. You might get a file with 0 blocks and 3 frags, assuming that UFS2 > will do that, which doesn't seem good. If UFS2 won't do that, you get a > lot of half-empty blocks, which likewise isn't good. The other option is > a 4K block size, which means you get a lot of 1 block + 1 frag files. > That seems optimal in this case. That's a logical analysis, but you're missing one important premise. UFS doesn't do "more than one file per frag" until the file system gets close to filling up, and the optimization switches from time to space. Therefore, in your example you're actually wasting more space than you would with 8k blocks, and as a side effect making the fs less efficient in at least 2 ways. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 29 22:45:51 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 A944916A41F; Thu, 29 Sep 2005 22:45:51 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05FAD43D4C; Thu, 29 Sep 2005 22:45:50 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j8TMjm0H011105; Fri, 30 Sep 2005 02:45:49 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j8TMjmvT011100; Fri, 30 Sep 2005 02:45:48 +0400 (MSD) (envelope-from yar) Date: Fri, 30 Sep 2005 02:45:48 +0400 From: Yar Tikhiy To: hackers@freebsd.org, current@freebsd.org Message-ID: <20050929224548.GB3035@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Cc: Subject: A smarter mergemaster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 22:45:51 -0000 Folks, I've got tired of dumb default choices mergemaster(8) offers and modified it to be a bit smarter. Upgrading /etc often, as when following CURRENT, is much less pain to me now. The modified mergemaster is available from P4 for now since I'd like to have it tested well before it hits the src tree. The path is //depot/user/yar/hack/usr.sbin/mergemaster, also accessible via web as http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/yar/hack/usr.sbin/mergemaster Since mergemaster still is a shell script, you can just grab and run it. The manual page there has been updated as well. The fruitiest features are as follows: - mergemaster no longer teases you with pauses in -v mode. Use -N (novice mode) if you still want the pauses. - "Stale" rc.d files can be rm'ed or kept on individual basis. - There is expert mode, -E. In this mode, mergemaster offers more dangerous defaults, mostly [install] or [delete] depending on the question. So you can just keep hitting Enter most of the time if your /etc is just slightly modified. In addition, you get the 's' choice when in a subdirectory: auto-install all files from this subdirectory -- much useful to deal with sweeping changes to rc.d or periodic. Feedback is welcome. And please please don't skip making a backup of your /etc before running mergemaster! I can't be responsible for its loss due to bugs in my code or whatever. -- Yar From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 01:11:51 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 C8FFB16A41F; Fri, 30 Sep 2005 01:11:51 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2655E43D49; Fri, 30 Sep 2005 01:11:50 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.31]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j8U1BF1h020820 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 30 Sep 2005 10:41:21 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Fri, 30 Sep 2005 10:41:09 +0930 User-Agent: KMail/1.8.2 References: <20050929224548.GB3035@comp.chem.msu.su> In-Reply-To: <20050929224548.GB3035@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1667406.x3QNet1TlP"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200509301041.10480.doconnor@gsoft.com.au> X-Spam-Score: -2.82 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: Yar Tikhiy , hackers@freebsd.org, current@freebsd.org Subject: Re: A smarter mergemaster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 01:11:52 -0000 --nextPart1667406.x3QNet1TlP Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 30 September 2005 08:15, Yar Tikhiy wrote: > Feedback is welcome. And please please don't skip making a backup of > your /etc before running mergemaster! I can't be responsible for its > loss due to bugs in my code or whatever. This work does look neat, but.. Try etcmerge :) It's a bit of a pain to get started with it, but it is a *lot* faster (huma= n=20 input wise) than mergemaster. It only asks you about files that you have=20 modified rather than ones that have been changed by committers (ie does a 3= =20 way merge). It does have problems handling DB files, but that is usually not a big prob= lem=20 to fix. =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 --nextPart1667406.x3QNet1TlP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDPJCu5ZPcIHs/zowRAonsAKClO/GZv+6Mm0Y542IHl/x9m/Y4JgCeKIdo 8rpLcz3uZ704OXNvs66ykMs= =nv9V -----END PGP SIGNATURE----- --nextPart1667406.x3QNet1TlP-- From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 01:52:38 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 66C4216A41F for ; Fri, 30 Sep 2005 01:52:38 +0000 (GMT) (envelope-from aanton@spintech.ro) Received: from smtpx.spintech.ro (smtpx.spintech.ro [81.180.92.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB93243D48 for ; Fri, 30 Sep 2005 01:52:37 +0000 (GMT) (envelope-from aanton@spintech.ro) Received: from laura-axiomeda (unknown [11.0.0.25]) by smtpx.spintech.ro (Postfix) with ESMTP id 49F8B3A49F for ; Fri, 30 Sep 2005 01:52:52 +0000 (UTC) X-Laura: version 0.0.1b10-frustratus proxied X-Laura-Remote-IP: 10.0.0.2 Received: from [10.0.0.2] (beastie [10.0.0.2]) by smtpx.spintech.ro (Postfix) with ESMTP id BDEF73A496 for ; Fri, 30 Sep 2005 01:52:51 +0000 (UTC) Message-ID: <433C9A64.3030602@spintech.ro> Date: Fri, 30 Sep 2005 04:52:36 +0300 From: Alin-Adrian Anton Organization: Spintech Security Systems User-Agent: Mozilla Thunderbird 1.0 (X11/20041229) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <433B3F41.8060004@spintech.ro> <433B60EE.4090207@centtech.com> In-Reply-To: <433B60EE.4090207@centtech.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: journaling fs and large mailbox format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: aanton@spintech.ro List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 01:52:38 -0000 Eric Anderson wrote: > Alin-Adrian Anton wrote: > >> >> I don't know if the mbox format can handle this, and I know >> Maildir cannot handle this on UFS2 standard install, no matter of >> soft-updates. (because it exhaustes the free nodes) So I currently >> have no solution for this stuff. > > > I'm not sure how you came to this conclusion, or what the history is, > but I see no reason why UFS2 would have any adverse affects on maildir > format mail system. You can set the number of inodes to be created to a > higher number when using newfs on the filesystem, so if you believe that > is an issue, you should be able to tweak it to your needs. mbox starts > to break down on large mailboxes with many messages. 50mb may or may > not be in that range, but maildir is much better for performance. > I run out of inodes with Maildir, and there were just a few hundred accounts. Outlook ppl tend to "leave their messages on server if they are not 7 days old" and this brings Christmas every day. OK now i received some directions of how to tune it for Maildir, and there's also this link I received: http://www.mostlygeek.com/node/11 > > A quick note - run the mail area on a RAID array, preferrably a RAID0+1 > (or 10 depending on who you ask). Disks are nearly always a bottleneck, > so if you can keep your random read/writes fast, the whole system will > feel snappy. Defenately. Also there is this: http://www.dbmail.org/ something more appropiate to my principles, however I was told it's not so stable. > > You might try posting this to freebsd-isp@, since many people there have > much larger installations running than this, and can probably provide > some good hints. > > Thanks for the tip. Mike Meyer wrote: > The solution isn't to avoid Maildir/mh - the solution is to tune the file system for the expected usage. Well, I dislike throwing up my problems to a superior level, and act like it was brilliant. It was just running away from the issue, instead of dealing with it. More exactly, storage problems are database theory. Storing the mail is a classic database problem. Throwing this up to the filesystem level is not an elegant way of dealing with it, because now the filesystem must solve it, and this imposes new restrictions to the filesystem. I agree, B-trees are for database index problems, and not only, however, just imagine what would happen if mySQL or PostgreSQL would throw away their database indexing/locking issue up to the filesystem level? It would be a total hoax, one would need separate filesystem tuning for mysql, one for postresql, one for mail, one for apache, etc.. This just brings headaches and unnecessarry restrictions to the partitioning schema. This is why something like dbmail seems more appropiate in my opinion (conceptually). >Neither journaling nor soft updates would solve the problem of running out of inodes. The only solution there is more inodes. XFS may be flexible enough to deal with file systems that far from the norm - but I wouldn't write a business plan based on it without checking first. XFS fits incredibly well with Maildir, however this I did not test practically (i'd need Linux for that :) ). I think having XFS and maybe ReiserFS in BSD is a must (and obviously there must be reasons for being a must, one of them being a large scale Maildir situation), however it's just my opinion. ZCB wrote: >From personal experience on a smaller system(~1000 accounts and nearly all ways less than 45MB boxes) I would suggest avoiding mboxes all together. Maildir is all ways the way to go. For cleaning stuff out automatically and ect, maildir is much nicer as well. Hm ok, thank's for the info. >Also is this vnodes or inodes? See the tuning man pages. For vnodes, there are some sysctls. Inodes. I'll try both tuning the FS and using dbmail, and see what happens. Thank you all. Yours Sincerely, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 02:09:11 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 A956316A41F for ; Fri, 30 Sep 2005 02:09:11 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.62]) by mx1.FreeBSD.org (Postfix) with SMTP id 1CB3E43D49 for ; Fri, 30 Sep 2005 02:09:10 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 584 invoked by uid 399); 30 Sep 2005 02:09:10 -0000 Received: from mail1.fluidhosting.com (204.14.90.61) by mail2.fluidhosting.com with SMTP; 30 Sep 2005 02:09:10 -0000 Received: (qmail 80214 invoked by uid 399); 30 Sep 2005 02:09:10 -0000 Received: from localhost (HELO ?192.168.1.100?) (dougb@dougbarton.net@127.0.0.1) by localhost with SMTP; 30 Sep 2005 02:09:10 -0000 Message-ID: <433C9E44.8000800@FreeBSD.org> Date: Thu, 29 Sep 2005 19:09:08 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: aanton@spintech.ro References: <433B3F41.8060004@spintech.ro> <433B60EE.4090207@centtech.com> <433C9A64.3030602@spintech.ro> In-Reply-To: <433C9A64.3030602@spintech.ro> X-Enigmail-Version: 0.92.1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: journaling fs and large mailbox format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 02:09:11 -0000 Alin-Adrian Anton wrote: > XFS fits incredibly well with Maildir, however this I did not test > practically I am curious as to what the defaults are for frag, inode, and block sizes on XFS, and whether that is one of the factors that make it work well with maildir. Doug -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 02:17:56 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 3DA2416A41F; Fri, 30 Sep 2005 02:17:56 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A7C943D48; Fri, 30 Sep 2005 02:17:55 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j8U2HioU009196; Thu, 29 Sep 2005 19:17:48 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200509300217.j8U2HioU009196@gw.catspoiler.org> Date: Thu, 29 Sep 2005 19:17:44 -0700 (PDT) From: Don Lewis To: dougb@FreeBSD.org In-Reply-To: <433C6D51.8020409@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-hackers@FreeBSD.org, aanton@smtpx.spintech.ro, mwm@mired.org Subject: Re: journaling fs and large mailbox format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 02:17:56 -0000 On 29 Sep, Doug Barton wrote: > Mike Meyer wrote: >> A 4K block won't hold your median file. But an 8K block wastes a lot of >> space. You might get a file with 0 blocks and 3 frags, assuming that UFS2 >> will do that, which doesn't seem good. If UFS2 won't do that, you get a >> lot of half-empty blocks, which likewise isn't good. The other option is >> a 4K block size, which means you get a lot of 1 block + 1 frag files. >> That seems optimal in this case. > > That's a logical analysis, but you're missing one important premise. UFS > doesn't do "more than one file per frag" until the file system gets close to > filling up, and the optimization switches from time to space. Therefore, in > your example you're actually wasting more space than you would with 8k > blocks, and as a side effect making the fs less efficient in at least 2 ways. If you know that most of the files are write-once and don't grow over time, you can tune the file system to always do space optimization. I used to do this with classic Usenet spools and it worked well. From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 03:13:11 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 E4CD316A41F for ; Fri, 30 Sep 2005 03:13:10 +0000 (GMT) (envelope-from mwm-keyword-hackers.e471b2@mired.org) Received: from delight.idiom.com (outbound.idiom.com [216.240.47.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CAF043D48 for ; Fri, 30 Sep 2005 03:13:06 +0000 (GMT) (envelope-from mwm-keyword-hackers.e471b2@mired.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id 923032257A7 for ; Thu, 29 Sep 2005 20:13:05 -0700 (PDT) Received: from mired.org (mwm@idiom [216.240.32.1]) by idiom.com (8.12.11/8.12.11) with SMTP id j8U3D37L055319 for ; Thu, 29 Sep 2005 20:13:05 -0700 (PDT) (envelope-from mwm-keyword-hackers.e471b2@mired.org) Received: (qmail 89325 invoked by uid 1001); 30 Sep 2005 03:13:48 -0000 Received: by localhost.mired.org (tmda-sendmail, from uid 1001); Thu, 29 Sep 2005 23:13:48 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17212.44395.869528.437031@bhuda.mired.org> Date: Thu, 29 Sep 2005 23:13:47 -0400 To: aanton@spintech.ro In-Reply-To: <433C9A64.3030602@spintech.ro> References: <433B3F41.8060004@spintech.ro> <433B60EE.4090207@centtech.com> <433C9A64.3030602@spintech.ro> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" 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 Cc: freebsd-hackers@freebsd.org Subject: Re: journaling fs and large mailbox format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 03:13:11 -0000 In <433C9A64.3030602@spintech.ro>, Alin-Adrian Anton typed: > I run out of inodes with Maildir, and there were just a few hundred > accounts. Outlook ppl tend to "leave their messages on server if they > are not 7 days old" and this brings Christmas every day. How many files was that, and on how big a file system? Something seems out of kilter. > Mike Meyer wrote: > > The solution isn't to avoid Maildir/mh - the solution is to tune the > file system for the expected usage. > > Well, I dislike throwing up my problems to a superior level, and act > like it was brilliant. It was just running away from the issue, instead > of dealing with it. More exactly, storage problems are database theory. > Storing the mail is a classic database problem. Throwing this up to the > filesystem level is not an elegant way of dealing with it, because now > the filesystem must solve it, and this imposes new restrictions to the > filesystem. I hate to tell you this, but a file system *is* a database. Unix file systems tend to be pretty simple databases, but that's not true on all systems. Using the file system in lieue of a more complicated database - if it will work - is a time-honored unix technic. I keep a couple of gig of mail archived, and let the file system deal with sorting it out by date. Someone's got to solve the problems. If you can find an existing tool to do it for you, that's brilliant, whether the tool is a file system, a database, or a custom application. But there are tradeoffs to each such solution, and you're the only one who can decide if a specific solution is right for you or not. > I agree, B-trees are for database index problems, and not only, however, > just imagine what would happen if mySQL or PostgreSQL would throw away > their database indexing/locking issue up to the filesystem level? It > would be a total hoax, one would need separate filesystem tuning for > mysql, one for postresql, one for mail, one for apache, etc.. This just > brings headaches and unnecessarry restrictions to the partitioning schema. That depends on the underlying file system, and how flexible it is. Apache, mail, etc tend to work ok with a standard Unix file system. Database have more stringent requirements - including performance constraints. I remember commercial databases recommending that you hand them raw disk devices, and skip the OS file system manipulations completely. File systems have gotten a lot better since then, so they may not do that any longer. > This is why something like dbmail seems more appropiate in my opinion > (conceptually). Well, it's more appropriate for some uses. I punted on mbox format in the 80s, when I realized that I could use stock unix commands for manipulating single messages if I used mh mailboxes. This was a major win, as there weren't very good tools for manipulating single messages in an mbox. If your usage is restricted to people doing POP/IMAP, then dbmail would certainly work better. The downside is that you can't use Unix tools to manipulate messages. The upside (?) is that you can use SQL to manipulate messages, which may be a major win. I'm certainly going to check it out. Thanks, http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 06:42:04 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 643A316A41F for ; Fri, 30 Sep 2005 06:42:04 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.62]) by mx1.FreeBSD.org (Postfix) with SMTP id F032C43D66 for ; Fri, 30 Sep 2005 06:41:59 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 71922 invoked by uid 399); 30 Sep 2005 06:41:59 -0000 Received: from mail1.fluidhosting.com (204.14.90.61) by mail2.fluidhosting.com with SMTP; 30 Sep 2005 06:41:59 -0000 Received: (qmail 95351 invoked by uid 399); 30 Sep 2005 06:41:58 -0000 Received: from localhost (HELO ?192.168.1.102?) (dougb@dougbarton.net@127.0.0.1) by localhost with SMTP; 30 Sep 2005 06:41:58 -0000 Message-ID: <433CDE35.7040801@FreeBSD.org> Date: Thu, 29 Sep 2005 23:41:57 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yar Tikhiy References: <20050929224548.GB3035@comp.chem.msu.su> In-Reply-To: <20050929224548.GB3035@comp.chem.msu.su> X-Enigmail-Version: 0.92.1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: A smarter mergemaster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 06:42:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yar, First let me say that you've obviously put a lot of work into this, and you have some very interesting ideas here that are worthy of further discussion. Please don't let any of my comments here be understood as criticism, or an attempt to discourage you. Second, I'd like to point out that it's generally a bad idea to cross post to more than one list. I've set a reply-to for hackers@, if you'd rather have the discussion on current@ that's fine too, but please pick one. Finally, please be aware that in src/MAINTAINERS I have requested pre-commit approval on changes to mergemaster. I hope that you'll respect that. I have some more specific comments below. Yar Tikhiy wrote: | Folks, | | I've got tired of dumb default choices mergemaster(8) offers and modified | it to be a bit smarter. While I can appreciate your frustration, the way you've phrased this departs from the project's tradition of respect for fellow developers and their work. A better way for you to deal with your frustration here would have been to send me, or alternatively, one of the mailing lists, a post which stated your frustrations and asked for an explanation of the reasons for the defaults. I am sure that you meant no actual insult here, so I'll not say anything more about this topic. | Upgrading /etc often, as when following CURRENT, is much less pain to me | now. One of the design decisions that you need to be aware of for this project since day one was to try and balance intelligent behavior and configuration options that would be useful for the very small percentage of the FreeBSD user community that constitutes our developers, versus the needs of the vast majority of "regular" users who need to be able to use the tool without becoming experts in either our build system, or the tool itself. That is why every single default for mergemaster is to do nothing. It was a purposeful decision to require the user to examine change requests, and make an affirmative choice to approve them. I find your idea of an "expert" mode for mm to be an interesting one, and I think that enough time has gone by so that it will be "safe" to add this. However I'd like to add a big, hairy warning message that says that users who enable this option do so at their own risk, etc. I need to think more about this. | The fruitiest features are as follows: | | - mergemaster no longer teases you with pauses in -v mode. Use -N (novice | mode) if you still want the pauses. I'm inclined to alter this to hide the pauses behind an expert mode flag, but I need to study your patch more before I give a more firm opinion on this. Do you have another strong reason for adding this mode? | - "Stale" rc.d files can be rm'ed or kept on individual basis. I think this is a good compromise for those who insist on "polluting" /etc/rc.d with non-system stuff. :) If you're so inclined, could you add a knob to specify a list of files to exclude from consideration? If not, I'll take a look at it. It should also be noted that I have a plan (and a POC) that will allow us to migrate to full rcorder treatment for both /etc/rc.d/ and /usr/local/etc/rc.d/ scripts, but I'm waiting for 6.0-RELEASE to get out the door before starting that bikeshed. | - There is expert mode, -E. In this mode, | mergemaster offers more dangerous defaults, mostly [install] or [delete] | depending on the question. So you can just keep hitting Enter most of | the time if your /etc is just slightly modified. In addition, you get | the 's' choice when in a subdirectory: auto-install all files from this | subdirectory -- much useful to deal with sweeping changes to rc.d or | periodic. Hrrrm ... this is partially in violation of one of my other design goals, which is to have admins actually SEE the changes to the things that they're installing, but this is also one of the least popular aspects of the thing, so I'm inclined to lean into the wind on this one. I would like to consider /etc/defaults/ exempt from this treatment however. I still feel strongly that admins should see what is being changed there since those changes are much more likely to introduce a problem than any other directory. | Feedback is welcome. And please please don't skip making a backup of | your /etc before running mergemaster! I can't be responsible for its | loss due to bugs in my code or whatever. While on the one hand I certainly appreciate and agree with this sentiment, not introducing changes that violate POLA, or are very dangerous to unsophisticated users, is one of the reason I request pre-commit approval. Thanks again for your work on this, Doug - -- ~ This .signature sanitized for your protection -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDPN41yIakK9Wy8PsRAoA4AKC2X04Xnok/nj+nIdEpN7r8Z2/b/wCgtoQE Wov5z1ozZ9tLGFY+VwTTMdQ= =JMsn -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 06:50:46 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 F2AEC16A41F for ; Fri, 30 Sep 2005 06:50:45 +0000 (GMT) (envelope-from nsrashmi@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88F1643D4C for ; Fri, 30 Sep 2005 06:50:43 +0000 (GMT) (envelope-from nsrashmi@gmail.com) Received: by xproxy.gmail.com with SMTP id t4so178022wxc for ; Thu, 29 Sep 2005 23:50:43 -0700 (PDT) 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; b=AIR9z+xjsrOTWn6FhVGNOLN3jM6V0td+XeEdEDX72P5GakdT1Kb39VIPE5hduLKRnemRkRqCIMKcd9MZw1n6RKraDGzZr0CH99BczJp3csM9eKov4OGI1Zs/4COOSs0aAn2FMPiyY0bVcZLOjocUk2YI8f+W5kiYzZmYr+MVjtY= Received: by 10.70.22.8 with SMTP id 8mr802072wxv; Thu, 29 Sep 2005 23:44:19 -0700 (PDT) Received: by 10.70.15.12 with HTTP; Thu, 29 Sep 2005 23:44:19 -0700 (PDT) Message-ID: <9f9993160509292344l51ee40c3o5baef7b80ce222de@mail.gmail.com> Date: Fri, 30 Sep 2005 12:14:19 +0530 From: rashmi ns To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: request:help reqd in using bus_dma functions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rashmi ns List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 06:50:46 -0000 hello group , I am writing a network driver where in have created tags and maps for tx_desc of transmit-q-size by using these functions . 1. bus_dma_tag_create 2. bus_dmamap_create 3.bus_dmamem_alloc struct xxxx_tx_desc { DWORD data_buff; DWORD cvbcnxt; DWORD channel_no; DWORD pend_desc; }; For a packet to be transmitted a packet's address should be placed in tx_desc_q 's DWORD data_buff field and update the rest of the fields .Then h/w detects the presence of the packet and tranmits the packet now to test I want to load a buffer like (char buff[50])in tx_q space can any one tell me in which order I can use bus_dma functions .I have gone th' docs but not very sure as I'm writing n/w drivers for the first time .I'm not clear with the dma concepts . I'm getting confused kindly help Now should I use bus_dmamap_load(bus_dma_tag_t dmat, bus_dmamap_t map, voi= d *buf, bus_size_t buflen, bus_dmamap_callback_t *callback,void *callback_arg= , int flags); I'm not getting what callback func should to how to get the mapped address and place into tx_desc_q 's Thanks and regards, Member From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 08:54:37 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 00CE316A41F for ; Fri, 30 Sep 2005 08:54:37 +0000 (GMT) (envelope-from work@ashleymoran.me.uk) Received: from mta08-winn.ispmail.ntl.com (mta08-winn.ispmail.ntl.com [81.103.221.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F9F843D49 for ; Fri, 30 Sep 2005 08:54:36 +0000 (GMT) (envelope-from work@ashleymoran.me.uk) Received: from aamta12-winn.ispmail.ntl.com ([81.103.221.35]) by mta08-winn.ispmail.ntl.com with ESMTP id <20050930085434.FQUA10357.mta08-winn.ispmail.ntl.com@aamta12-winn.ispmail.ntl.com> for ; Fri, 30 Sep 2005 09:54:34 +0100 Received: from jigsaw-sbs02.jigsawhq.com ([213.106.224.113]) by aamta12-winn.ispmail.ntl.com with ESMTP id <20050930085434.SNBM3160.aamta12-winn.ispmail.ntl.com@jigsaw-sbs02.jigsawhq.com> for ; Fri, 30 Sep 2005 09:54:34 +0100 Received: from [192.168.0.181] ([192.168.0.181]) by jigsaw-sbs02.jigsawhq.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Sep 2005 09:53:46 +0100 Message-ID: <433CFD16.6060200@ashleymoran.me.uk> Date: Fri, 30 Sep 2005 09:53:42 +0100 From: Ashley Moran User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <20050929224548.GB3035@comp.chem.msu.su> <200509301041.10480.doconnor@gsoft.com.au> In-Reply-To: <200509301041.10480.doconnor@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Sep 2005 08:53:46.0535 (UTC) FILETIME=[77CBEB70:01C5C59C] Subject: Re: A smarter mergemaster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 08:54:37 -0000 Daniel O'Connor wrote: > This work does look neat, but.. > Try etcmerge :) > It's a bit of a pain to get started with it, but it is a *lot* faster (human > input wise) than mergemaster. It only asks you about files that you have > modified rather than ones that have been changed by committers (ie does a 3 > way merge). > > It does have problems handling DB files, but that is usually not a big problem > to fix. > I read about etcmerge in BSD Hacks and there's been no going back for me. It seems pretty stable even though it's not been updated for a good while. Is there any chance it will ever make it into the FreeBSD core system? Ashley From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 09:24:45 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 DC59216A41F for ; Fri, 30 Sep 2005 09:24:44 +0000 (GMT) (envelope-from apelisse@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB59B43D48 for ; Fri, 30 Sep 2005 09:24:43 +0000 (GMT) (envelope-from apelisse@gmail.com) Received: by nproxy.gmail.com with SMTP id x4so21261nfb for ; Fri, 30 Sep 2005 02:24:43 -0700 (PDT) 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:references; b=dd5jeYl0qY/XqzDoqP8yYSY5xaTnF+KqUJ1r4CG++WpvqnXllJYpyEtwLoz98dkGVMlh8hIDA+PQcfWe0Qpj6KvvsZ5Nco+9qud5MP8haebWJ+nGSTnRlH9VzCMCBf/ovTxJOs4Hobnyve3U1QLLeHCxRfxsZJ/AlvYfiPD8U+4= Received: by 10.48.226.17 with SMTP id y17mr91982nfg; Fri, 30 Sep 2005 02:24:43 -0700 (PDT) Received: by 10.48.108.18 with HTTP; Fri, 30 Sep 2005 02:24:43 -0700 (PDT) Message-ID: <61c746830509300224g3d79cbe4ve55e8b0b27004fc3@mail.gmail.com> Date: Fri, 30 Sep 2005 10:24:43 +0100 From: Antoine Pelisse To: freebsd-hackers@freebsd.org In-Reply-To: <61c746830509300215x7833746ew60896c4c1338ec65@mail.gmail.com> MIME-Version: 1.0 References: <20050927140535.G50334@daemon.mistermishap.net> <20050927203128.S61419@fledge.watson.org> <20050927222624.R34322@fledge.watson.org> <20050928134724.P56436@daemon.mistermishap.net> <20050929185538.R61419@fledge.watson.org> <20050929160945.A65402@daemon.mistermishap.net> <20050929212738.A34322@fledge.watson.org> <61c746830509300215x7833746ew60896c4c1338ec65@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: freebsd-5.4-stable panics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Antoine Pelisse List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 09:24:46 -0000 Hi Robert, I don't think your patch is correct, the total linked list can be broken while the lock is released, thus just passing the link may not be enough I have submitted a PR[1] for this a month ago but nobody took care of it ye= t Regards, Antoine Pelisse [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/84684 On 9/29/05, Robert Watson wrote: > > On Thu, 29 Sep 2005, Rob Watt wrote: > > > On Thu, 29 Sep 2005, Robert Watson wrote: > > > >> Could you dump the contents of *td and *td->td_proc for me? I'm quite > >> interested to know what the value in td->td_proc->p_state is, among > other > >> things. If I could also have you generate a dump of the KSE group > >> structures in td->td_proc->p_ksegrps and the threads in > >> td->td_proc->p_threads. > > > > I've attached a file with many of the values you have asked for. We > > looked at some of the threads referenced by td->td_proc->p_threads, but > > we weren't sure we were walking the list correctly. Do you have any tip= s > > > for walking those thread lists? > > > >> Could you tell me if the program named by p->p_comm is linked against = a > >> threading library? If it's a custom app, you may already know, and if > >> not, you can run ldd on the application to see what it is linked > >> against. > > > > The programs named by p->p_comm is linked against the pthreads library. > > This seems to be enough information to at least track this down a bit: > td_ksegrp is NULL, rather than a corrupt value, which suggests that the > thread is incompletely initialized. Other hints that this are the case > are that td_critnest is 1 (as is set when it is allocated), and the state > is TDS_INACTIVE. Some other fields are set though, such as td_oncpu, > which is normally initialized to NOCPU. > > > (kgdb) p *td > > $1 =3D {td_proc =3D 0xffffff004aa9f000, td_ksegrp =3D 0x0, td_plist =3D > > {tqe_next =3D 0xff ffff00b4798000, > > tqe_prev =3D 0xffffff00a97ae010}, td_kglist =3D {tqe_next =3D > > 0xffffff00b4798000, > > tqe_prev =3D 0xffffff00a97ae020}, td_slpq =3D {tqe_next =3D 0x0, tqe_pr= ev > > =3D 0xffff ff001fac7c10}, td_lockq =3D { > > tqe_next =3D 0xffffff00a97ae000, tqe_prev =3D 0xffffffffb6797a70}, > > td_runq =3D {tq e_next =3D 0x0, > > tqe_prev =3D 0xffffffff80608180}, td_selq =3D {tqh_first =3D 0x0, tqh_l= ast > > =3D 0xfff fff00633112c0}, > > td_sleepqueue =3D 0xffffff00382b0400, td_turnstile =3D 0xffffff00c17129= 00, > > td_umtx q =3D 0xffffff00d1207080, > > td_tid =3D 100253, td_flags =3D 16777216, td_inhibitors =3D 0, td_pflag= s =3D > > 128, td_d upfd =3D 0, td_wchan =3D 0x0, > > td_wmesg =3D 0x0, td_lastcpu =3D 2 '\002', td_oncpu =3D 2 '\002', > > td_owepreempt =3D 0 '\0', td_locks =3D 0, > > td_blocked =3D 0x0, td_ithd =3D 0x0, td_lockname =3D 0x0, td_contested = =3D > > {lh_first =3D > > 0x0}, td_sleeplocks =3D 0x0, > > td_intr_nesting_level =3D 0, td_pinned =3D 0, td_mailbox =3D 0x0, td_uc= red =3D > > 0xfffff f00ad18f200, > > td_standin =3D 0x0, td_upcall =3D 0x0, td_sticks =3D 0, td_uuticks =3D = 0, > > td_usticks =3D > > 0, td_intrval =3D 0, > > td_oldsigmask =3D {__bits =3D {0, 0, 0, 0}}, td_sigmask =3D {__bits =3D > > {4294967295, 4 294967295, 4294967295, > > 4294967295}}, td_siglist =3D {__bits =3D {0, 0, 0, 0}}, td_generation > > =3D 14, td _sigstk =3D {ss_sp =3D 0x0, > > ss_size =3D 0, ss_flags =3D 0}, td_kflags =3D 0, td_xsig =3D 0, > > td_profil_addr =3D 0, td_profil_ticks =3D 0, > > td_base_pri =3D 182 '\uffff', td_priority =3D 182 '\uffff', td_pcb =3D > > 0xffffffffb68 dcd10, td_state =3D TDS_INACTIVE, > > td_retval =3D {1, 29309280}, td_slpcallout =3D {c_links =3D {sle =3D {s= le_next > > =3D 0x0}, > > tqe =3D {tqe_next =3D 0x0, > > tqe_prev =3D 0xffffff001fac7d80}}, c_time =3D 55907602, c_arg =3D > > 0xffffff0063 311260, > > c_func =3D 0xffffffff802e32a0 , c_mtx =3D 0x0, c_flags = =3D > > 16}, td _frame =3D 0xffffffffb68dcc40, > > td_kstack_obj =3D 0xffffff0087f93d20, td_kstack =3D 1844674407247731507= 2, > > td_kstac k_pages =3D 4, > > td_altkstack_obj =3D 0x0, td_altkstack =3D 0, td_altkstack_pages =3D 0, > > td_critnest =3D 1, td_md =3D { > > md_spinlock_count =3D 1, md_saved_flags =3D 582}, td_sched =3D > > 0xffffff0063311488} > > I'm not familiar with the internals of the thread and KSE life cycle here= , > > so I think we'll need to look to those more familiar with this to > understand what of two things may be going on: > > (1) Is the fact that td_ksegrp !=3D NULL an invariant for a connected > thread, and that kern_proc is relying on that but the thread code is > failing to implement it safely? > > (2) Is td_ksegrp sometimes left legitimately as NULL as part of the threa= d > life cycle, and that kern_proc incorrectly assumes that it is never > NULL when hooked up to a thread. > > This suggests a possible work-around of simply testing td_ksegrp for NULL > in kern_proc in order to avoid this, while attempting to resolve whether > an invariant is violated (or incorrectly assumed), which might require > some serious thinking and a solution that is non-trivial. Something like > the following might work in the mean time: > > Index: kern_proc.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/ncvs/src/sys/kern/kern_proc.c,v > retrieving revision 1.231 > diff -u -r1.231 kern_proc.c > --- kern_proc.c 27 Sep 2005 18:03:15 -0000 1.231 > +++ kern_proc.c 29 Sep 2005 20:50:33 -0000 > @@ -882,6 +882,8 @@ > } else { > _PHOLD(p); > FOREACH_THREAD_IN_PROC(p, td) { > + if (td->td_ksegrp =3D=3D NULL) > + continue; > fill_kinfo_thread(td, &kinfo_proc); > PROC_UNLOCK(p); > error =3D SYSCTL_OUT(req, (caddr_t)&kinfo_proc, > > I'm going to forward off your e-mail to the threads@ list and see if > anyone there wants to talk some more about this. If you don't mind > testing the above patch to see if this is a workable work-around, we may > want to think about getting it committed in the mean time. > > Thanks, > > 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 Fri Sep 30 10:47:05 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 0A75716A41F for ; Fri, 30 Sep 2005 10:47:05 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id E05E943D4C for ; Fri, 30 Sep 2005 10:47:01 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j8UAkvq1046173 for ; Fri, 30 Sep 2005 14:46:57 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j8UAkuui046169 for freebsd-hackers@FreeBSD.org; Fri, 30 Sep 2005 14:46:56 +0400 (MSD) (envelope-from yar) Date: Fri, 30 Sep 2005 14:46:56 +0400 From: Yar Tikhiy To: freebsd-hackers@FreeBSD.org Message-ID: <20050930104656.GA45907@comp.chem.msu.su> References: <20050929224548.GB3035@comp.chem.msu.su> <433CDE35.7040801@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <433CDE35.7040801@FreeBSD.org> User-Agent: Mutt/1.5.9i Cc: Subject: Re: A smarter mergemaster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 10:47:05 -0000 On Thu, Sep 29, 2005 at 11:41:57PM -0700, Doug Barton wrote: > > First let me say that you've obviously put a lot of work into this, and you > have some very interesting ideas here that are worthy of further discussion. > Please don't let any of my comments here be understood as criticism, or an > attempt to discourage you. Thanks! > Second, I'd like to point out that it's generally a bad idea to cross post > to more than one list. I've set a reply-to for hackers@, if you'd rather > have the discussion on current@ that's fine too, but please pick one. Well, I just couldn't decide between the two lists because I thought that -current was much devoted to reporting LORs and panics while discussions on -hackers tended to be rather theoretic unless they were about LORs and panics :-) Let's stick to -hackers now. > Finally, please be aware that in src/MAINTAINERS I have requested pre-commit > approval on changes to mergemaster. I hope that you'll respect that. I have > some more specific comments below. No problem with that, I'm by no means going to violate your maintainership over mergemaster. And yes, I should have peeked in src/MAINTAINERS earlier :-) > Yar Tikhiy wrote: > | Folks, > | > | I've got tired of dumb default choices mergemaster(8) offers and modified > | it to be a bit smarter. > > While I can appreciate your frustration, the way you've phrased this departs > from the project's tradition of respect for fellow developers and their > work. A better way for you to deal with your frustration here would have > been to send me, or alternatively, one of the mailing lists, a post which > stated your frustrations and asked for an explanation of the reasons for the > defaults. > > I am sure that you meant no actual insult here, so I'll not say anything > more about this topic. I beg your pardon. Let's say I was over-excited with having mm work the way I always wanted it to :-) And, not being a native English speaker, I didn't imagine that the word "dumb" could be insulting after I had seen so much references to the illustrious Dumb Terminals of the Golden Era of Computing ;-) > | Upgrading /etc often, as when following CURRENT, is much less pain to me > | now. > > One of the design decisions that you need to be aware of for this project > since day one was to try and balance intelligent behavior and configuration > options that would be useful for the very small percentage of the FreeBSD > user community that constitutes our developers, versus the needs of the vast > majority of "regular" users who need to be able to use the tool without > becoming experts in either our build system, or the tool itself. That is why > every single default for mergemaster is to do nothing. It was a purposeful > decision to require the user to examine change requests, and make an > affirmative choice to approve them. In fact, following CURRENT is not the only case when "expert" mode of mm could be desired. People following STABLE branches on their production machines use mm, too, and yours truly is among them. Their case is even more calling for "expert" mode because numerous machines usually need upgrading in a row. The admins study all the peculiarities of mm as soon as they run it a dozen times, but they still need to run it after that. Our /etc is well-suited for staying just slightly modified in the most common cases, so there is little need in turning each mm session into a school class to the admin. Of course, the admins will be responsible for the massive destruction their errors can cause when using mm in expert mode, but most admins are used to this kind of responsibility :-) > I find your idea of an "expert" mode for mm to be an interesting one, and I > think that enough time has gone by so that it will be "safe" to add this. > However I'd like to add a big, hairy warning message that says that users > who enable this option do so at their own risk, etc. I need to think more > about this. I'm unsure if it is hairy enough, but it's on the manpage already, as well as on the help screen, in my version. > | The fruitiest features are as follows: > | > | - mergemaster no longer teases you with pauses in -v mode. Use -N (novice > | mode) if you still want the pauses. > > I'm inclined to alter this to hide the pauses behind an expert mode flag, > but I need to study your patch more before I give a more firm opinion on > this. Do you have another strong reason for adding this mode? I just liked mm -v for it showing the list of files added locally, but I wasn't happy with the pauses obviously intended for novices, especially when I had to upgrade several machines in a row. > | - "Stale" rc.d files can be rm'ed or kept on individual basis. > > I think this is a good compromise for those who insist on "polluting" > /etc/rc.d with non-system stuff. :) If you're so inclined, could you add a > knob to specify a list of files to exclude from consideration? If not, I'll > take a look at it. Done and doc'ed in my p4 branch as LOCAL_RC_FILES, which can be a list of names and wildcards. > It should also be noted that I have a plan (and a POC) that will allow us to > migrate to full rcorder treatment for both /etc/rc.d/ and > /usr/local/etc/rc.d/ scripts, but I'm waiting for 6.0-RELEASE to get out the > door before starting that bikeshed. I appreciate your plan greatly. The main reasoning behind this particular change to mm was having to keep rc.d scripts for 3rd party apps that should start earlier that localpkg and use rcorder, e.g., routing daemons. > | - There is expert mode, -E. In this mode, > | mergemaster offers more dangerous defaults, mostly [install] or [delete] > | depending on the question. So you can just keep hitting Enter most of > | the time if your /etc is just slightly modified. In addition, you get > | the 's' choice when in a subdirectory: auto-install all files from this > | subdirectory -- much useful to deal with sweeping changes to rc.d or > | periodic. > > Hrrrm ... this is partially in violation of one of my other design goals, > which is to have admins actually SEE the changes to the things that they're > installing, but this is also one of the least popular aspects of the thing, > so I'm inclined to lean into the wind on this one. I would like to consider > /etc/defaults/ exempt from this treatment however. I still feel strongly > that admins should see what is being changed there since those changes are > much more likely to introduce a problem than any other directory. I think this feature of expert mode can be justified by having to run mm on more than one machine when upgrading a whole herd of them from version A to version B. Then the admins can look at the changes once, but they won't have to browse through them a dozen times. > | Feedback is welcome. And please please don't skip making a backup of > | your /etc before running mergemaster! I can't be responsible for its > | loss due to bugs in my code or whatever. > > While on the one hand I certainly appreciate and agree with this sentiment, > not introducing changes that violate POLA, or are very dangerous to > unsophisticated users, is one of the reason I request pre-commit approval. Well, it can hardly be more dangerous than having "rm -rf" in the base system, so there is little reason in over-protecting the humble users ;-) Of course, I won't commit anything to the stock mm w/o your approval. And thank you for your suggestions! -- Yar From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 11:08:55 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 2CDA316A421 for ; Fri, 30 Sep 2005 11:08:55 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9778C43D48 for ; Fri, 30 Sep 2005 11:08:51 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j8UB8gT3047627; Fri, 30 Sep 2005 15:08:42 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j8UB8gIG047626; Fri, 30 Sep 2005 15:08:42 +0400 (MSD) (envelope-from yar) Date: Fri, 30 Sep 2005 15:08:42 +0400 From: Yar Tikhiy To: Jon Dama Message-ID: <20050930110841.GC45907@comp.chem.msu.su> References: <20050929224548.GB3035@comp.chem.msu.su> <433CDE35.7040801@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@freebsd.org Subject: Re: A smarter mergemaster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 11:08:55 -0000 [Replying to everyone who mentioned etcmerge or 3-way merge in general] On Fri, Sep 30, 2005 at 12:15:59AM -0700, Jon Dama wrote: > It is worth while to mention sysutils/etcmerge. > > Having the "three-way" merge makes the process much better. The primary > way I've shot myself with mergemaster is forgetting some local change. > > Being able to distinguish the class of things that are changing upstream > really helps the situation and provides a more reasonable indication of > the default: > if it changed upstream but not locally => default is install > if it changed locally but not upstream => default is keep > if it changed locally and upstream => default is merge Obviously, in order to do a 3-way merge, we need information about the old versions of original files as well. However, currently we have only the new versions in /usr/src and local versions in /etc for mergemaster to work with. I'll be glad to hear how etcmerge approaches this issue. In any case, we cannot offer the users to access the CVS repo when merging /etc. Personally, I'd like to see a complete copy of current unmodified /etc files installed to /usr/share/examples/etc. They could serve as the old original versions for the 3-way merge then. Alas, now the copy installed there is rather incomplete, motivation of which is unknown to me yet. Any ideas? -- Yar From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 29 17:06:29 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 6754E16A41F; Thu, 29 Sep 2005 17:06:29 +0000 (GMT) (envelope-from rob@hudson-trading.com) Received: from daemon.mistermishap.net (167-49.nyc.dsl.access.net [166.84.167.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D23843D53; Thu, 29 Sep 2005 17:06:27 +0000 (GMT) (envelope-from rob@hudson-trading.com) Received: from daemon.mistermishap.net (localhost.mistermishap.net [127.0.0.1]) by daemon.mistermishap.net (8.12.9/8.12.9) with ESMTP id j8TH6RmU066347; Thu, 29 Sep 2005 13:06:27 -0400 (EDT) (envelope-from rob@hudson-trading.com) Received: from localhost (rob@localhost) by daemon.mistermishap.net (8.12.9/8.12.9/Submit) with ESMTP id j8TH6QPW066344; Thu, 29 Sep 2005 13:06:26 -0400 (EDT) X-Authentication-Warning: daemon.mistermishap.net: rob owned process doing -bs Date: Thu, 29 Sep 2005 13:06:26 -0400 (EDT) From: Rob Watt X-X-Sender: rob@daemon.mistermishap.net To: Robert Watson In-Reply-To: <20050927222624.R34322@fledge.watson.org> Message-ID: <20050929124027.U65402@daemon.mistermishap.net> References: <20050925115912.H11229@fledge.watson.org> <20050927140535.G50334@daemon.mistermishap.net> <20050927203128.S61419@fledge.watson.org> <20050927222624.R34322@fledge.watson.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-432868459-1128013586=:65402" X-Mailman-Approved-At: Fri, 30 Sep 2005 11:30:24 +0000 Cc: Rob Watt , mikep@hudson-trading.com, freebsd-hackers@FreeBSD.org, freebsd-amd64@FreeBSD.org, Jason Carroll Subject: Re: freebsd-5.4-stable panics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 17:06:29 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-432868459-1128013586=:65402 Content-Type: TEXT/PLAIN; charset=US-ASCII Robert, We have gotten some more information from our type1 crash: >sh lockedvnods Locked vnodes >sh alllocks Process 2204 (dataplay) thread 0xffffff00b1726a000 (100214) exclusive sleep mutex inp (udpinp) f = 0 (0xffffff00cc90fcc8) locked @ /usr/src/sys/netinet/udp_usrreq.c:762 Process 62 (pagedaemon) thread 0xffffff00e358c280 (100049) exclusive sleep mutex UMA lock r = 0 (0xffffffff8068bf80) locked @ /usr/src/sys/vm/uma_core.c:1491 exclusive sleep mutex Giant r = 0 (0xffffffff8062ed80) locked @ /usr/src/sys/vm/vm_pageout.c:717 Process 48 (swi1:net) thread 0xffffff00e3597780 (100027) exclusive sleep mutex IPFW static rules r = 0 (0xffffffff8067ae50) locked @ /usr/src/sys/netinet/ip_fw2.c:149 >sh pcpu cpuid=0 currthread = 0xffffff00e358c280: pid 63 "pagedaemon" currpcb = 0xffffffffb34e3d10 fpcurrthread = none idle thread = 0xffffff00e35b6000: pid 14 (idle cpu0) spin locks held = >sh pcpu 1 cpuid=1 currthread = 0xffffff00e358b3c80: pid 13 "idle cpu1" currpcb = 0xffffffffffb34e7d10 fpcurrthread = none idle thread = 0xffffff00e358b3c80: pid 13 (idle cpu1) spin locks held = >sh pcpu 2 cpuid=2 currthread = 0xffffff00e35e4000: pid 2715 "bonnie" currpcb = 0xffffffffffb636dd10 fpcurrthread = none idle thread = 0xffffff00e35b3a00: pid 12 (idle cpu2) spin locks held = >sh pcpu 3 cpuid=3 currthread = 0xffffff00e35aea00: pid 40 "irq27: em1 em2" currpcb = 0xffffffffffb34b6d10 fpcurrthread = none idle thread = 0xffffff00e35b3780: pid 11 (idle cpu0) spin locks held = I have attached the core output as type1-core.2.txt, but unfortunately it does not help us determine the area of code that triggered the exception. If I can get more DDB output from the type2 crash I will post it. There is some encouraging news: since we stopped running top, our 6.0-BETA5 test machine has not crashed (its been running tests now for over 26 hours). We also started running tests on a dual single-core machine running 5-STABLE. That machine has been running for 50 hours without crashing. This means that we are now only hitting these bugs with dual dual-core machines running 5-STABLE. - Rob Watt --0-432868459-1128013586=:65402 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="type1-core.2.txt" Content-Transfer-Encoding: BASE64 Content-Description: Content-Disposition: attachment; filename="type1-core.2.txt" RERCOg0KPnNoIGxvY2tlZHZub2RzDQpMb2NrZWQgdm5vZGVzDQoNCj5zaCBh bGxsb2Nrcw0KUHJvY2VzcyAyMjA0IChkYXRhcGxheSkgdGhyZWFkIDB4ZmZm ZmZmMDBiMTcyNmEwMDAgKDEwMDIxNCkNCmV4Y2x1c2l2ZSBzbGVlcCBtdXRl eCBpbnAgKHVkcGlucCkgZiA9IDAgKDB4ZmZmZmZmMDBjYzkwZmNjOCkgbG9j a2VkIEAgL3Vzci9zcmMvc3lzL25ldGluZXQvdWRwX3VzcnJlcS5jOjc2Mg0K UHJvY2VzcyA2MiAocGFnZWRhZW1vbikgdGhyZWFkIDB4ZmZmZmZmMDBlMzU4 YzI4MCAoMTAwMDQ5KQ0KZXhjbHVzaXZlIHNsZWVwIG11dGV4IFVNQSBsb2Nr IHIgPSAwICgweGZmZmZmZmZmODA2OGJmODApIGxvY2tlZCBAIC91c3Ivc3Jj L3N5cy92bS91bWFfY29yZS5jOjE0OTENCmV4Y2x1c2l2ZSBzbGVlcCBtdXRl eCBHaWFudCByID0gMCAoMHhmZmZmZmZmZjgwNjJlZDgwKSBsb2NrZWQgQCAv dXNyL3NyYy9zeXMvdm0vdm1fcGFnZW91dC5jOjcxNw0KUHJvY2VzcyA0OCAo c3dpMTpuZXQpIHRocmVhZCAweGZmZmZmZjAwZTM1OTc3ODAgKDEwMDAyNykN CmV4Y2x1c2l2ZSBzbGVlcCBtdXRleCBJUEZXIHN0YXRpYyBydWxlcyByID0g MCAoMHhmZmZmZmZmZjgwNjdhZTUwKSBsb2NrZWQgQCAvdXNyL3NyYy9zeXMv bmV0aW5ldC9pcF9mdzIuYzoxNDkNCg0KPnNoIHBjcHUNCmNwdWlkPTANCmN1 cnJ0aHJlYWQgICAgICA9IDB4ZmZmZmZmMDBlMzU4YzI4MDogcGlkIDYzICJw YWdlZGFlbW9uIg0KY3VycnBjYiAgICAgICAgID0gMHhmZmZmZmZmZmIzNGUz ZDEwDQpmcGN1cnJ0aHJlYWQgICAgPSBub25lDQppZGxlIHRocmVhZCAgICAg PSAweGZmZmZmZjAwZTM1YjYwMDA6IHBpZCAxNCAoaWRsZSBjcHUwKQ0Kc3Bp biBsb2NrcyBoZWxkID0NCg0KPnNoIHBjcHUgMQ0KY3B1aWQ9MQ0KY3VycnRo cmVhZCAgICAgID0gMHhmZmZmZmYwMGUzNThiM2M4MDogcGlkIDEzICJpZGxl IGNwdTEiDQpjdXJycGNiICAgICAgICAgPSAweGZmZmZmZmZmZmZiMzRlN2Qx MA0KZnBjdXJydGhyZWFkICAgID0gbm9uZQ0KaWRsZSB0aHJlYWQgICAgID0g MHhmZmZmZmYwMGUzNThiM2M4MDogcGlkIDEzICJpZGxlIGNwdTEiDQpzcGlu IGxvY2tzIGhlbGQgPQ0KDQo+c2ggcGNwdSAyDQpjcHVpZD0yDQpjdXJydGhy ZWFkICAgICAgPSAweGZmZmZmZjAwZTM1ZTQwMDA6IHBpZCAyNzE1ICJib25u aWUiDQpjdXJycGNiICAgICAgICAgPSAweGZmZmZmZmZmZmZiNjM2ZGQxMA0K ZnBjdXJydGhyZWFkICAgID0gbm9uZQ0KaWRsZSB0aHJlYWQgICAgID0gMHhm ZmZmZmYwMGUzNWIzYTAwOiBwaWQgMTIgImlkbGUgY3B1MiINCnNwaW4gbG9j a3MgaGVsZCA9DQoNCj5zaCBwY3B1IDMgDQpjcHVpZD0zDQpjdXJydGhyZWFk ICAgICAgPSAweGZmZmZmZjAwZTM1YWVhMDA6IHBpZCA0MCAiaXJxMjc6IGVt MSBlbTIiDQpjdXJycGNiICAgICAgICAgPSAweGZmZmZmZmZmZmZiMzRiNmQx MA0KZnBjdXJydGhyZWFkICAgID0gbm9uZQ0KaWRsZSB0aHJlYWQgICAgID0g MHhmZmZmZmYwMGUzNWIzNzgwOiBwaWQgMTEgImlkbGUgY3B1MCINCnNwaW4g bG9ja3MgaGVsZCA9DQoNCg0KDQpLR0RCOg0KVW5yZWFkIHBvcnRpb24gb2Yg dGhlIGtlcm5lbCBtZXNzYWdlIGJ1ZmZlcjoNCnBhbmljOiBObyBUSUQgYml0 bWFwPw0KY3B1aWQgPSAwDQpLREI6IGVudGVyOiBwYW5pYw0KDQojMCAgZG9h ZHVtcCAoKSBhdCBwY3B1Lmg6MTY3DQoxNjcgICAgIHBjcHUuaDogTm8gc3Vj aCBmaWxlIG9yIGRpcmVjdG9yeS4NCiAgICAgICAgaW4gcGNwdS5oDQooa2dk YikgYnQNCiMwICBkb2FkdW1wICgpIGF0IHBjcHUuaDoxNjcNCiMxICAweGZm ZmZmZmZmODAxOTI0ZjYgaW4gZGJfZm5jYWxsIChkdW1teTE9MCwgZHVtbXky PTAsIGR1bW15Mz0wLCBkdW1teTQ9MHgwKSBhdCAvdXNyL3NyYy9zeXMvZGRi L2RiX2NvbW1hbmQuYzo1MzENCiMyICAweGZmZmZmZmZmODAxOTI5ODUgaW4g ZGJfY29tbWFuZF9sb29wICgpIGF0IC91c3Ivc3JjL3N5cy9kZGIvZGJfY29t bWFuZC5jOjM0OQ0KIzMgIDB4ZmZmZmZmZmY4MDE5NDgzMyBpbiBkYl90cmFw ICh0eXBlPS0xMjg2NzE5NjQ4LCBjb2RlPTApIGF0IC91c3Ivc3JjL3N5cy9k ZGIvZGJfbWFpbi5jOjIyMQ0KIzQgIDB4ZmZmZmZmZmY4MDJjYjhmMCBpbiBr ZGJfdHJhcCAodHlwZT0zLCBjb2RlPTAsIHRmPTB4MCkgYXQgL3Vzci9zcmMv c3lzL2tlcm4vc3Vicl9rZGIuYzo0NzANCiM1ICAweGZmZmZmZmZmODA0MTY5 ZGMgaW4gdHJhcCAoZnJhbWU9DQogICAgICB7dGZfcmRpID0gMCwgdGZfcnNp ID0gLTIxMzY5MjgyNTYsIHRmX3JkeCA9IDAsIHRmX3JjeCA9IDUyMzc3Niwg dGZfcjggPSAtMTI4NjcxOTQ0MCwgdGZfcjkgPSAxMCwgdGZfcmF4ID0gMTgs IHRmX3JieCA9IC0yMTQyNjg2MjU4LCB0Zl9yYnAgPSAtMTI4NjcxOTIwMCwg dGZfcjEwID0gMjA3NjUsIHRmX3IxMSA9IDAsIHRmX3IxMiA9IDAsIHRmX3Ix MyA9IDI1NiwgdGZfcjE0ID0gLTEwOTU2OTczODI3ODQsIHRmX3IxNSA9IDc2 ODYwNSwgdGZfdHJhcG5vID0gMywgdGZfYWRkciA9IDAsIHRmX2ZsYWdzID0g MjU2LCB0Zl9lcnIgPSAwLCB0Zl9yaXAgPSAtMjE0NDU1NDE2MSwgdGZfY3Mg PSA4LCB0Zl9yZmxhZ3MgPSA2NDIsIHRmX3JzcCA9IC0xMjg2NzE5MjAwLCB0 Zl9zcyA9IDE2fSkgYXQgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L3RyYXAu Yzo0MzENCiM2ICAweGZmZmZmZmZmODA0MDQ2ZmIgaW4gY2FsbHRyYXAgKCkg YXQgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L2V4Y2VwdGlvbi5TOjE3MQ0K IzcgIDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQ0KIzggIDB4ZmZmZmZm ZmY4MGExMTAwMCBpbiA/PyAoKQ0KIzkgIDB4MDAwMDAwMDAwMDAwMDAwMCBp biA/PyAoKQ0KIzEwIDB4MDAwMDAwMDAwMDA3ZmUwMCBpbiA/PyAoKQ0KIzEx IDB4ZmZmZmZmZmZiMzRlMzgzMCBpbiA/PyAoKQ0KIzEyIDB4MDAwMDAwMDAw MDAwMDAwYSBpbiA/PyAoKQ0KIzEzIDB4MDAwMDAwMDAwMDAwMDAxMiBpbiA/ PyAoKQ0KIzE0IDB4ZmZmZmZmZmY4MDQ5MzNjZSBpbiBfX2Z1bmNfXy4wICgp DQojMTUgMHhmZmZmZmZmZmIzNGUzOTIwIGluID8/ICgpDQojMTYgMHgwMDAw MDAwMDAwMDA1MTFkIGluID8/ICgpDQojMTcgMHgwMDAwMDAwMDAwMDAwMDAw IGluID8/ICgpDQojMTggMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpDQoj MTkgMHgwMDAwMDAwMDAwMDAwMTAwIGluID8/ICgpDQojMjAgMHhmZmZmZmYw MGUzNThjMjgwIGluID8/ICgpDQojMjEgMHgwMDAwMDAwMDAwMGJiYTVkIGlu ID8/ICgpDQojMjIgMHgwMDAwMDAwMDAwMDAwMDAzIGluID8/ICgpDQojMjMg MHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpDQojMjQgMHgwMDAwMDAwMDAw MDAwMTAwIGluID8/ICgpDQojMjUgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ ICgpDQojMjYgMHhmZmZmZmZmZjgwMmNiMzRmIGluIGtkYl9lbnRlciAobXNn PTB4MCkgYXQgY3B1ZnVuYy5oOjU5DQojMjcgMHhmZmZmZmZmZjgwMmIwMTg5 IGluIHBhbmljIChmbXQ9MHhmZmZmZmZmZjgwNDkzM2NlICJObyBUSUQgYml0 bWFwPyIpIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2h1dGRvd24uYzo1 NTINCiMyOCAweGZmZmZmZmZmODAyYmI2ZDkgaW4gdGhyZWFkX2ZpbmkgKG1l bT0weDAsIHNpemU9MCkgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl90aHJl YWQuYzoyNjkNCiMyOSAweGZmZmZmZmZmODAzZjk1ZTkgaW4gem9uZV9kcmFp biAoem9uZT0weDEpIGF0IC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjc0 OQ0KIzMwIDB4ZmZmZmZmZmY4MDNmNzRkNiBpbiB6b25lX2ZvcmVhY2ggKHpm dW5jPTB4ZmZmZmZmZmY4MDNmOTQ0MCA8em9uZV9kcmFpbj4pIGF0IC91c3Iv c3JjL3N5cy92bS91bWFfY29yZS5jOjE0OTQNCiMzMSAweGZmZmZmZmZmODAz ZmE5MTEgaW4gdW1hX3JlY2xhaW0gKCkgYXQgL3Vzci9zcmMvc3lzL3ZtL3Vt YV9jb3JlLmM6MjYyMw0KIzMyIDB4ZmZmZmZmZmY4MDNmNTBlYSBpbiB2bV9w YWdlb3V0ICgpIGF0IC91c3Ivc3JjL3N5cy92bS92bV9wYWdlb3V0LmM6NzI1 DQojMzMgMHhmZmZmZmZmZjgwMjk5ZmEzIGluIGZvcmtfZXhpdCAoY2FsbG91 dD0weGZmZmZmZmZmODAzZjRkYjAgPHZtX3BhZ2VvdXQ+LCBhcmc9MHgwLCBm cmFtZT0weGZmZmZmZmZmYjM0ZTNjNTApDQogICAgYXQgL3Vzci9zcmMvc3lz L2tlcm4va2Vybl9mb3JrLmM6NzkxDQojMzQgMHhmZmZmZmZmZjgwNDA0OGZl IGluIGZvcmtfdHJhbXBvbGluZSAoKSBhdCAvdXNyL3NyYy9zeXMvYW1kNjQv YW1kNjQvZXhjZXB0aW9uLlM6Mjk2DQojMzUgMHgwMDAwMDAwMDAwMDAwMDAw IGluID8/ICgpDQojMzYgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpDQoj MzcgMHgwMDAwMDAwMDAwMDAwMDAxIGluID8/ICgpDQojMzggMHgwMDAwMDAw MDAwMDAwMDAwIGluID8/ICgpDQojMzkgMHgwMDAwMDAwMDAwMDAwMDAwIGlu ID8/ICgpDQojNDAgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpDQojNDEg MHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpDQojNDIgMHgwMDAwMDAwMDAw MDAwMDAwIGluID8/ICgpDQojNDMgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ ICgpDQojNDQgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpDQojNDUgMHgw MDAwMDAwMDAwMDAwMDAwIGluID8/ICgpDQojNDYgMHgwMDAwMDAwMDAwMDAw MDAwIGluID8/ICgpDQojNDcgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgp DQojNDggMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpDQojNDkgMHgwMDAw MDAwMDAwMDAwMDAwIGluID8/ICgpDQojNTAgMHgwMDAwMDAwMDAwMDAwMDAw IGluID8/ICgpDQojNTEgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpDQoj NTIgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpDQojNTMgMHgwMDAwMDAw MDAwMDAwMDAwIGluID8/ICgpDQojNTQgMHgwMDAwMDAwMDAwMDAwMDAwIGlu ID8/ICgpDQojNTUgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpDQojNTYg MHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpDQojNTcgMHgwMDAwMDAwMDAw MDAwMDAwIGluID8/ICgpDQojNTggMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ ICgpDQojNTkgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpDQojNjAgMHgw MDAwMDAwMDAwMDAwMDAwIGluID8/ICgpDQojNjEgMHgwMDAwMDAwMDAwMDAw MDAwIGluID8/ICgpDQojNjIgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgp DQojNjMgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpDQojNjQgMHgwMDAw MDAwMDAwMDAwMDAwIGluID8/ICgpDQojNjUgMHgwMDAwMDAwMDAwMDAwMDAw IGluID8/ICgpDQojNjYgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpDQoj NjcgMHgwMDAwMDAwMDAwODY4MDAwIGluID8/ICgpDQojNjggMHgwMDAwMDAw MDAwMGJiYTVkIGluID8/ICgpDQojNjkgMHgwMDAwMDAwMDAwMDAwMDAxIGlu ID8/ICgpDQojNzAgMHhmZmZmZmYwMGUzNTcxNWQwIGluID8/ICgpDQojNzEg MHhmZmZmZmYwMDNhODk3YzgwIGluID8/ICgpDQojNzIgMHhmZmZmZmZmZmIz NGUzOWQwIGluID8/ICgpDQojNzMgMHhmZmZmZmZmZmIzNGUzOWE4IGluID8/ ICgpDQojNzQgMHhmZmZmZmYwMGUzNThjMjgwIGluID8/ICgpDQojNzUgMHhm ZmZmZmZmZjgwMmMzNDJlIGluIHNjaGVkX3N3aXRjaCAodGQ9MHgwLCBuZXd0 ZD0weGZmZmZmZmZmODAzZjRkYjAsIGZsYWdzPTEpIGF0IC91c3Ivc3JjL3N5 cy9rZXJuL3NjaGVkXzRic2QuYzo4ODENClByZXZpb3VzIGZyYW1lIGlubmVy IHRvIHRoaXMgZnJhbWUgKGNvcnJ1cHQgc3RhY2s/KQ0KKGtnZGIpIGZyYW1l IDI4DQojMjggMHhmZmZmZmZmZjgwMmJiNmQ5IGluIHRocmVhZF9maW5pICht ZW09MHgwLCBzaXplPTApIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdGhy ZWFkLmM6MjY5DQoyNjkgICAgICAgICAgICAgS0FTU0VSVChibXAgIT0gTlVM TCwgKCJObyBUSUQgYml0bWFwPyIpKTsNCihrZ2RiKSBsDQoyNjQgICAgICAg ICAgICAgU1RBSUxRX0ZPUkVBQ0goYm1wLCAmdGlkX2JpdG1hcCwgYm1wX25l eHQpIHsNCjI2NSAgICAgICAgICAgICAgICAgICAgIGlmICh0ZC0+dGRfdGlk ID49IGJtcC0+Ym1wX2Jhc2UgJiYNCjI2NiAgICAgICAgICAgICAgICAgICAg ICAgICB0ZC0+dGRfdGlkIDwgYm1wLT5ibXBfYmFzZSArIFRJRF9JRFNfUEVS X1BBUlQpDQoyNjcgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJyZWFr Ow0KMjY4ICAgICAgICAgICAgIH0NCjI2OSAgICAgICAgICAgICBLQVNTRVJU KGJtcCAhPSBOVUxMLCAoIk5vIFRJRCBiaXRtYXA/IikpOw0KMjcwICAgICAg ICAgICAgIG10eF9sb2NrKCZ0aWRfbG9jayk7DQoyNzEgICAgICAgICAgICAg dGlkID0gdGQtPnRkX3RpZCAtIGJtcC0+Ym1wX2Jhc2U7DQoyNzIgICAgICAg ICAgICAgaWR4ID0gdGlkIC8gVElEX0lEU19QRVJfSURYOw0KMjczICAgICAg ICAgICAgIGJpdCA9IDFVTCA8PCAodGlkICUgVElEX0lEU19QRVJfSURYKTsN CihrZ2RiKSBwIGJtcA0KJDEgPSAoc3RydWN0IHRpZF9iaXRtYXBfcGFydCAq KSAweDANCihrZ2RiKSBpIHJlZw0KcmF4ICAgICAgICAgICAgMHgwICAgICAg MA0KcmJ4ICAgICAgICAgICAgMHgwICAgICAgMA0KcmN4ICAgICAgICAgICAg MHgwICAgICAgMA0KcmR4ICAgICAgICAgICAgMHgwICAgICAgMA0KcnNpICAg ICAgICAgICAgMHgwICAgICAgMA0KcmRpICAgICAgICAgICAgMHgwICAgICAg MA0KcmJwICAgICAgICAgICAgMHgwICAgICAgMHgwDQpyc3AgICAgICAgICAg ICAweGZmZmZmZmZmYjM0ZTNjNTAgICAgICAgMHhmZmZmZmZmZmIzNGUzYzUw DQpyOCAgICAgICAgICAgICAweDAgICAgICAwDQpyOSAgICAgICAgICAgICAw eDAgICAgICAwDQpyMTAgICAgICAgICAgICAweDAgICAgICAwDQpyMTEgICAg ICAgICAgICAweDAgICAgICAwDQpyMTIgICAgICAgICAgICAweGZmZmZmZmZm ODAzZjRkYjAgICAgICAgLTIxNDMzMzQ5OTINCnIxMyAgICAgICAgICAgIDB4 ZmZmZmZmZmY4MDYyOGVhMCAgICAgICAtMjE0MTAyNDYwOA0KcjE0ICAgICAg ICAgICAgMHgxICAgICAgMQ0KcjE1ICAgICAgICAgICAgMHgwICAgICAgMA0K cmlwICAgICAgICAgICAgMHhmZmZmZmZmZjgwNDA0OGZlICAgICAgIDB4ZmZm ZmZmZmY4MDQwNDhmZSA8Zm9ya190cmFtcG9saW5lKzE0Pg0KZWZsYWdzICAg ICAgICAgMHg4MiAgICAgMTMwDQpjcyAgICAgICAgICAgICAweDAgICAgICAw DQpzcyAgICAgICAgICAgICAweDAgICAgICAwDQpkcyAgICAgICAgICAgICAw eDAgICAgICAwDQplcyAgICAgICAgICAgICAweDAgICAgICAwDQpmcyAgICAg ICAgICAgICAweDAgICAgICAwDQpncyAgICAgICAgICAgICAweDAgICAgICAw DQooa2dkYikgbCAqMHhmZmZmZmZmZjgwNDA0OGZlDQoweGZmZmZmZmZmODA0 MDQ4ZmUgaXMgYXQgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L2V4Y2VwdGlv bi5TOjI5OC4NCjI5MyAgICAgICAgICAgICBtb3ZxICAgICVyMTIsICVyZGkg ICAgICAgICAgICAgIC8qIGZ1bmN0aW9uICovDQoyOTQgICAgICAgICAgICAg bW92cSAgICAlcmJ4LCAlcnNpICAgICAgICAgICAgICAvKiBhcmcxICovDQoy OTUgICAgICAgICAgICAgbW92cSAgICAlcnNwLCAlcmR4ICAgICAgICAgICAg ICAvKiB0cmFwZnJhbWUgcG9pbnRlciAqLw0KMjk2ICAgICAgICAgICAgIGNh bGwgICAgZm9ya19leGl0DQoyOTcgICAgICAgICAgICAgTUVYSVRDT1VOVA0K Mjk4ICAgICAgICAgICAgIGptcCAgICAgZG9yZXRpICAgICAgICAgICAgICAg ICAgLyogSGFuZGxlIGFueSBBU1RzICovDQoyOTkNCjMwMCAgICAgLyoNCjMw MSAgICAgICogVG8gZWZmaWNpZW50bHkgaW1wbGVtZW50IGNsYXNzaWZpY2F0 aW9uIG9mIHRyYXAgYW5kIGludGVycnVwdCBoYW5kbGVycw0KMzAyICAgICAg KiBmb3IgcHJvZmlsaW5nLCB0aGVyZSBtdXN0IGJlIG9ubHkgdHJhcCBoYW5k bGVycyBiZXR3ZWVuIHRoZSBsYWJlbHMgYnRyYXANCg0K --0-432868459-1128013586=:65402-- From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 29 17:19:01 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 0BA0916A41F for ; Thu, 29 Sep 2005 17:19:01 +0000 (GMT) (envelope-from stas@core.310.ru) Received: from core.310.ru (core.310.ru [83.97.105.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50A6143D53 for ; Thu, 29 Sep 2005 17:18:59 +0000 (GMT) (envelope-from stas@core.310.ru) Received: from core.310.ru (localhost [127.0.0.1]) by core.310.ru (8.13.3/8.12.11) with ESMTP id j8THF0dx011684 for ; Thu, 29 Sep 2005 21:15:00 +0400 (MSD) (envelope-from stas@core.310.ru) Received: (from stas@localhost) by core.310.ru (8.13.3/8.12.11/Submit) id j8THF0Nq011683 for freebsd-hackers@freebsd.org; Thu, 29 Sep 2005 21:15:00 +0400 (MSD) (envelope-from stas) Date: Thu, 29 Sep 2005 21:14:59 +0400 From: Stanislav Sedov To: freebsd-hackers@freebsd.org Message-ID: <20050929171459.GA11654@core.310.ru> Mail-Followup-To: freebsd-hackers@freebsd.org References: <433B3F41.8060004@spintech.ro> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <433B3F41.8060004@spintech.ro> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Fri, 30 Sep 2005 11:30:24 +0000 Subject: Re: journaling fs and large mailbox format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 17:19:01 -0000 On Thu, Sep 29, 2005 at 04:11:29AM +0300, Alin-Adrian Anton wrote: > Dear Hackers, > > First of all thank you for your time and attention. > > I am in the position to implement a large-scale mail server and I > will never go for anything else but FreeBSD (fixation?). > > It should be able to handle graceously 4000 e-mail accounts where a > minimum of 50 Mb/mailbox would be a requirement. In the begining, it is > desirable that users could use as much free space as available, so this > implies some gigabytes/mailbox. > > I don't know if the mbox format can handle this, and I know Maildir > cannot handle this on UFS2 standard install, no matter of soft-updates. > (because it exhaustes the free nodes) So I currently have no solution > for this stuff. > > I was wondering what is the status of Journaling File Systems on > FreeBSD? Any which is usable and mature, with write access? XFS would > fit amazingly well with Maildir, but.. I doubt it's anything else but > readonly. > > So any suggestion would really help a lot. Thank's in advance. > > > Yours Sincerely, > -- > Alin-Adrian Anton > GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) > gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA > > "It is dangerous to be right when the government is wrong." - Voltaire > Consider to use DBMS storage as alternative. IMHO, this is more flexible solution, especially if you have a lot of disk space. Also you will be able to buil a mail cluster to scale your solution. From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 29 20:17:59 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 DB62A16A41F; Thu, 29 Sep 2005 20:17:59 +0000 (GMT) (envelope-from rob@hudson-trading.com) Received: from daemon.mistermishap.net (167-49.nyc.dsl.access.net [166.84.167.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5285243D4C; Thu, 29 Sep 2005 20:17:58 +0000 (GMT) (envelope-from rob@hudson-trading.com) Received: from daemon.mistermishap.net (localhost.mistermishap.net [127.0.0.1]) by daemon.mistermishap.net (8.12.9/8.12.9) with ESMTP id j8TKHwmU067205; Thu, 29 Sep 2005 16:17:58 -0400 (EDT) (envelope-from rob@hudson-trading.com) Received: from localhost (rob@localhost) by daemon.mistermishap.net (8.12.9/8.12.9/Submit) with ESMTP id j8TKHvsk067202; Thu, 29 Sep 2005 16:17:58 -0400 (EDT) X-Authentication-Warning: daemon.mistermishap.net: rob owned process doing -bs Date: Thu, 29 Sep 2005 16:17:57 -0400 (EDT) From: Rob Watt X-X-Sender: rob@daemon.mistermishap.net To: Robert Watson In-Reply-To: <20050929185538.R61419@fledge.watson.org> Message-ID: <20050929160945.A65402@daemon.mistermishap.net> References: <20050925115912.H11229@fledge.watson.org> <20050927140535.G50334@daemon.mistermishap.net> <20050927203128.S61419@fledge.watson.org> <20050927222624.R34322@fledge.watson.org> <20050928134724.P56436@daemon.mistermishap.net> <20050929185538.R61419@fledge.watson.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-318985421-1128025077=:65402" X-Mailman-Approved-At: Fri, 30 Sep 2005 11:30:24 +0000 Cc: Rob Watt , mikep@hudson-trading.com, freebsd-hackers@FreeBSD.org, freebsd-amd64@FreeBSD.org, Jason Carroll Subject: Re: freebsd-5.4-stable panics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 20:18:00 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-318985421-1128025077=:65402 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 29 Sep 2005, Robert Watson wrote: > Could you dump the contents of *td and *td->td_proc for me? I'm quite > interested to know what the value in td->td_proc->p_state is, among other > things. If I could also have you generate a dump of the KSE group > structures in td->td_proc->p_ksegrps and the threads in > td->td_proc->p_threads. I've attached a file with many of the values you have asked for. We looked at some of the threads referenced by td->td_proc->p_threads, but we weren't sure we were walking the list correctly. Do you have any tips for walking those thread lists? > > Could you tell me if the program named by p->p_comm is linked against a > threading library? If it's a custom app, you may already know, and if > not, you can run ldd on the application to see what it is linked against. > The programs named by p->p_comm is linked against the pthreads library. > Depending on how much time you have available, it might make sense for me > to grab from you a copy of your source tree, compiled kernel with debug > symbols, and core dump. We can upload the source, kernel etc somewhere, but uncompressed that is about 5G of data. What is the best way to get that to you? Thanks. - Rob Watt --0-318985421-1128025077=:65402 Content-Type: APPLICATION/octet-stream; name="6.0-BETA5.kgdb.out" Content-Transfer-Encoding: BASE64 Content-Description: Content-Disposition: attachment; filename="6.0-BETA5.kgdb.out" W0dEQiB3aWxsIG5vdCBiZSBhYmxlIHRvIGRlYnVnIHVzZXItbW9kZSB0aHJl YWRzOiAvdXNyL2xpYi9saWJ0aHJlYWRfZGIuc286IFVuZGVmaW5lZCBzeW1i b2wgInBzX3BnbG9iYWxfbG9va3VwIl0KR05VIGdkYiA2LjEuMSBbRnJlZUJT RF0KQ29weXJpZ2h0IDIwMDQgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJ bmMuCkdEQiBpcyBmcmVlIHNvZnR3YXJlLCBjb3ZlcmVkIGJ5IHRoZSBHTlUg R2VuZXJhbCBQdWJsaWMgTGljZW5zZSwgYW5kIHlvdSBhcmUKd2VsY29tZSB0 byBjaGFuZ2UgaXQgYW5kL29yIGRpc3RyaWJ1dGUgY29waWVzIG9mIGl0IHVu ZGVyIGNlcnRhaW4gY29uZGl0aW9ucy4KVHlwZSAic2hvdyBjb3B5aW5nIiB0 byBzZWUgdGhlIGNvbmRpdGlvbnMuClRoZXJlIGlzIGFic29sdXRlbHkgbm8g d2FycmFudHkgZm9yIEdEQi4gIFR5cGUgInNob3cgd2FycmFudHkiIGZvciBk ZXRhaWxzLgpUaGlzIEdEQiB3YXMgY29uZmlndXJlZCBhcyAiYW1kNjQtbWFy Y2VsLWZyZWVic2QiLgoKVW5yZWFkIHBvcnRpb24gb2YgdGhlIGtlcm5lbCBt ZXNzYWdlIGJ1ZmZlcjoKa2VybmVsIHRyYXAgMTIgd2l0aCBpbnRlcnJ1cHRz IGRpc2FibGVkCgoKRmF0YWwgdHJhcCAxMjogcGFnZSBmYXVsdCB3aGlsZSBp biBrZXJuZWwgbW9kZQpjcHVpZCA9IDM7IGFwaWMgaWQgPSAwMwpmYXVsdCB2 aXJ0dWFsIGFkZHJlc3MgICA9IDB4NDgKZmF1bHQgY29kZSAgICAgICAgICAg ICAgPSBzdXBlcnZpc29yIHJlYWQsIHBhZ2Ugbm90IHByZXNlbnQKaW5zdHJ1 Y3Rpb24gcG9pbnRlciAgICAgPSAweDg6MHhmZmZmZmZmZjgwMmI4OTdhCnN0 YWNrIHBvaW50ZXIgICAgICAgICAgID0gMHgxMDoweGZmZmZmZmZmYjYyZDg0 OTAKZnJhbWUgcG9pbnRlciAgICAgICAgICAgPSAweDEwOjB4ZmZmZmZmZmZi NjJkODRmMApjb2RlIHNlZ21lbnQgICAgICAgICAgICA9IGJhc2UgMHgwLCBs aW1pdCAweGZmZmZmLCB0eXBlIDB4MWIKICAgICAgICAgICAgICAgICAgICAg ICAgPSBEUEwgMCwgcHJlcyAxLCBsb25nIDEsIGRlZjMyIDAsIGdyYW4gMQpw cm9jZXNzb3IgZWZsYWdzICAgICAgICA9IHJlc3VtZSwgSU9QTCA9IDAKY3Vy cmVudCBwcm9jZXNzICAgICAgICAgPSAyOTgxMCAodG9wKQpMb2NrZWQgdm5v ZGVzCgoweGZmZmZmZjAwM2E0YmM5YjA6IHRhZyB1ZnMsIHR5cGUgVlJFRwog ICAgdXNlY291bnQgMSwgd3JpdGVjb3VudCAxLCByZWZjb3VudCA4MDY5IG1v dW50ZWRoZXJlIDAKICAgIGZsYWdzICgpCiAgICB2X29iamVjdCAweGZmZmZm ZjAwY2ZiNWZkMjAgcmVmIDAgcGFnZXMgMzIyNjgKICAgICBsb2NrIHR5cGUg dWZzOiBFWENMIChjb3VudCAxKSBieSB0aHJlYWQgMHhmZmZmZmYwMDczMWFm NGMwIChwaWQgMjk4MDkpCiAgICAgICAgaW5vIDIwNDY2Njk5LCBvbiBkZXYg YWFjZDBzMWUKUHJvY2VzcyAyOTgxMCAodG9wKSB0aHJlYWQgMHhmZmZmZmYw MDRhZmZjYmUwICgxMDAwOTcpCmV4Y2x1c2l2ZSBzbGVlcCBtdXRleCBwcm9j ZXNzIGxvY2sgciA9IDAgKDB4ZmZmZmZmMDA0YWE5ZjBjMCkgbG9ja2VkIEAg L3Vzci9zcmMvc3lzL2tlcm4va2Vybl9wcm9jLmM6ODkwCnNoYXJlZCBzeCBh bGxwcm9jIHIgPSAwICgweGZmZmZmZmZmODA2NDM0ZTApIGxvY2tlZCBAIC91 c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJvYy5jOjIyOQpleGNsdXNpdmUgc3gg c3lzY3RsIGxvY2sgciA9IDAgKDB4ZmZmZmZmZmY4MDY0M2QwMCkgbG9ja2Vk IEAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zeXNjdGwuYzoxMzQyCmV4Y2x1 c2l2ZSBzbGVlcCBtdXRleCBHaWFudCByID0gMCAoMHhmZmZmZmZmZjgwNjQz MzYwKSBsb2NrZWQgQCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3N5c2N0bC5j OjEyODAKUHJvY2VzcyAyNTA1NyAoZGF0YXBsYXkpIHRocmVhZCAweGZmZmZm ZjAwMTU2ZmIyNjAgKDEwMDA5MSkKZXhjbHVzaXZlIHNsZWVwIG11dGV4IGlu cCAodWRwaW5wKSByID0gMCAoMHhmZmZmZmYwMGE4MjZiOTM4KSBsb2NrZWQg QCAvdXNyL3NyYy9zeXMvbmV0aW5ldC91ZHBfdXNycmVxLmM6NzYyCkR1bXBp bmcgMzc1OSBNQiAoMiBjaHVua3MpCiAgY2h1bmsgMDogMU1CICgxNTUgcGFn ZXMpIC4uLiBvawogIGNodW5rIDE6IDM3NTlNQiAoOTYyMjg4IHBhZ2VzKSAz NzQzIDM3MjcgMzcxMSAzNjk1IDM2NzkgMzY2MyAzNjQ3IDM2MzEgMzYxNSAz NTk5IDM1ODMgMzU2NyAzNTUxIDM1MzUgMzUxOSAzNTAzIDM0ODcgMzQ3MSAz NDU1IDM0MzkgMzQyMyAzNDA3IDMzOTEgMzM3NSAzMzU5IDMzNDMgMzMyNyAz MzExIDMyOTUgMzI3OSAzMjYzIDMyNDcgMzIzMSAzMjE1IDMxOTkgMzE4MyAz MTY3IDMxNTEgMzEzNSAzMTE5IDMxMDMgMzA4NyAzMDcxIDMwNTUgMzAzOSAz MDIzIDMwMDcgMjk5MSAyOTc1IDI5NTkgMjk0MyAyOTI3IDI5MTEgMjg5NSAy ODc5IDI4NjMgMjg0NyAyODMxIDI4MTUgMjc5OSAyNzgzIDI3NjcgMjc1MSAy NzM1IDI3MTkgMjcwMyAyNjg3IDI2NzEgMjY1NSAyNjM5IDI2MjMgMjYwNyAy NTkxIDI1NzUgMjU1OSAyNTQzIDI1MjcgMjUxMSAyNDk1IDI0NzkgMjQ2MyAy NDQ3IDI0MzEgMjQxNSAyMzk5IDIzODMgMjM2NyAyMzUxIDIzMzUgMjMxOSAy MzAzIDIyODcgMjI3MSAyMjU1IDIyMzkgMjIyMyAyMjA3IDIxOTEgMjE3NSAy MTU5IDIxNDMgMjEyNyAyMTExIDIwOTUgMjA3OSAyMDYzIDIwNDcgMjAzMSAy MDE1IDE5OTkgMTk4MyAxOTY3IDE5NTEgMTkzNSAxOTE5IDE5MDMgMTg4NyAx ODcxIDE4NTUgMTgzOSAxODIzIDE4MDcgMTc5MSAxNzc1IDE3NTkgMTc0MyAx NzI3IDE3MTEgMTY5NSAxNjc5IDE2NjMgMTY0NyAxNjMxIDE2MTUgMTU5OSAx NTgzIDE1NjcgMTU1MSAxNTM1IDE1MTkgMTUwMyAxNDg3IDE0NzEgMTQ1NSAx NDM5IDE0MjMgMTQwNyAxMzkxIDEzNzUgMTM1OSAxMzQzIDEzMjcgMTMxMSAx Mjk1IDEyNzkgMTI2MyAxMjQ3IDEyMzEgMTIxNSAxMTk5IDExODMgMTE2NyAx MTUxIDExMzUgMTExOSAxMTAzIDEwODcgMTA3MSAxMDU1IDEwMzkgMTAyMyAx MDA3IDk5MSA5NzUgOTU5IDk0MyA5MjcgOTExIDg5NSA4NzkgODYzIDg0NyA4 MzEgODE1IDc5OSA3ODMgNzY3IDc1MSA3MzUgNzE5IDcwMyA2ODcgNjcxIDY1 NSA2MzkgNjIzIDYwNyA1OTEgNTc1IDU1OSA1NDMgNTI3IDUxMSA0OTUgNDc5 IDQ2MyA0NDcgNDMxIDQxNSAzOTkgMzgzIDM2NyAzNTEgMzM1IDMxOSAzMDMg Mjg3IDI3MSAyNTUgMjM5IDIyMyAyMDcgMTkxIDE3NSAxNTkgMTQzIDEyNyAx MTEgOTUgNzkgNjMgNDcgMzEgMTUKCiMwICBkb2FkdW1wICgpIGF0IHBjcHUu aDoxNzIKMTcyICAgICBwY3B1Lmg6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3Rv cnkuCiAgICAgICAgaW4gcGNwdS5oCihrZ2RiKSBidAojMCAgZG9hZHVtcCAo KSBhdCBwY3B1Lmg6MTcyCiMxICAweGZmZmZmZmZmODAxOTc2YjEgaW4gZGJf Zm5jYWxsIChkdW1teTE9MCwgZHVtbXkyPTAsIGR1bW15Mz0wLCBkdW1teTQ9 MHgwKQogICAgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9jb21tYW5kLmM6NDg5 CiMyICAweGZmZmZmZmZmODAxOTdiMDUgaW4gZGJfY29tbWFuZF9sb29wICgp IGF0IC91c3Ivc3JjL3N5cy9kZGIvZGJfY29tbWFuZC5jOjM0OQojMyAgMHhm ZmZmZmZmZjgwMTk5OTczIGluIGRiX3RyYXAgKHR5cGU9LTEyMzg1MzE0NTYs IGNvZGU9MCkgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9tYWluLmM6MjIxCiM0 ICAweGZmZmZmZmZmODAyZGI5YmUgaW4ga2RiX3RyYXAgKHR5cGU9MTIsIGNv ZGU9MCwgdGY9MHhmZmZmZmZmZjgwNWUxZjAwKQogICAgYXQgL3Vzci9zcmMv c3lzL2tlcm4vc3Vicl9rZGIuYzo0NzMKIzUgIDB4ZmZmZmZmZmY4MDQyYzFi ZSBpbiB0cmFwX2ZhdGFsIChmcmFtZT0weGZmZmZmZmZmYjYyZDgzZTAsIGV2 YT0xODQ0Njc0Mjk3NTQ1NjIwMTY5NikKICAgIGF0IC91c3Ivc3JjL3N5cy9h bWQ2NC9hbWQ2NC90cmFwLmM6NjU2CiM2ICAweGZmZmZmZmZmODA0MmM2ZjMg aW4gdHJhcCAoZnJhbWU9CiAgICAgIHt0Zl9yZGkgPSAwLCB0Zl9yc2kgPSAw LCB0Zl9yZHggPSAyOTksIHRmX3JjeCA9IDkzODcyOCwgdGZfcjggPSAyNTA1 OSwgdGZfcjkgPSAzMjk2LCB0Zl9yYXggPSAwLCB0Zl9yYnggPSAwLCB0Zl9y YnAgPSAtMTIzODUzMDgzMiwgdGZfcjEwID0gMSwgdGZfcjExID0gNDI5NDk2 NzI5NCwgdGZfcjEyID0gLTEyMzg1MzA4MDAsIHRmX3IxMyA9IDYsIHRmX3Ix NCA9IC0xMDk4MjU4OTc2NzY4LCB0Zl9yMTUgPSAtMTA5Nzg0NzQ2NzQyNCwg dGZfdHJhcG5vID0gMTIsIHRmX2FkZHIgPSA3MiwgdGZfZmxhZ3MgPSAtMTA5 NzcyNzg2OTc4NCwgdGZfZXJyID0gMCwgdGZfcmlwID0gLTIxNDQ2MzA0MDYs IHRmX2NzID0gOCwgdGZfcmZsYWdzID0gNjU1NTksIHRmX3JzcCA9IC0xMjM4 NTMwOTEyLCB0Zl9zcyA9IDE2fSkKICAgIGF0IC91c3Ivc3JjL3N5cy9hbWQ2 NC9hbWQ2NC90cmFwLmM6MjQxCiM3ICAweGZmZmZmZmZmODA0MWEwZWIgaW4g Y2FsbHRyYXAgKCkgYXQgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L2V4Y2Vw dGlvbi5TOjE2OAojOCAgMHhmZmZmZmZmZjgwMmI4OTdhIGluIGZpbGxfa2lu Zm9fdGhyZWFkICh0ZD0weGZmZmZmZjAwNjMzMTEyNjAsIGtwPTB4ZmZmZmZm ZmZiNjJkODUxMCkKICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJv Yy5jOjczMwojOSAgMHhmZmZmZmZmZjgwMmI5Mjg2IGluIHN5c2N0bF9vdXRf cHJvYyAocD0weGZmZmZmZjAwNGFhOWYwMDAsIHJlcT0weGZmZmZmZmZmYjYy ZDhhMjAsIGZsYWdzPTApCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJu X3Byb2MuYzo4ODYKIzEwIDB4ZmZmZmZmZmY4MDJiOTVjMSBpbiBzeXNjdGxf a2Vybl9wcm9jIChvaWRwPTB4MCwgYXJnMT0weDAsIGFyZzI9Mjk5LCByZXE9 MHhmZmZmZmZmZmI2MmQ4YTIwKQogICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4v a2Vybl9wcm9jLmM6MTA3NQojMTEgMHhmZmZmZmZmZjgwMmM3ZDIwIGluIHN5 c2N0bF9yb290IChvaWRwPTB4MCwgYXJnMT0weDAsIGFyZzI9MCwgcmVxPTB4 ZmZmZmZmZmZiNjJkOGEyMCkKICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tl cm5fc3lzY3RsLmM6MTI0OAojMTIgMHhmZmZmZmZmZjgwMmM4MTljIGluIHVz ZXJsYW5kX3N5c2N0bCAodGQ9MHhmZmZmZmYwMDRhZmZjYmUwLCBuYW1lPTB4 ZmZmZmZmZmZiNjJkOGFmMCwgbmFtZWxlbj0zLAogICAgb2xkPTB4NTk2MDAw LCBvbGRsZW5wPTB4N2ZmZmZmZmZlNGY4LCBpbmtlcm5lbD0wLCBuZXc9MHgw LCBuZXdsZW49MCwgcmV0dmFsPTB4ZmZmZmZmZmZiNjJkOGFlOCwgZmxhZ3M9 MCkKICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc3lzY3RsLmM6MTM0 NwojMTMgMHhmZmZmZmZmZjgwMmM4MzJkIGluIF9fc3lzY3RsICh0ZD0weGZm ZmZmZjAwNGFmZmNiZTAsIHVhcD0weGZmZmZmZmZmYjYyZDhiYzApCiAgICBh dCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3N5c2N0bC5jOjEyODIKIzE0IDB4 ZmZmZmZmZmY4MDQyY2Y2MiBpbiBzeXNjYWxsIChmcmFtZT0KICAgICAge3Rm X3JkaSA9IDE0MDczNzQ4ODM0ODUxMiwgdGZfcnNpID0gMywgdGZfcmR4ID0g NTg1NzI4MCwgdGZfcmN4ID0gMTQwNzM3NDg4MzQ4NDA4LCB0Zl9yOCA9IDAs IHRmX3I5ID0gMCwgdGZfcmF4ID0gMjAyLCB0Zl9yYnggPSA1ODUzMTg0LCB0 Zl9yYnAgPSAwLCB0Zl9yMTAgPSAxLCB0Zl9yMTEgPSA1MTQsIHRmX3IxMiA9 IDE0MDczNzQ4ODM0ODUxMiwgdGZfcjEzID0gMTQwNy0tLVR5cGUgPHJldHVy bj4gdG8gY29udGludWUsIG9yIHEgPHJldHVybj4gdG8gcXVpdC0tLXEKUXVp dAopIGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC90cmFwLmM6Nzk3CiMx NSAweGZmZmZmZmZmODA0MWEyODggaW4gWGZhc3Rfc3lzY2FsbCAoKSBhdCAv dXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvZXhjZXB0aW9uLlM6MjcwCiMxNiAw eDAwMDAwMDA4MDA5ZmRhZGMgaW4gPz8gKCkKUHJldmlvdXMgZnJhbWUgaW5u ZXIgdG8gdGhpcyBmcmFtZSAoY29ycnVwdCBzdGFjaz8pCihrZ2RiKSBmcmFt ZSA4CiM4ICAweGZmZmZmZmZmODAyYjg5N2EgaW4gZmlsbF9raW5mb190aHJl YWQgKHRkPTB4ZmZmZmZmMDA2MzMxMTI2MCwga3A9MHhmZmZmZmZmZmI2MmQ4 NTEwKQogICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9wcm9jLmM6NzMz CjczMyAgICAgICAgICAgICAgICAgICAgIGtnID0gdGQtPnRkX2tzZWdycDsK KGtnZGIpIGwKNzI4ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9Cjcy OSAgICAgICAgICAgICAgICAgICAgIH0gZWxzZSB7CjczMCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAga3AtPmtpX3N0YXQgPSBTSURMOwo3MzEgICAg ICAgICAgICAgICAgICAgICB9CjczMgo3MzMgICAgICAgICAgICAgICAgICAg ICBrZyA9IHRkLT50ZF9rc2VncnA7CjczNAo3MzUgICAgICAgICAgICAgICAg ICAgICAvKiB0aGluZ3MgaW4gdGhlIEtTRSBHUk9VUCAqLwo3MzYgICAgICAg ICAgICAgICAgICAgICBrcC0+a2lfZXN0Y3B1ID0ga2ctPmtnX2VzdGNwdTsK NzM3ICAgICAgICAgICAgICAgICAgICAga3AtPmtpX3NscHRpbWUgPSBrZy0+ a2dfc2xwdGltZTsKKGtnZGIpIHAgKnRkCiQxID0ge3RkX3Byb2MgPSAweGZm ZmZmZjAwNGFhOWYwMDAsIHRkX2tzZWdycCA9IDB4MCwgdGRfcGxpc3QgPSB7 dHFlX25leHQgPSAweGZmZmZmZjAwYjQ3OTgwMDAsCiAgICB0cWVfcHJldiA9 IDB4ZmZmZmZmMDBhOTdhZTAxMH0sIHRkX2tnbGlzdCA9IHt0cWVfbmV4dCA9 IDB4ZmZmZmZmMDBiNDc5ODAwMCwKICAgIHRxZV9wcmV2ID0gMHhmZmZmZmYw MGE5N2FlMDIwfSwgdGRfc2xwcSA9IHt0cWVfbmV4dCA9IDB4MCwgdHFlX3By ZXYgPSAweGZmZmZmZjAwMWZhYzdjMTB9LCB0ZF9sb2NrcSA9IHsKICAgIHRx ZV9uZXh0ID0gMHhmZmZmZmYwMGE5N2FlMDAwLCB0cWVfcHJldiA9IDB4ZmZm ZmZmZmZiNjc5N2E3MH0sIHRkX3J1bnEgPSB7dHFlX25leHQgPSAweDAsCiAg ICB0cWVfcHJldiA9IDB4ZmZmZmZmZmY4MDYwODE4MH0sIHRkX3NlbHEgPSB7 dHFoX2ZpcnN0ID0gMHgwLCB0cWhfbGFzdCA9IDB4ZmZmZmZmMDA2MzMxMTJj MH0sCiAgdGRfc2xlZXBxdWV1ZSA9IDB4ZmZmZmZmMDAzODJiMDQwMCwgdGRf dHVybnN0aWxlID0gMHhmZmZmZmYwMGMxNzEyOTAwLCB0ZF91bXR4cSA9IDB4 ZmZmZmZmMDBkMTIwNzA4MCwKICB0ZF90aWQgPSAxMDAyNTMsIHRkX2ZsYWdz ID0gMTY3NzcyMTYsIHRkX2luaGliaXRvcnMgPSAwLCB0ZF9wZmxhZ3MgPSAx MjgsIHRkX2R1cGZkID0gMCwgdGRfd2NoYW4gPSAweDAsCiAgdGRfd21lc2cg PSAweDAsIHRkX2xhc3RjcHUgPSAyICdcMDAyJywgdGRfb25jcHUgPSAyICdc MDAyJywgdGRfb3dlcHJlZW1wdCA9IDAgJ1wwJywgdGRfbG9ja3MgPSAwLAog IHRkX2Jsb2NrZWQgPSAweDAsIHRkX2l0aGQgPSAweDAsIHRkX2xvY2tuYW1l ID0gMHgwLCB0ZF9jb250ZXN0ZWQgPSB7bGhfZmlyc3QgPSAweDB9LCB0ZF9z bGVlcGxvY2tzID0gMHgwLAogIHRkX2ludHJfbmVzdGluZ19sZXZlbCA9IDAs IHRkX3Bpbm5lZCA9IDAsIHRkX21haWxib3ggPSAweDAsIHRkX3VjcmVkID0g MHhmZmZmZmYwMGFkMThmMjAwLAogIHRkX3N0YW5kaW4gPSAweDAsIHRkX3Vw Y2FsbCA9IDB4MCwgdGRfc3RpY2tzID0gMCwgdGRfdXV0aWNrcyA9IDAsIHRk X3VzdGlja3MgPSAwLCB0ZF9pbnRydmFsID0gMCwKICB0ZF9vbGRzaWdtYXNr ID0ge19fYml0cyA9IHswLCAwLCAwLCAwfX0sIHRkX3NpZ21hc2sgPSB7X19i aXRzID0gezQyOTQ5NjcyOTUsIDQyOTQ5NjcyOTUsIDQyOTQ5NjcyOTUsCiAg ICAgIDQyOTQ5NjcyOTV9fSwgdGRfc2lnbGlzdCA9IHtfX2JpdHMgPSB7MCwg MCwgMCwgMH19LCB0ZF9nZW5lcmF0aW9uID0gMTQsIHRkX3NpZ3N0ayA9IHtz c19zcCA9IDB4MCwKICAgIHNzX3NpemUgPSAwLCBzc19mbGFncyA9IDB9LCB0 ZF9rZmxhZ3MgPSAwLCB0ZF94c2lnID0gMCwgdGRfcHJvZmlsX2FkZHIgPSAw LCB0ZF9wcm9maWxfdGlja3MgPSAwLAogIHRkX2Jhc2VfcHJpID0gMTgyICdc dWZmZmYnLCB0ZF9wcmlvcml0eSA9IDE4MiAnXHVmZmZmJywgdGRfcGNiID0g MHhmZmZmZmZmZmI2OGRjZDEwLCB0ZF9zdGF0ZSA9IFREU19JTkFDVElWRSwK ICB0ZF9yZXR2YWwgPSB7MSwgMjkzMDkyODB9LCB0ZF9zbHBjYWxsb3V0ID0g e2NfbGlua3MgPSB7c2xlID0ge3NsZV9uZXh0ID0gMHgwfSwgdHFlID0ge3Rx ZV9uZXh0ID0gMHgwLAogICAgICAgIHRxZV9wcmV2ID0gMHhmZmZmZmYwMDFm YWM3ZDgwfX0sIGNfdGltZSA9IDU1OTA3NjAyLCBjX2FyZyA9IDB4ZmZmZmZm MDA2MzMxMTI2MCwKICAgIGNfZnVuYyA9IDB4ZmZmZmZmZmY4MDJlMzJhMCA8 c2xlZXBxX3RpbWVvdXQ+LCBjX210eCA9IDB4MCwgY19mbGFncyA9IDE2fSwg dGRfZnJhbWUgPSAweGZmZmZmZmZmYjY4ZGNjNDAsCiAgdGRfa3N0YWNrX29i aiA9IDB4ZmZmZmZmMDA4N2Y5M2QyMCwgdGRfa3N0YWNrID0gMTg0NDY3NDQw NzI0NzczMTUwNzIsIHRkX2tzdGFja19wYWdlcyA9IDQsCiAgdGRfYWx0a3N0 YWNrX29iaiA9IDB4MCwgdGRfYWx0a3N0YWNrID0gMCwgdGRfYWx0a3N0YWNr X3BhZ2VzID0gMCwgdGRfY3JpdG5lc3QgPSAxLCB0ZF9tZCA9IHsKICAgIG1k X3NwaW5sb2NrX2NvdW50ID0gMSwgbWRfc2F2ZWRfZmxhZ3MgPSA1ODJ9LCB0 ZF9zY2hlZCA9IDB4ZmZmZmZmMDA2MzMxMTQ4OH0KKGtnZGIpIHAgKnRkLT50 ZF9wcm9jCiQyID0ge3BfbGlzdCA9IHtsZV9uZXh0ID0gMHhmZmZmZmYwMGI1 OTA4MzQwLCBsZV9wcmV2ID0gMHhmZmZmZmYwMGI0MjAwMzQwfSwgcF9rc2Vn cnBzID0gewogICAgdHFoX2ZpcnN0ID0gMHhmZmZmZmYwMGI1YmU1MjQwLCB0 cWhfbGFzdCA9IDB4ZmZmZmZmMDA0YWE5ZTVhOH0sIHBfdGhyZWFkcyA9IHsK ICAgIHRxaF9maXJzdCA9IDB4ZmZmZmZmMDA2Zjg3MjAwMCwgdHFoX2xhc3Qg PSAweGZmZmZmZjAwNDI1NmYyNzB9LCBwX3N1c3BlbmRlZCA9IHt0cWhfZmly c3QgPSAweDAsCiAgICB0cWhfbGFzdCA9IDB4ZmZmZmZmMDA0YWE5ZjAzMH0s IHBfdWNyZWQgPSAweGZmZmZmZjAwYWQxOGYyMDAsIHBfZmQgPSAweGZmZmZm ZjAwYTM5ZmVhMDAsIHBfZmR0b2wgPSAweDAsCiAgcF9zdGF0cyA9IDB4ZmZm ZmZmMDAzMjE1NTgwMCwgcF9saW1pdCA9IDB4ZmZmZmZmMDBhMmNiMWEwMCwg cF9zaWdhY3RzID0gMHhmZmZmZmYwMDZhNTFmMDAwLAogIHBfZmxhZyA9IDQ5 MjgyLCBwX3NmbGFnID0gMSwgcF9zdGF0ZSA9IFBSU19OT1JNQUwsIHBfcGlk ID0gMjUwNTksIHBfaGFzaCA9IHtsZV9uZXh0ID0gMHgwLAogICAgbGVfcHJl diA9IDB4ZmZmZmZmZmY4MGEzZGYxOH0sIHBfcGdsaXN0ID0ge2xlX25leHQg PSAweGZmZmZmZjAwYjU5MDgzNDAsIGxlX3ByZXYgPSAweGZmZmZmZjAwYjQy MDAzZDB9LAogIHBfcHB0ciA9IDB4ZmZmZmZmMDBlMzdlMjljMCwgcF9zaWJs aW5nID0ge2xlX25leHQgPSAweGZmZmZmZjAwYjQyMDAzNDAsIGxlX3ByZXYg PSAweGZmZmZmZjAwYjU5MDgzZTh9LAogIHBfY2hpbGRyZW4gPSB7bGhfZmly c3QgPSAweDB9LCBwX210eCA9IHttdHhfb2JqZWN0ID0ge2xvX2NsYXNzID0g MHhmZmZmZmZmZjgwNjA1M2YwLAogICAgICBsb19uYW1lID0gMHhmZmZmZmZm ZjgwNGE0MWNlICJwcm9jZXNzIGxvY2siLCBsb190eXBlID0gMHhmZmZmZmZm ZjgwNGE0MWNlICJwcm9jZXNzIGxvY2siLAogICAgICBsb19mbGFncyA9IDQz OTA5MTIsIGxvX2xpc3QgPSB7dHFlX25leHQgPSAweGZmZmZmZjAwNGFhOWY0 MDAsIHRxZV9wcmV2ID0gMHhmZmZmZmYwMDRhZGJhYWEwfSwKICAgICAgbG9f d2l0bmVzcyA9IDB4ZmZmZmZmZmY4MDY2MGU2MH0sIG10eF9sb2NrID0gMTg0 NDY3NDI5NzU0NTYyMDE2OTgsIG10eF9yZWN1cnNlID0gMH0sIHBfb3BwaWQg PSAwLAogIHBfdm1zcGFjZSA9IDB4ZmZmZmZmMDBiMDZhNDg4MCwgcF9zd3Rp bWUgPSAzMjk2LCBwX3JlYWx0aW1lciA9IHtpdF9pbnRlcnZhbCA9IHt0dl9z ZWMgPSAwLCB0dl91c2VjID0gMH0sCiAgICBpdF92YWx1ZSA9IHt0dl9zZWMg PSAwLCB0dl91c2VjID0gMH19LCBwX3J1eCA9IHtydXhfcnVudGltZSA9IHtz ZWMgPSAyOTksIGZyYWMgPSAxNzMxNjQ4MTIwNTIyMzkwNDgyNH0sCiAgICBy dXhfdXRpY2tzID0gMzkxNCwgcnV4X3N0aWNrcyA9IDM1MDQyLCBydXhfaXRp Y2tzID0gMCwgcnV4X3V1ID0gMzAxMzU0MjQsIHJ1eF9zdSA9IDI2OTgwMjEz NSwKICAgIHJ1eF9pdSA9IDF9LCBwX2NydXggPSB7cnV4X3J1bnRpbWUgPSB7 c2VjID0gMCwgZnJhYyA9IDB9LCBydXhfdXRpY2tzID0gMCwgcnV4X3N0aWNr cyA9IDAsCiAgICBydXhfaXRpY2tzID0gMCwgcnV4X3V1ID0gMCwgcnV4X3N1 ID0gMCwgcnV4X2l1ID0gMH0sIHBfcHJvZnRocmVhZHMgPSAwLCBwX21heHRo cndhaXRzID0gMCwKICBwX3RyYWNlZmxhZyA9IDAsIHBfdHJhY2V2cCA9IDB4 MCwgcF90cmFjZWNyZWQgPSAweDAsIHBfdGV4dHZwID0gMHhmZmZmZmYwMGI2 MGEyMWYwLCBwX3NpZ2xpc3QgPSB7X19iaXRzID0gewogICAgICAwLCAwLCAw LCAwfX0sIHBfbG9jayA9IDEgJ1wwMDEnLCBwX3NpZ2lvbHN0ID0ge3NsaF9m aXJzdCA9IDB4MH0sIHBfc2lncGFyZW50ID0gMjAsIHBfc2lnID0gMCwKICBw X2NvZGUgPSAwLCBwX3N0b3BzID0gMCwgcF9zdHlwZSA9IDAsIHBfc3RlcCA9 IDAgJ1wwJywgcF9wZnNmbGFncyA9IDAgJ1wwJywgcF9ubG1pbmZvID0gMHgw LAogIHBfYWlvaW5mbyA9IDB4MCwgcF9zaW5nbGV0aHJlYWQgPSAweDAsIHBf c3VzcGNvdW50ID0gMCwgcF94dGhyZWFkID0gMHgwLCBwX2JvdW5kYXJ5X2Nv dW50ID0gMCwKICBwX3Byb2NzY29wZWdycCA9IDB4MCwgcF9tYWdpYyA9IDMy MDMzOTgzNTAsCiAgcF9jb21tID0gImNxc2ZlZWRcMDAwNlwwMDBcMDAwXDAw MFwwMDBcMDAwXDAwMFwwMDBcMDAwXDAwMFwwMDAiLCBwX3BncnAgPSAweGZm ZmZmZjAwYTBmNmYzODAsCiAgcF9zeXNlbnQgPSAweGZmZmZmZmZmODA2MjVj ODAsIHBfYXJncyA9IDB4ZmZmZmZmMDA1ZGNhYmQ4MCwgcF9jcHVsaW1pdCA9 IDkyMjMzNzIwMzY4NTQ3NzU4MDcsCiAgcF9uaWNlID0gMCAnXDAnLCBwX3hz dGF0ID0gMCwgcF9rbGlzdCA9IHtrbF9saXN0ID0ge3NsaF9maXJzdCA9IDB4 MH0sCiAgICBrbF9sb2NrID0gMHhmZmZmZmZmZjgwMmExNWYwIDxrbmxpc3Rf bXR4X2xvY2s+LCBrbF91bmxvY2sgPSAweGZmZmZmZmZmODAyYTE2MTAgPGtu bGlzdF9tdHhfdW5sb2NrPiwKICAgIGtsX2xvY2tlZCA9IDB4ZmZmZmZmZmY4 MDJhMTYzMCA8a25saXN0X210eF9sb2NrZWQ+LCBrbF9sb2NrYXJnID0gMHhm ZmZmZmYwMDRhYTlmMGMwfSwgcF9udW10aHJlYWRzID0gNiwKICBwX251bWtz ZWdycHMgPSAyLCBwX21kID0gPGluY29tcGxldGUgdHlwZT4sIHBfaXRjYWxs b3V0ID0ge2NfbGlua3MgPSB7c2xlID0ge3NsZV9uZXh0ID0gMHgwfSwgdHFl ID0gewogICAgICAgIHRxZV9uZXh0ID0gMHgwLCB0cWVfcHJldiA9IDB4MH19 LCBjX3RpbWUgPSAwLCBjX2FyZyA9IDB4MCwgY19mdW5jID0gMCwgY19tdHgg PSAweDAsIGNfZmxhZ3MgPSAxNn0sCiAgcF9hY2ZsYWcgPSAwLCBwX3J1ID0g MHgwLCBwX3BlZXJzID0gMHgwLCBwX2xlYWRlciA9IDB4ZmZmZmZmMDA0YWE5 ZjAwMCwgcF9lbXVsZGF0YSA9IDB4MCwgcF9sYWJlbCA9IDB4MCwKICBwX3Nj aGVkID0gMHhmZmZmZmYwMDRhYTlmMzQwfQoKKGtnZGIpIHAgdGQtPnRkX3By b2MtPnBfa3NlZ3JwcwokNiA9IHt0cWhfZmlyc3QgPSAweGZmZmZmZjAwYjVi ZTUyNDAsIHRxaF9sYXN0ID0gMHhmZmZmZmYwMDRhYTllNWE4fQooa2dkYikg cCAqdGQtPnRkX3Byb2MtPnBfa3NlZ3Jwcy50cWhfZmlyc3QKJDggPSB7a2df cHJvYyA9IDB4ZmZmZmZmMDA0YWE5ZjAwMCwga2dfa3NlZ3JwID0ge3RxZV9u ZXh0ID0gMHhmZmZmZmYwMDRhYTllNWEwLAogICAgdHFlX3ByZXYgPSAweGZm ZmZmZjAwNGFhOWYwMTB9LCBrZ190aHJlYWRzID0ge3RxaF9maXJzdCA9IDB4 ZmZmZmZmMDA0MjU2ZjI2MCwKICAgIHRxaF9sYXN0ID0gMHhmZmZmZmYwMDQy NTZmMjgwfSwga2dfcnVucSA9IHt0cWhfZmlyc3QgPSAweDAsIHRxaF9sYXN0 ID0gMHhmZmZmZmYwMGI1YmU1MjY4fSwKICBrZ191cGNhbGxzID0ge3RxaF9m aXJzdCA9IDB4ZmZmZmZmMDBhZTQxNmNjMCwgdHFoX2xhc3QgPSAweGZmZmZm ZjAwYWU0MTZjYzB9LCBrZ19lc3RjcHUgPSAwLAogIGtnX3NscHRpbWUgPSAy LCBrZ19udW11cGNhbGxzID0gMSwga2dfdXBzbGVlcHMgPSAwLCBrZ19jb21w bGV0ZWQgPSAweDAsIGtnX25leHR1cGNhbGwgPSAwLAogIGtnX3VwcXVhbnR1 bSA9IDAsIGtnX3ByaV9jbGFzcyA9IDMgJ1wwMDMnLCBrZ191c2VyX3ByaSA9 IDE4MCAnXHVmZmZmJywga2dfbnVtdGhyZWFkcyA9IDEsCiAga2dfc2NoZWQg PSAweGZmZmZmZjAwYjViZTUyYjh9CihrZ2RiKSBwICp0ZC0+dGRfcHJvYy0+ cF9rc2VncnBzLnRxaF9maXJzdC5rZ19rc2VncnAudHFlX25leHQKJDkgPSB7 a2dfcHJvYyA9IDB4ZmZmZmZmMDA0YWE5ZjAwMCwga2dfa3NlZ3JwID0ge3Rx ZV9uZXh0ID0gMHgwLCB0cWVfcHJldiA9IDB4ZmZmZmZmMDBiNWJlNTI0OH0s CiAga2dfdGhyZWFkcyA9IHt0cWhfZmlyc3QgPSAweGZmZmZmZjAwNmY4NzIw MDAsIHRxaF9sYXN0ID0gMHhmZmZmZmYwMGI0Nzk4MDIwfSwga2dfcnVucSA9 IHt0cWhfZmlyc3QgPSAweDAsCiAgICB0cWhfbGFzdCA9IDB4ZmZmZmZmMDA0 YWE5ZTVjOH0sIGtnX3VwY2FsbHMgPSB7dHFoX2ZpcnN0ID0gMHhmZmZmZmYw MGFlNDE2ZDIwLAogICAgdHFoX2xhc3QgPSAweGZmZmZmZjAwYTlmZmQ3ODB9 LCBrZ19lc3RjcHUgPSA5MSwga2dfc2xwdGltZSA9IDAsIGtnX251bXVwY2Fs bHMgPSA0LCBrZ191cHNsZWVwcyA9IDMsCiAga2dfY29tcGxldGVkID0gMHgw LCBrZ19uZXh0dXBjYWxsID0gMjY1OTgzNDEsIGtnX3VwcXVhbnR1bSA9IDIw LCBrZ19wcmlfY2xhc3MgPSAzICdcMDAzJywKICBrZ191c2VyX3ByaSA9IDE4 MiAnXHVmZmZmJywga2dfbnVtdGhyZWFkcyA9IDUsIGtnX3NjaGVkID0gMHhm ZmZmZmYwMDRhYTllNjE4fQooa2dkYikgcCAqdGQtPnRkX3Byb2MtPnBfa3Nl Z3Jwcy50cWhfbGFzdAokMTAgPSAoc3RydWN0IGtzZWdycCAqKSAweDAKCgoo a2dkYikgcCB0ZC0+dGRfcHJvYy0+cF90aHJlYWRzCiQyMCA9IHt0cWhfZmly c3QgPSAweGZmZmZmZjAwNmY4NzIwMDAsIHRxaF9sYXN0ID0gMHhmZmZmZmYw MDQyNTZmMjcwfQooa2dkYikgcCAqdGQtPnRkX3Byb2MtPnBfdGhyZWFkcy50 cWhfZmlyc3QKJDIxID0ge3RkX3Byb2MgPSAweGZmZmZmZjAwNGFhOWYwMDAs IHRkX2tzZWdycCA9IDB4ZmZmZmZmMDA0YWE5ZTVhMCwgdGRfcGxpc3QgPSB7 CiAgICB0cWVfbmV4dCA9IDB4ZmZmZmZmMDBiNWJlZjI2MCwgdHFlX3ByZXYg PSAweGZmZmZmZjAwNGFhOWYwMjB9LCB0ZF9rZ2xpc3QgPSB7CiAgICB0cWVf bmV4dCA9IDB4ZmZmZmZmMDBiNWJlZjI2MCwgdHFlX3ByZXYgPSAweGZmZmZm ZjAwNGFhOWU1Yjh9LCB0ZF9zbHBxID0ge3RxZV9uZXh0ID0gMHhmZmZmZmYw MGI1YmVmMjYwLAogICAgdHFlX3ByZXYgPSAweGZmZmZmZjAwM2Y4YTc3NTB9 LCB0ZF9sb2NrcSA9IHt0cWVfbmV4dCA9IDB4MCwgdHFlX3ByZXYgPSAweGZm ZmZmZmZmYjY4ZGNhNzB9LCB0ZF9ydW5xID0gewogICAgdHFlX25leHQgPSAw eDAsIHRxZV9wcmV2ID0gMHhmZmZmZmYwMDRhYTllNWM4fSwgdGRfc2VscSA9 IHt0cWhfZmlyc3QgPSAweDAsCiAgICB0cWhfbGFzdCA9IDB4ZmZmZmZmMDA2 Zjg3MjA2MH0sIHRkX3NsZWVwcXVldWUgPSAweDAsIHRkX3R1cm5zdGlsZSA9 IDB4ZmZmZmZmMDAyZjg5NTM4MCwKICB0ZF91bXR4cSA9IDB4ZmZmZmZmMDBh ZTJiMjAwMCwgdGRfdGlkID0gMTAwMjg1LCB0ZF9mbGFncyA9IDE2Nzc3MjI0 LCB0ZF9pbmhpYml0b3JzID0gMiwgdGRfcGZsYWdzID0gMTM2LAogIHRkX2R1 cGZkID0gMCwgdGRfd2NoYW4gPSAweGZmZmZmZjAwNGFhOWU1ZjgsIHRkX3dt ZXNnID0gMHhmZmZmZmZmZjgwNGEyODcxICJrc2VyZWwiLCB0ZF9sYXN0Y3B1 ID0gMCAnXDAnLAogIHRkX29uY3B1ID0gMjU1ICdcdWZmZmYnLCB0ZF9vd2Vw cmVlbXB0ID0gMCAnXDAnLCB0ZF9sb2NrcyA9IDAsIHRkX2Jsb2NrZWQgPSAw eDAsIHRkX2l0aGQgPSAweDAsCiAgdGRfbG9ja25hbWUgPSAweDAsIHRkX2Nv bnRlc3RlZCA9IHtsaF9maXJzdCA9IDB4MH0sIHRkX3NsZWVwbG9ja3MgPSAw eDAsIHRkX2ludHJfbmVzdGluZ19sZXZlbCA9IDAsCiAgdGRfcGlubmVkID0g MCwgdGRfbWFpbGJveCA9IDB4MCwgdGRfdWNyZWQgPSAweGZmZmZmZjAwYWQx OGYyMDAsIHRkX3N0YW5kaW4gPSAweGZmZmZmZjAwMmZlNTk3MjAsCiAgdGRf dXBjYWxsID0gMHhmZmZmZmYwMGE5ZmZkODQwLCB0ZF9zdGlja3MgPSAwLCB0 ZF91dXRpY2tzID0gMCwgdGRfdXN0aWNrcyA9IDAsIHRkX2ludHJ2YWwgPSAw LAogIHRkX29sZHNpZ21hc2sgPSB7X19iaXRzID0gezAsIDAsIDAsIDB9fSwg dGRfc2lnbWFzayA9IHtfX2JpdHMgPSB7NDI5NDkwMTUwMywgNDI5NDk2NzI5 NSwgNDI5NDk2NzI5NSwKICAgICAgNDI5NDk2NzI5NX19LCB0ZF9zaWdsaXN0 ID0ge19fYml0cyA9IHswLCAwLCAwLCAwfX0sIHRkX2dlbmVyYXRpb24gPSAz LCB0ZF9zaWdzdGsgPSB7c3Nfc3AgPSAweDAsCiAgICBzc19zaXplID0gMCwg c3NfZmxhZ3MgPSAwfSwgdGRfa2ZsYWdzID0gMSwgdGRfeHNpZyA9IDAsIHRk X3Byb2ZpbF9hZGRyID0gMCwgdGRfcHJvZmlsX3RpY2tzID0gMCwKICB0ZF9i YXNlX3ByaSA9IDEwNCAnaCcsIHRkX3ByaW9yaXR5ID0gMTA0ICdoJywgdGRf cGNiID0gMHhmZmZmZmZmZmI2ODIzZDEwLCB0ZF9zdGF0ZSA9IFREU19JTkhJ QklURUQsCiAgdGRfcmV0dmFsID0gezAsIDU5NTA5NzZ9LCB0ZF9zbHBjYWxs b3V0ID0ge2NfbGlua3MgPSB7c2xlID0ge3NsZV9uZXh0ID0gMHhmZmZmZmYw MGI1YmVmNDAwfSwgdHFlID0gewogICAgICAgIHRxZV9uZXh0ID0gMHhmZmZm ZmYwMGI1YmVmNDAwLCB0cWVfcHJldiA9IDB4ZmZmZmZmZmY5OWI5ODE1MH19 LCBjX3RpbWUgPSAyNjYwNTgzNSwKICAgIGNfYXJnID0gMHhmZmZmZmYwMDZm ODcyMDAwLCBjX2Z1bmMgPSAweGZmZmZmZmZmODAyZTMyYTAgPHNsZWVwcV90 aW1lb3V0PiwgY19tdHggPSAweDAsIGNfZmxhZ3MgPSAyMn0sCiAgdGRfZnJh bWUgPSAweGZmZmZmZmZmYjY4MjNjNDAsIHRkX2tzdGFja19vYmogPSAweGZm ZmZmZjAwZDM2ZDBiNjAsIHRkX2tzdGFjayA9IDE4NDQ2NzQ0MDcyNDc2NTU3 MzEyLAogIHRkX2tzdGFja19wYWdlcyA9IDQsIHRkX2FsdGtzdGFja19vYmog PSAweDAsIHRkX2FsdGtzdGFjayA9IDAsIHRkX2FsdGtzdGFja19wYWdlcyA9 IDAsIHRkX2NyaXRuZXN0ID0gMSwKICB0ZF9tZCA9IHttZF9zcGlubG9ja19j b3VudCA9IDEsIG1kX3NhdmVkX2ZsYWdzID0gNTgyfSwgdGRfc2NoZWQgPSAw eGZmZmZmZjAwNmY4NzIyMjh9CihrZ2RiKQoK --0-318985421-1128025077=:65402-- From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 01:04:35 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 CB36216A41F for ; Fri, 30 Sep 2005 01:04:35 +0000 (GMT) (envelope-from kerndev@yahoo.com) Received: from web35003.mail.mud.yahoo.com (web35003.mail.mud.yahoo.com [209.191.68.197]) by mx1.FreeBSD.org (Postfix) with SMTP id 32D0443D5C for ; Fri, 30 Sep 2005 01:04:35 +0000 (GMT) (envelope-from kerndev@yahoo.com) Received: (qmail 67729 invoked by uid 60001); 30 Sep 2005 01:04:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=SFSSRBm6YNCzCLdR3nmFNC625pa3GOgkzCu+D6Z9IgRkEsChmx8LUHBFx1643bfafGIYoG4EOziyIT+7CSjLhp1pwnjYncYa4grSC1IR1q90MrkrbRGzOvLA89A6seFyZrGZQg7PQjYKUCDLPcTTDkrZ/cd7q6TJ3fhTi/f5Qbk= ; Message-ID: <20050930010434.67727.qmail@web35003.mail.mud.yahoo.com> Received: from [198.95.226.224] by web35003.mail.mud.yahoo.com via HTTP; Thu, 29 Sep 2005 18:04:34 PDT Date: Thu, 29 Sep 2005 18:04:34 -0700 (PDT) From: Kernel Dev To: hackers@freebsd.org MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 30 Sep 2005 11:30:24 +0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: using fast interrupts with em(4) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 01:04:35 -0000 Hello All. For a project, I am looking into making the em(4) driver use fast interrupts. Has someone done this or are there other driver references that could help me in this? I understand that the main problems are: 1. Sharing of interrupts. 2. Blocking (memory and mutexes). Are there any other issues I might have missed? br --------------------------------- Yahoo! for Good Click here to donate to the Hurricane Katrina relief effort. From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 08:41:54 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 A950416A41F; Fri, 30 Sep 2005 08:41:54 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from leto.uk.clara.net (leto.uk.clara.net [80.168.69.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5018B43D48; Fri, 30 Sep 2005 08:41:54 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from bloodhound.noc.clara.net ([195.8.70.207]) by leto.uk.clara.net with esmtp (Exim 4.43) id 1ELGSn-000EGK-9A; Fri, 30 Sep 2005 09:41:53 +0100 Received: from personal by bloodhound.noc.clara.net with local (Exim 4.52 (FreeBSD)) id 1ELGTC-000KuD-55; Fri, 30 Sep 2005 09:42:18 +0100 Date: Fri, 30 Sep 2005 09:42:18 +0100 From: Brian Candler To: Yar Tikhiy Message-ID: <20050930084218.GC80146@uk.tiscali.com> References: <20050929224548.GB3035@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050929224548.GB3035@comp.chem.msu.su> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Fri, 30 Sep 2005 12:36:38 +0000 Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: A smarter mergemaster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 08:41:54 -0000 On Fri, Sep 30, 2005 at 02:45:48AM +0400, Yar Tikhiy wrote: > The fruitiest features are as follows: Will it automatically install new versions of files where the old one was not altered? That's my biggest bugbear with mergemaster - it asks you about a zillion files in /etc/rc.d which you have to manually agree to overwrite just because the RCS ID has changed. In those cases where you've not altered them yourself, I think you should just get the latest version. However to do this properly, you'd need checksums of the original files. [*] Also, can we have mergemaster work as part of the binary upgrade process too please... the new files are in /usr/share/examples/etc so I don't see why we can't merge directly from there into /etc Regards, Brian. [*] http://lists.freebsd.org/mailman/htdig/freebsd-current/2005-May/049784.html point 4. From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 13:27:03 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 A5E3316A421 for ; Fri, 30 Sep 2005 13:27:03 +0000 (GMT) (envelope-from xfb52@dial.pipex.com) Received: from smtp-out3.blueyonder.co.uk (smtp-out3.blueyonder.co.uk [195.188.213.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06B7743D48 for ; Fri, 30 Sep 2005 13:27:02 +0000 (GMT) (envelope-from xfb52@dial.pipex.com) Received: from [82.41.253.249] ([82.41.253.249]) by smtp-out3.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Sep 2005 14:27:50 +0100 Message-ID: <433D3D24.10907@dial.pipex.com> Date: Fri, 30 Sep 2005 14:27:00 +0100 From: Alex Zbyslaw User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.7.11) Gecko/20050917 X-Accept-Language: en-us, pl MIME-Version: 1.0 To: Brian Candler References: <20050929224548.GB3035@comp.chem.msu.su> <20050930084218.GC80146@uk.tiscali.com> In-Reply-To: <20050930084218.GC80146@uk.tiscali.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Sep 2005 13:27:50.0374 (UTC) FILETIME=[C116A060:01C5C5C2] Cc: hackers@freebsd.org Subject: Re: A smarter mergemaster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 13:27:03 -0000 Brian Candler wrote: >That's my biggest bugbear with mergemaster - it asks you about >a zillion files in /etc/rc.d which you have to manually agree to overwrite >just because the RCS ID has changed. In those cases where you've not altered >them yourself, I think you should just get the latest version. However to do >this properly, you'd need checksums of the original files. [*] > > Not necessarily. Diff can be made to ignore changes which match specific regular expressions (-I), so if you can reliably match the RCS Id lines you can ignore those changes. Note, though, that this is different from files which you haven't changed. The new version might change more than the RCS Id, in which you would be back to checksums, or some such. However, a change to automatically install files where *only* the RCS Id had changed would be easier and quicker to effect than the general case of all files which you hadn't changed. --Alex From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 13:51:23 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 E94A116A45C; Fri, 30 Sep 2005 13:51:22 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EB5A43D48; Fri, 30 Sep 2005 13:51:21 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp219-232.lns1.adl2.internode.on.net [203.122.219.232]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j8UDop12037723 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 30 Sep 2005 23:21:04 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Fri, 30 Sep 2005 23:20:35 +0930 User-Agent: KMail/1.8.2 References: <20050929224548.GB3035@comp.chem.msu.su> <20050930084218.GC80146@uk.tiscali.com> In-Reply-To: <20050930084218.GC80146@uk.tiscali.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1650412.kWo8yImQIv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200509302320.36572.doconnor@gsoft.com.au> X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: Yar Tikhiy , hackers@freebsd.org, current@freebsd.org, Brian Candler Subject: Re: A smarter mergemaster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 13:51:23 -0000 --nextPart1650412.kWo8yImQIv Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 30 September 2005 18:12, Brian Candler wrote: > On Fri, Sep 30, 2005 at 02:45:48AM +0400, Yar Tikhiy wrote: > > The fruitiest features are as follows: > > Will it automatically install new versions of files where the old one was > not altered? That's my biggest bugbear with mergemaster - it asks you abo= ut > a zillion files in /etc/rc.d which you have to manually agree to overwrite > just because the RCS ID has changed. In those cases where you've not > altered them yourself, I think you should just get the latest version. > However to do this properly, you'd need checksums of the original files. *broken record* Try etcmerge, it's in ports. I think the main problem is that you can't use etcmerge *right now* because= =20 you have to do one last manual merge to get a baseline etc directory. =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 --nextPart1650412.kWo8yImQIv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDPUKs5ZPcIHs/zowRAhOOAJ98M63EpyO5PFlcL3zjcA43mc2g6gCeOmKt 8/3f7vcqDlWWuSXmxM3p9EA= =qBvb -----END PGP SIGNATURE----- --nextPart1650412.kWo8yImQIv-- From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 13:57:35 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 948C116A41F for ; Fri, 30 Sep 2005 13:57:35 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B459F43D48 for ; Fri, 30 Sep 2005 13:57:34 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp219-232.lns1.adl2.internode.on.net [203.122.219.232]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j8UDvDh9037785 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 30 Sep 2005 23:27:21 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Fri, 30 Sep 2005 23:26:59 +0930 User-Agent: KMail/1.8.2 References: <20050929224548.GB3035@comp.chem.msu.su> <200509301041.10480.doconnor@gsoft.com.au> <433CFD16.6060200@ashleymoran.me.uk> In-Reply-To: <433CFD16.6060200@ashleymoran.me.uk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart102554671.ZHddrDvl2P"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200509302327.00537.doconnor@gsoft.com.au> X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: Ashley Moran Subject: Re: A smarter mergemaster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 13:57:35 -0000 --nextPart102554671.ZHddrDvl2P Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 30 September 2005 18:23, Ashley Moran wrote: > > It does have problems handling DB files, but that is usually not a big > > problem to fix. > > I read about etcmerge in BSD Hacks and there's been no going back for > me. It seems pretty stable even though it's not been updated for a good > while. Is there any chance it will ever make it into the FreeBSD core > system? It sure would be nice :) One thing would be to have automatically fetched etc directories so when yo= u=20 ran it for the first time it would grab a release version of etc for you :) Hmm.. I'll try and add that if I get some time I think! =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 --nextPart102554671.ZHddrDvl2P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDPUQs5ZPcIHs/zowRArZ+AJ4/gl1oyecnShM/XztjC/V4+fmRjwCgnEdz dLEbYei7myn0M3Z4+/YJf7g= =TCaP -----END PGP SIGNATURE----- --nextPart102554671.ZHddrDvl2P-- From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 14:06:03 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 4480B16A41F for ; Fri, 30 Sep 2005 14:06:03 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FC1943D4C for ; Fri, 30 Sep 2005 14:06:02 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.233] (Not Verified[10.50.41.233]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 30 Sep 2005 10:22:02 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org, Antoine Pelisse Date: Fri, 30 Sep 2005 08:54:47 -0400 User-Agent: KMail/1.8 References: <61c746830509300215x7833746ew60896c4c1338ec65@mail.gmail.com> <61c746830509300224g3d79cbe4ve55e8b0b27004fc3@mail.gmail.com> In-Reply-To: <61c746830509300224g3d79cbe4ve55e8b0b27004fc3@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509300854.48210.jhb@FreeBSD.org> Cc: Subject: Re: freebsd-5.4-stable panics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 14:06:03 -0000 On Friday 30 September 2005 05:24 am, Antoine Pelisse wrote: > Hi Robert, > I don't think your patch is correct, the total linked list can be broken > while the lock is released, thus just passing the link may not be enough > I have submitted a PR[1] for this a month ago but nobody took care of it > yet Regards, > Antoine Pelisse > > [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84684 I think this patch looks ok. Robert, can you get the original panic on this thread tested against this patch? > On 9/29/05, Robert Watson wrote: > > On Thu, 29 Sep 2005, Rob Watt wrote: > > > On Thu, 29 Sep 2005, Robert Watson wrote: > > >> Could you dump the contents of *td and *td->td_proc for me? I'm quite > > >> interested to know what the value in td->td_proc->p_state is, among > > > > other > > > > >> things. If I could also have you generate a dump of the KSE group > > >> structures in td->td_proc->p_ksegrps and the threads in > > >> td->td_proc->p_threads. > > > > > > I've attached a file with many of the values you have asked for. We > > > looked at some of the threads referenced by td->td_proc->p_threads, but > > > we weren't sure we were walking the list correctly. Do you have any > > > tips > > > > > > for walking those thread lists? > > > > > >> Could you tell me if the program named by p->p_comm is linked against > > >> a threading library? If it's a custom app, you may already know, and > > >> if not, you can run ldd on the application to see what it is linked > > >> against. > > > > > > The programs named by p->p_comm is linked against the pthreads library. > > > > This seems to be enough information to at least track this down a bit: > > td_ksegrp is NULL, rather than a corrupt value, which suggests that the > > thread is incompletely initialized. Other hints that this are the case > > are that td_critnest is 1 (as is set when it is allocated), and the state > > is TDS_INACTIVE. Some other fields are set though, such as td_oncpu, > > which is normally initialized to NOCPU. > > > > > (kgdb) p *td > > > $1 = {td_proc = 0xffffff004aa9f000, td_ksegrp = 0x0, td_plist = > > > {tqe_next = 0xff ffff00b4798000, > > > tqe_prev = 0xffffff00a97ae010}, td_kglist = {tqe_next = > > > 0xffffff00b4798000, > > > tqe_prev = 0xffffff00a97ae020}, td_slpq = {tqe_next = 0x0, tqe_prev > > > = 0xffff ff001fac7c10}, td_lockq = { > > > tqe_next = 0xffffff00a97ae000, tqe_prev = 0xffffffffb6797a70}, > > > td_runq = {tq e_next = 0x0, > > > tqe_prev = 0xffffffff80608180}, td_selq = {tqh_first = 0x0, tqh_last > > > = 0xfff fff00633112c0}, > > > td_sleepqueue = 0xffffff00382b0400, td_turnstile = 0xffffff00c1712900, > > > td_umtx q = 0xffffff00d1207080, > > > td_tid = 100253, td_flags = 16777216, td_inhibitors = 0, td_pflags = > > > 128, td_d upfd = 0, td_wchan = 0x0, > > > td_wmesg = 0x0, td_lastcpu = 2 '\002', td_oncpu = 2 '\002', > > > td_owepreempt = 0 '\0', td_locks = 0, > > > td_blocked = 0x0, td_ithd = 0x0, td_lockname = 0x0, td_contested = > > > {lh_first = > > > 0x0}, td_sleeplocks = 0x0, > > > td_intr_nesting_level = 0, td_pinned = 0, td_mailbox = 0x0, td_ucred = > > > 0xfffff f00ad18f200, > > > td_standin = 0x0, td_upcall = 0x0, td_sticks = 0, td_uuticks = 0, > > > td_usticks = > > > 0, td_intrval = 0, > > > td_oldsigmask = {__bits = {0, 0, 0, 0}}, td_sigmask = {__bits = > > > {4294967295, 4 294967295, 4294967295, > > > 4294967295}}, td_siglist = {__bits = {0, 0, 0, 0}}, td_generation > > > = 14, td _sigstk = {ss_sp = 0x0, > > > ss_size = 0, ss_flags = 0}, td_kflags = 0, td_xsig = 0, > > > td_profil_addr = 0, td_profil_ticks = 0, > > > td_base_pri = 182 '\uffff', td_priority = 182 '\uffff', td_pcb = > > > 0xffffffffb68 dcd10, td_state = TDS_INACTIVE, > > > td_retval = {1, 29309280}, td_slpcallout = {c_links = {sle = {sle_next > > > = 0x0}, > > > tqe = {tqe_next = 0x0, > > > tqe_prev = 0xffffff001fac7d80}}, c_time = 55907602, c_arg = > > > 0xffffff0063 311260, > > > c_func = 0xffffffff802e32a0 , c_mtx = 0x0, c_flags = > > > 16}, td _frame = 0xffffffffb68dcc40, > > > td_kstack_obj = 0xffffff0087f93d20, td_kstack = 18446744072477315072, > > > td_kstac k_pages = 4, > > > td_altkstack_obj = 0x0, td_altkstack = 0, td_altkstack_pages = 0, > > > td_critnest = 1, td_md = { > > > md_spinlock_count = 1, md_saved_flags = 582}, td_sched = > > > 0xffffff0063311488} > > > > I'm not familiar with the internals of the thread and KSE life cycle > > here, > > > > so I think we'll need to look to those more familiar with this to > > understand what of two things may be going on: > > > > (1) Is the fact that td_ksegrp != NULL an invariant for a connected > > thread, and that kern_proc is relying on that but the thread code is > > failing to implement it safely? > > > > (2) Is td_ksegrp sometimes left legitimately as NULL as part of the > > thread life cycle, and that kern_proc incorrectly assumes that it is > > never NULL when hooked up to a thread. > > > > This suggests a possible work-around of simply testing td_ksegrp for NULL > > in kern_proc in order to avoid this, while attempting to resolve whether > > an invariant is violated (or incorrectly assumed), which might require > > some serious thinking and a solution that is non-trivial. Something like > > the following might work in the mean time: > > > > Index: kern_proc.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/kern/kern_proc.c,v > > retrieving revision 1.231 > > diff -u -r1.231 kern_proc.c > > --- kern_proc.c 27 Sep 2005 18:03:15 -0000 1.231 > > +++ kern_proc.c 29 Sep 2005 20:50:33 -0000 > > @@ -882,6 +882,8 @@ > > } else { > > _PHOLD(p); > > FOREACH_THREAD_IN_PROC(p, td) { > > + if (td->td_ksegrp == NULL) > > + continue; > > fill_kinfo_thread(td, &kinfo_proc); > > PROC_UNLOCK(p); > > error = SYSCTL_OUT(req, (caddr_t)&kinfo_proc, > > > > I'm going to forward off your e-mail to the threads@ list and see if > > anyone there wants to talk some more about this. If you don't mind > > testing the above patch to see if this is a workable work-around, we may > > want to think about getting it committed in the mean time. > > > > Thanks, > > > > 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" > > _______________________________________________ > 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" -- 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 Sep 30 14:06:04 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 6D55216A41F for ; Fri, 30 Sep 2005 14:06:04 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 138A143D53 for ; Fri, 30 Sep 2005 14:06:02 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.233] (Not Verified[10.50.41.233]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 30 Sep 2005 10:22:02 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org Date: Fri, 30 Sep 2005 08:59:59 -0400 User-Agent: KMail/1.8 References: <15627.1128022613@critter.freebsd.dk> In-Reply-To: <15627.1128022613@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509300900.01517.jhb@FreeBSD.org> Cc: Poul-Henning Kamp , Divacky Roman , Stanislav Sedov Subject: Re: dev_lock() question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 14:06:04 -0000 On Thursday 29 September 2005 03:36 pm, Poul-Henning Kamp wrote: > In message <200509291455.59914.jhb@FreeBSD.org>, John Baldwin writes: > >On Thursday 29 September 2005 02:14 pm, Poul-Henning Kamp wrote: > >> In message <200509291408.18098.jhb@FreeBSD.org>, John Baldwin writes: > >> >Actually, you would think that it could be initialized either via an > >> > early SYSINIT() or in the init_mutexes() function in kern_mutex.c and > >> > thus not need the early check and avoid penalizing dev_lock(). > >> > > >> >phk, how early his dev_lock needed? > >> > >> Far too early due to console madness (in syscons I belive). > > > >So would mutex_init() work? > > Havn't tried. It basically has to work right before the copyright > is printed. Actually, mutexes won't work until after mutex_init() anyway, so it had better work. :) I'll try it out. Patch is below for reference: --- //depot/vendor/freebsd/src/sys/kern/kern_conf.c 2005/09/19 20:01:08 +++ //depot/projects/smpng/sys/kern/kern_conf.c 2005/09/30 12:57:36 @@ -57,8 +57,7 @@ void dev_lock(void) { - if (!mtx_initialized(&devmtx)) - mtx_init(&devmtx, "cdev", NULL, MTX_DEF); + mtx_lock(&devmtx); } --- //depot/vendor/freebsd/src/sys/kern/kern_mutex.c 2005/09/02 20:25:20 +++ //depot/projects/smpng/sys/kern/kern_mutex.c 2005/09/30 12:57:36 @@ -900,5 +935,6 @@ mtx_init(&Giant, "Giant", NULL, MTX_DEF | MTX_RECURSE); mtx_init(&sched_lock, "sched lock", NULL, MTX_SPIN | MTX_RECURSE); mtx_init(&proc0.p_mtx, "process lock", NULL, MTX_DEF | MTX_DUPOK); + mtx_init(&devmtx, "cdev", NULL, MTX_DEF); mtx_lock(&Giant); } -- 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 Sep 30 14:06:04 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 785B816A420 for ; Fri, 30 Sep 2005 14:06:04 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23AF443D55 for ; Fri, 30 Sep 2005 14:06:02 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.233] (Not Verified[10.50.41.233]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 30 Sep 2005 10:22:02 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org Date: Fri, 30 Sep 2005 09:07:16 -0400 User-Agent: KMail/1.8 References: <20050929224548.GB3035@comp.chem.msu.su> <20050930110841.GC45907@comp.chem.msu.su> In-Reply-To: <20050930110841.GC45907@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509300907.17730.jhb@FreeBSD.org> Cc: Yar Tikhiy , Jon Dama Subject: Re: A smarter mergemaster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 14:06:04 -0000 On Friday 30 September 2005 07:08 am, Yar Tikhiy wrote: > [Replying to everyone who mentioned etcmerge or 3-way merge in general] > > On Fri, Sep 30, 2005 at 12:15:59AM -0700, Jon Dama wrote: > > It is worth while to mention sysutils/etcmerge. > > > > Having the "three-way" merge makes the process much better. The primary > > way I've shot myself with mergemaster is forgetting some local change. > > > > Being able to distinguish the class of things that are changing upstream > > really helps the situation and provides a more reasonable indication of > > the default: > > if it changed upstream but not locally => default is install > > if it changed locally but not upstream => default is keep > > if it changed locally and upstream => default is merge > > Obviously, in order to do a 3-way merge, we need information about > the old versions of original files as well. However, currently we > have only the new versions in /usr/src and local versions in /etc > for mergemaster to work with. I'll be glad to hear how etcmerge > approaches this issue. > > In any case, we cannot offer the users to access the CVS repo when > merging /etc. Personally, I'd like to see a complete copy of current > unmodified /etc files installed to /usr/share/examples/etc. They > could serve as the old original versions for the 3-way merge then. > Alas, now the copy installed there is rather incomplete, motivation > of which is unknown to me yet. Any ideas? I do the equivalent of etcmerge (sort of) by hand using some old instructions from the handbook (pre-mm). Basically, for each installworld, you do a distribute of src/etc into /var/tmp/root-YYMMDD. Then you keep around the previous tree and just compare the two previous trees and merge those changes into /etc. -- 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 Sep 30 14:21:42 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 976CF16A41F for ; Fri, 30 Sep 2005 14:21:42 +0000 (GMT) (envelope-from work@ashleymoran.me.uk) Received: from mta08-winn.ispmail.ntl.com (mta08-winn.ispmail.ntl.com [81.103.221.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9554F43D5A for ; Fri, 30 Sep 2005 14:21:40 +0000 (GMT) (envelope-from work@ashleymoran.me.uk) Received: from aamta11-winn.ispmail.ntl.com ([81.103.221.35]) by mta08-winn.ispmail.ntl.com with ESMTP id <20050930142139.RTWF10357.mta08-winn.ispmail.ntl.com@aamta11-winn.ispmail.ntl.com> for ; Fri, 30 Sep 2005 15:21:39 +0100 Received: from jigsaw-sbs02.jigsawhq.com ([213.106.224.113]) by aamta11-winn.ispmail.ntl.com with ESMTP id <20050930142139.YBLD1770.aamta11-winn.ispmail.ntl.com@jigsaw-sbs02.jigsawhq.com> for ; Fri, 30 Sep 2005 15:21:39 +0100 Received: from [192.168.0.181] ([192.168.0.181]) by jigsaw-sbs02.jigsawhq.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Sep 2005 15:20:46 +0100 Message-ID: <433D49BD.4070402@ashleymoran.me.uk> Date: Fri, 30 Sep 2005 15:20:45 +0100 From: Ashley Moran User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <20050929224548.GB3035@comp.chem.msu.su> <200509301041.10480.doconnor@gsoft.com.au> <433CFD16.6060200@ashleymoran.me.uk> <200509302327.00537.doconnor@gsoft.com.au> In-Reply-To: <200509302327.00537.doconnor@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Sep 2005 14:20:47.0398 (UTC) FILETIME=[26BE0460:01C5C5CA] Subject: Re: A smarter mergemaster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 14:21:42 -0000 Daniel O'Connor wrote: > On Friday 30 September 2005 18:23, Ashley Moran wrote: > > It sure would be nice :) > One thing would be to have automatically fetched etc directories so when you > ran it for the first time it would grab a release version of etc for you :) > Hmm.. I'll try and add that if I get some time I think! > Funny you should say that... I had a crack at something similar myself (see below). But I was hampered by the fact that a) I had never used CVS before (we use VSS here but I'm moving it all to SVN), and b) I have no idea how the FreeBSD build process works (I'm a hardcore hacker lol) Unfortunately it seems that config files for the subsystems (eg SSH) are stored separately in the CVS tree and I didn't have time to work out where they live. While we're on the subject, how do you handle the DB files? I don't see any special mention of them in the man pages. When I last etcmerged I glossed over them and haven't had any login problems since. Ashley Here is my effort: #!/bin/sh # takes one argument: name of the tag to get from CVS cd /var/db # clear out any previous files rm -rf etc # fetch new etc files from cvs export CVSROOT=:pserver:anoncvs:anoncvs@anoncvs.fr.FreeBSD.org:/home/ncvs cvs login cvs -QR export -r$1 etc cvs logout cd etc # local adjustment mv etc.i386/ttys . # clear out the other platform-specific files rm -r etc.* From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 14:59:45 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 D71B916A41F for ; Fri, 30 Sep 2005 14:59:45 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1BA543D4C for ; Fri, 30 Sep 2005 14:59:44 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp219-232.lns1.adl2.internode.on.net [203.122.219.232]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j8UExXwt038279 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 1 Oct 2005 00:29:39 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Sat, 1 Oct 2005 00:29:01 +0930 User-Agent: KMail/1.8.2 References: <20050929224548.GB3035@comp.chem.msu.su> <200509302327.00537.doconnor@gsoft.com.au> <433D49BD.4070402@ashleymoran.me.uk> In-Reply-To: <433D49BD.4070402@ashleymoran.me.uk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7096081.219UU85ohi"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200510010029.22358.doconnor@gsoft.com.au> X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: Ashley Moran Subject: Re: A smarter mergemaster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 14:59:46 -0000 --nextPart7096081.219UU85ohi Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 30 September 2005 23:50, Ashley Moran wrote: > Unfortunately it seems that config files for the subsystems (eg SSH) are > stored separately in the CVS tree and I didn't have time to work out > where they live. The trick is to get the system to build you an /etc - see how mergemaster d= oes=20 it (runs make in the right place basically) > While we're on the subject, how do you handle the DB files? I don't see > any special mention of them in the man pages. When I last etcmerged I > glossed over them and haven't had any login problems since. =46or passwd stuff I merge /etc/master.passwd and then run cap_mkdb to rebu= ild=20 the other 3 files based on it. Also run newaliases when aliases are touched, and cap_mkdb for login.conf. =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 --nextPart7096081.219UU85ohi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDPVLK5ZPcIHs/zowRAveLAJ9lh3TOnif1gN0nrEOpBErJwq8qMACfV5j6 S9yi2G+OSDAs+HfPbyPgIEc= =CX6w -----END PGP SIGNATURE----- --nextPart7096081.219UU85ohi-- From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 15:01:15 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 9C8A816A41F; Fri, 30 Sep 2005 15:01:15 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6B8343D49; Fri, 30 Sep 2005 15:01:10 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j8UF16RI061548; Fri, 30 Sep 2005 19:01:06 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j8UF15so061546; Fri, 30 Sep 2005 19:01:05 +0400 (MSD) (envelope-from yar) Date: Fri, 30 Sep 2005 19:01:05 +0400 From: Yar Tikhiy To: John Baldwin Message-ID: <20050930150105.GA55158@comp.chem.msu.su> References: <20050929224548.GB3035@comp.chem.msu.su> <20050930110841.GC45907@comp.chem.msu.su> <200509300907.17730.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509300907.17730.jhb@FreeBSD.org> User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@FreeBSD.org, Jon Dama Subject: Re: A smarter mergemaster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 15:01:15 -0000 On Fri, Sep 30, 2005 at 09:07:16AM -0400, John Baldwin wrote: > On Friday 30 September 2005 07:08 am, Yar Tikhiy wrote: > > [Replying to everyone who mentioned etcmerge or 3-way merge in general] > > > > On Fri, Sep 30, 2005 at 12:15:59AM -0700, Jon Dama wrote: > > > It is worth while to mention sysutils/etcmerge. > > > > > > Having the "three-way" merge makes the process much better. The primary > > > way I've shot myself with mergemaster is forgetting some local change. > > > > > > Being able to distinguish the class of things that are changing upstream > > > really helps the situation and provides a more reasonable indication of > > > the default: > > > if it changed upstream but not locally => default is install > > > if it changed locally but not upstream => default is keep > > > if it changed locally and upstream => default is merge > > > > Obviously, in order to do a 3-way merge, we need information about > > the old versions of original files as well. However, currently we > > have only the new versions in /usr/src and local versions in /etc > > for mergemaster to work with. I'll be glad to hear how etcmerge > > approaches this issue. > > > > In any case, we cannot offer the users to access the CVS repo when > > merging /etc. Personally, I'd like to see a complete copy of current > > unmodified /etc files installed to /usr/share/examples/etc. They > > could serve as the old original versions for the 3-way merge then. > > Alas, now the copy installed there is rather incomplete, motivation > > of which is unknown to me yet. Any ideas? > > I do the equivalent of etcmerge (sort of) by hand using some old instructions > from the handbook (pre-mm). Basically, for each installworld, you do a > distribute of src/etc into /var/tmp/root-YYMMDD. Then you keep around the > previous tree and just compare the two previous trees and merge those changes > into /etc. I'm curious if we can do this in the stock system using the stock tools. We could compare /usr/share/examples/etc with the results of "make distrubution" and merge the changes into /etc. Mergemaster invokes "make distrubution" anyway, so it just needs relevant /usr/share/examples/etc to be able to do a 3-way merge. This assumes that /usr/share/examples/etc is in keeping with /etc, of course, but the assumption can be verified using RCS Id strings, which should be the same here and there. -- Yar From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 15:16:08 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 5027E16A41F for ; Fri, 30 Sep 2005 15:16:08 +0000 (GMT) (envelope-from jerry@evasefor.com) Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE40E43D4C for ; Fri, 30 Sep 2005 15:16:07 +0000 (GMT) (envelope-from jerry@evasefor.com) Received: from config18.kundenserver.de [172.23.4.145] (helo=togal2.1and1.com) by mrelay.perfora.net with ESMTP (Nemesis), id 0MKoyl-1ELMcD46br-0004FY; Fri, 30 Sep 2005 11:16:01 -0400 To: From: X-Binford: 6100 (more power) X-Originating-From: 29983738 X-Mailer: Webmail X-Received: from config18 by 67.103.124.219 with HTTP id 29983738 for freebsd-hackers@freebsd.org; Fri, 30 Sep 2005 17:14:01 +0200 Content-Type: text/plain; charset="iso-8859-1" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 Date: Fri, 30 Sep 2005 17:14:01 +0200 Message-ID: <0MKoyl-1ELMcD46br-0004FY@mrelay.perfora.net> Subject: serial login to SBC X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 15:16:08 -0000 Hello list, I am trying to use a FreeBSD box to log into a Single Board Computer. I have a null modem and it's plugged to both serial ports. The SBC runs openbsd ( /dev/cua00). When I run "cu -l /dev/cuaa0" from FreeBSD, I don't get any login prompt. What I am doing wrong? I've already read the FBSD handbook. I have an OpenBSD box to experiment with first, and can't serial login either. I really need help on this one. Thank you From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 15:25:37 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 4DE7E16A41F for ; Fri, 30 Sep 2005 15:25:37 +0000 (GMT) (envelope-from apelisse@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF04643D58 for ; Fri, 30 Sep 2005 15:25:34 +0000 (GMT) (envelope-from apelisse@gmail.com) Received: by nproxy.gmail.com with SMTP id x4so10566nfb for ; Fri, 30 Sep 2005 08:25:33 -0700 (PDT) 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:references; b=n57Jq8LPXwLxcy/WUlkPjueRA/YcooCTiBMQ1tA/DEUZpbfKRQNRm5SfVAavYOuis+YSJCUPdRpiW6Enr/Um8QokW+EShbRmlWCzDg73u9RQKUnWxDXUfd3dQ9fA1DSzOtSXBINJBTaO0Rkt+AFZXUkKjGcdvNSMb3Lrzoe5mqw= Received: by 10.48.226.17 with SMTP id y17mr118573nfg; Fri, 30 Sep 2005 08:25:33 -0700 (PDT) Received: by 10.48.108.18 with HTTP; Fri, 30 Sep 2005 08:25:33 -0700 (PDT) Message-ID: <61c746830509300825s5ad197fbt908267d54f1b7b8f@mail.gmail.com> Date: Fri, 30 Sep 2005 16:25:33 +0100 From: Antoine Pelisse To: freebsd-hackers@freebsd.org, Robert Watson In-Reply-To: <61c746830509300824g2f368d26pcc500403fe319b3b@mail.gmail.com> MIME-Version: 1.0 References: <61c746830509300215x7833746ew60896c4c1338ec65@mail.gmail.com> <61c746830509300224g3d79cbe4ve55e8b0b27004fc3@mail.gmail.com> <200509300854.48210.jhb@FreeBSD.org> <61c746830509300824g2f368d26pcc500403fe319b3b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: freebsd-5.4-stable panics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Antoine Pelisse List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 15:25:37 -0000 On 9/30/05, John Baldwin wrote: > On Friday 30 September 2005 05:24 am, Antoine Pelisse wrote: > > Hi Robert, > > I don't think your patch is correct, the total linked list can be broke= n > > > while the lock is released, thus just passing the link may not be enoug= h > > I have submitted a PR[1] for this a month ago but nobody took care of i= t > > yet Regards, > > Antoine Pelisse > > > > [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/84684 > > I think this patch looks ok. Robert, can you get the original panic on > this > thread tested against this patch? I had a small program which could reproduce this panic in 10 seconds, it was basically creating empty threads and calling kvm_getprocs() in the same time. Anyway the patch was able to stop the program from panicing. The panic is also reproducible in RELENG_6 and HEAD IIRC. > On 9/29/05, Robert Watson wrote: > > > On Thu, 29 Sep 2005, Rob Watt wrote: > > > > On Thu, 29 Sep 2005, Robert Watson wrote: > > > >> Could you dump the contents of *td and *td->td_proc for me? I'm > quite > > > >> interested to know what the value in td->td_proc->p_state is, amon= g > > > > > > > other > > > > > > >> things. If I could also have you generate a dump of the KSE group > > > >> structures in td->td_proc->p_ksegrps and the threads in > > > >> td->td_proc->p_threads. > > > > > > > > I've attached a file with many of the values you have asked for. We > > > > looked at some of the threads referenced by td->td_proc->p_threads, > but > > > > we weren't sure we were walking the list correctly. Do you have any > > > > tips > > > > > > > > for walking those thread lists? > > > > > > > >> Could you tell me if the program named by p->p_comm is linked > against > > > >> a threading library? If it's a custom app, you may already know, > and > > > >> if not, you can run ldd on the application to see what it is linke= d > > > >> against. > > > > > > > > The programs named by p->p_comm is linked against the pthreads > library. > > > > > > This seems to be enough information to at least track this down a bit= : > > > td_ksegrp is NULL, rather than a corrupt value, which suggests that > the > > > thread is incompletely initialized. Other hints that this are the cas= e > > > are that td_critnest is 1 (as is set when it is allocated), and the > state > > > is TDS_INACTIVE. Some other fields are set though, such as td_oncpu, > > > which is normally initialized to NOCPU. > > > > > > > (kgdb) p *td > > > > $1 =3D {td_proc =3D 0xffffff004aa9f000, td_ksegrp =3D 0x0, td_plist= =3D > > > > {tqe_next =3D 0xff ffff00b4798000, > > > > tqe_prev =3D 0xffffff00a97ae010}, td_kglist =3D {tqe_next =3D > > > > 0xffffff00b4798000, > > > > tqe_prev =3D 0xffffff00a97ae020}, td_slpq =3D {tqe_next =3D 0x0, tq= e_prev > > > > =3D 0xffff ff001fac7c10}, td_lockq =3D { > > > > tqe_next =3D 0xffffff00a97ae000, tqe_prev =3D 0xffffffffb6797a70}, > > > > td_runq =3D {tq e_next =3D 0x0, > > > > tqe_prev =3D 0xffffffff80608180}, td_selq =3D {tqh_first =3D 0x0, t= qh_last > > > > =3D 0xfff fff00633112c0}, > > > > td_sleepqueue =3D 0xffffff00382b0400, td_turnstile =3D > 0xffffff00c1712900, > > > > td_umtx q =3D 0xffffff00d1207080, > > > > td_tid =3D 100253, td_flags =3D 16777216, td_inhibitors =3D 0, td_p= flags =3D > > > > > 128, td_d upfd =3D 0, td_wchan =3D 0x0, > > > > td_wmesg =3D 0x0, td_lastcpu =3D 2 '\002', td_oncpu =3D 2 '\002', > > > > td_owepreempt =3D 0 '\0', td_locks =3D 0, > > > > td_blocked =3D 0x0, td_ithd =3D 0x0, td_lockname =3D 0x0, td_contes= ted =3D > > > > {lh_first =3D > > > > 0x0}, td_sleeplocks =3D 0x0, > > > > td_intr_nesting_level =3D 0, td_pinned =3D 0, td_mailbox =3D 0x0, t= d_ucred > =3D > > > > 0xfffff f00ad18f200, > > > > td_standin =3D 0x0, td_upcall =3D 0x0, td_sticks =3D 0, td_uuticks = =3D 0, > > > > td_usticks =3D > > > > 0, td_intrval =3D 0, > > > > td_oldsigmask =3D {__bits =3D {0, 0, 0, 0}}, td_sigmask =3D {__bits= =3D > > > > {4294967295, 4 294967295, 4294967295, > > > > 4294967295}}, td_siglist =3D {__bits =3D {0, 0, 0, 0}}, td_generati= on > > > > =3D 14, td _sigstk =3D {ss_sp =3D 0x0, > > > > ss_size =3D 0, ss_flags =3D 0}, td_kflags =3D 0, td_xsig =3D 0, > > > > td_profil_addr =3D 0, td_profil_ticks =3D 0, > > > > td_base_pri =3D 182 '\uffff', td_priority =3D 182 '\uffff', td_pcb = =3D > > > > 0xffffffffb68 dcd10, td_state =3D TDS_INACTIVE, > > > > td_retval =3D {1, 29309280}, td_slpcallout =3D {c_links =3D {sle = =3D > {sle_next > > > > =3D 0x0}, > > > > tqe =3D {tqe_next =3D 0x0, > > > > tqe_prev =3D 0xffffff001fac7d80}}, c_time =3D 55907602, c_arg =3D > > > > 0xffffff0063 311260, > > > > c_func =3D 0xffffffff802e32a0 , c_mtx =3D 0x0, c_fl= ags =3D > > > > 16}, td _frame =3D 0xffffffffb68dcc40, > > > > td_kstack_obj =3D 0xffffff0087f93d20, td_kstack =3D > 18446744072477315072, > > > > td_kstac k_pages =3D 4, > > > > td_altkstack_obj =3D 0x0, td_altkstack =3D 0, td_altkstack_pages = =3D 0, > > > > td_critnest =3D 1, td_md =3D { > > > > md_spinlock_count =3D 1, md_saved_flags =3D 582}, td_sched =3D > > > > 0xffffff0063311488} > > > > > > I'm not familiar with the internals of the thread and KSE life cycle > > > here, > > > > > > so I think we'll need to look to those more familiar with this to > > > understand what of two things may be going on: > > > > > > (1) Is the fact that td_ksegrp !=3D NULL an invariant for a connected > > > thread, and that kern_proc is relying on that but the thread code is > > > failing to implement it safely? > > > > > > (2) Is td_ksegrp sometimes left legitimately as NULL as part of the > > > thread life cycle, and that kern_proc incorrectly assumes that it is > > > never NULL when hooked up to a thread. > > > > > > This suggests a possible work-around of simply testing td_ksegrp for > NULL > > > in kern_proc in order to avoid this, while attempting to resolve > whether > > > an invariant is violated (or incorrectly assumed), which might requir= e > > > some serious thinking and a solution that is non-trivial. Something > like > > > the following might work in the mean time: > > > > > > Index: kern_proc.c > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > RCS file: /home/ncvs/src/sys/kern/kern_proc.c,v > > > retrieving revision 1.231 > > > diff -u -r1.231 kern_proc.c > > > --- kern_proc.c 27 Sep 2005 18:03:15 -0000 1.231 > > > +++ kern_proc.c 29 Sep 2005 20:50:33 -0000 > > > @@ -882,6 +882,8 @@ > > > } else { > > > _PHOLD(p); > > > FOREACH_THREAD_IN_PROC(p, td) { > > > + if (td->td_ksegrp =3D=3D NULL) > > > + continue; > > > fill_kinfo_thread(td, &kinfo_proc); > > > PROC_UNLOCK(p); > > > error =3D SYSCTL_OUT(req, (caddr_t)&kinfo_proc, > > > > > > I'm going to forward off your e-mail to the threads@ list and see if > > > anyone there wants to talk some more about this. If you don't mind > > > testing the above patch to see if this is a workable work-around, we > may > > > want to think about getting it committed in the mean time. > > > > > > Thanks, > > > > > > 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 " > > > > _______________________________________________ > > 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" > > -- > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" =3D http://www.FreeBSD.org > From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 15:43:09 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 CDDED16A41F for ; Fri, 30 Sep 2005 15:43:09 +0000 (GMT) (envelope-from reichert@numachi.com) Received: from meisai.numachi.com (meisai.numachi.com [198.175.254.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 3E37F43D49 for ; Fri, 30 Sep 2005 15:43:08 +0000 (GMT) (envelope-from reichert@numachi.com) Received: (qmail 1727 invoked from network); 30 Sep 2005 15:42:51 -0000 Received: from natto.numachi.com (198.175.254.216) by meisai.numachi.com with SMTP; 30 Sep 2005 15:42:51 -0000 Received: (qmail 7959 invoked by uid 1001); 30 Sep 2005 15:43:06 -0000 Date: Fri, 30 Sep 2005 11:43:06 -0400 From: Brian Reichert To: jerry@evasefor.com Message-ID: <20050930154306.GJ74605@numachi.com> References: <0MKoyl-1ELMcD46br-0004FY@mrelay.perfora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0MKoyl-1ELMcD46br-0004FY@mrelay.perfora.net> User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@freebsd.org Subject: Re: serial login to SBC X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 15:43:09 -0000 On Fri, Sep 30, 2005 at 05:14:01PM +0200, jerry@evasefor.com wrote: > > Hello list, > I am trying to use a FreeBSD box to log into a Single Board Computer. I > have a null modem and it's plugged to both serial > ports. The SBC runs openbsd ( /dev/cua00). > When I run "cu -l /dev/cuaa0" from FreeBSD, I don't get any login > prompt. Do you have getty running on that port on the SBC? > What I am doing wrong? > > I've already read the FBSD handbook. > I have an OpenBSD box to experiment with first, and can't serial login > either. > I really need help on this one. > Thank you > _______________________________________________ > 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 Fri Sep 30 15:54:44 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 4562C16A41F for ; Fri, 30 Sep 2005 15:54:44 +0000 (GMT) (envelope-from khaled@ipbill.com) Received: from mail.ipbill.com (mail.ipbill.com [217.73.64.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8489B43D48 for ; Fri, 30 Sep 2005 15:54:42 +0000 (GMT) (envelope-from khaled@ipbill.com) Received: (qmail 74258 invoked from network); 30 Sep 2005 09:14:16 -0000 Received: from unknown (HELO khaledpc) (192.168.129.200) by mail.ipbill.com with SMTP; 30 Sep 2005 09:14:16 -0000 From: "Khaled" To: "FreeBSD Hackers" Date: Fri, 30 Sep 2005 10:13:42 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: arplookup/arpresolved failure messages in mailserver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 15:54:44 -0000 Hi, I am seeing a lot of these messages in my /var/log/messages directory and cannot understand why: arplookup 192.168.0.12 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.168.0.12rt There were more of these messages for two other IPs (one external), but this is the only one with 'rt' trailed at the end of the IP. Whats this for? Its been happenning since yesterday and it seems that the server is attempting this every 2-3 seconds, which I think is the cause for a sluggish mailserver (this litterally happened over night!). Also, would this be linked to another incident which meant that all mail was being dumped in queue (im running qmail MTA)? Following a restart of the mail server, we experienced routing problems such that we were not able to access the server from the office LAN but could be accessed by another machine on its LAN; zebrad and ospfd did not start at restart. Why was this? This morning, all seems to be fine accept a couple of the following messages from last night: Sep 29 16:08:26 freebsd10 /kernel: arplookup 217.73.66.16 failed: host is not on local network Sep 29 17:40:50 freebsd10 /kernel: arplookup 217.73.66.16 failed: host is not on local network Sep 29 23:46:38 freebsd10 /kernel: arplookup 217.73.66.16 failed: host is not on local network Forgive me for being such a novice...but I am :) Thanks Khaled From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 16:33:12 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 451A616A41F for ; Fri, 30 Sep 2005 16:33:12 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4267443D69 for ; Fri, 30 Sep 2005 16:33:08 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j8UGUasw050700; Fri, 30 Sep 2005 10:30:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 30 Sep 2005 10:31:18 -0600 (MDT) Message-Id: <20050930.103118.121221639.imp@bsdimp.com> To: kerndev@yahoo.com From: "M. Warner Losh" In-Reply-To: <20050930010434.67727.qmail@web35003.mail.mud.yahoo.com> References: <20050930010434.67727.qmail@web35003.mail.mud.yahoo.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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 30 Sep 2005 10:30:37 -0600 (MDT) Cc: hackers@freebsd.org Subject: Re: using fast interrupts with em(4) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 16:33:12 -0000 In message: <20050930010434.67727.qmail@web35003.mail.mud.yahoo.com> Kernel Dev writes: : Hello All. For a project, I am looking into making the em(4) driver use fast interrupts. Has someone done this or are there other driver references that could help me in this? : : I understand that the main problems are: : : 1. Sharing of interrupts. : 2. Blocking (memory and mutexes). : : Are there any other issues I might have missed? You can share fast interrupts, but it isn't a good idea... You can't block in a fast interrupt. You must use spin locks. You cannot call anything that will sleep in a fast interrupt. Ideally, you'd not modify anything that isn't covered by your own spin locks, leaving that for a taskqueue or similar queueing strategy. Warner From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 16:33:16 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 EFD8D16A41F for ; Fri, 30 Sep 2005 16:33:16 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4633443D5F for ; Fri, 30 Sep 2005 16:33:15 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j8UGWZRS050701; Fri, 30 Sep 2005 10:32:35 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 30 Sep 2005 10:33:17 -0600 (MDT) Message-Id: <20050930.103317.107966523.imp@bsdimp.com> To: reichert@numachi.com From: "M. Warner Losh" In-Reply-To: <20050930154306.GJ74605@numachi.com> References: <0MKoyl-1ELMcD46br-0004FY@mrelay.perfora.net> <20050930154306.GJ74605@numachi.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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 30 Sep 2005 10:32:35 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, jerry@evasefor.com Subject: Re: serial login to SBC X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 16:33:17 -0000 In message: <20050930154306.GJ74605@numachi.com> Brian Reichert writes: : On Fri, Sep 30, 2005 at 05:14:01PM +0200, jerry@evasefor.com wrote: : > : > Hello list, : > I am trying to use a FreeBSD box to log into a Single Board Computer. I : > have a null modem and it's plugged to both serial : > ports. The SBC runs openbsd ( /dev/cua00). : > When I run "cu -l /dev/cuaa0" from FreeBSD, I don't get any login : > prompt. : : Do you have getty running on that port on the SBC? Do you have all the modem pins connected for this cable? Warner From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 16:46:34 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 77CE316A41F for ; Fri, 30 Sep 2005 16:46:34 +0000 (GMT) (envelope-from sebastien.bourdeauducq@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08EF643D48 for ; Fri, 30 Sep 2005 16:46:33 +0000 (GMT) (envelope-from sebastien.bourdeauducq@gmail.com) Received: by xproxy.gmail.com with SMTP id t4so241548wxc for ; Fri, 30 Sep 2005 09:46:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=i3PycN0cQyanYPmZIoGQjI+bFBk4cfudm1SYjG0gzCLPgdDaKTeC3feKQwesWcVgASI3kqz8r9NiypE/nFHl11nc3mc59BKap/VInmRI3sB8F1/12evQZxOTMMD+5UBCUrg9wNzdMqvB7ilIiwAWCagIyA6gPLM/m9ZiTnqeyzc= Received: by 10.70.30.9 with SMTP id d9mr966820wxd; Fri, 30 Sep 2005 09:46:33 -0700 (PDT) Received: from ?10.0.1.32? ( [82.231.252.157]) by mx.gmail.com with ESMTP id i11sm1148444wxd.2005.09.30.09.46.30; Fri, 30 Sep 2005 09:46:31 -0700 (PDT) From: Sebastien To: Andrey Simonenko Date: Fri, 30 Sep 2005 18:48:19 +0200 User-Agent: KMail/1.8 References: <200509201949.53951.sebastien.bourdeauducq@gmail.com> <200509241706.47995.sebastien.bourdeauducq@gmail.com> <20050926084550.GA444@pm514-9.comsys.ntu-kpi.kiev.ua> In-Reply-To: <20050926084550.GA444@pm514-9.comsys.ntu-kpi.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509301848.20284.sebastien.bourdeauducq@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Filesystem access from a KLD causes "vrele: negative ref cnt" panic X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 16:46:34 -0000 > It is hard to say something not seeing and understanding the > complete source code. Well, it's a very simple module : http://lekernel.lya-fr.com/firmwareagent_en.html > But since fdinit() which is called from > fork1() and fdfree() which is called from exit1() get and release > reference on vnodes fd_cdir and fd_rdir point to, you need to > follow this semantics. Ok, so it should be VREF'd twice - it works now :) Thanks, Sebastien From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 17:20:27 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 3B0C316A429 for ; Fri, 30 Sep 2005 17:20:27 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6DDB43D75 for ; Fri, 30 Sep 2005 17:20:21 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.233] (Not Verified[10.50.41.233]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 30 Sep 2005 13:36:19 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org Date: Fri, 30 Sep 2005 12:46:23 -0400 User-Agent: KMail/1.8 References: <0MKoyl-1ELMcD46br-0004FY@mrelay.perfora.net> <20050930154306.GJ74605@numachi.com> <20050930.103317.107966523.imp@bsdimp.com> In-Reply-To: <20050930.103317.107966523.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509301246.24630.jhb@FreeBSD.org> Cc: jerry@evasefor.com Subject: Re: serial login to SBC X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 17:20:27 -0000 On Friday 30 September 2005 12:33 pm, M. Warner Losh wrote: > In message: <20050930154306.GJ74605@numachi.com> > > Brian Reichert writes: > : On Fri, Sep 30, 2005 at 05:14:01PM +0200, jerry@evasefor.com wrote: > : > Hello list, > : > I am trying to use a FreeBSD box to log into a Single Board Computer. I > : > have a null modem and it's plugged to both serial > : > ports. The SBC runs openbsd ( /dev/cua00). > : > When I run "cu -l /dev/cuaa0" from FreeBSD, I don't get any login > : > prompt. > : > : Do you have getty running on that port on the SBC? > > Do you have all the modem pins connected for this cable? Also, make sure and use the right speed. e.g., if the remote box's console is running at 9600, do 'cu -l /dev/cuaa0 -s 9600' -- 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 Sep 30 17:20:27 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 41EE416A424; Fri, 30 Sep 2005 17:20:27 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5169D43D86; Fri, 30 Sep 2005 17:20:16 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.233] (Not Verified[10.50.41.233]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 30 Sep 2005 13:36:19 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org, Antoine Pelisse Date: Fri, 30 Sep 2005 13:10:01 -0400 User-Agent: KMail/1.8 References: <61c746830509300824g2f368d26pcc500403fe319b3b@mail.gmail.com> <61c746830509300825s5ad197fbt908267d54f1b7b8f@mail.gmail.com> In-Reply-To: <61c746830509300825s5ad197fbt908267d54f1b7b8f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509301310.03124.jhb@FreeBSD.org> Cc: Robert Watson Subject: Re: freebsd-5.4-stable panics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 17:20:27 -0000 On Friday 30 September 2005 11:25 am, Antoine Pelisse wrote: > On 9/30/05, John Baldwin wrote: > > On Friday 30 September 2005 05:24 am, Antoine Pelisse wrote: > > > Hi Robert, > > > I don't think your patch is correct, the total linked list can be > > > broken > > > > > > while the lock is released, thus just passing the link may not be > > > enough I have submitted a PR[1] for this a month ago but nobody took > > > care of it yet Regards, > > > Antoine Pelisse > > > > > > [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84684 > > > > I think this patch looks ok. Robert, can you get the original panic on > > this > > thread tested against this patch? > > I had a small program which could reproduce this panic in 10 seconds, it > was basically creating empty threads and calling kvm_getprocs() in the same > time. Anyway the patch was able to stop the program from panicing. > The panic is also reproducible in RELENG_6 and HEAD IIRC. It turns out that the sysctl buffer is already wired in one of the two cases that this function is called, so I moved the wiring up to the upper layer in the other case and cut out a bunch of the locking gymnastics as a result. Can you try this patch? Index: kern_proc.c =================================================================== RCS file: /usr/cvs/src/sys/kern/kern_proc.c,v retrieving revision 1.231 diff -u -r1.231 kern_proc.c --- kern_proc.c 27 Sep 2005 18:03:15 -0000 1.231 +++ kern_proc.c 30 Sep 2005 17:04:57 -0000 @@ -875,22 +875,16 @@ if (flags & KERN_PROC_NOTHREADS) { fill_kinfo_proc(p, &kinfo_proc); - PROC_UNLOCK(p); error = SYSCTL_OUT(req, (caddr_t)&kinfo_proc, sizeof(kinfo_proc)); - PROC_LOCK(p); } else { - _PHOLD(p); FOREACH_THREAD_IN_PROC(p, td) { fill_kinfo_thread(td, &kinfo_proc); - PROC_UNLOCK(p); error = SYSCTL_OUT(req, (caddr_t)&kinfo_proc, sizeof(kinfo_proc)); - PROC_LOCK(p); if (error) break; } - _PRELE(p); } PROC_UNLOCK(p); if (error) @@ -932,6 +926,9 @@ if (oid_number == KERN_PROC_PID) { if (namelen != 1) return (EINVAL); + error = sysctl_wire_old_buffer(req, 0); + if (error) + return (error); p = pfind((pid_t)name[0]); if (!p) return (ESRCH); -- 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 Sep 30 17:44:11 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 A4CC216A41F; Fri, 30 Sep 2005 17:44:11 +0000 (GMT) (envelope-from jerry@evasefor.com) Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4869F43D49; Fri, 30 Sep 2005 17:44:11 +0000 (GMT) (envelope-from jerry@evasefor.com) Received: from config3.kundenserver.de [172.23.4.130] (helo=togal2.1and1.com) by mrelay.perfora.net with ESMTP (Nemesis), id 0MKp2t-1ELOvS2gcy-0001na; Fri, 30 Sep 2005 13:44:02 -0400 To: , From: X-Binford: 6100 (more power) X-Originating-From: 29983738 X-Mailer: Webmail X-Received: from config3 by 67.103.124.219 with HTTP id 29983738 for jhb@freebsd.org; Fri, 30 Sep 2005 19:42:01 +0200 Content-Type: text/plain; charset="iso-8859-1" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 Date: Fri, 30 Sep 2005 19:42:01 +0200 Message-ID: <0MKp2t-1ELOvS2gcy-0001na@mrelay.perfora.net> Cc: Subject: RE: serial login to SBC X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 17:44:11 -0000 Thank you all for your replys. My answers are inline: > : Do you have getty running on that port on the SBC? yes. It should be running. We have in /etc/ttys (openbsd) tty00 "/usr/libexec/getty std.9600" dialup on secure > Do you have all the modem pins connected for this cable? I got this null modem from circuit city. it worked in other circumstances when I do serial debugging on other boxes. >Also, make sure and use the right speed. e.g., if the remote box's >console is running at 9600, do 'cu -l /dev/cuaa0 -s 9600' I tried this and still no login prompt. One thing I've noticed on the FreeBSD (5.4 RELEASE) dmesg is sio0: port may not be enabled I enabled the first serial port in the BIOS, but I still get this. Me scratching head now. Anything else I may be missing? J. From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 18:21:30 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 DFB4216A420; Fri, 30 Sep 2005 18:21:30 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5860B43D4C; Fri, 30 Sep 2005 18:21:30 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j8UIJPkf051737; Fri, 30 Sep 2005 12:19:25 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 30 Sep 2005 12:20:07 -0600 (MDT) Message-Id: <20050930.122007.08405107.imp@bsdimp.com> To: jerry@evasefor.com From: "M. Warner Losh" In-Reply-To: <0MKp2t-1ELOvS2gcy-0001na@mrelay.perfora.net> References: <0MKp2t-1ELOvS2gcy-0001na@mrelay.perfora.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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 30 Sep 2005 12:19:25 -0600 (MDT) Cc: freebsd-hackers@freebsd.org Subject: Re: serial login to SBC X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 18:21:31 -0000 In message: <0MKp2t-1ELOvS2gcy-0001na@mrelay.perfora.net> writes: : One thing I've noticed on the FreeBSD (5.4 RELEASE) dmesg is : sio0: port may not be enabled : : I enabled the first serial port in the BIOS, but I still get this. : Me scratching head now. Anything else I may be missing? Can you post a dmesg? Also, ps auxww | grep getty | grep d0 should show something like: root 726 0.0 0.2 1316 956 d0 Is+ 8:16AM 0:00.00 /usr/libexec/getty Pc ttyd0 You should also be able to tell if sio attaches by looking at /dev: ls -l /dev/*d0* you will likely see ad0 devices, kbd0 devices in addition to ttyd0 and cuad0 devices. Warner From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 18:57:29 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 770B616A41F for ; Fri, 30 Sep 2005 18:57:29 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1679543D48 for ; Fri, 30 Sep 2005 18:57:29 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j8UIsvT0052085; Fri, 30 Sep 2005 12:54:57 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 30 Sep 2005 12:55:39 -0600 (MDT) Message-Id: <20050930.125539.116350804.imp@bsdimp.com> To: babkin@users.sourceforge.net, babkin@verizon.net From: "M. Warner Losh" In-Reply-To: <16436490.1128102582153.JavaMail.root@vms071.mailsrvcs.net> References: <16436490.1128102582153.JavaMail.root@vms071.mailsrvcs.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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 30 Sep 2005 12:54:58 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, jerry@evasefor.com Subject: Re: serial login to SBC X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 18:57:29 -0000 In message: <16436490.1128102582153.JavaMail.root@vms071.mailsrvcs.net> Sergey Babkin writes: : >From: "M. Warner Losh" : : >In message: <20050930154306.GJ74605@numachi.com> : > Brian Reichert writes: : >: On Fri, Sep 30, 2005 at 05:14:01PM +0200, jerry@evasefor.com wrote: : >: > : >: > Hello list, : >: > I am trying to use a FreeBSD box to log into a Single Board Computer. I : >: > have a null modem and it's plugged to both serial : >: > ports. The SBC runs openbsd ( /dev/cua00). : >: > When I run "cu -l /dev/cuaa0" from FreeBSD, I don't get any login : >: > prompt. : >: : >: Do you have getty running on that port on the SBC? : > : >Do you have all the modem pins connected for this cable? : : Also, is the cable pin-out correct even for the Rx : and Tx pins? There are weird recombinations of : male-female and DCE-DTE pin-out used by different : manufacturers. The easiest way to check is to get : a port tester (a pass-through BOX with LEDs) from : some place like Radioshack. : : The correct Unix cable connection is : : Tx - Rx : DTR - DSR, CD : CTS - RTS : : (and the other side symmetric). Many cable : manufacturers use different (wrong) connections. Closely related is the 1 3 5 7 9 2 4 6 8 10 vs 1 2 3 4 5 6 7 8 9 10 issue for headers. Warner From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 19:43:15 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 5253B16A41F for ; Fri, 30 Sep 2005 19:43:15 +0000 (GMT) (envelope-from V.Haisman@sh.cvut.cz) Received: from service.sh.cvut.cz (service.sh.cvut.cz [147.32.127.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id D369C43D48 for ; Fri, 30 Sep 2005 19:43:14 +0000 (GMT) (envelope-from V.Haisman@sh.cvut.cz) Received: from localhost (localhost [127.0.0.1]) by service.sh.cvut.cz (Postfix) with ESMTP id F27AA1A33EC for ; Fri, 30 Sep 2005 21:43:12 +0200 (CEST) Received: from service.sh.cvut.cz ([127.0.0.1]) by localhost (service [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22228-10 for ; Fri, 30 Sep 2005 21:43:07 +0200 (CEST) Received: from logout.sh.cvut.cz (logout.sh.cvut.cz [147.32.127.203]) by service.sh.cvut.cz (Postfix) with ESMTP id 676EE1A33F8 for ; Fri, 30 Sep 2005 21:43:06 +0200 (CEST) Received: from logout (logout [147.32.127.203]) by logout.sh.cvut.cz (Postfix) with ESMTP id 141653C0DD for ; Fri, 30 Sep 2005 21:43:13 +0200 (CEST) Date: Fri, 30 Sep 2005 21:43:13 +0200 (CEST) From: Vaclav Haisman Cc: freebsd-hackers@freebsd.org In-Reply-To: <433C9E44.8000800@FreeBSD.org> Message-ID: <20050930213905.M74024@logout.sh.cvut.cz> References: <433B3F41.8060004@spintech.ro> <433B60EE.4090207@centtech.com> <433C9A64.3030602@spintech.ro> <433C9E44.8000800@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at sh.cvut.cz Subject: Re: journaling fs and large mailbox format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 19:43:15 -0000 On Thu, 29 Sep 2005, Doug Barton wrote: > Alin-Adrian Anton wrote: > >> XFS fits incredibly well with Maildir, however this I did not test >> practically > > I am curious as to what the defaults are for frag, inode, and block sizes on > XFS, and whether that is one of the factors that make it work well with > maildir. > > Doug I don't think that frag, inode and block size is the main factor that makes XFS work well in many small files situations. From what I have read about XFS I gather that it allocates inodes on demand, that it doesn't have fixed amount of them. VH From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 20:08:52 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 47F8316A41F for ; Fri, 30 Sep 2005 20:08:52 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 7DCD643D4C for ; Fri, 30 Sep 2005 20:08:51 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 30 Sep 2005 21:08:49 +0100 (BST) Date: Fri, 30 Sep 2005 21:08:49 +0100 From: David Malone To: Vaclav Haisman Message-ID: <20050930200849.GA84809@walton.maths.tcd.ie> References: <433B3F41.8060004@spintech.ro> <433B60EE.4090207@centtech.com> <433C9A64.3030602@spintech.ro> <433C9E44.8000800@FreeBSD.org> <20050930213905.M74024@logout.sh.cvut.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050930213905.M74024@logout.sh.cvut.cz> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: freebsd-hackers@freebsd.org Subject: Re: journaling fs and large mailbox format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 20:08:52 -0000 On Fri, Sep 30, 2005 at 09:43:13PM +0200, Vaclav Haisman wrote: > I don't think that frag, inode and block size is the main factor that makes > XFS work well in many small files situations. From what I have read about > XFS I gather that it allocates inodes on demand, that it doesn't have fixed > amount of them. Nope - not by default on a Linux 2.6.12 kernel anyway: David. 11% df -i . Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda2 96384 31 96353 1% /boot 12% mount | fgrep /boot /dev/sda2 on /boot type xfs (rw) 13% @ i=0 14% while ( $i < 96358 ) while? touch $i while? @ i++ while? end touch: cannot touch `96353': No space left on device touch: cannot touch `96354': No space left on device touch: cannot touch `96355': No space left on device touch: cannot touch `96356': No space left on device touch: cannot touch `96357': No space left on device 16% df -i /boot Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda2 96384 96384 0 100% /boot From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 21:52:00 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 7373516A41F for ; Fri, 30 Sep 2005 21:52:00 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1697D43D48 for ; Fri, 30 Sep 2005 21:51:59 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.23] (andersonbox3.centtech.com [192.168.42.23]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j8ULpwZk054354 for ; Fri, 30 Sep 2005 16:51:58 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <433DB377.6080202@centtech.com> Date: Fri, 30 Sep 2005 16:51:51 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.11) Gecko/20050914 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 X-Virus-Scanned: ClamAV 0.82/1106/Fri Sep 30 12:17:17 2005 on mh2.centtech.com X-Virus-Status: Clean Subject: sysctl variable creation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 21:52:00 -0000 I'm hacking up sys/ufs/ufs/ufs_vnops.c, and I've added a sysctl entry, but it doesn't appear via sysctl -a -c vfs.ufs. Here's what I've done: --- ufs_vnops.c-orig Thu Sep 29 20:47:50 2005 +++ ufs_vnops.c Fri Sep 30 13:44:55 2005 @@ -79,6 +79,7 @@ #include #include #include +#include #ifdef UFS_DIRHASH #include #endif @@ -122,6 +123,12 @@ 0, DIRBLKSIZ - 12, 2, ".." }; +struct ufsstats ufsstats; + +static SYSCTL_NODE(_vfs, OID_AUTO, ufs, CTLFLAG_RD, 0, "UFS filesystem"); +SYSCTL_STRUCT(_vfs_ufs, OID_AUTO, ufsstats, CTLFLAG_RD, + &ufsstats, ufsstats, "S,ufsstats"); + void ufs_itimes(vp) struct vnode *vp; @@ -172,6 +179,7 @@ error = ufs_makeinode(MAKEIMODE(ap->a_vap->va_type, ap->a_vap->va_mode), ap->a_dvp, ap->a_vpp, ap->a_cnp); + ufsstats.create++; if (error) return (error); return (0); Compiles ok, just no sysctl variable.. Thanks! (sorry if it's a stupid mistake - I'm new to this) Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 1 04:05:41 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 77D4B16A41F; Sat, 1 Oct 2005 04:05:41 +0000 (GMT) (envelope-from grog@lemis.com) Received: from ext-gw.lemis.com (ext-gw.lemis.com [150.101.14.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6C0943D53; Sat, 1 Oct 2005 04:05:40 +0000 (GMT) (envelope-from grog@lemis.com) Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.135]) by ext-gw.lemis.com (Postfix) with ESMTP id A5CB2131D78; Sat, 1 Oct 2005 13:35:39 +0930 (CST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 83E0E85209; Sat, 1 Oct 2005 13:35:39 +0930 (CST) Date: Sat, 1 Oct 2005 13:35:39 +0930 From: Greg 'groggy' Lehey To: FreeBSD Chat , FreeBSD Hackers Message-ID: <20051001040539.GA95042@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: Subject: Daemon image with a beer mug? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2005 04:05:41 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'm just putting the finishing touches on a paper that I'll present at the AUUG 2005 conference (see http://www.auug.org.au/ for details). The paper is about using FreeBSD to control the fermentation process. Normally I put a beastie image at the bottom right of the slides (see http://www.lemis.com/SMPng/AUUG2001/slides.pdf for an example), but in this case it would seem appropriate to have the beastie holding a mug of beer. I seem to remember having seen something like that once, but I can't trace it. If you know where there is one, please let me know. Greg -- See complete headers for address and phone numbers. --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDPgsTIubykFB6QiMRAkZ+AJ48y34YjvDPCZLSOwD95wpsMC/usgCfTGKq h6NtcV8pK36mLwOksJ+DGCw= =Obv/ -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 1 04:08:32 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 3EDA416A41F for ; Sat, 1 Oct 2005 04:08:32 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail25.syd.optusnet.com.au (mail25.syd.optusnet.com.au [211.29.133.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E3D643D49 for ; Sat, 1 Oct 2005 04:08:31 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail25.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j9148OBv007330 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 1 Oct 2005 14:08:26 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j9148OSR079709; Sat, 1 Oct 2005 14:08:24 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j9148MnP079708; Sat, 1 Oct 2005 14:08:22 +1000 (EST) (envelope-from pjeremy) Date: Sat, 1 Oct 2005 14:08:22 +1000 From: Peter Jeremy To: Eric Anderson Message-ID: <20051001040822.GM72352@cirb503493.alcatel.com.au> References: <433DB377.6080202@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <433DB377.6080202@centtech.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: sysctl variable creation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2005 04:08:32 -0000 On Fri, 2005-Sep-30 16:51:51 -0500, Eric Anderson wrote: >I'm hacking up sys/ufs/ufs/ufs_vnops.c, and I've added a sysctl entry, >but it doesn't appear via sysctl -a -c vfs.ufs. Here's what I've done: The code looks correct but I can't find a '-c' option to sysctl in 4.x, 5.x or 7.x. Note that SYSCTL_STRUCT defines an opaque type that won't be displayed by default. You may want "sysctl -x vfs.ufs" -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 1 04:14:12 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 5B91816A41F for ; Sat, 1 Oct 2005 04:14:12 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E550043D4C for ; Sat, 1 Oct 2005 04:14:11 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.23] (andersonbox3.centtech.com [192.168.42.23]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j914E9Q4080172; Fri, 30 Sep 2005 23:14:09 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <433E0D09.7060804@centtech.com> Date: Fri, 30 Sep 2005 23:14:01 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.11) Gecko/20050914 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Jeremy References: <433DB377.6080202@centtech.com> <20051001040822.GM72352@cirb503493.alcatel.com.au> In-Reply-To: <20051001040822.GM72352@cirb503493.alcatel.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1106/Fri Sep 30 12:17:17 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: sysctl variable creation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2005 04:14:12 -0000 Peter Jeremy wrote: > On Fri, 2005-Sep-30 16:51:51 -0500, Eric Anderson wrote: > >>I'm hacking up sys/ufs/ufs/ufs_vnops.c, and I've added a sysctl entry, >>but it doesn't appear via sysctl -a -c vfs.ufs. Here's what I've done: > > > The code looks correct but I can't find a '-c' option to sysctl in > 4.x, 5.x or 7.x. Note that SYSCTL_STRUCT defines an opaque type that > won't be displayed by default. You may want "sysctl -x vfs.ufs" > Yea, that's what I meant, sorry about that. I think I am missing a SYSCTL_DECL in there, so maybe this would work: --- /usr/src/sys/ufs/ufs/ufs_vnops.c-orig Thu Sep 29 20:47:50 2005 +++ /usr/src/sys/ufs/ufs/ufs_vnops.c Fri Sep 30 23:14:34 2005 @@ -79,6 +79,7 @@ #include #include #include +#include #ifdef UFS_DIRHASH #include #endif @@ -122,6 +123,13 @@ 0, DIRBLKSIZ - 12, 2, ".." }; +struct ufsstats ufsstats; + +SYSCTL_DECL(_vfs_ufs); + +SYSCTL_STRUCT(_vfs_ufs, OID_AUTO, ufsstats, CTLFLAG_RW, + &ufsstats, ufsstats, "S,ufsstats"); + void ufs_itimes(vp) struct vnode *vp; @@ -172,6 +180,7 @@ error = ufs_makeinode(MAKEIMODE(ap->a_vap->va_type, ap->a_vap->va_mode), ap->a_dvp, ap->a_vpp, ap->a_cnp); + ufsstats.create++; if (error) return (error); return (0); Thanks for the reply! Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 1 09:16:28 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 7A07916A41F for ; Sat, 1 Oct 2005 09:16:28 +0000 (GMT) (envelope-from jhs@flat.berklix.net) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id C84D943D46 for ; Sat, 1 Oct 2005 09:16:27 +0000 (GMT) (envelope-from jhs@flat.berklix.net) Received: from js.berklix.net (p549A667B.dip.t-dialin.net [84.154.102.123]) (authenticated bits=0) by tower.berklix.org (8.12.9p2/8.12.9) with ESMTP id j919GMxr060423; Sat, 1 Oct 2005 11:16:23 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (fire.jhs.private [192.168.91.41]) by js.berklix.net (8.12.11/8.12.11) with ESMTP id j919GLgS005163; Sat, 1 Oct 2005 11:16:21 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (localhost.jhs.private [127.0.0.1]) by fire.jhs.private (8.13.1/8.13.1) with ESMTP id j919Gbe0014920; Sat, 1 Oct 2005 11:16:37 +0200 (CEST) (envelope-from jhs@fire.jhs.private) Message-Id: <200510010916.j919Gbe0014920@fire.jhs.private> To: jerry@evasefor.com From: "Julian Stacey" Organization: http://berklix.com Munich Unix, BSD, Internet Consultancy User-agent: EXMH http://beedub.com/exmh/ on FreeBSD http://freebsd.org X-URL: http://berklix.com/~jhs/ In-reply-to: Your message of "Fri, 30 Sep 2005 17:14:01 +0200." <0MKoyl-1ELMcD46br-0004FY@mrelay.perfora.net> Date: Sat, 01 Oct 2005 11:16:37 +0200 Sender: jhs@flat.berklix.net Cc: freebsd-hackers@freebsd.org Subject: Re: serial login to SBC X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2005 09:16:28 -0000 Reference: > From: > Date: Fri, 30 Sep 2005 17:14:01 +0200 > Message-id: <0MKoyl-1ELMcD46br-0004FY@mrelay.perfora.net> jerry@evasefor.com wrote: > > Hello list, > I am trying to use a FreeBSD box to log into a Single Board Computer. I > have a null modem and it's plugged to both serial > ports. The SBC runs openbsd ( /dev/cua00). > When I run "cu -l /dev/cuaa0" from FreeBSD, I don't get any login > prompt. > > What I am doing wrong? Use a break out box, look at the LEDs, see if all the CTS RTS DTR DCE tedious stuff is set right. > > I've already read the FBSD handbook. > I have an OpenBSD box to experiment with first, and can't serial login > either. > I really need help on this one. -- Julian Stacey. Consultant Unix Net & Sys. Eng., Munich. http://berklix.com Mail Ascii not HTML. Ihr Rauch = meine allergischen Kopfschmerzen. From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 17:49:43 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 3A06916A41F for ; Fri, 30 Sep 2005 17:49:43 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFBD043D49 for ; Fri, 30 Sep 2005 17:49:42 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms071.mailsrvcs.net ([192.168.1.4]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0INN00GX25IUVPK0@vms044.mailsrvcs.net> for freebsd-hackers@freebsd.org; Fri, 30 Sep 2005 12:49:42 -0500 (CDT) Date: Fri, 30 Sep 2005 12:49:42 -0500 (CDT) From: Sergey Babkin To: "M. Warner Losh" , reichert@numachi.com Message-id: <16436490.1128102582153.JavaMail.root@vms071.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Mailman-Approved-At: Sat, 01 Oct 2005 11:41:17 +0000 Cc: freebsd-hackers@freebsd.org, jerry@evasefor.com Subject: Re: Re: serial login to SBC X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: babkin@users.sf.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 17:49:43 -0000 >From: "M. Warner Losh" >In message: <20050930154306.GJ74605@numachi.com> > Brian Reichert writes: >: On Fri, Sep 30, 2005 at 05:14:01PM +0200, jerry@evasefor.com wrote: >: > >: > Hello list, >: > I am trying to use a FreeBSD box to log into a Single Board Computer. I >: > have a null modem and it's plugged to both serial >: > ports. The SBC runs openbsd ( /dev/cua00). >: > When I run "cu -l /dev/cuaa0" from FreeBSD, I don't get any login >: > prompt. >: >: Do you have getty running on that port on the SBC? > >Do you have all the modem pins connected for this cable? Also, is the cable pin-out correct even for the Rx and Tx pins? There are weird recombinations of male-female and DCE-DTE pin-out used by different manufacturers. The easiest way to check is to get a port tester (a pass-through BOX with LEDs) from some place like Radioshack. The correct Unix cable connection is Tx - Rx DTR - DSR, CD CTS - RTS (and the other side symmetric). Many cable manufacturers use different (wrong) connections. -SB From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 21:37:08 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 5B08716A41F for ; Fri, 30 Sep 2005 21:37:08 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CC6A43D4C for ; Fri, 30 Sep 2005 21:37:07 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465 for ; Fri, 30 Sep 2005 14:37:06 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 95F265D07 for ; Fri, 30 Sep 2005 14:37:05 -0700 (PDT) To: freebsd-hackers@FreeBSD.org In-reply-to: Your message of "Thu, 29 Sep 2005 23:41:57 PDT." <433CDE35.7040801@FreeBSD.org> Date: Fri, 30 Sep 2005 14:37:05 -0700 From: "Kevin Oberman" Message-Id: <20050930213705.95F265D07@ptavv.es.net> X-Mailman-Approved-At: Sat, 01 Oct 2005 11:41:17 +0000 Cc: Subject: Re: A smarter mergemaster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 21:37:08 -0000 > Date: Thu, 29 Sep 2005 23:41:57 -0700 > From: Doug Barton > Sender: owner-freebsd-current@freebsd.org > > One of the design decisions that you need to be aware of for this project > since day one was to try and balance intelligent behavior and configuration > options that would be useful for the very small percentage of the FreeBSD > user community that constitutes our developers, versus the needs of the vast > majority of "regular" users who need to be able to use the tool without > becoming experts in either our build system, or the tool itself. That is why > every single default for mergemaster is to do nothing. It was a purposeful > decision to require the user to examine change requests, and make an > affirmative choice to approve them. Doug, You just hit on one of my pet peeves with mergemaster! Contrary to what you say: "every single default for mergemaster is to do nothing", when a file is found in /etc/rc.d that is not in /usr/src/etc/rc.d, the default is to delete the file in etc. I think that this is a bad thing(tm). I have to restore my profile.sh (which MUST be in /etc/rc.d as it needs to be run before /usr is mounted). I do have an open PR on this (conf/85449), but it does not seem to have gone anywhere other than being assigned to you last Friday. (No, I didn't expect anything to happen this quickly. You just gave me such a perfect opportunity to gripe!) By the way, having run FreeBSD before mergemaster, it's a huge improvement on those ugly days. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 1 13:56:06 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 7250216A41F for ; Sat, 1 Oct 2005 13:56:06 +0000 (GMT) (envelope-from apelisse@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F03743D45 for ; Sat, 1 Oct 2005 13:56:05 +0000 (GMT) (envelope-from apelisse@gmail.com) Received: by nproxy.gmail.com with SMTP id x4so24422nfb for ; Sat, 01 Oct 2005 06:56:03 -0700 (PDT) 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:references; b=JoxOmOvqobB7gk3ZvaHN26Nln/Evt3Fm/NBw9aBpqQAEZqS18azmrvW4KDKxWw2hRk/N4PNMrsk4CuiZlIXvBJu/0M59AsPz3mpO5CDxLh3vDAnOoDfU6whvEnh+zLLq3mWr2+Tc0g3mUAALRSTPVM8lhJs9+haMbU3ahDTIjM0= Received: by 10.48.239.6 with SMTP id m6mr146597nfh; Sat, 01 Oct 2005 06:56:03 -0700 (PDT) Received: by 10.48.108.18 with HTTP; Sat, 1 Oct 2005 06:56:03 -0700 (PDT) Message-ID: <61c746830510010656o363cfbc7icc28556a6df27d36@mail.gmail.com> Date: Sat, 1 Oct 2005 14:56:03 +0100 From: Antoine Pelisse To: John Baldwin In-Reply-To: <200509301310.03124.jhb@FreeBSD.org> MIME-Version: 1.0 References: <61c746830509300824g2f368d26pcc500403fe319b3b@mail.gmail.com> <61c746830509300825s5ad197fbt908267d54f1b7b8f@mail.gmail.com> <200509301310.03124.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: freebsd-5.4-stable panics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Antoine Pelisse List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2005 13:56:06 -0000 On 9/30/05, John Baldwin wrote: > > On Friday 30 September 2005 11:25 am, Antoine Pelisse wrote: > > On 9/30/05, John Baldwin wrote: > > > On Friday 30 September 2005 05:24 am, Antoine Pelisse wrote: > > > > Hi Robert, > > > > I don't think your patch is correct, the total linked list can be > > > > broken > > > > > > > > while the lock is released, thus just passing the link may not be > > > > enough I have submitted a PR[1] for this a month ago but nobody too= k > > > > care of it yet Regards, > > > > Antoine Pelisse > > > > > > > > [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/84684 > > > > > > I think this patch looks ok. Robert, can you get the original panic o= n > > > this > > > thread tested against this patch? > > > > I had a small program which could reproduce this panic in 10 seconds, i= t > > was basically creating empty threads and calling kvm_getprocs() in the > same > > time. Anyway the patch was able to stop the program from panicing. > > The panic is also reproducible in RELENG_6 and HEAD IIRC. > > It turns out that the sysctl buffer is already wired in one of the two > cases > that this function is called, so I moved the wiring up to the upper layer > in > the other case and cut out a bunch of the locking gymnastics as a result. > Can you try this patch? > > Index: kern_proc.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /usr/cvs/src/sys/kern/kern_proc.c,v > retrieving revision 1.231 > diff -u -r1.231 kern_proc.c > --- kern_proc.c 27 Sep 2005 18:03:15 -0000 1.231 > +++ kern_proc.c 30 Sep 2005 17:04:57 -0000 > @@ -875,22 +875,16 @@ > > if (flags & KERN_PROC_NOTHREADS) { > fill_kinfo_proc(p, &kinfo_proc); > - PROC_UNLOCK(p); > error =3D SYSCTL_OUT(req, (caddr_t)&kinfo_proc, > sizeof(kinfo_proc)); > - PROC_LOCK(p); > } else { > - _PHOLD(p); > FOREACH_THREAD_IN_PROC(p, td) { > fill_kinfo_thread(td, &kinfo_proc); > - PROC_UNLOCK(p); > error =3D SYSCTL_OUT(req, (caddr_t)&kinfo_proc, > sizeof(kinfo_proc)); > - PROC_LOCK(p); > if (error) > break; > } > - _PRELE(p); > } > PROC_UNLOCK(p); > if (error) > @@ -932,6 +926,9 @@ > if (oid_number =3D=3D KERN_PROC_PID) { > if (namelen !=3D 1) > return (EINVAL); > + error =3D sysctl_wire_old_buffer(req, 0); > + if (error) > + return (error); > p =3D pfind((pid_t)name[0]); > if (!p) > return (ESRCH); > > -- > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" =3D http://www.FreeBSD.org > Hi John, I'm sorry I can't test it right now, I'm in a foreign country for three months and can only connect to the internet through the university connection. I'll be back home mid-december. Maybe Rob should take care of testing it. Regards, Antoine Pelisse From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 1 19:35:49 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 71DFB16A41F for ; Sat, 1 Oct 2005 19:35:49 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id A132B43D46 for ; Sat, 1 Oct 2005 19:35:48 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j91JZcoF036736; Sat, 1 Oct 2005 23:35:38 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j91JZcUn036735; Sat, 1 Oct 2005 23:35:38 +0400 (MSD) (envelope-from yar) Date: Sat, 1 Oct 2005 23:35:38 +0400 From: Yar Tikhiy To: Kevin Oberman Message-ID: <20051001193538.GA27782@comp.chem.msu.su> References: <433CDE35.7040801@FreeBSD.org> <20050930213705.95F265D07@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050930213705.95F265D07@ptavv.es.net> User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@freebsd.org Subject: Re: A smarter mergemaster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2005 19:35:49 -0000 On Fri, Sep 30, 2005 at 02:37:05PM -0700, Kevin Oberman wrote: > > You just hit on one of my pet peeves with mergemaster! Contrary to what > you say: "every single default for mergemaster is to do nothing", when a > file is found in /etc/rc.d that is not in /usr/src/etc/rc.d, the default > is to delete the file in etc. I think that this is a bad thing(tm). I > have to restore my profile.sh (which MUST be in /etc/rc.d as it needs to > be run before /usr is mounted). > > I do have an open PR on this (conf/85449), but it does not seem to have > gone anywhere other than being assigned to you last Friday. (No, I > didn't expect anything to happen this quickly. You just gave me such a > perfect opportunity to gripe!) FWIW, I wondered if my version of mergemaster in p4 was affected by this issue and found to my surprise that I had already addressed it in my changes. -- Yar From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 1 19:42:16 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 13DC916A41F for ; Sat, 1 Oct 2005 19:42:16 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.62]) by mx1.FreeBSD.org (Postfix) with SMTP id 4E1E143D6D for ; Sat, 1 Oct 2005 19:42:11 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 8522 invoked by uid 399); 1 Oct 2005 19:42:11 -0000 Received: from mail1.fluidhosting.com (204.14.90.61) by mail2.fluidhosting.com with SMTP; 1 Oct 2005 19:42:11 -0000 Received: (qmail 84426 invoked by uid 399); 1 Oct 2005 19:42:09 -0000 Received: from localhost (HELO ?192.168.1.102?) (dougb@dougbarton.net@127.0.0.1) by localhost with SMTP; 1 Oct 2005 19:42:09 -0000 Message-ID: <433EE690.9070408@FreeBSD.org> Date: Sat, 01 Oct 2005 12:42:08 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Oberman References: <20050930213705.95F265D07@ptavv.es.net> In-Reply-To: <20050930213705.95F265D07@ptavv.es.net> X-Enigmail-Version: 0.92.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: A smarter mergemaster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2005 19:42:16 -0000 Kevin Oberman wrote: >>Date: Thu, 29 Sep 2005 23:41:57 -0700 >>From: Doug Barton >>Sender: owner-freebsd-current@freebsd.org >> >>One of the design decisions that you need to be aware of for this project >>since day one was to try and balance intelligent behavior and configuration >>options that would be useful for the very small percentage of the FreeBSD >>user community that constitutes our developers, versus the needs of the vast >>majority of "regular" users who need to be able to use the tool without >>becoming experts in either our build system, or the tool itself. That is why >>every single default for mergemaster is to do nothing. It was a purposeful >>decision to require the user to examine change requests, and make an >>affirmative choice to approve them. > > > Doug, > > You just hit on one of my pet peeves with mergemaster! Contrary to what > you say: "every single default for mergemaster is to do nothing", when a > file is found in /etc/rc.d that is not in /usr/src/etc/rc.d, the default > is to delete the file in etc. I think that this is a bad thing(tm). Agreed, The only thing I can think of as a reason for the anomaly is that at the time I wrote that code, the problems being reported with stale rc files were pretty numerous, and perhaps I was being overzealous. I've already said that I like Yar's idea of offering options to delete files or not, so I'll look at bringing at least that code in ASAP with the change that you requested, and possibly seek an MFC before 6 release. > By the way, having run FreeBSD before mergemaster, it's a huge > improvement on those ugly days. Thanks for the kind words, they are always appreciated. :) I should also take this opportunity to say that I appreciate all the interesting ideas on this thread, and I am paying attention to what's said even if I don't comment on it. Doug -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 1 20:34:34 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 0B8E916A41F for ; Sat, 1 Oct 2005 20:34:34 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from gate.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 966AF43D49 for ; Sat, 1 Oct 2005 20:34:33 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by gate.bitblocks.com (8.13.4/8.13.1) with ESMTP id j91KYWPQ064132 for ; Sat, 1 Oct 2005 13:34:33 -0700 (PDT) (envelope-from bakul@bitblocks.com) Message-Id: <200510012034.j91KYWPQ064132@gate.bitblocks.com> To: freebsd-hackers@freebsd.org In-reply-to: Your message of "Fri, 30 Sep 2005 19:01:05 +0400." <20050930150105.GA55158@comp.chem.msu.su> Date: Sat, 01 Oct 2005 13:34:32 -0700 From: Bakul Shah Subject: Re: A smarter mergemaster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2005 20:34:34 -0000 Here is an idea for the mergemaster hackers' consideration! By keeping /etc files in a source repository one can archive and document all local changes. This is useful for some of the same reasons for which we keep sources in a repo: recovery from mistakes, reuse of old code, checking who did what, more than one person can make changes, tracking history, debugging etc. If mergemaster handled or worked with a local cvs /etc repo that'd be very nice! The idea is to make changes and test them in a temp workspace and commit them *only if they do the right thing*! I envision a workflow something like this (using make for illustration purposes): cd make etc-diff # ensure your workspace reflects what is in /etc make import # import the latest /usr/src/etc into etc workspace make diff # look over the changes make install # install to /etc; do mkdb etc. Finally: make commit # commit changes to local repo OR make undo # if things didn't quite work, restore /etc to old state. Roughly, the current mergemaster does the work of make import, make diff, repairs and install. Comments? -- bakul From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 1 21:00:35 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 A9BE716A424 for ; Sat, 1 Oct 2005 21:00:35 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5639443D7B for ; Sat, 1 Oct 2005 21:00:22 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j91KvNlL067560; Sat, 1 Oct 2005 14:57:23 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 01 Oct 2005 14:58:07 -0600 (MDT) Message-Id: <20051001.145807.69698496.imp@bsdimp.com> To: bakul@BitBlocks.com From: "M. Warner Losh" In-Reply-To: <200510012034.j91KYWPQ064132@gate.bitblocks.com> References: <20050930150105.GA55158@comp.chem.msu.su> <200510012034.j91KYWPQ064132@gate.bitblocks.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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 01 Oct 2005 14:57:23 -0600 (MDT) Cc: freebsd-hackers@freebsd.org Subject: Re: A smarter mergemaster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2005 21:00:35 -0000 In message: <200510012034.j91KYWPQ064132@gate.bitblocks.com> Bakul Shah writes: : Here is an idea for the mergemaster hackers' consideration! : : By keeping /etc files in a source repository one can archive : and document all local changes. This is useful for some of : the same reasons for which we keep sources in a repo: : recovery from mistakes, reuse of old code, checking who did : what, more than one person can make changes, tracking : history, debugging etc. : : If mergemaster handled or worked with a local cvs /etc repo : that'd be very nice! The idea is to make changes and test : them in a temp workspace and commit them *only if they do the : right thing*! I envision a workflow something like this : (using make for illustration purposes): : : cd : make etc-diff # ensure your workspace reflects what is in /etc : : : make import # import the latest /usr/src/etc into etc workspace : make diff # look over the changes : : make install # install to /etc; do mkdb etc. : : : Finally: : make commit # commit changes to local repo : OR : make undo # if things didn't quite work, restore /etc to old state. : : Roughly, the current mergemaster does the work of make : import, make diff, repairs and install. : : Comments? I implemented something very similar to this for maintaining all the etc files at Timing Solutions. We have a tree that gets installed over the base OS. However, it doesn't easily allow for a mergemaster step since it installs all the files with schg set, and doesn't have three way merge in potential. Doing the makefile goo is relatively easy, but the merging was much harder. Wanrer From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 1 21:09:50 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 E876816A42A for ; Sat, 1 Oct 2005 21:09:50 +0000 (GMT) (envelope-from mwm-keyword-hackers.e471b2@mired.org) Received: from delight.idiom.com (outbound.idiom.com [216.240.47.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DC3443D48 for ; Sat, 1 Oct 2005 21:09:50 +0000 (GMT) (envelope-from mwm-keyword-hackers.e471b2@mired.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id 0A39A225C54 for ; Sat, 1 Oct 2005 14:09:50 -0700 (PDT) Received: from mired.org (mwm@idiom [216.240.32.1]) by idiom.com (8.12.11/8.12.11) with SMTP id j91L9mkl017519 for ; Sat, 1 Oct 2005 14:09:49 -0700 (PDT) (envelope-from mwm-keyword-hackers.e471b2@mired.org) Received: (qmail 67586 invoked by uid 1001); 1 Oct 2005 21:10:24 -0000 Received: by localhost.mired.org (tmda-sendmail, from uid 1001); Sat, 01 Oct 2005 17:10:24 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17214.64320.220113.792951@bhuda.mired.org> Date: Sat, 1 Oct 2005 17:10:24 -0400 To: Bakul Shah In-Reply-To: <200510012034.j91KYWPQ064132@gate.bitblocks.com> References: <20050930150105.GA55158@comp.chem.msu.su> <200510012034.j91KYWPQ064132@gate.bitblocks.com> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" 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 Cc: freebsd-hackers@freebsd.org Subject: Re: A smarter mergemaster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2005 21:09:51 -0000 In <200510012034.j91KYWPQ064132@gate.bitblocks.com>, Bakul Shah typed: > Here is an idea for the mergemaster hackers' consideration! > > By keeping /etc files in a source repository one can archive > and document all local changes. This is useful for some of > the same reasons for which we keep sources in a repo: > recovery from mistakes, reuse of old code, checking who did > what, more than one person can make changes, tracking > history, debugging etc. Yup. I've been doing that for about a decade. It also makes a nice tool for disaster recovery. Rather than backing up all the FreeBSD-supplied softare, I back up the repository. After a disk loss, I pull the original install disks, reinstall, then check out the config files from the repository. > If mergemaster handled or worked with a local cvs /etc repo > that'd be very nice! The idea is to make changes and test > them in a temp workspace and commit them *only if they do the > right thing*! I envision a workflow something like this > (using make for illustration purposes): It really ought to provide hooks of some kind for dealing with the repository, rather than having CVS wired into it, as some of us prefer newer tools to CVS. But that's a minor detail. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 1 21:45:51 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 BD4C316A41F for ; Sat, 1 Oct 2005 21:45:51 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 929D443D72 for ; Sat, 1 Oct 2005 21:45:50 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j91LjgsL013885; Sat, 1 Oct 2005 14:45:47 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200510012145.j91LjgsL013885@gw.catspoiler.org> Date: Sat, 1 Oct 2005 14:45:42 -0700 (PDT) From: Don Lewis To: apelisse@gmail.com In-Reply-To: <61c746830509300224g3d79cbe4ve55e8b0b27004fc3@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-hackers@FreeBSD.org Subject: Re: freebsd-5.4-stable panics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2005 21:45:51 -0000 On 30 Sep, Antoine Pelisse wrote: > Hi Robert, > I don't think your patch is correct, the total linked list can be broken > while the lock is released, thus just passing the link may not be enough > I have submitted a PR[1] for this a month ago but nobody took care of it yet There are two problems with your patch: sched_lock needs to be held while iterating over the threads sysctl_kern_proc() calls sysctl_out_proc() multiple times in a loop in the !KERN_PROC_PID case, so the buffer needs to be wired before calling sysctl_out_proc(). Is _PHOLD()/_PRELE() needed if we don't drop PROC_LOCK? Passing a size estimate to sysctl_wire_old_buffer() is desirable, but sysctl_out_proc() would need some restructuring to do this correctly. From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 1 21:48:08 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 97E5616A41F; Sat, 1 Oct 2005 21:48:08 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D35C43D46; Sat, 1 Oct 2005 21:48:08 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j91LlwvB013891; Sat, 1 Oct 2005 14:48:02 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200510012148.j91LlwvB013891@gw.catspoiler.org> Date: Sat, 1 Oct 2005 14:47:58 -0700 (PDT) From: Don Lewis To: jhb@FreeBSD.org In-Reply-To: <200509301310.03124.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-hackers@FreeBSD.org, rwatson@FreeBSD.org, apelisse@gmail.com Subject: Re: freebsd-5.4-stable panics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2005 21:48:08 -0000 On 30 Sep, John Baldwin wrote: > On Friday 30 September 2005 11:25 am, Antoine Pelisse wrote: >> On 9/30/05, John Baldwin wrote: >> > On Friday 30 September 2005 05:24 am, Antoine Pelisse wrote: >> > > Hi Robert, >> > > I don't think your patch is correct, the total linked list can be >> > > broken >> > > >> > > while the lock is released, thus just passing the link may not be >> > > enough I have submitted a PR[1] for this a month ago but nobody took >> > > care of it yet Regards, >> > > Antoine Pelisse >> > > >> > > [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84684 >> > >> > I think this patch looks ok. Robert, can you get the original panic on >> > this >> > thread tested against this patch? >> >> I had a small program which could reproduce this panic in 10 seconds, it >> was basically creating empty threads and calling kvm_getprocs() in the same >> time. Anyway the patch was able to stop the program from panicing. >> The panic is also reproducible in RELENG_6 and HEAD IIRC. > > It turns out that the sysctl buffer is already wired in one of the two cases > that this function is called, so I moved the wiring up to the upper layer in > the other case and cut out a bunch of the locking gymnastics as a result. > Can you try this patch? > > Index: kern_proc.c > =================================================================== > RCS file: /usr/cvs/src/sys/kern/kern_proc.c,v > retrieving revision 1.231 > diff -u -r1.231 kern_proc.c > --- kern_proc.c 27 Sep 2005 18:03:15 -0000 1.231 > +++ kern_proc.c 30 Sep 2005 17:04:57 -0000 > @@ -875,22 +875,16 @@ > > if (flags & KERN_PROC_NOTHREADS) { > fill_kinfo_proc(p, &kinfo_proc); > - PROC_UNLOCK(p); > error = SYSCTL_OUT(req, (caddr_t)&kinfo_proc, > sizeof(kinfo_proc)); > - PROC_LOCK(p); > } else { > - _PHOLD(p); > FOREACH_THREAD_IN_PROC(p, td) { > fill_kinfo_thread(td, &kinfo_proc); > - PROC_UNLOCK(p); > error = SYSCTL_OUT(req, (caddr_t)&kinfo_proc, > sizeof(kinfo_proc)); > - PROC_LOCK(p); > if (error) > break; > } > - _PRELE(p); > } > PROC_UNLOCK(p); > if (error) > @@ -932,6 +926,9 @@ > if (oid_number == KERN_PROC_PID) { > if (namelen != 1) > return (EINVAL); > + error = sysctl_wire_old_buffer(req, 0); > + if (error) > + return (error); > p = pfind((pid_t)name[0]); > if (!p) > return (ESRCH); > sched_lock needs to be grabbed before the FOREACH_THREAD_IN_PROC loop. Can _PHOLD()/_PRELE() be dropped? From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 1 22:16:15 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 76D7E16A41F for ; Sat, 1 Oct 2005 22:16:15 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from gate.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 345B543D45 for ; Sat, 1 Oct 2005 22:16:15 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by gate.bitblocks.com (8.13.4/8.13.1) with ESMTP id j91MG7IE064664; Sat, 1 Oct 2005 15:16:07 -0700 (PDT) (envelope-from bakul@bitblocks.com) Message-Id: <200510012216.j91MG7IE064664@gate.bitblocks.com> To: "M. Warner Losh" In-reply-to: Your message of "Sat, 01 Oct 2005 14:58:07 MDT." <20051001.145807.69698496.imp@bsdimp.com> Date: Sat, 01 Oct 2005 15:16:07 -0700 From: Bakul Shah Cc: freebsd-hackers@freebsd.org Subject: Re: A smarter mergemaster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2005 22:16:15 -0000 > : cd > : make etc-diff # ensure your workspace reflects what is in /etc > : > : > : make import # import the latest /usr/src/etc into etc workspace > : make diff # look over the changes > : > : make install # install to /etc; do mkdb etc. > : > : > : Finally: > : make commit # commit changes to local repo > : OR > : make undo # if things didn't quite work, restore /etc to old state. > : > : Roughly, the current mergemaster does the work of make > : import, make diff, repairs and install. > : > : Comments? > > I implemented something very similar to this for maintaining all the > etc files at Timing Solutions. We have a tree that gets installed > over the base OS. > > However, it doesn't easily allow for a mergemaster step since it > installs all the files with schg set, and doesn't have three way merge > in potential. mergemaster just has to do a merge in a temp workspace (initially a copy of /etc). Makefile can do all the schg magic when it installs to /etc. But this can get messy and I don't have a clean model.... One would have to keep Freebsd's /usr/src/etc in a vendor branch and do a checkout -j or something. When there is no conflict, an update goes very fast. In case of conflicts perhaps one can use the interactive merge feature from mergemaster. For files of same name but with entirely different content, merge with the vendor branch needs to be avoided. Basically anything we can do to make it easy to use this "best practice" would be nice.... even nicer if it covers /usr/local/etc!